Cash application without the spreadsheet
Cash application is two puzzles at once: which invoices does this remittance pay, and has the money actually arrived? Most AR teams solve both by hand, in a spreadsheet, every morning. We replaced four separate remittance tools with one console that does both.
Two puzzles every morning
A customer pays twelve invoices with one ACH and emails a remittance listing them, with two short-pays for damage and a co-op deduction. Another mails a check whose stub is a photocopy. A big-box retailer posts a remittance file to a portal days before the money lands. Meanwhile the bank reports deposits with a name and an amount and nothing else.
Someone in AR has to put each remittance together with the right deposit and the right invoices, decide what each deduction is, and post it. When that takes all morning, it doesn’t get done every morning, and the receivables report stops being true.
What it costs when it lags
- Invoices that look unpaid. Customers get collection calls for invoices they paid last week.
- A borrowing base that’s wrong. Unapplied cash and stale receivables distort what you can borrow against.
- Deductions nobody disputes. A short-pay applied without a reason code is margin given away without a decision.
- Double posting. A remittance that says “check” for a payment that actually arrived by ACH gets posted twice if two people work it.
How the console works
- Intake. Every message to the AR mailbox is pulled automatically, de-duplicated and staged. Portal exports and retailer files are dropped in.
- Read. Known retailer formats go through their existing, proven parsers. Everything else is read by AI into structured lines: payer, reference, amount, invoices, deductions and reasons.
- Learn. When AR corrects how an unfamiliar customer’s remittance was read, the console remembers it for that customer.
- Match to invoices by invoice and PO number, flagging already-paid, duplicate and short-paid invoices.
- Match to the bank. The prior-day bank file is loaded, and each remittance is tied to the deposit that actually paid it. Cash with no remittance and remittances with no cash each get their own queue.
- Preview, post, verify. One payment per deposit, credit memos for deductions, the remittance attached to the payment as a PDF, and a check afterwards that everything landed.
A payment isn’t applied until you know the money is in the bank.
The judgment it encodes
- Paper checks wait. A check remittance doesn’t move to “ready” until the deposit shows up or someone confirms it arrived.
- Labels aren’t trusted blindly. A customer who has paid electronically in nearly every payment for a year, but whose remittance says “check number”, is treated as electronic. A person can always override.
- The payment date is the bank date, not the date printed on the remittance, so cash reports and aging agree with the bank.
- Card payments aren’t posted here; they belong to the card process.
What changed
Four separate remittance tools became one screen with one daily routine: load the bank file, work the exceptions, post what’s ready. The team posts the morning’s remittances before mid-morning, every payment carries its remittance, and the queues make the problems — cash with no remit, remits with no cash — visible instead of buried.
The matching rules that make this safe are in the companion piece.
Related: five rules for matching remittances to the bank, and the 13-week cash forecast.