Cash application via remittance parsing

A proposed match is ready when it names the remittance line it came from and the open invoice it points at. If the remittance cannot be parsed, that proposal stays empty. Do not invent an invoice number to fill the gap. Cash application still posts the receipt.

That split is the work. Parsing turns an email body, a PDF attachment, or an EDI remittance into lines a matcher can test. Matching tests those lines against open AR and returns a cite or nothing. Posting is a later, separate act that belongs to cash application, not to the parser.

Lockbox and ERP cash-app products in this class, including HighRadius, Artsyl, Workday, and SAP, all sit on some version of extract, propose, then post. Their screens and workflows differ. The quality bar does not: a match that cannot show both cites is not a match.

Cash-application leads get into trouble when those three steps collapse into one. A clean parse is not applied cash. An invoice number that looks right is not a cite if it is not on the remittance. A remainder with no invoice reference is unapplied cash, not a deduction you get to label.

Start from the artifact the customer actually sent, not from the bank amount. The bank amount tells you cash arrived. The remittance tells you how they meant it to land. Those two facts are related and they are not the same.

Work the common sources in a fixed order so operators know where a line came from:

1. Structured remittance (EDI 820, lockbox BAI addenda, portal CSV) when it is present and complete.
2. PDF or image remittance, including check stubs and emailed advice.
3. Email body text when the advice is only in the message.
4. Nothing. If none of those yield a line you can quote, stop. Empty stays empty.

For each extracted line, keep the raw span you used: invoice token, amount, and any discount or deduction text as written. That span is the remittance cite. If you cannot highlight it on the original artifact, you do not have a parse for that line.

Do not normalize away ambiguity. "INV 44102" and "44102" are different evidence. "Balance" and "short pay, freight" are different evidence. The matcher needs the customer's words, not a cleaned guess.

Short-pay and deduction language is especially easy to over-interpret. If the remittance does not state a reason, do not invent one so the line looks complete. An unexplained remainder is unmatched cash, not a coded deduction.

Invoice numbers that never appear on the remittance are out of scope for this step. If you need a cleaner invoice before it ever hits AR, that belongs upstream in an invoice pre-flight check, not in remittance parsing.

Matching is a lookup against open AR, not a search for the nearest invoice that would absorb the cash.

For each parsed line, require:

• The remittance cite (the span on the advice).
• An open invoice whose number matches that span, or a documented alias your AR master already holds.
• Amount agreement, or an explicit remainder that you leave unmatched rather than force-fitting.

If the invoice is closed, do not propose the match. Applying cash to a closed invoice looks efficient in the queue and creates a reversal later. The closed invoice is not a valid target, even when the remittance names it correctly. Route that line to unmatched, or to a duplicate-payment review, instead of auto-applying it.

If two open invoices could fit the same token, do not pick. Ambiguous matches stay unmatched until a person chooses. Auto-picking the oldest open invoice is how you apply a payment meant for a replacement invoice onto the original.

One worked example, not a measured result. A $28,150 ACH lands with a PDF remittance. Line 1 cites INV-44102 for $12,400. Line 2 cites INV-44118 for $8,750. Line 3 is the leftover $7,000 labeled only "balance." Open AR shows INV-44102 still open at $12,400. INV-44118 is closed; it was applied last week. No open invoice is named for the remainder.

The proposed matches are remittance line 1 to open INV-44102, both cites named. Line 2 is not proposed against the closed invoice. Line 3 stays empty because there is no invoice number to invent. Cash application still posts the $28,150 receipt. Unapplied cash holds the closed-invoice amount and the unnamed remainder until someone decides.

That is the quality outcome. The proposal is a cite pair or it is blank. The receipt is not waiting on a perfect parse.

When a remittance names invoices that sit on a promised date rather than a due date, do not let the promise rewrite the match. A promise-to-pay tracker is useful for collections follow-up. It is not a substitute for an invoice number on the advice.

Empty is a valid result. The parser failed, the invoice is closed, the amount disagrees without a stated split, or the remainder has no identifier. In all of those cases the line stays unmatched.

What you must not do:

• Invent an invoice number because the customer always pays that account that way.
• Treat a high-confidence parse as posted cash before cash application runs.
• Code a short-pay reason the remittance did not give you.
• Apply the leftover to the oldest open invoice to clear the batch.

Unmatched cash is visible work. False application is hidden work plus a correction. Cash-application leads should treat unmatched volume as a queue, not as a defect to zero out by guessing.

Duplicate-looking remittances belong in review, not in a second apply. If the same invoice number and amount appear against a receipt that already applied, send the line to duplicate and fraud detection rather than stacking another application.

Partial advice is common: one PDF covers three invoices and the fourth is "as discussed." The three citable lines can match. The fourth cannot. Do not complete the fourth from tribal knowledge inside the parsing step.

Cash application posts the bank receipt whether or not every remittance line matched. The deposit is real. The advice may be incomplete. Holding the entire receipt unposted because one line failed is how lockbox backlogs start.

The posting rule is:

1. Post the receipt to cash.
2. Apply only the proposed matches that carry both cites.
3. Park the rest as unapplied on that receipt.
4. Do not reverse or delay the post because parsing was incomplete.

Operators then work the unapplied remainder with the original remittance still attached. They can ask the customer, wait for a corrected advice, or apply manually with a human cite. None of that is the parser's job.

Do not let a payment-date prediction stand in for remittance. A predicted pay date can help you staff the lockbox. It cannot name the invoice the customer intended.

The failure mode that looks like speed is treating the parse as the post. A dashboard that counts parsed files is not a dashboard that shows cash applied. Parsed but unposted, and parsed and wrongly applied, are different problems. Only the second one quietly corrupts AR.

Keep the human loop on empty proposals and on amount breaks. Keep the machine loop on cite pairs against open invoices. Cash still posts. Empty stays empty. No invented invoice numbers.