Collections: which steps to automate, which stay with people, and the data each needs

Software can already sort delinquent balances, send reminder letters, match incoming payments to invoices and apply them in the required order. Negotiation, hardship decisions and write-off approval still need a person. None of it works until customer, invoice and payment records agree.

Where software already carries the load

Analysis of delinquent balances is the easiest win. A system can age every open item, group accounts by size or behaviour and flag the ones that broke a promise to pay. Machine learning models can rank accounts by likelihood of payment, so collectors start each day on the calls that matter. This is arithmetic and pattern matching. Nobody should be building it by hand in a spreadsheet.

Cash application comes next. Matching a receipt to the right invoice and payer account is mechanical when remittance detail is clean. The system can also apply each payment in the order policy demands, typically penalties first, then administrative costs, then interest, then principal. A returned check needs automation too. The original application should reverse, the balance should reopen and the account should re-enter the collection cycle without a clerk noticing it days later.

Routine correspondence also belongs to software. Dunning letters, payment links and confirmation notices can go out on a schedule tied to account status. Generative AI can draft replies to common emails, such as a request for an invoice copy or a statement. A collector should review those drafts before anything involving a dispute or a threat of legal action leaves the building.

Where a person has to stay involved

Policy for delinquent accounts is a management decision. A system can enforce thresholds and escalation rules, but someone has to decide what they are and defend them to auditors, customers and the sales team.

Negotiation stays human. A customer in genuine difficulty needs a payment plan built around their situation. A customer gaming the process needs firmness. Telling the two apart over a phone call is judgment, and the consequences land on the relationship for years.

Internal resolution is political as much as procedural. Sales may want an account left alone during a renewal. Service may know the customer is withholding payment over a real defect. Legal may need to weigh in. Software can route the case and record the outcome. It cannot broker the conversation.

Adjustments and write-offs need an approver with authority. Automation can prepare the entry, attach the evidence and post it once approved. The decision to stop pursuing money owed belongs to a named person.

Recovery workout and default accounts carry legal and reputational weight. Choosing between restructuring, referral to an outside agency and litigation depends on facts a model rarely sees, such as the debtor's other creditors or the cost of a court fight.

What has to be true about the data first

Each customer must exist once. Duplicate accounts, or parent and subsidiary entities that nobody has linked, make aging reports misleading and send letters to the wrong place.

Disputes must be flagged on the invoice itself. If a disputed item looks like an ordinary late one, automated reminders will harass a customer who is waiting on a credit note, and the account will escalate for the wrong reason.

Remittance information has to reach the system in a readable form. Payments that arrive without invoice references end up in an unapplied cash queue, and every downstream step inherits the error.

Contact history needs a single home. When promises to pay live in a collector's notebook or personal inbox, no model can learn from them and no colleague can pick up the account.

Finally, the written policy must match the rules configured in the system. Gaps here are common. The configured escalation often reflects an old version of the policy that was never updated.

Questions to ask the people who run collections

What the procedure manual describes and what the team actually does often diverge. These questions surface the difference.

• Which accounts do you never chase, and who told you not to?
• When a payment arrives without a reference, what do you do with it, and how long does it sit before someone looks?
• Where do you record a promise to pay?
• Which customers get a phone call before any letter goes out, and why?
• How do you find out an invoice is disputed?
• Who really approves a write-off, and does that match the authority limits on paper?
• What happens to an account after a check bounces?
• When you hand an account to an agency or to legal, what information travels with it, and what gets lost?
• Which report do you trust least?

The answers usually reveal informal rules worth keeping, workarounds that hide a data problem and approvals that exist only by habit. Each of those has to be settled before any of it is encoded in software.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.