One payment, forty lines
Your largest customers pay on a payment run. One transfer arrives in the bank for a large amount, and somewhere a remittance advice lists the invoices it covers. Sometimes the remittance is an email attachment. Sometimes you have to log in to the customer's supplier portal to download it. Sometimes it arrives a few days after the money.
Someone then works through it line by line, finding each invoice in the ledger, noting where the customer has paid less than invoiced, and trying to work out why. Deductions for returns, early-payment discounts, promotional allowances or disputed items are listed with the customer's own codes. The total has to balance before anything can be allocated.
Why this stays manual
Every customer's remittance looks different, and most do not quote your invoice numbers the way you print them. Some use their own purchase order numbers. Some add prefixes. Some list a deduction without saying which invoice it relates to.
| Remittance issue | Why a simple rule fails |
|---|---|
| Customer uses their PO numbers | Your invoice numbers do not appear at all |
| Deductions listed separately | Payment total does not equal the sum of invoices |
| Credit notes netted off | Need to be found and allocated too |
| Advice arrives after the money | Payment sits unallocated in the meantime |
| Portal download only | Nobody remembers to log in |
Accounting software reconciliation suggestions cannot help, because the information needed to split the payment is not in the bank line. It is in a document the software never sees.
What the delay costs
Until a payment is allocated, your aged debtors report is wrong. Invoices that were paid look overdue, credit control may chase them, and customers get annoyed at being chased for money they have already sent.
Short payments and deductions are the bigger issue. If nobody examines them promptly, disputed deductions become permanent. A deduction for a return you never received, or a discount the customer was not entitled to, is much harder to recover months later.
How we automate remittance matching
- Collect remittances from a dedicated inbox, and where customers use supplier portals, retrieve them through the portal's export or a scheduled download where the portal allows it.
- Read each remittance with a document model into a fixed structure: reference, amount paid, deductions, credit notes, and the customer's codes.
- Translate the customer's references to yours: PO number to invoice, customer deduction codes to reasons, using a lookup that starts from your history and grows as people confirm mappings.
- Match the remittance to the bank transaction on amount, date and customer.
- Allocate in Xero, QuickBooks, Sage or your ERP through its API: each invoice marked paid or part paid, credit notes applied.
- Send deductions to a queue: each shows the customer's reason, the invoice it relates to, and whether it fits an agreed term. A person accepts it, raises a credit note, or disputes it with a drafted email.
Where the money arrives before the remittance, the system parks the payment against the customer and completes the allocation automatically when the advice turns up.
The result for your team
Large payments are allocated shortly after they land rather than when someone finds the time. Deductions are reviewed while they are recent, so the ones that should be disputed actually get disputed. Credit control works from an accurate ledger, and nobody gets chased for an invoice they have already paid.
Over time you also build up a clear picture of each large customer's deduction habits. If one retailer routinely deducts for damaged goods on deliveries your own records show as signed for in good condition, that pattern is visible, with the invoices and dates to back it up, which is the kind of evidence an account review with that customer needs.
The person who used to spend a morning on each big remittance now spends that time on the handful of deductions that need a decision, and the rest of the allocation happens without them.
Do you recognise this?
- Some customers pay many invoices in one transfer.
- Remittance advices arrive in different formats or have to be downloaded from portals.
- Payments sit unallocated for days while someone works through the remittance.
- Deductions are written off because nobody has time to query them.
- Customers are chased for invoices they have already paid.