A customer pays one amount covering several invoices. The bank line contains a short reference; the remittance arrives separately; one invoice may already have a credit against it. Finding the right records can take longer than entering the payment.
Accounts receivable automation can help prepare a proposed match. The important distinction is between what the customer says they paid, what has actually reached the bank and what has been applied to the ledger.
What information should a proposed match include?
Bring together the customer account, payment reference, confirmed bank transaction and the current open entries. Keep the remittance as supporting evidence, including where it came from and which invoice references it names.
A remittance explains the customer’s intended allocation. It is not, on its own, proof that the money has arrived. Similar customer names and a matching total are useful clues, but they do not settle an ambiguous account or currency.
Worked example: the references match, but £20 is missing
In a fictional example, the remittance names invoice A for £720 and invoice B for £480: £1,200 in total. The confirmed receipt is £1,180. The workflow can gather those records and show a £20 difference.
It should not quietly mark both invoices paid or decide which one is short. A credit, deduction, fee or mistake may explain the difference, but the evidence must establish it. Send the case to the finance owner with the proposed allocation and the unresolved amount clearly separated.
Do the same check against the current ledger before posting. An invoice mentioned in an older remittance may have been settled or adjusted since the document was sent.
Can one payment be applied to several invoices?
Accounting systems may support applying one payment across several open entries. Microsoft’s Business Central documentation, for example, describes applying payments to multiple customer ledger entries and specifying partial amounts. The options and permissions in your own accounting system need checking.
The automation should work around the finance team’s approved allocation rules. It should not invent a write-off policy, discount tolerance or exchange-rate treatment. Keep those decisions with the responsible person and the accounting system.
What stops the same receipt being applied twice?
Retain the stable bank-transaction and ledger references, along with the recorded outcome of an application. Before repeating an action, check whether that transaction has already been processed.
If the connection times out after a posting request, an error screen does not establish that nothing happened. Reconcile the current ledger before retrying. Keep prepared, approved and posted as separate states, with the resulting accounting reference where available.
How should this affect credit-control chasing?
A confirmed allocation should update the balance used for chasing. An unresolved receipt or a customer’s payment claim may need a review hold under the team’s policy; neither should be turned into an invented cleared balance.
The invoice-chasing guide covers the checks before another reminder. Our finance automation service and proposed invoice and payment workflow show where this preparation could fit. The study is a proposed design, not a claim that your bank and ledger are already connected.
Test exact matches, short payments, credit notes, repeat bank records and an uncertain posting result. Retain the current manual allocation process and measure review effort as well as preparation time.
Sources and scope
Microsoft: apply customer payments and partial amounts in Business Central. Product behaviour and access depend on the software and configuration in use.