Cash Application: Matching Customer Payments and Remittance Advices to Open Invoices for Every Client
The money is in the bank, the invoices are still open, and the client is about to send a past-due reminder to a customer who paid two weeks ago. For a bookkeeping firm that keeps receivables for dozens of clients, cash application is where that happens: deposits that land without a clear link to the invoices they pay. This post covers how to apply every payment from the remittance advice, including the awkward ones.
In brief
- Cash application is the step that turns a customer deposit into closed invoices; until it is done, the AR aging shows paid invoices as open and the client chases customers who already paid.
- The bank line tells you how much arrived and from whom, but only the remittance advice says which invoices the payment covers and why it is short.
- Most difficult payments are one of four shapes: one payment for many invoices, a short payment with deductions, a payment with no remittance, or a payment from a party other than the customer.
- A short payment should be split into what was paid and what was deducted, with each deduction coded to a reason, rather than left as a partially open invoice.
- Unapplied cash should be a short, dated list reviewed every week, never a balance that grows quietly until year end.
Why unapplied cash causes real damage
When a customer payment is posted to the bank but not applied to invoices, the books are half right. Cash is correct and revenue was already recognized when the invoice went out, so the profit and loss looks fine. The damage is in accounts receivable. The aging report still shows the paid invoices as open, the customer account carries an unapplied credit next to them, and anyone reading the aging sees a receivable balance that is too high and too old.
That wrong aging drives wrong actions. The client sends reminders for invoices that were paid, which irritates good customers. A lender reading the borrowing base sees inflated receivables. The bad debt reserve is sized against invoices that are not really outstanding. And at year end someone has to reconstruct months of deposits from bank statements and email, which is the most expensive way to do the work.
For a bookkeeping firm the problem compounds across a portfolio. Each client has its own customers, its own payment terms and its own habits for sending remittance details, and the firm sees all of them through the same narrow window: a bank feed line with an amount, a date and a truncated payer name.
5
payment shapes covered in this post
3
documents behind every applied payment: bank line, remittance, open invoices
7
steps in the cash application checklist below
What the bank line does not tell you
A bank line answers two questions: how much arrived, and roughly from whom. It does not say which invoices the payment covers. When a customer pays one invoice for its exact amount, that is enough, because only one open item matches. As soon as the customer pays several invoices at once, or pays less than the invoice total, the amount alone stops being unique and the bank feed cannot settle it.
The remittance advice fills the gap. It lists each invoice number, the amount applied to it and any deduction taken, with a reason. It arrives in whatever form the customer's payment system produces: a PDF attached to an email, a stub printed with a check, a portal download, or a line of text squeezed into the transfer reference. The same customer can send a different layout from one month to the next, and a firm with forty clients may see hundreds of layouts in a year.
So cash application is really a document problem. The matching rules are simple once each remittance is read into the same fields; the time goes into reading them.
The five shapes a payment takes
Most payments fall into a small number of patterns, and each needs a different rule. Sorting them first keeps the easy ones automatic and puts the review time where it belongs.
Exact and multi-invoice payments
A payment equal to one open invoice for the same customer applies directly. A payment for several invoices applies line by line from the remittance advice, and the check is that the lines add up to the bank amount. Without a remittance, a multi-invoice payment can sometimes be solved by finding the set of open invoices that sums to the amount, but when two sets fit, the guess should go to a person.
Short payments
A short payment pays less than the invoice and usually says why: an early payment discount, a return, a pricing difference, damaged goods, or a deduction for a late delivery. The discount is easy to verify against the terms and the invoice date, the same arithmetic covered in the post on early payment discounts, seen from the other side. Other deductions need support: a credit memo the client issued, or a dispute the client has to accept or reject.
No remittance, or a different payer
Some payments arrive with nothing but an amount. Others come from a parent company, a factoring company or a customer's payment processor, under a name that matches no customer record. Both should be parked as unapplied with a date and an owner, and the client asked one specific question, never left to sit.
One payment, one invoice, exact
One payment, many invoices
Short payment with deductions
No remittance advice
Paid by a third party
A worked example: one deposit, three invoices
Take an illustrative client with 2/10 net 30 terms. A deposit of 18,412.50 arrives from a payer called customer-b holdings. The client has three open invoices for its customer, customer-b: 9,600.00, 6,250.00 and 3,200.00, which total 19,050.00. The bank line alone leaves 637.50 unexplained and no way to tell which invoice is short.
The remittance advice, a PDF the customer emailed, settles it. The customer paid the first invoice within ten days and took the 2 percent discount, 192.00. It deducted 445.50 from the second invoice for damaged goods, citing its own debit memo. The third invoice was paid in full. The three lines sum to the deposit, so the payment applies cleanly, and the review is narrowed to two questions: has the client issued a credit memo for the damaged goods, and is customer-b holdings really the parent of customer-b.
{ "client_id": "client-0142", "bank_line": { "date": "2026-10-14", "amount": 18412.50, "payer": "customer-b holdings", "reference": "PMT 88214" }, "remittance_advice": { "payer": "customer-b holdings", "payment_reference": "PMT 88214", "payment_date": "2026-10-13", "lines": [ { "invoice_number": "INV-3301", "invoice_amount": 9600.00, "paid": 9408.00, "deduction": 192.00, "reason": "2% early payment discount" }, { "invoice_number": "INV-3317", "invoice_amount": 6250.00, "paid": 5804.50, "deduction": 445.50, "reason": "damaged goods, debit memo DM-771" }, { "invoice_number": "INV-3322", "invoice_amount": 3200.00, "paid": 3200.00, "deduction": 0.00, "reason": null } ], "total_paid": 18412.50 }, "checks": [ { "check": "remittance_total_equals_bank_line", "status": "ties" }, { "check": "invoices_open_for_customer", "status": "ties" }, { "check": "discount_within_terms", "invoice": "INV-3301", "terms": "2/10 net 30", "invoice_date": "2026-10-05", "status": "ties" }, { "check": "deduction_supported", "invoice": "INV-3317", "status": "review", "hint": "No credit memo issued for DM-771; route to client" }, { "check": "payer_matches_customer_record", "status": "review", "hint": "Payer name differs from customer name on invoices; confirm parent company" } ], "requires_review": true}Nothing in that result is a judgment the software makes. The extraction reads the remittance into fields, and the checks are rules the reviewer would run by hand: the total ties to the bank, the invoices are open for that customer, the discount fits the terms. What is left for a person is what only the client can answer.
Recording deductions so they do not come back
The common shortcut is to apply what was received and leave the rest of the invoice open. The aging then fills with small balances nobody can explain six months later. A better rule: every difference gets a reason code at the moment of application.
- Discount taken within terms: written off to sales discounts.
- Return or allowance with a credit memo: applied against the credit memo, so both close.
- Deduction the client accepts: a credit memo issued now, then applied.
- Deduction the client disputes: left open, with the reason and the customer's reference attached, so collections chases the dispute rather than the invoice.
- Overpayment: held as a customer credit and reported to the client, never absorbed into revenue.
Coded this way, deductions become data. A client can see that one customer takes discounts after the discount window every month, or that damage deductions cluster on one product line, and act on it. It is the receivables mirror of the post on matching vendor credit memos to open invoices.
Before clearingAfter clearing
Current
1 to 30 days
31 to 60 days
Over 60 days
Apply from the remittance, not from the amount
Keep unapplied cash short and dated
Some payments will always need a question answered. The control is to keep that list short and visible: each unapplied item with the date received, the amount, the payer as it appeared on the bank line, the question asked and who owns it. Review it weekly with each client, and age it the way receivables are aged. A growing unapplied balance is a sign that remittances are not being collected, often because they go to a mailbox nobody at the firm can see; routing them to one intake address fixes more than any matching rule.
At month end, the receivable subledger should tie to the control account, and the unapplied balance should be explained item by item. That tie-out sits next to the receipt-to-bank matching the firm already does on the spending side.
Cash application: a checklist
- Route every remittance advice for every client to one intake address the firm can read.
- Read each remittance into the same fields: payer, payment reference, date, and per line the invoice number, amount paid, deduction and reason.
- Confirm the remittance total equals the bank line before applying anything.
- Apply line by line to open invoices for that customer, and confirm the payer belongs to the customer record.
- Check discounts against the terms and the invoice date, and code every other deduction to a reason.
- Park payments without a remittance or with an unknown payer as unapplied, with a date, an owner and one specific question to the client.
- At month end, tie the AR subledger to the control account and explain the unapplied balance item by item.
Where extraction fits
The matching rules are short. What does not scale is reading remittance advices in hundreds of layouts for every client, every week. Parser turns each remittance into structured JSON against an extraction template you define, so invoice numbers, amounts and deduction reasons arrive as fields and the application runs on data. Your team's time goes to the deductions and the unknown payers, which is where the client needs judgment. The post on extraction schema design covers how to type the fields so the checks above can run on them.