When the accountant becomes the reviewer

There is an assumption buried in most automation projects: that if a person reviews what the system did, the output is safe.

It is not automatically true. Review is a skill, it is performed badly by default, and the specific way it fails is well documented outside accounting — in aviation, in medicine, in every field where humans supervise automation.

The failure has a name: automation bias. People accept machine output more readily than they would accept the same output from a colleague, and the more reliable the system has been historically, the less carefully they check.

That is worth understanding before you rely on review as a control.

Why reviewing is harder than doing

When you produce an entry yourself, error is caught by construction. You look up the account, notice the amount is odd, remember the supplier. The thinking happens as a by-product.

When you review, none of that occurs unless you make it occur. You are presented with a finished, confident, plausible answer, and the default cognitive response to a plausible answer is acceptance. Finding the wrong one requires actively reconstructing what the right one should be — which is real work that looks, from outside, like doing nothing.

This is why a queue of eight items can be cleared in ninety seconds and why that ninety seconds is worse than useless: it produces a signature without a check.

The three review failures

Rubber-stamping. Approving in bulk without examining. Recognisable by how fast a queue empties and by reviewers who cannot say what was in it afterwards.

Checking the wrong thing. Verifying that the arithmetic is internally consistent rather than that the treatment is right. The invoice does total RM 4,200 and the entry does balance — neither tells you it belongs in repairs rather than fixed assets.

Reviewing only what is flagged. The exception queue contains what the system was unsure about. The dangerous errors are the ones it was confident about and wrong. If nothing outside the queue is ever sampled, that category is never caught.

How to review well

Reconstruct before you look

Before opening an item, form an expectation. Which account should this be? Roughly what amount is normal for this supplier?

Then compare. This single habit converts passive acceptance into active checking, and it takes a few seconds.

Ask why it stopped

Every exception has a reason attached. Read it. "Price above tolerance" and "no purchase order" are different problems with different causes, and treating them as one undifferentiated queue loses the information.

Resolve the cause, not the item

If the same exception type recurs weekly, the fix is upstream. Clearing it every week is a permanent tax you have chosen to pay. See investigating rather than clearing.

Sample the unflagged

The most important review habit and the one nobody schedules. Periodically pull a sample of transactions the system processed confidently and check them properly.

You are looking for the error class the system does not know it has — a supplier consistently miscoded, a tolerance set wrong, a rule that made sense before the business changed. A monthly sample of twenty is more valuable than clearing four hundred exceptions.

Keep the queue short enough to read

A queue that reaches the hundreds stops being reviewed and becomes a backlog. If it is growing, the answer is not more reviewer hours — it is that a threshold is wrong or an upstream process is broken. Rising exception volume is a signal about the process, not a staffing problem.

What the review has to leave behind

For the review to function as a control rather than a gesture, the record needs to show who reviewed, when, what they saw, and what they decided. A blanket approval with no trace is indistinguishable from no review at all, and an auditor will treat it that way.

That is part of why who is accountable for an automated entry needs answering before automation scales, not after.

Reviewing less, better

A counterintuitive conclusion worth sitting with.

If reviewers are clearing three hundred items a week, they are not reviewing — there is not enough attention to go round, and the process is producing a signature rather than a check. Reducing the queue by fixing upstream causes, and reviewing the remainder properly, catches more errors than skimming everything.

Fewer items, genuinely examined, beats more items, waved through. That is a hard argument to make to someone who measures throughput, but it is the one that holds.

Common questions

What is automation bias?

It is the documented tendency for people to accept output from an automated system more readily than they would accept identical output from a colleague, and to check less carefully the more reliable the system has been. It matters in accounting because it means review can become a signature rather than a genuine check, which produces the appearance of a control without the substance of one.

How should an accountant review AI-generated entries?

Form an expectation before looking at each item, read the reason the system flagged it rather than treating the queue as undifferentiated, resolve recurring causes upstream instead of clearing the same exception repeatedly, and periodically sample transactions the system processed confidently. That last habit catches the most dangerous errors, which are the ones the system was sure about and wrong.

Should I review every automated transaction?

No, and attempting to defeats the purpose while producing worse results, because attention spread across hundreds of items becomes superficial. The effective pattern is reviewing the exceptions properly, sampling the confident transactions periodically, and treating a growing exception queue as a signal that a threshold or upstream process needs fixing rather than as a staffing problem.

What does an auditor expect from review of automated entries?

Evidence that the review actually happened and what it consisted of — who reviewed, when, what they were shown, and what they decided — rather than a blanket approval leaving no trace. Auditors are generally comfortable with automated processing where exceptions are handled under a documented process; they object where entries exist that nobody can explain or attribute after the fact.

Related: the exception queue as a control · keeping a human in the loop · sampling automated transactions