A customer paid a lump sum with no remittance advice: how to work out which Xero invoices it covers

The bank feed shows a deposit of $14,743.75. It matches no single invoice. No remittance advice arrived, the reference field says something unhelpful like PAYMENT or a bank-generated string, and the customer's accounts team is not answering today. You still have to reconcile the line. This is the worst version of the bulk-payment problem, because before you can allocate anything you first have to reconstruct what the payer meant.

Step one: shrink the candidate pool

Do not try to match against your whole ledger. Almost every lump sum comes from one payer, so identify the payer first — from the bank line's payer name, the amount's plausibility, or simply which customer has enough outstanding to produce a deposit that size. Then pull only that contact's open invoices: Business, then Invoices, filter Awaiting Payment, filter by the contact, and export. You are now matching against ten or thirty invoices, not four hundred.

• Filter to the payer's open invoices and export them to a spreadsheet.
• Sort oldest first — payers overwhelmingly settle oldest invoices before newer ones.
• Check the trivial cases before anything clever: does the deposit equal the contact's entire outstanding balance? Their balance minus one disputed invoice? A single month's statement total?

Step two: look for a combination that fits to the cent

If no shortcut fits, the deposit is some combination of open invoices, and your job is to find which one. Start from the oldest invoice and accumulate: running totals down the aged list catch the common case where the payer settled everything up to a cutoff date. If the running total passes the deposit without hitting it exactly, the payer skipped something — usually a disputed invoice or a credit they took without telling you. Try removing recently queried invoices from the run and see if it lands.

The cents are your best friend. If the deposit ends in .75 and only two open invoices have non-round cents, one or both of them are almost certainly in the combination, and the rest of the puzzle shrinks dramatically. Work the odd cents first, then fill in round amounts.

The discipline rule: a combination is only an answer if it is the only one

Here is the trap. With enough open invoices, more than one combination can sum exactly to the deposit. If $3,390.00 can be made from invoices 2500 + 890 and also from 1600 + 1790, exact arithmetic proves nothing — you have two candidate stories and no evidence for either. Pick the wrong one and every invoice involved is now misallocated: the aged receivables report lies, follow-up chasing goes to customers who already paid, and unwinding it later means reversing posted payments.

Step three: ask for the remittance advice properly

The fastest permanent fix is upstream. When you ask the payer for detail, ask for the document, not a conversation: 'Could you send the remittance advice for your payment of $14,743.75 received 14 July — the list of invoice numbers and amounts it covers?' Most accounts-payable systems generate this automatically and can re-send it in seconds. If the payer is a regular, ask them to set your accounts-receivable email as the standing remittance address so the advice arrives with every future payment instead of after every mystery.

Prevention: make your references survivable

• Put the invoice number somewhere the payer's system will echo back — many AP systems return whatever reference was on the invoice.
• Keep invoice numbers short and unambiguous; a 6-digit number survives re-keying far better than one buried in a long code.
• Issue credit notes promptly, so payers deduct a documented credit instead of a mystery amount.
• Chase remittance advices as a routine, not an emergency — a standing 'please send remittances to this address' line on statements pays for itself.

When this happens every month

Reconstructing one mystery deposit is detective work; reconstructing one every week is a process failure. The mechanical part — normalising references, testing combinations, proving the allocation sums to the deposit to the cent, and refusing to guess when two answers fit — is exactly the kind of work software should do, with the ambiguous cases routed to a human instead of silently auto-matched. That last property is the one to insist on if you evaluate any tool for this: ask what it does when two combinations fit. If the answer is anything other than 'it stops and asks you', keep looking.