How to Apply a Lump Sum Payment Across Multiple Invoices

Apply a lump sum across multiple invoices by reconstructing what the payer intended, using the remittance first, then the arithmetic of the amount, then the payer's own history, and by refusing to spread cash pro rata when the combination is ambiguous. Monk is an AI-native invoice-to-cash platform that runs invoicing, cash application, collections and disputes as one system, so a single wire, the nineteen invoices it settles and the two it does not stay connected in one record. The hard version is common: one payment lands, the remittance lists the buyer's internal voucher numbers rather than your invoice numbers, and the total ties to no obvious combination of open items. Guessing is expensive, and so is leaving the whole payment on account.

Here is the case this article works through. Meridian Foods Group owes you £163,900.00 across 24 open invoices. A wire arrives for £147,318.42. Attached to a separate email is a PDF remittance with nineteen lines, each carrying a voucher reference like V-88214, a purchase order number, and an amount. None of the nineteen references is one of your invoice numbers. The nineteen amounts add up to £147,461.00, which is £142.58 more than the wire.

Why does a lump sum with the buyer's own document numbers break automatic matching?

Because the matching key your ledger is built around, the invoice number, is absent from the document that tells you what was paid.

Automatic cash application works by finding your reference in the payment. In a BAI2 file that reference sits in the addenda of a type 165 detail record. In an ACH credit it sits in the CTX or CCD addenda. In an EDI 820 remittance it belongs in the RMR segment. When the buyer's AP system generates a voucher number at the point of approval and prints that instead, every one of those lookups returns nothing, and the payment lands in the exception queue however good the parser is. Timing compounds it, because the remittance often arrives on a different day from a different sender.

Purchase order numbers are the usual bridge, because the buyer raised the PO and you quoted it on the invoice. That works when invoices are one to one with POs, and stops working when a single PO covers eleven monthly invoices or a year of deliveries, because then the PO identifies the relationship rather than the document. You are left matching on amounts, and amounts are ambiguous in a way references are not.

How does subset sum matching work, and where does it become ambiguous?

Subset sum matching searches for a combination of open invoices whose total equals the payment, and it becomes unreliable as soon as invoice values repeat or a tolerance is applied.

The maths is unforgiving. With 24 open invoices there are more than sixteen million possible combinations, and a solver will find one that hits £147,318.42 in well under a second. The trouble is that it may find several, and it has no way of knowing which one the payer meant. A single true answer is only guaranteed when every invoice value is distinct and no tolerance is allowed.

Real ledgers break both conditions. Recurring charges produce identical amounts, so a customer on a monthly service fee of £4,180.00 has three invoices at the same value and the solver cannot separate them. A tolerance of even fifty pence multiplies the valid combinations, because near misses now count. Add a credit note the buyer has netted off and the target is no longer the sum of any subset of invoices.

So use subset sum as a last resort rather than a first move. Match on references where they exist, then on PO, then on remittance line amounts one by one, and only then let a solver work on the residue. In the Meridian case, seventeen of the nineteen voucher lines carry a PO that maps to one invoice each. Two do not, both are for £4,180.00, and the ledger holds three invoices at that value.

Which tie breakers should you use when two combinations both add up?

Rank candidates by observed payer behaviour first, then by invoice age, then by whatever the remittance line carries that you have not used yet.

Payer behaviour is the strongest signal because it is specific to this customer. Pull the last twelve months of their payments and ask three questions. Do they pay oldest first or by approval date? Have they ever split an invoice across two payments? Do they pay on a fixed day of the month, which tells you which approval cycle a voucher belongs to? A payer who has settled oldest first for a year has almost certainly done it again, and that resolves the £4,180.00 ambiguity in the Meridian file.

Invoice age is the fallback, and it is the most defensible if you turn out to be wrong. Applying to the oldest open item minimises aging distortion, matches the default behaviour of most buyer AP systems and is easy to explain. Exclude disputed invoices from the candidate set before ranking by age.

Then use the remaining fields. A voucher line often carries a delivery note number, a cost centre, a site code or a date that narrows the field. Site codes help with multi-site buyers, because the invoice for the Leeds depot was not approved by the Bristol cost centre. Write the rule down, because the same customer will send the same shaped file next month.

What should you do when the total reconciles to no combination at all?

Stop searching for a subset and start looking for the adjustment the payer applied silently, because a gap of a few pounds is almost never a missing invoice.

Four adjustments cause most of these gaps. A bank charge on a cross border wire shows up as an odd amount like £22.58 and repeats on the same corridor. A credit note the buyer has netted off without listing it explains why the gap often equals a credit sitting open on your ledger. Foreign exchange leaves the payment a few units away from the invoice value. And a deduction with a reason code may have arrived on a second page nobody opened.

In the Meridian file the £142.58 splits neatly. A correspondent charge of £22.58 matches the previous three payments from the same originating bank. The remaining £120.00 equals credit note CN-4471, raised six weeks earlier for a short delivery and never applied, which the buyer netted against voucher V-88231. Once the credit is applied, the nineteen lines and the wire tie exactly. A gap of thousands rather than pounds is a different problem, and the fix there is to ask the payer's treasury for the payment file.

How should on-account balances be handled after a partial allocation?

Allocate everything you can identify, leave the unidentified remainder on account with an owner and a date, and never spread it pro rata to make the ledger look tidy.

Pro rata spreading is the tempting error. If £3,200.00 of a wire cannot be attributed, splitting it across open invoices in proportion to value leaves every invoice partly paid, nothing closed, and the real question smeared across a dozen documents. Reversing that later is manual. One clean on-account line of £3,200.00 keeps the question visible and the eventual correction to a single entry.

An on-account balance needs four things: an owner, a reason, a target resolution date and a place on the customer statement. Showing on-account credits on the statement is the most effective way to resolve them, because the customer's AP team can see the money and will usually tell you what it was for. Age the balance alongside receivables and review it monthly.

One caution on the collections side. An on-account balance means the customer's true exposure is lower than the aging report shows, so dunning sent before the cash is applied overstates the debt. Hold chases on accounts carrying material on-account cash until it is allocated.

What happens when one bank account pays for three legal entities?

You have to split the payment before you apply it, because a single receipt cannot post to three sales ledgers without an allocation step in the middle.

Group treasury structures change the shape of the problem. Meridian Group Treasury Ltd pays for Meridian Foods Ltd, Meridian Logistics Ltd and Meridian Foods BV. Your ledger holds three customer records, possibly in two currencies. The wire arrives from one account under one name, and the remittance may not indicate which subsidiary each voucher belongs to.

The workable structure is a payer record separate from the customer record. The payer is Meridian Group Treasury Ltd, identified by bank account and originating BIC, with the three billed entities linked to it. Cash lands against the payer, remittance lines are attributed to entities by PO, site code or reference, and only then posts to each sales ledger. Without that separation, three teams claim the same receipt and the reconciliation only works if one person holds it in their head.

Two details matter in practice. Cross entity offsetting, where a credit in one subsidiary reduces a payment for another, needs an intercompany entry rather than silent netting, or entity level receivables will not reconcile. And where the paying entity sits in another country, withholding tax may reduce the remittance below the invoice value, which is a certificate to collect rather than a shortfall to chase.

How does Monk handle this?

Monk builds the payer view and the matching logic in the same place, so a lump sum is resolved once and the rule is reused next month.

Monk's AI cash application matches around 80% of incoming payments automatically, and 95% once suggested matching rules are in place. For lump sums those rules are the ones that carry the most value: map this payer's voucher prefix to our PO field, treat this payer as oldest first, expect a correspondent charge of roughly this size on this corridor, link these three billed entities to this one treasury account. Each rule comes from a decision a person made once.

Monk reads remittance advices as they arrive, whether that is a nineteen line PDF, a CSV exported by an AP clerk, an EDI 820, an ACH addenda record or a BAI2 or EDI 823 lockbox file, and pairs them with the bank receipt even when the two arrive days apart from different senders. Where a combination stays ambiguous, the exception carries the candidate matches and the evidence behind each, so the person deciding is choosing rather than searching. Monk's measurement is that 39% of cash flow slowdown comes from edge cases.

Applications and on-account balances sync to QuickBooks, NetSuite, Salesforce, HubSpot and Stripe, so collections and finance see the same allocation. Teams running Monk report 26 hours a month saved on receivables work and a 40% average reduction in DSO. Monk is SOC 2 Type II compliant and onboarding takes under a week.

Where should you start?

Take your ten largest payers and check, for each one, whether their remittance carries your invoice number.

That question sorts your book into two groups. Payers who quote your reference should be matching automatically, and if they are not, the fault is parsing rather than data. Payers who quote their own voucher numbers need a documented bridge, usually the PO field, written down once per payer rather than rediscovered monthly.

Next, pull every payment from the last quarter that settled more than three invoices and record how long each took to apply. Then age your on-account balance by payer and find the accounts where cash keeps landing unallocated, because those are payer structure problems rather than individual mistakes. Check whether any customer pays from a group treasury account, and confirm your ledger models the payer separately from the billed entity.

Those three checks take an afternoon and usually explain most of your exception volume. To see how payer rules, remittance parsing and multi-entity allocation work on your own ledger, book a demo.

Frequently Asked Questions

What is subset sum matching in cash application?

It is the search for a combination of open invoices whose total equals an incoming payment. It helps when a lump sum arrives without usable references, and it becomes unreliable when invoice values repeat or a tolerance is allowed, because several combinations hit the same total. Treat it as a last resort after reference, PO and line amount matching, and show candidate combinations to a person rather than posting the first one found.

Should I apply a lump sum to the oldest invoices by default?

Oldest first is a sound default because it minimises aging distortion and matches how most buyer AP systems release payments. Override it with anything you know about the specific payer, such as a history of paying by approval date, and exclude disputed invoices from the candidate set before ranking. Apply the rule consistently so the customer statement and your aging tell the same story.

What do I do when the remittance total does not equal the payment?

Look for an adjustment rather than a missing invoice. Small gaps are usually a bank charge, an unlisted credit note, a foreign exchange difference or a deduction on a second page. Compare the gap against open credit notes on the account first, because that often resolves it immediately. Large gaps normally mean a voucher was pulled after the remittance was produced.

Is it acceptable to spread unallocated cash across invoices pro rata?

No. Pro rata spreading leaves every invoice partly paid and none closed, which hides the real question, distorts aging and makes the eventual correction a manual reversal across many documents. Keep the unidentified remainder as one on-account line with an owner and a resolution date. A single visible balance is easier to chase, easier to explain and easier to clear.

How do I handle a customer who pays from a group treasury account?

Model the payer separately from the billed entity. Record the treasury company as a payer, identified by bank account and originating BIC, and link the subsidiaries it pays for to that record. Cash lands against the payer, remittance lines are attributed by PO, site code or reference, and only then posts to each sales ledger. Cross entity offsets need an intercompany entry rather than silent netting.

What should a remittance advice contain to be usable?

The minimum is your invoice number, the amount paid against each invoice, and the total. Useful extras are the PO number, credit note references, deduction reason codes and a site or cost centre. If a customer cannot supply your invoice number, ask for the PO and for a consistent sender and format, because a predictable file can be parsed automatically even when imperfect.

How long should a multi-invoice payment take to apply?

A payment with a clean remittance should be applied the day it arrives, and one needing investigation should have an owner within a day and a resolution target within five working days. Track the tail rather than the average, because a small number of payers generate most of the delay. Time to apply by payer shows which relationships need a conversation about file format.