One payment, twelve invoices, and the list that has to travel with it.

The money arrives without the list.

One ACH credit lands for 340,812 dollars. The customer has twelve open invoices. The amount equals none of them, and the email that says which twelve arrived yesterday afternoon from somebody in their AP team. Every receivables function knows this receipt. It sits in a queue called unapplied and somebody opens a spreadsheet.

The Federal Reserve Bank of Cleveland published a research brief on 25 September 2026 that walks the whole B2B chain from supplier onboarding to reconciliation, and it names this case directly. Under the challenges to reconciliation it describes a single payment aggregated to cover multiple underlying remittance items whose items may be transmitted individually, and says the receivables system then needs to be capable of complex parsing logic to fully automate the receipt. It is a precise description of a problem usually discussed as a productivity complaint.

The same section explains why the list and the money come apart in the first place. Matching may be automatic when the supplier receives structured remittance data along with the payment. Manual handling is needed when the data are detached from it, and the brief notes that advice reports may arrive hours or days earlier or later through a completely different channel. It also maps the rails: wire and instant payments carry ISO 20022, cards carry ISO 8583, and ACH carries the older ANSI ASC X12 format, with a footnote recording that the ACH CTX code can carry rich remittance while CCD cannot.

That footnote matters more than it looks. In part one of the same series, ACH is 41 percent of the number of US B2B payments in 2024, having grown from 3.6 billion payments in 2015 to 8.7 billion, at an average of 8,084 dollars each. The rail that carries most of the count is the one where whether the invoice detail travels at all comes down to a code on the payer side.

What a matcher actually leaves on the table.

The advice usually given at this point is to improve your matching rules. So we measured what rules can and cannot do, using the engine behind the reconciliation tool published on this site. It is a small, honest piece of logic and a fair stand in for the matching most teams have: first a pass on an exact shared reference, then a pass on amount within a tolerance and date within a window, with each row consumed at most once.

The example book has 120 customers with 8 open invoices each, so 960 invoices, and 12,081,313.10 dollars of cash across 666 receipts. Most customers pay invoice by invoice, and 42 of them send one payment for the whole set. Those 42 receipts are 6.3 percent of the receipt count and 34.9 percent of the money. Every payment lands two days after the invoice it settles, so the date window is never the thing standing in the way.

The first three rows are the finding. Going from a three day window and an exact amount to a full year and a thousand dollars of tolerance changes nothing whatsoever. Not one more receipt, not one more dollar, not one fewer open invoice. Tolerance is not the binding constraint, because no amount of tolerance turns one row into twelve. A lump sum has nothing to pair with, and an engine that consumes each row once will keep reporting it as unapplied however generous you are with it.

The two numbers to hold on to are the pair in the first row: 93.7 percent of receipts and 65.1 percent of the cash. If the metric on the wall is the count, this looks like a solved problem with a small tail. If the metric is money, a third of the cash is sitting in a queue. The gap opens because the payments a one to one matcher cannot handle are the aggregated ones, and aggregated payments are by definition the large ones.

The fourth row is what happens when someone tries to close the gap with the only lever the settings screen offers. Taking the amount tolerance to 100,000 dollars produces a much better looking dashboard: 99.2 percent of receipts matched and 94.3 percent of the value applied. Of the 661 matches it made, 310 were correct. 314 receipts were paired with an unrelated single invoice that happened to fall within the tolerance, and 37 lump sums were posted against one invoice each. 7,583,620.03 dollars of the 12,081,313.10 dollars received landed on the wrong invoice, and the receivables ledger gives no sign of it, because every individual match is a pairing the rule permitted.

This is worth stating plainly because the failure is silent and the metric improves. A tolerance is the right tool for a bank fee, a rounding difference or a small FX movement. It is the wrong tool for aggregation, and pushed far enough it converts an exception you can see into a misapplication you cannot.

Solving for the combination, and when that is honest.

The other instinct is better: if the payment equals the sum of some of the open invoices, find which ones. It is the right idea, and it has a limit worth knowing before you trust it. The question is not whether a combination exists. It is whether only one does.

We ran 20,000 trials for each case below. A customer has some open invoices, pays a random subset of them, and we count how many subsets of the whole set sum to exactly the amount received. One means the answer is provable. More than one means any engine that picks is guessing, and the guess is invisible afterwards because every candidate ties to the penny.

The spread in that table is the useful part. Whether a combination search is arithmetic or a guess depends almost entirely on whether your invoice amounts repeat. A subscription business billing from a handful of price points is the worst case in the table: with 20 open invoices and 8 paid, every one of the 20,000 trials had more than one valid answer, averaging 2,794 of them. A book of bespoke amounts priced to the cent is a different world, ambiguous in 0.03 percent of cases at 12 open invoices and 8.85 percent at 20.

Two practical readings follow. If your amounts are distinct and the customer has few open invoices, a combination search is a reasonable assistant and you should still show the operator what it chose. If your amounts repeat, treat any combination it offers as a suggestion with no evidential weight at all, however neatly it adds up. And in both cases the number of open invoices matters more than anything else, which is a quiet argument for keeping the open items on a large account short rather than letting them accumulate.

The list is the fix, and the rail decides how it travels.

Both measurements point the same way. The information that says which invoices a payment covers is not recoverable from the amount, and no matching rule creates it. It has to arrive. The Fed brief frames the whole reconciliation phase around exactly that, and it is why the useful work here is mostly about data arriving rather than logic improving.

The ACH row is where most of the available improvement sits, because ACH carries most of the B2B count and the difference between carrying the detail and not carrying it is a code the payer selects. Asking a large customer to send on CTX rather than CCD is a conversation, not a project, and it is the sort of request that goes better when you can say precisely what you want in the addenda.

For everything that still arrives separately, and the brief is clear that plenty will, the discipline is to capture the advice as data on the day it arrives rather than leaving it in an inbox to be found later. One row per invoice referenced, holding the invoice number exactly as the customer wrote it, the amount they say they are paying and any adjustment they have applied. Stored that way the advice waits for its payment, the match becomes a lookup, and the mismatches between their reference and yours become a list you can fix at the source. The brief names incorrect invoice numbers as one of the data quality issues that prevents automated matching, and that is a problem you can only work on if you have kept the number they used.

It is also worth noticing that part of this loops back to your own invoicing. The reference your customer quotes is usually the one your invoice showed them. An invoice with a single unambiguous reference, in the same place every time, is the cheapest improvement available to a matching process that will run weeks later, and it costs nothing.

# One receipt, twelve invoices. A worked example of structure.
# No real customer, payment or company.

receipt:
  reference: ACH-20260930-004181
  received_at: 2026-09-30T09:14:00Z
  settlement_currency: USD
  amount: 340_812.00
  customer: CUST-0412

# Captured as rows on arrival, from whichever channel carried it.
remittance_advice:
  arrived_at: 2026-09-29T17:02:00Z   # a day before the money
  channel: EMAIL_ATTACHMENT
  lines:
    - customer_reference: "INV 100412"   # as the customer wrote it
      our_invoice: INV-0000100412        # resolved on our side
      amount: 28_401.00
      adjustment: null
    - customer_reference: "100413"
      our_invoice: INV-0000100413
      amount: 31_250.00
      adjustment: { code: EARLY_PAY_DISCOUNT, amount: 625.00 }
    # ... ten more lines

allocations:
  - seq: 1
    invoice: INV-0000100412
    amount: 28_401.00
    invoice_currency: USD
    journal_entry: JE-0000551903
  - seq: 2
    invoice: INV-0000100413
    amount: 31_250.00
    invoice_currency: USD
    journal_entry: JE-0000551904
  # ... ten more

# Derived, never stored: receipt amount minus the sum of allocations.
unapplied: 0.00

# Invariants checked where the rows are written, not in a report.
#   sum(allocations.amount) <= receipt.amount
#   each allocation.amount  <= that invoice's remaining balance
#   invoice payment status follows the remaining balance

How we model a receipt in Rivane.

Our customer receipts are built on the shape this article argues for, and it is worth being specific about what is actually in the system today. A receipt is a header plus N applications, each one naming a single sales invoice with its own amount, its own currency and its own journal entry reference. The header and every application are written in one serializable transaction together with the balance change on each invoice and the ledger entry, so a failure anywhere rolls the whole receipt back rather than leaving a payment recorded and the invoices untouched.

The arithmetic is enforced where the rows are written. The sum of the applications on a receipt cannot exceed the receipt amount, and an individual application cannot exceed the remaining balance of the invoice it names. Every cited invoice has to belong to the same customer and be in a state that can receive a payment, and an over application is refused with a conflict that reports the maximum amount still applicable rather than being clamped silently. Unapplied cash is derived, as the receipt amount less the sum of its applications, so it is never a suspense balance somebody has to reconcile. An invoice moves to partly paid or paid from its remaining balance rather than from a flag, in both directions, so a reversal puts the status back correctly. A receipt still in draft cannot carry applications at all.

Cross currency receipts are handled explicitly rather than by accident. Application amounts are denominated in the invoice currency while the receipt is in the settlement currency, the system detects when those differ, and it refuses the receipt unless a positive settlement rate is supplied instead of quietly defaulting to one and misstating the ledger.

Two limits, stated plainly, because they are the point of the article. Rivane does not guess the split. There is no engine that infers which twelve invoices a lump sum covers, and after running the numbers above we are not in a hurry to build one that presents a guess as an answer. The applications are supplied, from a remittance advice or by a person, and what the system guarantees is that whatever is supplied is arithmetically valid, atomically posted and individually reversible. Separately, the reconciliation tool published on this site is one to one by construction, which is why it makes a fair measuring instrument for this problem and why its results here are a description of a limit rather than a complaint about the tool.

What to do this month.

• Measure your own unapplied position before changing anything. Count receipts that could not be applied on the day they landed, and separately total their value. The two numbers usually differ by a lot, and the value number is the one that matters, because the payments a matcher cannot handle are the aggregated ones and aggregated payments are large.
• Split the exceptions by cause rather than by customer. A receipt with no remittance at all is a different fix from a receipt whose remittance arrived with three wrong invoice numbers, which is different again from a receipt that is short by a deduction nobody has coded. Each has its own owner and its own remedy, and a single unapplied bucket hides all three.
• For your top customers by receipt value, find out how they actually pay and how they send remittance today. The Fed brief describes email, EDI, supplier portals and accounting systems as the usual separate channels. Knowing which one each large customer uses is a short piece of work and it tells you where the parsing effort should go.
• Ask your largest ACH payers to send on the CTX code rather than CCD. Footnote 7 of the brief is explicit that CTX carries rich remittance and CCD does not, and this is a setting on their side, not a system you have to buy.
• Put the invoice numbers you want back into the invoice you send out. The remittance you receive is usually assembled from what your invoice showed, so an invoice with a single clear reference in a predictable place is the cheapest improvement available to the matching that happens weeks later.
• Hold allocations at invoice level rather than at payment level. One receipt for 340,812 dollars is one fact. Twelve allocations, each naming an invoice, an amount and the entry it posted, is twelve facts you can test, reverse and explain separately.
• Make unapplied cash a derived figure. If it is the payment amount minus the sum of what has been allocated, it is always right and always explains itself. If it is a balance in a suspense account maintained by journal, it drifts and someone has to reconcile it at period end.
• Decide the tolerance policy deliberately and write down what it is for. A small tolerance absorbs bank fees and rounding. A large one starts matching things that were never related, and our measurement shows exactly how that failure looks on a dashboard: greener, and wrong.

Where this goes wrong, and how to see it coming.

• Treating the unapplied total as a queue to be worked down rather than a signal about the payments arriving. Working the queue is real work and it repeats every month. The count of receipts arriving without usable remittance is the number that predicts next month, and it is the one that can be changed by talking to a customer.
• Widening the amount tolerance because the match rate looks low. In our example book, taking the tolerance to 100,000 dollars lifted the receipt match rate from 93.7 percent to 99.2 percent and the value matched from 65.1 percent to 94.3 percent, while 314 of 661 matches became pairings with an unrelated invoice and 37 lump sums posted against a single invoice. The dashboard improves and the subledger gets worse.
• Searching for the combination of invoices that adds up, without checking whether the answer is unique. On a book with six repeated price points, 20,000 trials found more than one valid combination every single time, and 2,794 of them on average for a customer with 20 open invoices paying 8. An engine that picks one is guessing, and the guess is invisible afterwards because the total ties.
• Applying a lump sum to the oldest invoices by default and calling it settled. It clears the aging and it can be wrong in a way that only surfaces when the customer disputes an invoice you have already marked paid, or when a deduction nobody coded turns up as a small residual with no explanation.
• Posting the residual to a writeoff or suspense account without naming a reason. A short payment is usually a deduction, a credit note, a bank fee or an FX difference, and each one belongs somewhere different. An unexplained residual account grows quietly and is very hard to unpick a year later.
• Letting the remittance advice live only in an inbox. The Fed brief calls this out directly: when remittance data travel separately, reassociating them with the payment requires manual handling, and advice reports may arrive hours or days before or after the payment through a completely different channel. An advice that is captured as data on arrival can wait for its payment. An advice in an inbox cannot.

Data and system considerations.

• Store remittance detail as rows, not as a blob on the payment. One row per invoice referenced, each with the invoice number as the customer wrote it, the amount they say they are paying and any adjustment they have applied. Everything useful afterwards, including matching the number they used to the number you issued, is a join on those rows.
• Keep the customer’s invoice reference exactly as received alongside your own invoice identifier. The brief names incorrect invoice numbers as a cause of exceptions. Once both forms are stored, the mismatches become a list you can fix at the source rather than a lookup someone redoes by hand every month.
• Give every allocation its own amount, its own target invoice and its own journal entry reference. That is what makes a single allocation reversible without unwinding the whole receipt, and it is what lets an invoice answer the question of how it was paid.
• Enforce the arithmetic where the data is written, not in a report. The sum of allocations on a receipt cannot exceed the receipt, and an allocation cannot exceed the remaining balance of the invoice it names. Checked at write time these are cheap. Checked in a monthly report they are findings.
• Keep the settlement currency and the invoice currency apart. The cash arrives in one currency and the receivable clears in another, and comparing the two totals only means something when they are the same. A system that quietly treats a missing rate as one will misstate the ledger and give no sign that it did.
• Record when the remittance advice arrived, separately from when the payment arrived. The gap between the two is the thing you are actually managing, and it is invisible if both are stamped with the posting date.
• Derive the payment status of an invoice from its remaining balance rather than storing it as a flag someone sets. A flag and a balance can disagree. A derived status cannot, and it also moves correctly when an allocation is reversed.

The evidence file for cash application.

• For each receipt: the bank record as received, the remittance advice as received with its arrival time and channel, and the list of allocations made against it with amounts that sum to no more than the receipt.
• For each allocation: the invoice it cleared, the amount, the journal entry it posted and the person or process that created it.
• The unapplied balance at each period end, derived as receipts less allocations, with the individual receipts that make it up rather than a single account total.
• For every residual left after allocation: the reason it was left, coded, and the entry that disposed of it. Deductions, credit notes, bank charges and FX differences each belong to a different account and a different conversation.
• The tolerance settings in force during the period and the date any of them changed, since a tolerance change alters which matches the system was willing to make.
• A list of receipts applied by judgement rather than by a remittance line, which is the population worth sampling if anyone asks how the receivables ledger was maintained.

Questions worth asking this week.

• How much of last month’s cash could not be applied on the day it arrived, measured in money rather than in number of receipts?
• For our ten largest customers, does the remittance detail arrive with the payment or somewhere else, and which channel is it?
• Which of our ACH payers are sending on CCD when CTX would carry the invoice detail?
• When a lump sum is applied, does the system record which invoices it cleared and how it decided, or only that the total was applied?
• What is our amount tolerance set to, who last changed it, and what was it meant to absorb?
• If a customer disputes one invoice inside a payment we applied three months ago, can we reverse that one allocation without touching the other eleven?

A list that arrives beats a rule that guesses.

The encouraging part is how tractable this turns out to be once it is measured. The gap in our example book was not a tuning problem and no setting closed it, which means the months teams spend adjusting match rules were never going to pay off. What closes it is information that already exists on the payer side and simply needs a route to you: a code on an ACH file, a structured field on a wire, a portal export captured as rows instead of read by a person. Those are conversations and small pieces of plumbing, and they compound, because a customer who starts sending usable remittance keeps sending it.

If you want to see the shape of your own position, take one month of bank credits and one month of open invoices and put them through the Rivane reconciliation tool. Look at the two numbers separately: the share of receipts it could match, and the share of the money. The distance between them is the part of your cash that arrives without a list, and it is the number worth taking to your largest payers. It runs in the browser and it is free to use.

Sources

• Federal Reserve Bank of Cleveland, Payments Research Brief, B2B Payments: Business Processing and Challenges to Achieving Straight-Through Processing, published 25 September 2026 by Todd Albers, Sam Baird, Fumiko Hayashi, Ken Isaacson and Aditi Routh. The page was downloaded and read in full rather than summarised. Source for the five phases of business processing and the numbered steps inside them, for the statement that matching may be automatic when the supplier receives structured remittance data along with the payment while manual handling is needed when remittance data are detached from the payment or the AR function lacks an automated bank feed, for the passage on complex relationships among invoices, payments and remittance advice reports including the single payment aggregated to cover multiple underlying remittance items, for the point that missing data elements and incorrect invoice numbers create exceptions, for the message format map of wire and instant on ISO 20022, card on ISO 8583 and ACH on ANSI ASC X12, for the note that each translation point introduces the potential for errors, data loss and processing delays, and for footnote 7 on the ACH CTX and CCD codes.
• Federal Reserve Bank of Cleveland, Payments Research Brief, B2B Payments: A Gradual Shift from Checks to Electronic Payment Methods, published 21 September 2026, part one of the same series. Downloaded and read. Source for the B2B payment counts and values by method, including ACH rising from 3.6 billion payments in 2015 to 8.7 billion in 2024 and 41 percent of the B2B count, checks falling from 4.6 billion to 2.7 billion while their value held near 15 trillion dollars, and the average 2024 transaction size of 8,084 dollars for ACH and 5,577 dollars for a check.
• Accredited Standards Committee X9, ISO 20022 Remittance Market Practices Guide, cited by the Cleveland Fed brief as one of the standardisation efforts already published. Referenced here for the existence and scope of the guide rather than for any figure.
• Digital Business Networks Alliance, Profile for Remittance Advice, version 1.2.1. Referenced for the existence of a published remittance advice profile on the alliance exchange framework, which the Cleveland Fed brief records the alliance as having adopted in 2024.
• Nacha, ISO 20022 Credit Transaction Guide to Mapping US ACH File Formats, covering CCD, CTX, PPD and outbound IAT. Cited by the Cleveland Fed brief as the bridge between the ISO 20022 standard and the established ACH format, and referenced here for that role.
• Emagia, Unapplied Cash in Cash Application, read as one of the current top answers to this question. It defines unapplied cash and lists causes and remedies well, and it does not measure what a matching engine leaves unapplied or when a combination search has more than one answer.
• Oracle JD Edwards EnterpriseOne Accounts Receivable Implementation Guide, Understanding Unapplied Receipts, read as a second current answer. It documents the unapplied receipt record and how it is later applied, from the ERP side, and likewise does not quantify either limit.
• Rivane reconciliation tool, published on this site. Every figure in the matching tables was produced by running its published engine logic over the example book described in the article. The engine source is a small, pure module: a reference pass, then an amount and nearby date pass, with each row consumed at most once.

A note on how this was researched. Both Cleveland Fed research briefs were downloaded and read in full as text rather than summarised, and every statement attributed to them here comes from a passage that was read on the page. The authors note that the views are their own and do not necessarily reflect the positions of the Federal Reserve Banks of Cleveland and Kansas City or the Federal Reserve System. The X9 guide, the alliance remittance profile and the Nacha mapping guide are cited for their existence and role as the brief describes them, not for any figure. The two practitioner and vendor pages are cited only to describe what current answers to this question cover. No suitable public posts on X were found on this topic during research, so none are embedded and none were invented. Every matching and ambiguity figure was produced by running code over an example book that is synthetic and describes no real company, customer, invoice or payment, using the published engine logic of the reconciliation tool on this site for the matching tables. The 340,812 dollar receipt in the opening is an example of the case, not a real payment. Statements about Rivane describe what is built and shipped today, including the stated limits. Rivane has no public customers to cite and none are implied. Nothing here is accounting, audit or legal advice.