One payment, forty invoices, no remittance advice

A credit lands for 48,210.00 and nothing in the ledger is 48,210.00. Before anyone files it as unidentified, be clear about what is missing. Not the payment, which is sitting in the account, but 2 joins: which customer sent it, and which of their open invoices it was meant to clear. Those are separate problems, solved in that order, because subset matching against the wrong customer's open items will produce an answer and the answer will be wrong.

The reason to be strict is that the costs are asymmetric. An unapplied receipt is visible and ages in a report. A wrongly applied one is invisible: the invoice it cleared goes quiet, the invoice it should have cleared keeps ageing and gets chased, and the error resurfaces in November as a dispute about a payment made in July. Design for a system that would rather leave money unapplied than apply it plausibly.

The query that decides whether this receipt is really unidentifiable

Run this before touching any matching rule. One candidate-set query separates the 3 states that matter: solvable now, ambiguous, and genuinely unknown.

1. Resolve the payer from the account, not the name. Take the counterparty account identifier off the bank feed and look it up against every account that has ever paid you. One customer back means you have your ledger; 2 means a shared payment factory and a larger problem.
2. Pull the candidate pool. Every open item for that customer and its known sister entities, dated between the oldest open item and the receipt. Include credit notes as negative items — a missing credit note is behind a large share of failed matches.
3. Search exact subsets first. Find every combination whose net total equals the receipt to the cent, before any tolerance is applied, because tolerance multiplies what fits.
4. Count the answers, then act on the count. Exactly 1 subset applies. 2 or more stops. Zero widens once, by one bounded step, and counts again.
5. Store the search, not just the outcome. Keep the pool, the subsets found and the rule that decided, so a disputed application can be explained a year later.

Step 1 carries most of the value and is the step teams skip, because the statement shows a name that looks close enough. It is not. That name is free text that has passed through the payer's ERP, their bank, any intermediaries and your bank's statement generator, and each of those may truncate or rewrite it. What survives that journey is covered in what a payment narration field can actually carry.

Four ways the remittance advice exists but never reaches your ledger

Usually the customer did send one. It went somewhere your matching process cannot see, and each destination has a different fix and a different owner.

Row 2 costs the most, because it looks like a data problem and is a routing problem. The detail exists in full, in a file, and nobody built the path from that file into the matcher — so somebody retypes 40 invoice numbers. That path is the sort of plumbing we scope as internal tools and operations builds.

The alias record that stops the same payer being a stranger every month

Payer resolution deserves a stored object rather than a fuzzy-name function called at match time, because resolution is evidence you accumulate. Work out once that a remitting account belongs to a customer and it should never be worked out again.

• Key on the account identifier. It does not change when the payer renames a subsidiary or moves the payment run to a treasury team.
• Keep the raw string. Store the counterparty name exactly as delivered alongside a normalised form; the raw string is how a bad alias gets audited.
• Carry the evidence and the confirmer. An alias a collector confirmed on a call is stronger than one inferred from a single match, and the record should show which it is.
• Hold a confidence state, not a boolean. Provisional aliases may only propose a pool. Confirmed aliases may let a single exact subset auto-apply.
• Expire nothing automatically. An alias falling out of use is not evidence it was wrong, and deleting it destroys the audit trail.

Fuzzy name matching is a guess dressed as an algorithm. An alias table is the same guess, made once, by a person, with their name on it.

When several combinations of invoices add up to the same number

Understand the shape of the search before tuning it. 40 open items admit roughly 1.1 trillion combinations, which nobody enumerates. Bounding subset size collapses that: combinations of up to 6 items drawn from 40 come to about 4.6 million, which a database walks in well under a second. Almost every real lump-sum payment clears a handful of invoices, so the bound costs little and buys a search that terminates.

The interesting failure is not an empty result. It is several results. As the pool grows and amounts cluster — recurring monthly charges, identical licence lines, the same freight fee on every consignment — the chance that 2 different subsets sum to the same total rises sharply. Widening tolerance makes it worse, because every item allowed to be approximately right multiplies the combinations that qualify.

Where the shortfall is systematic rather than random — the same payer, always a little light — a wider tolerance is the wrong instrument, because the gap has a cause and an owner. That diagnosis is in why payments keep arriving short by small amounts. The order of operations across exact, tolerance, subset and learned matching belongs to the cash-application matcher specification; this page governs only the case where the remittance is absent.

Getting the payer to tell you what they paid for

Self-declaration is the third rung and it works better than its reputation, provided the question is closed. "We received a payment, please advise allocation" asks their AP team to do reconciliation on your behalf, and they will not. A message listing their open items with your invoice number, their PO number, the date and the amount, asking them to tick what this payment covers, is a 2-minute job at their end and arrives already structured at yours.

1. Send to the remittance address, not the buyer. The person who ran the payment can answer; the person who signed the contract cannot.
2. Lead with their reference. Their ledger is organised by PO number, so a list sorted by your invoice number is a list they must translate first.
3. Offer a reply that is not prose. Checkboxes against rendered open items, or a table they amend and return, both beat free text you then have to parse.
4. Set an expiry and a fallback. If nothing returns inside 14 days the receipt stays unapplied and the account goes to a person — it does not quietly land on the oldest invoice.

When those messages go unanswered it is usually the address rather than the request, which is the same failure that kills payment reminders. The diagnosis in why reminder emails go unanswered applies here unchanged.

What the rest of the process must do while the receipt is unresolved

An unresolved receipt is not inert. It changes what everyone else should be doing, and a system that fails to propagate that damages the relationship while you work it out.

• Suppress dunning on the candidate set. Every invoice in a live pool is possibly paid, and chasing it while you hold their money is the most damaging thing the automation can do.
• Keep the balance visible, not buried. It belongs on the account as unapplied cash with an owner and a due-by date, in the shape set out in what unapplied cash really represents.
• Feed the state into prioritisation. An account sitting on a large unresolved receipt needs a different action from one that has not paid, which is why the collections worklist should be ordered by what a call can change.
• Escalate on age, not size. A small receipt unidentified for 90 days is a broken process; a large one from Tuesday is just Tuesday.

All of it sits inside receivables, cash application and dunning, and in the finance operations builds that carry it the hard part was never the arithmetic. It was deciding in advance, in writing, what the software is allowed to conclude on its own.

• cash application
• receivables
• payment matching
• finance operations