The money has arrived. Why do the invoices still look unpaid?
For Finance controllers, CFOs and accounts teams · Plan implementation
TL;DR — what you’ll learn
- Allocate a recorded receipt using reliable remittance evidence and approved matching rules.
- Show partial allocations, available cash and invoice balances together.
- Keep deductions, credits and ordinary partial payments distinct.
- Test duplicate remittances, reversals and ambiguous customer identities before automating acceptance.
Sales calls a customer about overdue invoices. The customer says payment was made three days ago. Finance finds the money in the bank but cannot tell which of twenty invoices it settles. The collection problem is really an allocation problem, and it is already affecting the customer relationship.
How can a food distributor match bulk customer payments to invoices?
Use the recorded bank receipt and customer remittance to propose invoice allocations. Keep unmatched money and unresolved deductions visible. Matching should allocate an existing payment, not create another receipt or assume that every difference is a discount.
- 01Capture the receiptBank and customer evidence
- 02Propose allocationsRemittance and open invoices
- 03Review ambiguityShort pay, multiple matches and deductionsIs the allocation evidenced?YesPost the allocationNoKeep the amount unapplied until the authorised reviewer resolves it.
- 04Post the allocationPreserve the receipt-to-invoice trail
Illustrative information flow. The article explains the evidence, exceptions and responsible decisions. Diagram: NextEdge Labs.
Start from the recorded receipt
Confirm the company, customer, currency and available payment amount. Then use explicit invoice references from the remittance where they are reliable. Similar amounts or dates can suggest candidates, but they are weak evidence when a customer regularly pays round sums.
ERPNext describes payment reconciliation as linking an existing payment or credit to invoices without creating a new bank movement. Preserve that distinction in any integration. Reprocessing the same remittance must not duplicate the receipt or allocate more than the remaining available amount.
Source: Frappe / ERPNext · Existing payment allocation and reconciliation prerequisites. Reference details
A partial payment is not necessarily a dispute
Suppose an illustrative ₹75,000 receipt refers to invoices of ₹40,000 and ₹50,000. The remittance may explicitly allocate ₹40,000 to the first and ₹35,000 to the second. The remaining ₹15,000 is still outstanding; nothing in that arithmetic proves the customer disputes it.
Keep partial payments, unapplied credits and deductions as separate conditions. Where the remittance is unclear, ask the reviewer to confirm the allocation. Do not apply an oldest-invoice rule unless finance has approved that policy for the relevant accounts.
The customer name on the bank line may be different
A group treasury account may pay for several trading entities, or a payment reference may contain an abbreviated name. Maintain approved payer-to-customer relationships where the business uses them. A model can suggest an alias, but similar names should not establish authority to allocate funds across companies or accounts.
Show the legal entity, customer account and currency before presenting invoice candidates. If a payment could relate to more than one account, route it for review with the supporting remittance. The proposed system should make ambiguity visible rather than choose the customer whose open balance happens to fit the amount most closely.
Reconcile what is left after the proposal
Consider an illustrative ₹90,000 receipt with a remittance allocating ₹40,000 to Invoice A and ₹35,000 to Invoice B. The proposal leaves ₹15,000 unapplied. If Invoice B originally totalled ₹50,000, it also leaves ₹15,000 outstanding on that invoice. Those two equal figures do not prove the remaining cash belongs there; the remittance may cover another invoice or an advance.
Display the remaining payment amount and remaining invoice amounts separately. Reviewers should not have to infer them from a total matched figure. When a credit note is involved, preserve its identity and approved allocation. The amount available for allocation must be checked again when the proposal is accepted, because another user may have acted on the same receipt meanwhile.
A reversal is a business event, not a deleted match
If an allocation was wrong, retain the original decision and record the authorised reversal or correction. The customer account should show how the balance changed and why. Deleting a match history can leave collections staff unable to explain why an invoice moved from paid to overdue.
Include concurrent work in testing: two users reviewing the same receipt, a remittance resent with a corrected reference and a payment whose earlier allocation was reversed. The integration needs a stable source identity and a clear processing history. Automatic retry should resolve a technical interruption without repeating an allocation that the ERP already accepted.
Use the exception queue to improve the source
Review which customers repeatedly require clarification. The practical fix may be a better remittance format or a consistent payment reference, rather than a more complex matching model. Track the reasons for manual intervention and use them in account-management conversations through the business's normal channels. Better source information can reduce work across finance and collections at the same time.
Give the team a small exception queue
AI can extract invoice references from inconsistent remittance layouts and suggest customer aliases. Rules can check totals, already allocated amounts and duplicate references. The review screen should show the original evidence and the proposed allocation together, including the balance left afterwards.
Pilot with a group of customers whose payment patterns differ. Include one receipt spanning many invoices, a credit note, a reversal and a remittance sent twice. Track unallocated cash age and correction effort alongside the percentage matched. A high match rate is unhelpful if the team later has to undo allocations to answer a customer.
Summary
Cash application should make the relationship between money received and invoices settled explicit. Useful automation proposes and validates those allocations while preserving uncertain balances for review. The strongest success measure is less ageing unallocated cash with fewer corrections, rather than an isolated matching percentage.
What to do next
- Select customers with different remittance formats and payment patterns for the sample.
- Agree the evidence needed for automatic proposals and the conditions requiring review.
- Reconcile one receipt across invoices, credits and a remaining unapplied amount.
Scope this automation around your operation
Tell us your current systems, transaction volume and the exception you need to resolve. We can discuss a bounded first release, its review controls and how to measure the result.
Sources and further reading
Sources checked 15 October 2026. The worked examples and software evaluation suggestions are NextEdge Labs’ editorial analysis.
- Payment ReconciliationFrappe / ERPNext · Online product documentation, accessed October 2026
An example of allocating existing payments and credits to invoices. Proposed matching rules require finance approval.
Visual credits
AI-generated illustration created for NextEdge Labs; it does not depict a client facility. Workflow diagram by NextEdge Labs. Icons from Lucide (ISC licence).