Which accounting controls survive automation

Most control frameworks were designed for a world where people did the work. Automate the work and some controls keep functioning, some become theatre, and some new ones become necessary.

Implementations that go wrong usually keep the whole existing framework unexamined — which means carrying the cost of controls that no longer control anything, while the new risks go unaddressed.

Here is the sorting.

Controls that survive intact

Reconciliation to an independent source. Bank statements, supplier statements, marketplace settlements — comparing your records to a record produced by somebody else. This is arguably the strongest control in accounting and automation makes it stronger, because it can run continuously across everything rather than monthly across the largest accounts.

Physical verification. Counting stock, verifying assets exist. No system knows whether the machine is still in the workshop. This becomes more important, because automated records look authoritative and nothing else challenges them.

Approval limits on outgoing money. Payment authorisation thresholds work regardless of what produced the payment. Keep them, and keep them enforced as hard rules rather than model judgement.

Master data separation. Whoever sets up a supplier should not release payment to it. Unchanged by technology, and increasingly leveraged — see segregation of duties when software posts.

Controls that become theatre

Approving individual routine transactions. An approver facing three hundred small automated items approves them in bulk. This was already weak with volume; automation makes it worse by increasing volume while making each item look identical. Replace with policy applied at entry plus sampling.

Reviewing every entry. Not possible at automated volumes, and attempting it produces superficial review across everything rather than genuine review of anything.

The traditional initiate-approve-record separation. Increasingly separates duties no human performs. The transaction is initiated by a document arriving, recorded by software, and the only human step is approval — so the three-way split has quietly become a one-way step.

Period-end scrutiny as the primary check. When processing is continuous, waiting until month end to look means errors have been compounding for weeks. Detection has to move earlier.

Signature-based authorisation with no context. A signature on a page attesting to something nobody could realistically have verified.

Controls that become necessary

These did not exist in the manual framework and have to be added deliberately.

Configuration change control. Who may change a rule, threshold or tolerance; whether a second person approves; whether changes are logged where the changer cannot edit them. A single configuration change affects every future transaction, which makes it the highest-leverage action in the function — and it is typically ungoverned.

Sampling of confident transactions. The primary detection method for systematic error. See sampling automated transactions.

Exception queue monitoring as a metric. Not just working the queue but tracking its size and composition over time, because trend is a leading indicator that something upstream has changed.

Threshold review. A scheduled reconsideration of whether tolerances still fit the business. Nothing prompts this and nobody owns it by default.

Model and rule version recording. So that when something is wrong you can identify every transaction it affected. This determines whether a correction takes hours or weeks.

The mapping exercise

A short exercise worth an afternoon. For each control in your current framework:

1. What risk does it address?
2. Does that risk still exist in the same form?
3. Does the control still work at automated volumes?
4. If not, what addresses that risk now?

Question three is where most of the discoveries happen. Controls that worked at forty transactions a day frequently do not work at four hundred, and nobody notices because the control still nominally exists and is still nominally performed.

The trap of adding without removing

The common failure is additive: keep every existing control, add the new ones, and end up with a finance team spending more time on control than they did before automating.

That is not caution, it is cost without benefit — and it has a second-order effect, because a team overloaded with control activities performs all of them superficially. Removing controls that have become theatre is what creates the capacity to perform the necessary ones properly.

Fewer controls, genuinely performed, beats more controls, gone through. That argument is uncomfortable to make to an auditor or a board, and it is the right one — provided you can show which risks the removed controls addressed and what addresses them now.

Common questions

Which accounting controls still work with automation?

Reconciliation to an independent source such as bank or supplier statements, physical verification of stock and assets, approval limits on outgoing payments, and separation between master data maintenance and payment release. These target risks that automation does not change, and reconciliation in particular becomes stronger because it can run continuously across everything rather than monthly across the largest accounts.

Which controls stop being effective?

Approving individual routine transactions, reviewing every entry, the traditional initiate-approve-record separation where software now performs two of the three, period-end scrutiny as the primary detection method, and signature-based authorisation without supporting context. Most fail because of volume rather than design — they worked at forty transactions a day and do not at four hundred.

What new controls does automated accounting need?

Configuration change control covering who may alter rules and thresholds and whether changes are independently logged, periodic sampling of high-confidence transactions, monitoring the exception queue's size and composition as a metric, scheduled review of whether thresholds still fit the business, and recording the rule or model version against each transaction so an error's scope can be determined.

Should we keep our existing controls as well as adding new ones?

Not automatically. Keeping everything produces a team spending more time on control than before automating, and an overloaded team performs all controls superficially. The useful exercise is mapping each existing control to the risk it addresses, asking whether that risk still exists in the same form and whether the control still functions at automated volumes, then removing the ones that have become theatre so the necessary ones can be done properly.

Related: segregation of duties when software posts · the exception queue as a control · internal audit in an automated finance function