A line sits in your bank statement: a date, an amount, a payment type, and a truncated sender name with the accents stripped out. No invoice number, no usable remittance text. The money is in the account, but in your ledger it has no owner. Until that line is tied to a customer, both your collections report and the customer's payables report are wrong.
This is one of the quietest time sinks in finance. Nobody reports "today I investigated unapplied cash," yet the hours are real, and they land in the week you can least afford them. Below are five routes to the owner of that line — how strong each signal is, where it misleads you, and why none of them alone should be allowed to close anything.
Unapplied cash: the three identities a statement line is missing
Before a receipt can be applied, three separate identities have to be established, and they are not the same thing.
Who sent it. The sender text is the account title the sending bank passed along — often cut off at a field-length limit, stripped of accented characters, and sometimes belonging to a parent entity, a factoring company, or a payment institution rather than the customer you invoiced.
Which account it belongs to. Payer and debtor are frequently different legal entities. Under a group cash pool they are almost never the same.
Which invoices it clears. Identifying the customer is only half the job. How the amount is applied — in what order, to which open items, in full or in part — is a separate question, covered in our piece on why payment-to-invoice matching is hard.
While any of the three is missing, the line sits as unapplied cash. Sitting there is fine; being forgotten is not. Forgotten cash turns into an invoice the customer has paid but that still shows as open — the phantom debt problem. The cost is a dunning email that should never have been sent, a damaged relationship, and a reconciliation difference nobody can trace at year-end.
Start with the sender name — and know why it is the weakest signal
The first instinct is correct: compare the sender text against your customer master. The problem is that the two strings are never written identically.
Payment channels commonly transmit a reduced character set, so accented names arrive flattened — a German "MÜLLER" becomes "MULLER", a Turkish "İŞ" becomes "IS". On top of that come legal-form suffixes and generic sector words: GmbH, S.A., Ltd, A.Ş., trading, industry, construction. Then a field-length limit cuts the tail off the long ones, which is exactly where the distinguishing word usually sits.
The fix is to fold both sides with the same rule: upper-case, strip diacritics, remove punctuation, drop legal-form and generic sector tokens, then compare what remains — as a similarity score, not an equality test, because a truncated name never matches exactly.
This is still the least reliable of the five routes, for an ironic reason: companies inside the same group share the same core word, so after folding, two sister companies may be separated by a single token. Name similarity produces a candidate list, never a decision.
When the remittance field comes back empty
Most cash application work is really a fight over one small field. A cross-border payment carries a free-text remittance line that the payer fills in by hand, if at all. Domestic instant-payment schemes carry an even shorter one. Every hop — the payer's ERP, their bank, the correspondent, your bank, your statement export — can truncate it, and the statement PDF you finally open is the lossiest version of all.
Two moves recover more identity than any matching algorithm can.
Pull the statement in a structured format rather than as a PDF. Bank feeds built on the ISO 20022 message family carry the sender name, the sender account and the remittance information in separate, labelled fields. A PDF flattens all of that into one string your parser then has to guess at. If your bank offers a structured statement feed, the field you thought was missing is often already there — it was destroyed in the export, not in the payment.
Ask payers for a structured reference, once. ISO 20022 supports a structured creditor reference: a machine-checkable code you print on the invoice and the payer copies into the payment. Customers who adopt it stop generating unapplied cash almost entirely. It works only for the ones who agree, which is why the remaining routes still matter. Where volume justifies it, a lockbox arrangement or a virtual account per customer moves the problem upstream in the same way: the receiving account number itself carries the identity, so the sender text is no longer the only clue.
Amount and date proximity: decisive on odd numbers, useless on round ones
The next signal is arithmetic. If the incoming amount equals the remaining balance of exactly one open invoice, that is strong evidence — and how strong depends on how unusual the number is.
An odd amount, say 187,432.60, is likely unique across your open items; a match is close to conclusive. A round amount behaves the opposite way: 50,000 can collide with dozens of lines. Round amounts are usually on-account payments; they belong to a customer before they belong to an invoice.
Dates help, but weakly. A receipt landing near a due date narrows the list, yet paying days early or weeks late is ordinary behaviour, and on cross-border payments the value date on your statement can sit days away from the date the payer booked.
The trap here is small differences. Wire fees, correspondent-bank deductions, currency conversion, or an early-payment discount the customer decided to take shift the amount by cents or by a few hundred. Comparison should run against a defined tolerance band rather than exact equality — and every line closed inside tolerance should be flagged, because that difference still has to be explained one day.
Adding up open invoices — and why a sum that works can still be wrong
If no single invoice matches, a sum of several might. Bulk payment is the norm: the customer clears three of the month's invoices with one transfer and labels none of them.
Combination search works, but it is dangerous. As open items grow, coincidental subsets that happen to add up grow much faster. With twenty open invoices, finding more than one distinct triple equal to the incoming amount is unremarkable. "A solution exists" is not the same statement as "this is the right solution." So a combination match is not evidence on its own; it needs a supporting signal — the invoices falling in the same due-date window, belonging to the same order group, or the customer having behaved this way before.
Your own history is evidence you already own
The most reliable source is usually your own past work. If a payment from the same account, or carrying the same sender text, was previously matched and approved by a person, you hold an identity record rather than a guess. A transfer type solved once should not be researched from scratch a second time.
In practice this means writing the answer down where the whole team can reach it: a shared record of which sender text and which account correspond to which customer. Most teams already hold that knowledge — in one person's head. When that person takes leave, the knowledge takes leave with them.
This route ages, too. Account ownership changes: receivables get assigned to a factoring company, group treasury moves to another entity, the customer switches banks. A written record needs periodic review; it speeds the work up but does not exempt it from checking.
Ask the customer — but ask something they can answer at a glance
The cheapest and most accurate method is still asking, provided you ask well. An email saying "is this payment yours?" usually goes unanswered, because it forces the recipient to run the same investigation from zero.
The question that works does the recipient's work for them: send the date, the amount, the sender text exactly as it appears in your statement, and your list of their open invoices. The customer finds their own payment record at a glance and tells you what it was meant to clear.
One step further is to have the customer share their own statement of account. Even a partial one covering a single month resolves most unowned lines in a single pass. For the process on the bank side, see our step-by-step bank reconciliation guide.
A hypothetical example: three signals stacking up
Consider a made-up but entirely typical line: a compressed, accent-stripped company name and an amount of 187,432.60.
Name folding returns three candidates; two of them belong to the same group. Not enough on its own.
Amount checking shows that two open invoices of one candidate sum exactly to that figure, and that no such combination exists for the other two. The list drops to one — but a combination is not evidence by itself.
History checking finds a receipt from the same account two months earlier, manually approved and applied to that same customer. Three independent signals now point to the same place.
The decision still belongs to a person: three written reasons sit side by side, the accountant approves, the line closes, and the team writes the identity down so the next transfer from that account is not researched again. The investigation took minutes — accountability did not move.
Why cash application decisions must stay with a human
The appeal of automatic matching is speed, and so is its risk. Cash applied to the wrong customer is not one error but two: an invoice closes on your side that should have stayed open, and an invoice stays open on the customer's side although it was paid. Both surface months later, usually in front of the customer.
The scale of everyday error supports caution. In Gartner research from July 2023 (n=497), 18% of accountants reported making errors every day and 59% a few times a month. In field audits compiled by Raymond Panko, roughly 94% of the operational spreadsheets examined contained at least one error. (The repeated line that "88% of spreadsheets contain errors" is a misquote; 88 is the number of spreadsheets audited.) APQC data puts duplicate or erroneous payments at 0.8% of annual disbursements for top performers and 2% for bottom performers.
There is an extreme reminder of how large a transfer mistake can get: in August 2020 Citibank sent roughly 900 million dollars of principal on the Revlon loan when it intended to send 7.8 million dollars of interest. Errors on the transfer side do not respect scale, which is why a human checkpoint is a control rather than a delay.
One misconception is worth correcting: reconciliation is not a fraud-detection tool. In ACFE's 2024 "Occupational Fraud: A Report to the Nations," tips were the initial detection method in 43% of cases and account reconciliation in 5%. (ACFE's 14th edition appeared in 2026; these figures are from the 2024 edition.) Reconciliation keeps records accurate and makes anomalies visible — it does not solve fraud.
Where iFinances fits
iFinances brings ledger and ERP records, the bank statement, and e-invoice data into one table. For unapplied cash it runs the first three of the five routes above systematically: candidate customers from accent-folding name similarity, amount comparison with a tolerance band and official central-bank rates for cross-currency lines, and partial and bulk payment allocation through FIFO and invoice-specific application. Every suggestion carries a written reason — the amount agrees, the date fits, the reference points to this invoice. Missing invoices, duplicate entries, and out-of-pattern amounts are flagged separately.
The fifth route has a path too: you send the counterparty a secure link and they upload their own statement, with no software needed on their side. Excel and CSV ingestion is ERP-agnostic.
The limits are worth stating plainly: iFinances does not keep books, does not create entries, and never closes a line on its own. What it produces is a suggestion and a reason; a person always makes the closing decision. You can see how this works on our bank reconciliation page.
Frequently Asked Questions
The sender name in my statement looks meaningless. Can I get more detail from the bank?
Usually yes. The transaction detail or payment advice view in online and corporate banking carries more fields than the compressed statement line: the full sender title, the sender account, and the remittance field are often visible there. Pulling the statement as a structured feed or as CSV instead of PDF also reduces field loss, because each field arrives labelled rather than concatenated into one string. Failing that, request the payment advice for that transaction from your bank.
The remittance advice arrived, but the total does not match the invoices it lists. What now?
Treat the advice as a candidate list, not as an instruction. Work through the usual suspects before going back to the customer: a deduction taken for a credit note the advice does not mention, an early-payment discount applied unilaterally, wire or correspondent-bank fees taken out of the principal, and currency conversion where the invoice currency differs from the payment currency. If the gap survives all four, apply what the advice does explain, leave the remainder as unapplied cash, and ask one specific question about the difference rather than a general one about the whole payment.
Should unidentified cash be posted to a customer account anyway?
No. Posting cash to a guessed customer buries the error inside the ledger and returns it months later as a reconciliation difference. Common practice is to hold such amounts in a suspense-type account until the identity is confirmed, and to age the waiting lines regularly so that nothing sits there quietly for a year. Which account to use depends on your chart of accounts and your accountant.
If the amount matches an invoice exactly, can I close it?
Not on that basis alone. An exact match on an odd amount is strong evidence; on round amounts, or where many open invoices carry similar balances, coincidental matches are ordinary. Require two independent signals: amount plus sender identity, or amount plus a previously approved match for the same sender.
Can cash application be fully automated?
You can automate the investigation, not the decision. Generating candidates, scoring them and writing the reason next to each one is machine work; declaring that a line belongs to a given customer is human work. Automation also remains the exception rather than the rule: Ventana Research found in 2023 that 31% of organisations automate most or all of their reconciliations.
✦ iFinances — See what you're missing.
