
Why matching payments to invoices sometimes defeats software — and what that reveals about modern work.
Everyone learns about NP-complete problems in computer science.
Almost nobody realises that one of them is hidden in the most routine corner of business life:
applying a customer payment to a list of open invoices.
This isn’t a metaphor.
It is literally the subset-sum problem — formally catalogued by Garey & Johnson (Computers and Intractability, 1979) — and explicitly discussed in accounting-reconciliation research such as Pettersson & Strömberg (2007), who identify multi-item invoice matching as a computationally hard variant of subset selection.
But the important point is not that the equivalence exists.
It’s that everyday business practice routinely generates worst-case instances of a famous computational barrier — and accountants are the ones who run into it.
A Worked Example That Shows the Entire Problem
Take a payment of £4,215.
The customer has nine open items:
- £600
- £615
- £700
- £1,200
- £1,300
- £1,415
- £2,000
- £2,015
- (£300) credit note
Try the obvious strategies:
- Greedy (largest-first) → fails
- Date proximity → fails
- Similar-amount grouping → fails
The correct match?
£1,415 + £1,300 + £1,200 + (£300 credit note) = £4,215.
This kind of combination is common in real accounts — especially when customers drip payments or credit notes distort the pattern.
And the combinatorics behind the scene are brutal.
With 1,000 open invoices, the search space is 2¹⁰⁰⁰ — vastly more than atoms in the observable universe.
This is what ERP systems quietly face.
Why This Isn’t Just a Trivia Fact
A few operations-research papers note the connection between reconciliation and subset-sum, but very little writing explains why real-world accounting systems produce the hardest instance types:
- Repeated invoice amounts
Creates dense clusters → many candidate subsets. - Staggered and partial payments
Three small payments → exponential branching across ten invoices. - Credit notes and adjustments (negative numbers)
Multiply the space of feasible combinations. - Long account histories
5–15 years of open items is normal in large ERPs. - Exact-to-the-penny matching
No numerical tolerance → no approximate shortcuts.
In other words:
ordinary bookkeeping practices routinely generate pathological subset-sum instances.
ERP Systems Know This — They Just Don’t Say It
When an ERP displays:
“Unable to automatically apply payment.”
the real meaning is:
“You have asked me to solve an NP-complete instance for which no guaranteed fast method exists. Please be the algorithm.”
And this is not speculation.
Real ERP documentation says exactly this — but in more diplomatic language.
- SAP Note 310597 (“Automatic Clearing: Limitations and Manual Intervention”) explicitly acknowledges that SAP’s F.13 auto-clearing fails for “complex multi-item combinations” or when credit memos create ambiguous matches, and must be resolved manually.
- NetSuite’s Help Center — “Applying Payments to Multiple Invoices” states that automatic application may not complete when invoice/credit memo combinations “require user judgment.”
- Oracle Receivables User Guide — “Automatic Receipt Processing Limitations” similarly lists cases where auto-apply halts because “multiple plausible matches exist.”
All three systems — along with Microsoft Dynamics — converge on the same truth:
The software stalls exactly where the mathematics becomes hostile.
Meanwhile, credit controllers perform live combinatorial optimisation.
What Matching Engines Actually Do
Commercial reconciliation tools survive by using layered heuristics:
- date proximity
- behavioural priors (typical ways a customer pays)
- amount clustering
- machine-learned likelihood scoring
- ILP solvers for isolated subproblems
- manual review for anything ambiguous
These handle most cases.
But substantial manual effort persists across large organisations, even after decades of automation attempts — because the bottleneck isn’t a missing feature, it’s a mathematical limit.
AI doesn’t escape this.
Machine-learning tools don’t “solve” the problem; they learn better heuristics for navigating an NP-complete search space.
Manual review remains essential because the hardness is structural, not technological.
And once you accept that, the deeper point comes into view.
The Larger, More Interesting Point
This isn’t really about accounting or ERP failures.
It’s about a much broader phenomenon:
Many workflows in modern organisations look trivial on the surface yet sit directly on top of computationally hard problems.
Invoice matching is just the clearest example.
Other cases include:
- multi-leg cash application
- FX netting across global entities
- portfolio allocation under constraints
- warehouse picking optimisation
- shift scheduling
- bundled-product revenue recognition
- supply-chain backorder allocation
The “clerical” layer often conceals a theoretical limit — and a persistent research opportunity.
Research implication:
Domain-specific versions of subset-sum may admit specialised algorithms far more efficient than generic formulations. This is an underexplored intersection of computer science, accounting, and operations research.
The next time an ERP system refuses to apply a payment automatically, don’t assume incompetence.
Sometimes it’s telling you the truth:
Some tasks in modern business are small on the surface — and NP-complete underneath.
