Customer statements that show which payment settled which invoice

"But we paid that invoice"

A customer calls about an overdue reminder. They paid last month, they say, and they can send the bank transfer to prove it. You can see the payment too. The problem is that your system applied it to an older invoice than the one they meant, so their records and yours now disagree about which invoices are open, even though the total owed is the same.

A traditional running-balance statement makes this conversation harder. It lists invoices and payments in date order with a balance column, but it never says which payment settled which invoice. The customer's accounts team works invoice by invoice, so they cannot reconcile it.

Balance-forward and open-item statements

There are two classic statement formats:

• Balance forward: an opening balance, the period's transactions and a closing balance. Good for showing the total owed; poor at explaining it.
• Open item: the unpaid invoices only. Good for showing what is outstanding; it hides how earlier payments were applied.

The statement customers find easiest to agree with shows both sides of the link: each payment with the invoices it settled, and each invoice with the payments that settled it.

What a clear customer statement includes

1. Payments listed once each, with the invoices each one was applied to and what remained on each invoice afterwards.
2. A "paid by" reference on every invoice, giving the receipt or credit note numbers that settled it.
3. Credit notes shown with the invoices they were applied to.
4. Unapplied money, held on account, stated plainly rather than buried in the balance.
5. Totals: billed, received, unapplied and left to pay.
6. Ageing of what is still open.
7. Optionally, the full ledger for customers who want the running balance as well.

Provide it in the format the customer will use: printed or PDF for the owner, a spreadsheet for the accounts team that has to tick items off.

Why payments end up on the wrong invoices

Most allocation errors are not mistakes in the amount. The money and the bank entry are right; only the link to invoices is wrong. Typical causes:

• the payment was applied oldest first by default, but the customer's remittance named specific, newer invoices, perhaps because an older one is disputed;
• the remittance advice arrived after the payment was recorded;
• a cheque or transfer reference was not recorded, so nobody could match it later;
• one payment covered several invoices and only some were selected.

Fix the allocation, not the payment

The tempting fix is to reverse the payment and record it again. That touches the bank account for no reason, creates extra entries for your bank reconciliation, and can collide with a period that has already been closed.

The better fix is to re-allocate: take the payment off the wrong invoices and apply it to the right ones, leaving the payment itself, its date and its bank entry alone. From an accounting point of view:

• if the total applied to invoices is unchanged, moving it between invoices of the same customer changes no account balance, so no journal is needed;
• if more or less of the payment ends up held on account, a single entry moves the difference between receivables and customer advances. The bank is not touched.

Because the payment date dates the change, the period containing the payment should still be open.

Match the remittance advice

Remittance advices arrive in every shape: an email line listing invoice numbers, a table pasted from a spreadsheet, amounts with different separators. Matching by hand is slow and error-prone. Whatever tool you use should read the list, find the invoices and flag anything that needs a person:

• an invoice number that does not exist for this customer;
• a number that matches more than one invoice;
• an invoice that is already paid;
• an amount above what is open, or a part payment;
• the same invoice listed twice.

Then review the proposed allocation before saving it. A review step that says plainly when nothing has been allocated prevents the most common error of all.

Duplicate receipts

Sometimes the same payment is recorded twice, by two people or by one person on a slow connection. The second receipt usually ends up as money on account. When you void the duplicate, the invoice should stay paid by the receipt that remains. Check this in any system: voiding one of two receipts must not make a paid invoice look unpaid.

How NAQIX handles statements and allocation

NAQIX's customer statement shows which payment settled which invoice, on screen, in print and in Excel.

• A By payment view lists each receipt, credit note or advance with the invoices it settled, and offers a remittance advice for a single payment. A By invoice view gives a "Paid by" column of receipt numbers.
• Billed, received, unapplied and left-to-pay totals, an ageing table and an optional full ledger are included; the Excel export has separate sheets for invoices, payments and credits, ageing and the ledger.
• Re-allocate moves a customer payment to the right invoices without reversing it. No journal is posted when the applied total is unchanged; if the on-account amount changes, one entry moves it between receivables and customer advances.
• Paste remittance matches a remittance advice against open invoices and flags numbers not found, ambiguous matches, invoices already paid, overpayments, part payments and duplicates. It suggests an allocation; a person applies it.
• Receive Payment has a prominent reference field and a review step before saving, and voiding a duplicate receipt leaves the invoice paid by the receipts that remain.

See the Sales & billing page for the full order-to-cash flow, and the Accounting & reports page for receivables ageing.

A weekly habit

Record references when money arrives, match remittances the same day, and send statements in the format each customer uses. Disputes about "which invoice" become rare when both sides can see the same link between payments and invoices.