A customer paid on the 28th. The receipt is still sitting unapplied on the 3rd, so the aging report shows their invoices 30 days past due and a collector has them on today’s call list. Nobody was slow to pay. The delay is between the bank and the ledger, and that delay belongs to cash application.
This guide covers how to match receipts reliably, what to do with money you cannot place, how four ERPs behave at the points where automation usually breaks, and what to measure.
Three records, three questions
Every application decision uses three records. Put them side by side before you apply anything.
| Record | Question it answers | What it cannot tell you |
|---|---|---|
| Bank line | What arrived, when, from whom, in what currency | Which invoices it pays |
| Remittance advice | What the payer intended to settle | Whether the money actually arrived |
| Open items | What the customer owes you | What the customer believes they owe |
When all three agree, application is clerical. The work is in the cases where they disagree.
Decide by case, not by rule of thumb
| Case | What to do |
|---|---|
| One payment names several invoices | Check that the listed allocations add up to the payment, then apply them |
| Payment is short and the remittance gives a reason | Apply the supported amount; open a claim for the difference with the reason |
| Payment is short with no reason | Apply what the remittance supports; ask the customer for the claim detail |
| Payer known, no invoice reference | Search that customer’s open items; request remittance if more than one could match |
| Two open invoices for the same amount, neither named | Do not guess. Ask for the reference before applying |
| Payment exceeds the invoice | Decide whether it is an overpayment or an advance on a future invoice, and record why |
| Payer unknown | Keep it in the unidentified queue until you establish who paid |
Worked example: a bundled payment with a deduction (illustrative)
A customer sends $14,350 with a remittance listing three invoices: $5,000, $6,200, and $3,400, which total $14,600. The remittance notes a $250 freight deduction against the third invoice.
- Apply $5,000 to invoice one and $6,200 to invoice two. Both close.
- Apply $3,150 to invoice three ($3,400 − $250). It stays open for $250.
- Total applied: $5,000 + $6,200 + $3,150 = $14,350, which ties to the bank line.
- Open a claim record for the $250 with the invoice line, the remittance, and the shipping terms, and route it to whoever can confirm who owed freight.
Applying the cash and deciding whether to accept the deduction are separate actions with separate owners. The journal entry for the application is simply a debit to cash and credits to receivables for $14,350. Any credit memo for the $250 comes later, only if the claim is approved. The deductions guide covers that decision.
Get the remittance attached before you match
A match usually fails because the remittance is missing, not the money. The bank line arrives on time; the explanation of what it pays arrives later, somewhere else. Remittance can come as a check stub in the lockbox image, an email to a shared inbox, a PDF in the customer’s AP portal, a structured EDI message, or a reference squeezed into the bank memo field. Each source needs a place where it gets attached to the right bank line.
Work through candidates in a fixed order of evidence, strongest first:
- Invoice numbers named on the remittance, with amounts that add up to the receipt.
- Invoice numbers in the bank memo field, checked against the customer on the bank line.
- Customer plus exact open amount, accepted only when one open item matches.
- Customer plus a combination of open items that sums to the receipt, treated as a proposal for a reviewer, never auto-applied when more than one combination works.
Anything below that line is a guess. Record which level of evidence supported each application, so a reviewer can sample the weaker ones and an auditor can see why cash landed where it did.
Give each kind of unresolved money its own owner
Leftover money falls into at least four queues, each with a different owner.
- Payer unidentified. Cash application traces the bank reference and requests supporting detail.
- Customer known, invoice unclear. The account owner requests remittance; collectors see that a receipt is pending so they hold reminders.
- Invoice identified, amount disputed. Apply the supported amount; the dispute owner gets the difference.
- Application approved, posting failed. The system owner gets the error; someone verifies the ledger before any retry.
Take a receipt that has been open for a week and test this. Give the queue owner its bank reference and see whether they can tell who touched it last, what evidence is missing, and who can supply it. If they cannot, the queue is a parking lot.
Many systems also distinguish cash left unapplied from cash placed on account against the customer. Oracle Fusion documents both outcomes under its AutoCash remaining-remittance setting. Confirm which status your team uses and make sure collectors can see it. Oracle’s AutoCash documentation. For parent-company and consolidated remittances, see the unapplied cash guide.
How this works in NetSuite, Oracle Fusion, Sage Intacct, and Sage 300
NetSuite: check for an existing payment first
An imported bank line can represent a new customer payment or one someone already entered by hand. Oracle documents both payment generation from bank lines and application to open invoices. Oracle’s payment generation guide.
- Check whether it is already recorded. If a customer payment exists, use the bank matching workflow for that transaction instead of generating another.
- Compare remittance to invoice list. Check the proposed amount on each invoice.
- Keep short payments visible. Record the supported application and give the difference to whoever can confirm it is a deduction.
- Check the result. Confirm the payment amount, the invoices applied, and any open balance, then reconcile to the imported line.
Oracle notes that an imported line drops off the Automated Cash Application page once an existing transaction is matched and submitted. Test one already-posted receipt and one new receipt so you know where each result lands. Oracle’s guide to imported bank lines.
Oracle Fusion: failed validation is not the same as unidentified
When a lockbox batch leaves cash unresolved, find out first whether the receipt passed validation.
| What you see | What to check |
|---|---|
| Receipt failed validation | Compare the error with the original transmission. For a currency error, verify currency and conversion data before correcting the batch. |
| Receipt is unidentified | Use bank reference and remittance to confirm customer and site |
| Customer known, invoice unclear | Compare remittance to open transactions; keep unconfirmed amounts visible |
Oracle documents that lockbox can mark a receipt unidentified when it cannot match the customer, while an undetermined conversion rate can cause validation to fail. Oracle’s lockbox validation guide. Keep transmission totals beside the receipt register. On a corrected transmission, reconcile only the previously failed row. If the original run already created a receipt, resolve that one instead of creating a second.
Sage Intacct: overpayments, advances, and entity
A $1,000 receipt arrives against an $800 invoice. Before assigning the $200, decide whether the customer overpaid or sent an advance for a future invoice, and record the reason.
In Receive Payments, at the top level of a multi-entity shared environment, the overpayment location must match either the receiving bank’s location or the invoice’s location. Confirm bank, invoice, and overpayment location before saving. Sage’s Receive Payments documentation. Sage also documents full or partial invoice payments and applying advances once an invoice exists. Selecting invoices for payment · Customer advances.
Sage 300: apply the posted document, don’t re-enter it
The money posted yesterday; the invoice reference arrived today. In Sage 300’s classic A/R, use Apply Document in Receipt Entry against the posted receipt or unapplied cash document. Select the invoice the remittance supports, enter a partial amount if needed, and post the batch to update the accounts. Sage also documents an Auto Apply option that uses the earliest due date. If the customer named a different invoice, override it. Sage’s Apply Document instructions.
Duplicates and failed postings
Automation creates a specific risk: retrying a write that partly succeeded. Before any retry, the operator must be able to answer “does a payment already exist for this bank line?” Test it in a sandbox by interrupting a posting and retrying. The correct result is one payment. Include a remittance that arrives twice, and an already-posted receipt that someone imports again.
Measure the backlog, not only the match rate
A higher auto-match rate means little if corrections rise with it. Track:
- Time from bank receipt to application, by payment channel
- Unapplied amount by age bucket, at each week-end
- Applications reopened or reversed after review
- Share of proposed matches a reviewer accepted, corrected, or rejected
Sample both accepted and rejected matches. Every applied amount should trace to a bank line, a customer, and an invoice. Compare the same payment channels before and after a pilot. The AR pricing and ROI guide shows how to turn those measurements into a business case, and bank reconciliation automation covers the bank side of the same tie-out.
Daily cash application checklist
- Bank lines for the day imported; totals tie to the bank statement.
- Each line checked for an existing payment before a new one is created.
- Remittances attached to their bank lines; missing ones requested.
- Allocations add up to the bank amount on every multi-invoice receipt.
- Short pays split: cash applied, claim opened with reason and owner.
- Unidentified, unapplied, and on-account items each have an owner and a next action.
- Failed postings verified in the ledger before retry.
- Collectors can see which invoices have a pending receipt.