AR automation: cash application and collections that learn

Cash application is a matching problem: link each incoming payment to the invoices it settles. Collections is a prioritisation problem: decide which open accounts to work and when. Both automate well once you put deterministic rules under a ranking model and route the uncertain cases to a review queue. Skip that queue and you manufacture reconciliation breaks that surface at quarter-end.

Cash application is entity resolution wearing a finance hat

Start with what actually blocks straight-through processing. A bank feed gives you an amount, a value date, a payer name that is often a truncated or transliterated version of the legal entity, and a memo field that may or may not carry invoice numbers. Your AR ledger holds open invoices per customer, credit notes, and disputes. Applying cash means linking one side to the other, and the failure mode is the one that breaks any entity resolution job: the string you have does not equal the string you stored.

Build it in layers, cheapest first.

• Deterministic rules clear the easy volume. Exact invoice number in the memo, exact amount against a single open item, a standing payer-to-customer mapping. These run before any model touches the payment, and they should be logged so you can see what fraction of cash never needed intelligence.
• Fuzzy matching handles the near-misses. Amount within tolerance, invoice number with a transposed digit, payer name resolved to a customer through a maintained alias table rather than raw edit distance. Keep the alias table as data, not as model weights, so a clerk can correct it and the correction sticks.
• A ranking model handles the genuinely ambiguous. When a payment could plausibly settle several combinations of open invoices, the model scores candidate allocations using the customer’s historical payment pattern, typical short-pay behaviour, invoice age, and whether this payer usually batches. It returns ranked candidates with scores, and a person picks among them.

Point-in-time discipline matters here more than people expect. When you train on historical applications, every feature has to reflect what was knowable at the moment the payment landed. Build a feature like “customer’s average days to pay” from invoices that only settled after this payment, and you have leaked the future into training. The model will look excellent in backtest and disappoint in production. Compute features from a snapshot as of the value date, and store them so the same values are reproducible at scoring time and at audit.

The review path is the product, not a fallback

Auto-applying cash you are unsure about is how you create breaks that a reconciler has to chase three weeks later. So the threshold is the design decision. Set a false-positive budget the controller signs off on: how many wrong auto-applications per thousand is acceptable, given what it costs to unwind one. Calibrate the confidence threshold to that budget on a held-out eval set of real historical payments, then auto-apply only above it.

Everything below the line lands in a queue, and the queue should be fast to work:

• Each unapplied payment shows its top three candidate allocations with scores and the reason each scored where it did.
• The clerk confirms or overrides in one action, and that decision becomes a labelled example for the next training round.
• Overrides are the most valuable data you have. They tell you exactly where the model is wrong, and clustering them usually points to a fixable cause: a new payer name variant, a customer who changed remittance habits, a currency edge case.

Keep an audit trail on every applied payment, whether a rule, a model, or a human applied it: which candidate won, what score it had, who confirmed it, and the feature snapshot behind it. When someone in a control review asks why a payment landed on that invoice, the answer should already be on file.

Collections learns from what the last email actually did

Cash application decides where money goes. Collections decides where attention goes, and most teams still allocate attention by balance size or by a fixed dunning calendar. That wastes effort on accounts that would have paid anyway and starves the accounts where a nudge moves the date.

A useful collections model predicts days-to-pay for each open item and estimates the lift from contacting now versus waiting. Rank the book by that expected effect, not by exposure. The features that carry signal:

• The customer’s own payment history, including how they responded to prior reminders.
• Invoice age relative to that customer’s normal pattern rather than an absolute bucket.
• Disputes or credit notes open against the account, which usually explain a stall better than any behavioural feature.
• Seasonality around the customer’s own close, since much “late” payment is really their AP cycle.

Watch for drift. A collections model trained on last year’s behaviour degrades when rates move, when a large customer restructures its payables, or when your own dunning policy changes and retrains the customers. Monitor the gap between predicted and actual days-to-pay by segment, and treat a widening gap as a retraining trigger instead of waiting for the scheduled cycle. Feed applied-cash outcomes straight back: an invoice the model flagged as at-risk that then cleared on its own is a labelled example telling you the ranking was too aggressive. The same lineage that supports cash application makes that feedback loop cheap to run.