What to do when nothing matches

Sometimes a reconciliation does not have a few exceptions. It has nothing that matches, or a difference so large that the whole period looks wrong.

The instinct is to start examining individual transactions. That is almost always the slowest route, because a large failure is usually one structural cause rather than many small ones, and structural causes are found by checking assumptions rather than by inspecting records.

Establish the shape of the problem first

Four questions, in this order, before looking at any transaction.

Is it one difference or many? A single unexplained amount points at one event — a reserve change, a missing payout, an adjustment. Many small differences point at a rule: a fee rate, a rounding convention, a tax treatment.

Is it proportional or fixed? A difference that scales with volume is a rate or a percentage. A constant amount regardless of volume is a charge, a fee or a single transaction.

Did it start on a date? Almost the most useful question available. If the reconciliation worked until the eighteenth and has failed since, something changed on the eighteenth, and finding what changed is faster than analysing the symptom.

Is it one stream or all of them? A difference confined to one payment method or one gateway localises the cause immediately — see reconciling two gateways into one bank account.

Those four answers usually narrow the cause to one or two possibilities before any detailed work begins.

The eight usual causes

In rough order of how often they turn out to be responsible.

A reference stopped flowing. A checkout or gateway configuration change, and the order reference no longer reaches the settlement report. Matching falls back to composite, quality drops, and nothing announces it — see the gateway reference that joins everything.

A rate changed. Your provider adjusted a fee, or a new card type is being used, and every calculation is now slightly off.

A reserve was introduced or changed. A percentage now withheld that was not before. The difference is proportional and exactly the size of the reserve rate — see payment gateway holds and reserves.

A new payment method went live. Enabled by whoever runs the store, settling on its own cycle, sometimes directly rather than through the gateway, and nobody told finance — see e-wallet payments and how they settle.

A file format changed. The provider altered a column, and your import is reading the wrong field or silently dropping rows.

Missed notifications. An outage at your end, retries exhausted, and a set of orders that exists at the store and not in your system — see Shopify webhooks and why they are not enough.

A period boundary. Not a fault at all. Transactions in flight across a cut-off, being compared against a period that does not contain them — see reconciling across a period boundary.

Two payouts treated as one. A provider combining transfers, or a bank splitting one, so the amounts never tie.

Working down that list against the four shape questions resolves the large majority of total failures without opening a single transaction.

When it is one specific amount

A single unexplained figure is the most tractable case, and there is a fast way at it.

Take the amount and ask what it could be a percentage of. If it is close to a round percentage of the period's transactions, it is a rate or a reserve. If it matches a single order's value, it is one transaction — most likely a payment with no order or an order with no payment, and both are findable directly.

If it is a round number, it is almost certainly manual: an adjustment, a correction or a fee the provider applied and did not itemise. Ask them. Providers answer this kind of question readily, and merchants are often reluctant to ask, which is why round unexplained numbers sit in books for years.

When the whole period is wrong

Different situation, and the response is different: do not try to fix the period. Rebuild one day.

Take a single day with a manageable number of transactions and reconcile it completely by hand. Every order, every transaction, every fee, the payout, the bank credit. To the sen.

That does three things. It tells you whether the process can work at all with this data. It surfaces the cause on a sample small enough to hold in your head. And it gives you a verified day to test any fix against — see decomposing a payout line by line.

Trying to diagnose across a whole month means holding hundreds of possible explanations at once. One day is a tractable object, and a cause found there is almost always the cause everywhere.

Three responses that make it permanent

Each one closes the books and takes the underlying problem out of view.

Do not plug the difference. A journal to make it balance closes the books and destroys the information. The difference was the only evidence you had, and next month it will be there again with no record of what you did about it last time.

Do not widen the tolerance. The same act with a more respectable name. A tolerance large enough to absorb the problem is large enough to absorb a real error indefinitely — see rounding differences and where they come from.

Do not switch to reconciling from the bank. The most tempting response, because bank data is complete and always available. It also records revenue net of fees, understating sales and leaving the fees unrecorded, which trades a visible problem for an invisible one — see the three-way match a Malaysian store needs.

Ask the provider

Worth saying explicitly, because it is consistently the last resort and should be closer to the first.

Your gateway can tell you what a specific amount was, whether a rate changed, whether a reserve was applied, whether a file was republished, and whether two payouts were combined. All of it is knowable and none of it is inferable from your side.

A short, specific question — what is the difference between this payout and the transactions your report lists inside it — usually gets a precise answer. Merchants spend weeks deriving what a five-minute enquiry would establish.

Common questions

Where do you start when a reconciliation is badly out?

With the shape of the problem rather than with individual transactions. Establish whether it is one difference or many, whether it scales with volume or is fixed, whether it started on a particular date, and whether it affects one payment stream or all of them. Those four answers usually narrow the cause before any detailed work begins.

What most often causes a reconciliation to stop working?

A reference that stopped flowing after a checkout or gateway configuration change, so the order reference no longer reaches the settlement report. Nothing breaks visibly — matching falls back to amount and date, match quality quietly drops, and the effect appears as a growing exception queue rather than an error.

What should you do when a whole period will not reconcile?

Rebuild a single day completely by hand — every order, transaction, fee, the payout and the bank credit, to the sen. That establishes whether the process can work with this data at all, surfaces the cause on a sample small enough to reason about, and provides a verified day to test any fix against.

Why should an unexplained difference never be plugged?

Because a journal that makes the books balance destroys the only evidence of the problem. The difference will recur next period with no record of what was done about it, and a tolerance widened to absorb it will absorb genuine errors of similar size indefinitely. The difference is information, not an inconvenience.

Related: decomposing a payout line by line · the exception queue and how to size it · rounding differences and where they come from