The exception queue and how to size it

The promise of automated reconciliation is not that nobody looks at anything. It is that a person looks only at the things that genuinely need a decision.

Which makes the exception queue the most informative object in the whole process. Its size, its composition and how fast it clears tell you more about the health of your finance operation than any report.

What belongs in it

An exception is not an error. Most of them are entirely normal situations that automation correctly declined to resolve on its own, and the distinction matters because it changes how the queue is treated.

A transaction with no matching order. Usually an interrupted payment the customer completed and your store never recorded — see failed payments and the orders they leave behind.

An order with no matching transaction. Often just in flight, which is why age matters before it counts as an exception at all.

An ambiguous match. Two candidates fit and the system correctly refused to choose. Deciding this is exactly what a person is for.

A fee that is not the expected rate. Sometimes a different card type, sometimes a rate change nobody told you about. Worth a look either way.

An unidentified bank credit. A directly settled wallet, a dormant gateway, a customer transfer — see bank transfers and manual payments you still receive.

A residual in a payout decomposition. Some amount that closes the arithmetic and has no name — see decomposing a payout line by line.

A late-arriving event on a closed period. A chargeback or refund on an old order, needing a decision about where it lands.

Seven categories, and a mature process has a defined handling for each. That is what turns a queue into routine work rather than an investigation.

Sizing it honestly

The number that matters is not how many exceptions arrive but how much time they cost against how much they used to.

A useful way to hold it: what share of transactions reaches a person, and how long does each take. A queue of thirty items that each take twenty seconds is a ten-minute daily task. A queue of five items that each take half an hour is a bad afternoon.

So volume alone is misleading in both directions. Track both, and track them over time rather than sampling them.

The target that matters for a growing business is that the queue does not grow with revenue. Doubling sales should not double the queue, because most exception causes are structural rather than proportional. If it does scale linearly, the automation is handling volume and not handling causes, and that distinction becomes expensive as you grow — see what 98% automated reconciliation means.

Where the 98 per cent figure comes from

Worth being precise about, because it is a design target rather than a measurement.

The point of naming a figure short of a hundred is that a hundred is not achievable and claiming it would be dishonest. Some situations genuinely require judgement: whether a short payment was a bank charge or a dispute, whether an unfamiliar payer is a known customer, whether a residual is worth chasing. No system decides those correctly without knowing things it cannot know.

So the design goal is that the great majority of matching happens without a person, and the remainder arrives as a short list of clear decisions. The measure of success is the size of the remainder, not its absence — see keeping a human in the loop.

Clearing it, which is a process not an intention

Four practices, and the second is the one most often missing.

Age everything and work oldest first. Recency bias is the enemy here. A three-week-old exception is more likely to be a real problem than yesterday's, and it is harder to resolve the longer it waits, because the people who would remember have moved on.

Set a maximum age. Anything beyond it escalates. Without this, hard items sink to the bottom permanently and the queue develops a floor of undecidable things that everyone learns to scroll past.

Record the resolution, not just the decision. Why this transaction matched that order. Next month's identical case is then a lookup rather than a repeat investigation, and the accumulated resolutions are what let rules improve.

Feed causes back into the rules. The point of recording resolutions is to remove categories. If the same exception type appears every week, it is a fixable cause — usually a reference not flowing, a rounding rule, or a payment method nobody set up properly — see matching orders to transactions to payouts.

The signals to watch

Three, and each means something specific.

Growing queue. Something has broken and the composition tells you what. A sudden increase in one category points directly at its cause.

Rising average age. The queue is being added to faster than it clears, which is a capacity problem and it will not resolve itself.

Shifting composition. A category that used to be rare becoming common is the earliest available warning of a configuration change somewhere upstream — a reference stopped flowing, a provider changed a format, a new payment method went live without anyone telling finance.

All three are visible in a queue that is measured and invisible in one that is merely worked through. That is the argument for treating it as an instrument rather than as a chore — see keeping automated books healthy.

Common questions

What is a reconciliation exception queue?

The list of items automated matching correctly declined to resolve on its own — transactions with no order, orders with no transaction, ambiguous matches, unexpected fees, unidentified bank credits, unexplained payout residuals and late-arriving events on closed periods. Most are normal situations requiring a decision rather than errors, and each category should have a defined handling.

How large should the exception queue be?

Small enough that working it is a short daily task rather than a project, and — more importantly — it should not grow in proportion to revenue. Most exception causes are structural rather than volume-driven, so a queue that doubles when sales double indicates the automation is absorbing volume without addressing causes.

Why does automated reconciliation not reach 100 per cent?

Because some situations require knowledge no system has. Whether a short payment reflects a bank charge or a dispute, whether an unfamiliar payer name is a known customer, or whether a small residual is worth chasing are judgements. The design goal is that the great majority matches automatically and the remainder arrives as a short list of clear decisions.

What is the most useful signal from an exception queue?

A shift in its composition. A category that used to be rare becoming common is the earliest warning of an upstream change — a reference that stopped flowing, a provider that altered a file format, or a payment method enabled without telling finance. That signal is visible only if the queue is measured by category rather than simply worked through.

Related: what 98% automated reconciliation means · matching orders to transactions to payouts · keeping automated books healthy