How Do You Apply a Customer Payment With No Remittance Detail?

A single ACH credit arrives for one of your larger customers. The bank feed says "ACH CREDIT RIVERTOWN MECH 13,520.00" and nothing else: no invoice numbers, no remittance advice, no note. That customer has five open items on the ledger. Now someone has to decide which invoices this money clears. This is cash application, and when the remittance detail is missing it becomes the quiet time-sink of an accounts receivable team, because you are working backward from the money instead of forward from the paperwork.

The short answer is to split the payment into what is certain and what is not. Apply the portion that every reasonable reading of the ledger agrees on, hold the ambiguous remainder as unapplied cash with a reason, route that remainder to a named person before any collection message goes out, and let rules handle only the matches that carry real certainty. This article shows where that line sits and how a person resolves the part a rule should not.

This is a different job from reconciling the bank feed to the ledger, which asks whether a bank line is already recorded on your books. Cash application asks a narrower question on the receivables side: which of this customer's open invoices does this receipt pay? The receipt is real and posted; the work is the allocation.

See how a finance team routes an ambiguous item to a named owner.

Why the remittance is so often missing

The detail is missing by design more than by carelessness. The most common business-to-business ACH format carries the dollars with little or no room for invoice-level remittance; a richer format or a newer message type has to be used, and both the payer's and the payee's banks have to support it, before invoice numbers travel alongside the payment. Nacha, the body that writes the ACH rules, describes its Request for Payment flow precisely this way: the buyer sends the payment as a CTX entry that "includes the required remittance advice details," so that when the seller receives it, the payment "will include all the information needed to post the payment automatically," in its explanation of Request for Payment on U.S. ACH. The plain implication is that a standard credit frequently does not carry that detail, which is why a payment can land as a bare dollar amount.

Banks that run large receivables operations describe the same reality. J.P. Morgan notes that "payments may arrive through ACH, wires, checks or other channels, often with incomplete or inconsistent remittance information," and lists unapplied cash balances as a metric to watch, in its treasury guidance on receivables. Treat that as service positioning rather than measured data, but the operating description matches what an AR desk sees: the money and the explanation travel separately, and sometimes the explanation never arrives.

A confidence ladder for applying a receipt

Treat each incoming payment as a match with a confidence level, and let the confidence decide whether a rule or a person handles it. This ladder is a decision method, not a benchmark or a guarantee; set the thresholds to your own customers and tolerance for a misapplied receipt.

The point of the ladder is that an exact-looking total is not the top of it. Applying a payment to the oldest invoices simply because the arithmetic can be made to work is how a disputed or already-credited invoice gets marked paid, or how a not-yet-due invoice gets a partial it never received.

A worked allocation packet

The following example is illustrative; the customer, invoices, and amounts are assumptions, not a client result. Rivertown Mechanical, a plumbing contractor, sends one ACH payment of $13,520.00 with no remittance detail. Their open items when it lands:

Start with what is certain. The two oldest invoices together are $6,480.00 + $5,140.00 = $11,620.00, and every reading of this payment includes them, so apply those two now. That leaves an ambiguous remainder of $13,520.00 - $11,620.00 = $1,900.00, and the remainder is where the judgment sits. It has two clean but incompatible readings:

• A partial on the current invoice. The $1,900.00 is a down payment on INV-2246, leaving it $3,900.00 - $1,900.00 = $2,000.00 open, with the disputed INV-2251 still fully outstanding.
• Full payment of the disputed invoice. The $1,900.00 exactly equals the balance of INV-2251, so the customer may have paid the disputed invoice to clear it, leaving the not-yet-due INV-2246 fully open.

Both readings sum to the same $13,520.00, and the CM-118 credit sits unused in each. You cannot tell them apart from the ledger alone, and the difference matters: under the first reading, INV-2251 stays open and the customer gets a dunning notice for an invoice they may believe they just paid, on top of a dispute they already raised. So the payment resolves into three actions, not one. Apply the certain $11,620.00. Hold the $1,900.00 as unapplied cash, coded "awaiting remittance, possible dispute," rather than posting it to a guess. Route that $1,900.00 together with the open CM-118 credit to the person who owns receivables research, with a note asking the customer's accounts payable contact which invoice the $1,900.00 clears and whether the $780.00 credit should be taken now.

Who owns the held amount, and what waits

Unapplied cash is only handled when a person owns it. Name the role, usually an AR analyst or the receivables lead, give the held items a service level so a payment does not sit unapplied for a week, and decide two things in advance. First, who may approve applying a short-payment against a credit or writing off a small deduction, because a deduction has a reason and an approver, not an automatic offset. Second, and most important for the customer relationship, hold automated dunning on any invoice touched by an unapplied receipt. In the Rivertown packet, that means no reminder goes out on INV-2251 or INV-2246 until the $1,900.00 is resolved. A collection message sent against a disputed, possibly-paid invoice undoes more goodwill than the reminder recovers.

The mechanics of parking a receipt are standard, not a custom build. Ledgers separate receiving a payment from applying it: money can be recorded against the customer and left waiting before anyone decides which invoices it clears. Oracle's NetSuite documentation, for one, describes putting a payment in an Undeposited Funds account when "your bank account is not credited until you actually deposit the funds," so the receipt is recorded and pending rather than lost, in its guidance on managing undeposited customer payments. Most ledgers also let a payment sit as an unapplied or on-account balance against the customer until its invoices are settled. The tooling to park an ambiguous receipt already exists; the discipline to use it instead of forcing a match is the part that has to be decided.

Where software helps, and where it does not

Cash application software is genuinely useful in one place on the ladder: when remittance detail exists but is not structured. A remittance emailed as a PDF, a portal export, or a scanned check stub can be read, its invoice references extracted, and the payment matched with high confidence. That is real work removed, and it is worth buying or configuring for a customer base that sends detail in inconvenient formats. What software cannot decide is the coincidental-match and short-payment rows of the ladder, because those turn on intent and on a dispute or credit that lives outside the payment: whether the customer meant to clear the disputed invoice, whether a deduction is valid, whether a credit applies. Automating those is how a wrong allocation flows silently into the subledger. Before adding a matching tool, confirm the ledger you already run can park an unapplied receipt and route it, because most can; the gap is usually process, not product.

What to measure

Track three numbers each week and keep them apart. The share of receipts applied automatically tells you how well rules and remittance are working. The amount and age of unapplied cash tells you whether held items are actually being resolved or just accumulating. The share of receipts a person had to correct after they posted tells you whether the automatic lane is too aggressive. A rising auto-apply rate is only good news if the correction rate and the unapplied-cash age do not rise with it. Report the hours the team no longer spends hunting for remittance as freed capacity, not as cash saved, and keep unapplied cash separate from days sales outstanding; clearing a backlog of unapplied receipts can move the reported DSO without a single dollar arriving sooner. Measure against your own baseline and you will know whether the split between rules and people is holding.