A new line appears on your bank statement: 148,500 arrived. The date is clear, the amount is clear. In the description field, there is a single phrase: "Payment for ORD-2024-0417." No company name, no tax ID, no invoice number. Whose money is this, and which invoice does it settle?
Saying "the money arrived" is easy. The hard part is writing that money against the right invoice. And that decision isn't made once — it's made thousands of times across a month. Every one of them has to be right, because when a single one is made wrong, that error settles quietly onto your balance sheet and surfaces months later at its most expensive point.
This is the third chapter in our "Invisible Balance Sheet" series. The thread running through it is that thin layer between what's recorded and what's real — the one nobody looks at. In the second chapter, we explained how a phantom debt is born, and why a paid receivable can show as open for months. Here we step one move earlier: to the moment that gives rise to that phantom debt — the decision point where a payment is written to the correct invoice, or fails to be.
Matching is really a chain of decisions
In accounting, "matching" — linking an incoming payment to the invoice it belongs to — looks like a single move. In practice it means answering four separate questions at the same time:
- Who sent this money?
- Which invoice does it belong to?
- Is the amount exact, short, or over?
- If there are several open invoices, which one does it reduce?
When the description is clean — company name, amount and date all agree — this chain takes seconds. The name on the statement matches the customer, the amount matches an open invoice, the date falls inside the due-date window, and the link forms on its own.
The problem is that the description is rarely clean. In practice, the description field on a corporate bank statement carries no standard identifier. Some payments arrive with a reference number, some with an order code, some with an abbreviation a clerk invented, and some arrive entirely blank. That ambiguity makes each of the four questions harder on its own.
"Money arrived" is an event; "which invoice it was written to" is a decision. That decision has to be made thousands of times a month without error — and that's exactly where the difficulty begins.
One payment can leave several invoices half-settled: the partial-payment problem
The most common tangle comes from a partial payment — where a customer sends only part of their total balance. With three open invoices, the customer wires a portion of what they owe; the incoming amount matches none of the invoices exactly, settling two in full and leaving the third half-paid.
Here a discipline steps in: FIFO — short for "first in, first out," the rule of settling the oldest open invoice first. The standard accounting approach is to write an incoming payment against the oldest open invoice. The logic is sound: the oldest debt carries the longest delay and the highest risk, so clearing it first keeps both the aging picture accurate and the collection priority intact.
It sounds simple. But when a customer has dozens of open invoices, tracking which payment settled which invoice, and by how much, in the correct order, stops being a task anyone can sustain by hand.
What does a wrong FIFO order break?
A slipped FIFO order isn't a single line sitting in the wrong place — it's a chain reaction:
- A settled old invoice shows as open. If the payment is written to a newer invoice, an old debt that was actually collected keeps sitting in the ledger — and turns red as it ages.
- A new invoice is counted as settled before it's due. That means treating an as-yet-uncollected receivable as "collected," inflating your cash-flow expectation early.
- The aging table stops reflecting reality. You only see that a risk you thought was 90 days old is really 210 days old once the order is set correctly.
Partial payments and FIFO are about surfacing how a payment settled an invoice. Making that settlement logic traceable line by line is the core of an invoice-payment settlement view that shows which payment closed which invoice, and by how much.
Whose money is it? — when the description has no company name
The most demanding case is a payment that carries a reference but no identity. A purchase order (PO) or order number is embedded in the bank description — something like "ORD-2024-0417" — but the paying company's name is nowhere in it.
The reference can lead you to the right invoice, provided you can match it against your order records. If you can't, the money is orphaned: it sits on the statement but can't be linked to any invoice. This is called unapplied cash — money that has been collected but not applied to an invoice. Unapplied cash isn't a loss on its own; it's the threshold of one. As long as it sits there, it neither reduces that customer's balance nor lands in the right place on your cash picture.
Two further complications weigh this picture down.
Third-party transfers: looking beyond the name
The payment may be made not by your customer but by another legal entity on their behalf — a group company, a collection agent, a dealer. The name on the statement isn't your customer's, yet the money settles your customer's debt. A check that looks only at the name gets this wrong: it suspends a genuine collection as "unknown company," or worse, closes the wrong customer's balance.
The bank-line identity gate: not every credit is a collection
Not every credit line on a statement is a customer payment. Interest income, an FX revaluation adjustment, an internal transfer, a fee refund — these appear as credits too. Mistake one of them for a customer collection and you write a payment that never existed against a real invoice. That settles the invoice falsely: the debt looks cleared in the ledger, while the customer still owes it.
This "identity gate" — the filter that tests whether each line is really a customer collection — is the quietest but most critical step in matching. A system that skips it produces a reconciliation that looks correct but rests on a rotten foundation.
Why trusting a single source isn't enough
The bank statement, viewed alone, can mislead; the e-invoice list, alone, can be incomplete; the ledger entry, alone, shows only intent, not what actually happened. Writing a payment to the right invoice is really a matter of seating three separate records on the same reality: the money movement the bank saw, the receivable the e-invoice shows, and the balance the ledger holds.
When these three sources confirm one another, the match is solid. When one diverges from the others, that is exactly the line to investigate. This is why serious reconciliation rests not on a single file but on a three-way approach where bank, e-invoice and ledger are cross-verified. You can only say a payment was written to "the right invoice" when these three sources meet on the same line.
Why people and Excel break at scale
Each of these decisions can be solved by a person on its own. The problem is the count.
Tens of thousands of statement lines, several companies, two currencies — a EUR invoice and a TRY payment can concern the same debt, which we call cross-currency matching: reconciling a collection in one currency by converting it into the invoice's currency, typically at the CBRT official rate (the Central Bank of the Republic of Türkiye's published exchange rate). On top of that sits a FIFO order tracked by hand. Eyeballing and VLOOKUP carry you only so far.
A single identity gate a tired eye misses becomes, a week later, the question "why does this customer still show as owing?" We treat how insidious a layer cross-currency is on its own — how FX difference seeps into the balance sheet on foreign-currency invoices — in a separate chapter; here it's enough to note how much it complicates matching.
The issue isn't the accountant's carelessness; it's capacity. No human is built to repeat the same five decisions across tens of thousands of lines without error. Excel is a calculation tool, not a decision engine. It places two sources side by side, but it can't ask "which order does this reference belong to, which group company's dealer is this name, is this credit line a real collection" on your behalf.
What systematic matching does — and doesn't do
Systematic matching first handles the certain cases: when tax ID, company name, amount and date all agree, it forms the link. That's the majority of all lines, and it's mechanical.
Where there's no clear reference, fuzzy matching steps in — weighing, by probability, combinations of name, reference and amount that aren't identical but very likely point to the same party. It compares "ORD-2024-0417" against your order records; it links a group company's name to the actual customer; it weighs whether an amount off by a single unit still points to the same invoice.
Then it applies the identity gate: separating deposit, FX and transfer lines from customer payments. It traces a third-party transfer beyond the name, through the reference.
What it does is not make the decision, but prepare it. It marks the certain as certain and the uncertain as uncertain, and leaves the remaining handful of lines — the ones that genuinely need judgment — to a person. It doesn't take the accountant's job away; it frees them from tens of thousands of mechanical decisions and focuses them where real judgment is required. We build this distinction as the shared design principle across every module: the system reveals, the person decides.
The cost of a wrong match
When a payment is written to the wrong invoice, three things break at once:
- A settled debt shows as open — we call this phantom debt, a receivable that doesn't really exist but sits in the ledger.
- The aging table slips — a receivable that isn't past due drops into the "overdue" ranks, or the reverse.
- Your collections team spends effort for nothing — calling, writing to, even drafting a dunning notice for a customer who has already paid.
The last is the most expensive, because it erodes not just time but customer trust. The other side knows they paid; you tell them they didn't. Every call wears a little more on the relationship you built.
That same wrong match also feeds another risk: overlooked duplicates and missing invoices. A line being "different from expected" isn't always an error; often it's a signal. We treat why financial anomalies — a missing invoice, a duplicate entry, an outlier amount — should be questioned rather than deleted in a separate chapter. Matching and anomaly detection are two sides of the same coin: one forms the link, the other asks why an unformed link wasn't formed.
"The right invoice" is a ground for judgment, not a calculation
When that 148,500 on the statement is written to the right invoice, the only thing visible is a line closing. Ordinary, quiet, unremarkable. What's invisible when it isn't written is your ledger quietly beginning to tell a wrong story — and you pay for that story months later, at its most expensive point.
Matching is where that invisible link between records is formed. When the link is formed correctly, no one notices; when it's formed wrong, everyone notices, months later. What iFinances does is not form and close that link for you, but surface which links are solid and which are suspect. It puts the certain in front of you with its certainty, and the uncertain with its uncertainty. The remaining judgment is yours — because we don't want to replace an accountant, we want to turn their eye to the right line.
Frequently asked questions
What is FIFO, and should a payment always be deducted from the oldest invoice?
FIFO — "first in, first out" — is the rule of settling from the oldest open invoice first, and it's the standard accounting approach, because the oldest debt carries the highest delay risk. But there are exceptions: if the payment description contains a specific invoice number or order reference, the payment should skip the FIFO order and be written to that invoice. A correct system looks for a clear reference first; if there's none, it applies FIFO. A blind FIFO and a blind reference-follow each produce errors on their own.
When a partial payment arrives, which invoice and how much should I apply?
A partial payment is an amount that doesn't match any of your open invoices exactly. The principle is to settle the incoming amount from the oldest open invoice in order: the first invoice closes in full, the surplus carries to the next, and it may leave the last one half-paid. What's critical is keeping this partial settlement traceable — which payment closed which invoice, and by how much, should be visible line by line. Otherwise the remaining amount sits open as if it were the invoice's full original amount, and a phantom debt is born.
If the bank description only has a reference number, how do I match the money?
By comparing the reference against your order, PO or invoice records. Systematic matching first searches an embedded reference like "ORD-2024-0417" in your order records; if it finds it, it links it to the invoice. If it can't, the money is flagged as "unapplied cash" and brought to a person for review — not deleted, not hidden. A third party may also have paid on the customer's behalf, which is why you have to look at the reference, not just the name.
---
Seeing whether a line on the statement lands on "the right invoice" isn't possible by looking one by one — it takes cross-referencing the sources. If you'd like to review together where your partial payments, embedded references and suspect matches stand in your ledger, get in touch with us.
✦ iFinances — See what you're missing.
One post a month.
Get new insights straight to your inbox. No spam, just well-crafted reads.
