Matching the money that arrived to the order that made it

Reconciliation proves that every payment in the bank belongs to an order, and every order marked paid has money behind it. The gap between the two is where small businesses lose money quietly: not to fraud, but to differences nobody has time to chase. It closes when a reference exists before the money arrives, when the three unknowns are absorbed by the system rather than by memory, and when one person owns a queue of the payments that could not be placed.

Why is the amount not a key?

Because two customers pay the same amount on the same day, and the amount cannot tell them apart. One pays part of an invoice, one pays two orders in a single transfer, and one settles an old invoice while a newer one stays open. A matcher working on amounts alone finds several candidates, chooses one, and the choice is often wrong in a way that still balances.

The wrongness is quiet: the ledger total stays right, because the money is there, and the order states are wrong. One customer is marked paid who is not, another is chased for a settlement already received, and the aging report that drives the calls is built on both errors.

What must exist before the money arrives?

A reference the payer quotes, generated when the order is raised, and short enough that people type it correctly into a bank application. That last condition is the difficulty: a long code copied by hand gets truncated, transposed, or dropped because the field is too small.

So the reference is designed for the channel it travels through — a short numeric code on the invoice, repeated on the reminder, expected for a transfer, kept in its own field rather than inside a free-text note. Business buyers can get the same reference as structured data: the payment and remittance documents in UBL carry it as a field, which is why an invoice built to a standard reconciles more easily than one built to a spreadsheet.

The rule that makes it stick: the reference is created with the order, never afterwards, because one written after the money arrived is a guess with a number attached.

Each channel needs its own space: a transfer, a card settlement, a courier's remittance and a till receipt arrive with four identifiers, and an order number means nothing to three of them until the system maps it.

Which three unknowns must every reconciliation absorb?

Every unexplained line is one of three things, and the system should model them, not log exceptions.

Unknown	What it looks like	What the system must do
Timing	the customer paid, the money has not landed	hold the order open with a date
Fees deducted	the transfer arrives short by a charge	book the charge as a cost, not a discount
A third party paid	a relative, a driver or a partner sent it	attach the payer's name to the order

Timing is the ordinary case and generates the most pointless work. A transfer made on Thursday may land on Monday; an order open across the weekend is not a problem, and treating it as one produces reminders to customers who have already paid; that costs more trust than the delay costs cash.

A payment that arrives short by a bank charge is not a partial payment. Posting it as one leaves a permanent unpaid balance on a settled order; the charge belongs on its own line, as the cost of collecting, so the sale stays whole and the cost stays visible.

The third breaks matching entirely, because somebody who is not the customer pays: a brother paying for a sister's order, a driver depositing the cash he collected, a company paying for an employee. The order keeps its customer; the payment records who actually paid.

What do you do with a payment you cannot identify?

Put it in a queue with a name against it, and give it an age. The queue is the mechanism: a list reviewed at a fixed time by a person who can ring somebody, ordered by how long each line has sat there. Unidentified money is not a note in a notebook, and not a line typed into a miscellaneous account to make the total balance.

Each entry carries the amount, the date, the narrative exactly as the bank printed it, who is looking, and when it arrived. After two statements it escalates to whoever can call the customer or accept the loss. Nothing leaves the queue without an explanation a second person could read and accept.

The one thing never to do is adjust an order to absorb a difference. That closes the line and destroys the evidence of why it existed.

How often, and what does a week of reconciliation look like?

Weekly, because a difference found in its first week is a phone call and the same difference found at year end is an audit. The annual version is not another method; it is the weekly one deferred until the evidence is cold.

1. Take the statement on the day it closes, and import it untouched.
2. Match on the reference first, the amount second, the payer's name third, and never on one of those alone.
3. Leave what does not match visible. A forced match is a wrong answer with a receipt.
4. Post fees and exchange differences on their own lines, never against the sale.
5. Bank the counted cash against the day's till receipts, and record the difference rather than correcting it.
6. Age the queue, assign each line to a name, and close only the lines that were explained.
7. At the month end, prove the total: statement equals matched, plus unmatched, plus fees, plus cash in transit.

The last step catches a bad week: when the parts do not add to the statement, the gap is usually a line matched twice.

Where this goes wrong

• The reference written afterwards. Somebody matches from memory and types the order number into the note. The record now claims the money was identified when it was guessed.
• Deposits counted as revenue. Money for goods not delivered is held, not earned; treating it as a sale flatters the month and distorts the margin.
• The reconciliation lives in one person's file. When they take leave, the month stops.

What this does not cover

No fees, no prices, no claim about how a payment must be recorded for tax or an auditor; that is your accountant's to state. This does not cover card disputes and chargebacks, which need evidence from the order record rather than a matching rule, or multi-currency settlement, where each currency needs its own reconciliation. It assumes you can read your statements; where the account is shared, or statements arrive on paper monthly, the first fix is access, not software.

We build the reference, the matching and the queue, so every payment that arrives has an order to land on and a name to answer for it.