Quality review in an automated practice

Practice quality review was built around a specific assumption: a person did the work, and a more experienced person checks it.

The reviewer looks for the errors people make — misunderstanding, carelessness, inexperience, guessing when unsure. Review checklists encode decades of knowledge about where juniors go wrong.

Automated work goes wrong differently. A checklist tuned for human error applied to machine output looks thorough and misses the things that matter.

What changes about the errors

Human error is random and isolated. One invoice miscoded because someone was rushing. The next one is fine.

Machine error is systematic. Every invoice from that supplier miscoded, consistently, since the pattern was learned. Reviewing a sample of five finds five errors or none.

That difference reorients the whole exercise. The reviewer is no longer estimating an error rate from a sample — they are looking for whether a class of transaction is being handled correctly.

What the reviewer should check

Whether classes are right, not whether items are right. Take the largest recurring suppliers and confirm the treatment is correct for each — once. That tells you about hundreds of transactions. Checking twenty random small items tells you about twenty.

The balances that will not decompose. Any control account whose balance cannot be broken into nameable items is the strongest signal available that something systematic is wrong upstream.

What was manual. In an automated file, the manual journals are the exceptions — and they are disproportionately where problems sit. A manual journal in an account that normally receives only automated entries deserves attention every time. This inverts the traditional priority, where manual was everything.

The exception queue, and how it was cleared. Not just that it is empty, but how it emptied. Timestamps clustered in a two-minute window on the last day of the month say the queue was cleared rather than worked.

Period boundaries. Cut-off is where automated processing is least reliable and where an error is systematic and lands in the most-tested area.

Whether anything changed. A threshold adjusted mid-period means the file contains two processing regimes.

What to stop checking

Removing things from a review checklist is uncomfortable and necessary, because a checklist that grows without pruning gets performed superficially.

Candidates for removal:

• Arithmetic within an entry. It balances; it was not typed.
• Transposition errors. A human failure mode, not a machine one.
• Whether every transaction has a document. If the entry was created from the document, it does by construction — verify the mechanism once rather than the instances repeatedly.
• Casting and cross-casting. Derived, not entered.

Time released by dropping these funds the checks that actually apply.

The reviewer's hardest problem

A file produced by software looks finished. Consistent formatting, complete references, everything reconciled, nothing obviously odd.

A file produced by a junior looks like a junior produced it, and that visible roughness is itself information — it directs attention.

Automated output gives the reviewer no signal about where to look. Everything appears equally finished, including the parts that are wrong.

The response is to direct attention systematically rather than by instinct: check the classes, check the manual items, check the boundaries, check what changed. Instinct developed on human work does not transfer, because it was tuned to a texture that no longer exists.

Practice-level review

Beyond individual files, the practice needs a view across the book, and this is genuinely new.

Are the same exception types recurring across clients? That indicates a configuration issue in how the practice sets clients up, not a client-specific problem.

Is one person's work generating more corrections? A training need, visible in aggregate and invisible file by file.

Are thresholds consistent across clients? If not, deliberately or by accident?

Is anyone sampling automated output? At practice level this is the answer to a professional body or insurer asking how quality is assured — see sampling automated transactions.

Where the professional risk sits

Worth stating plainly: automation does not transfer professional risk to a vendor. The practice signs the accounts.

What changes is that a single misconfiguration can affect every client configured the same way — a risk profile with more correlation than a practice is used to. One junior's mistakes affect their files; one wrong standard template affects the book.

That argues for the practice-level review above, and for treating configuration changes with the seriousness normally reserved for technical positions.

Common questions

How does file review change when the work is automated?

The reviewer stops estimating an error rate from a sample and starts checking whether classes of transaction are handled correctly, because automated errors are systematic rather than isolated. Confirming the treatment for each major recurring supplier once tells you about hundreds of transactions, whereas checking twenty random small items tells you about twenty.

What should reviewers focus on in an automated file?

Whether classes of transaction are treated correctly, any balance that will not decompose into nameable items, the manual journals — which are now the exceptions and disproportionately where problems sit — how the exception queue was actually cleared, period cut-off, and whether any threshold changed mid-period leaving two processing regimes in one file.

What can be removed from a review checklist?

Arithmetic within entries, transposition errors, casting and cross-casting, and confirming every transaction has a supporting document where entries are created from the documents themselves. These are human failure modes or mechanical checks better verified once at the process level than repeatedly at the instance level, and removing them funds the checks that do apply.

Where does professional risk sit in an automated practice?

With the practice, unchanged — automation does not transfer it to a software vendor. What changes is correlation: one junior's mistakes affect their own files, whereas one misconfigured standard template affects every client set up the same way. That argues for review at practice level as well as file level, and for treating configuration changes with real seriousness.

Related: when the accountant becomes the reviewer · standardising processes across a client base · sampling automated transactions