Internal audit in an automated finance function

Traditional internal audit tests transactions. Pull a sample, check each against the documentation and the policy, extrapolate.

That logic depends on an assumption: each transaction was handled individually, so errors are independent. Sample forty, find one error, and you have a basis for estimating the rate.

Automated processing breaks the assumption. Transactions are no longer independent — they are outputs of the same rule. If the rule is right, all of them are right. If it is wrong, all of them are wrong, and a sample of forty will show forty errors or none, telling you almost nothing about anything else.

The unit of testing has to change from the transaction to the rule.

What to test instead

The configuration. What are the thresholds, and can they be justified? A tolerance set for a scale of business you have outgrown is a finding, and it is invisible in transaction testing because everything passes.

The change history. What was altered during the period, by whom, on whose authority, and was it recorded. Unrecorded configuration change is the single most common finding in automated finance functions, and it undermines every other assurance.

The boundaries. What the system cannot do regardless of confidence. Test them by attempting to exceed them, not by reading the documentation. A limit that exists in a settings screen and not in behaviour is not a limit.

The exception process. Whether the queue is being worked or cleared. Approval timestamps clustered in short windows tell you which. So does asking a reviewer what was in yesterday's queue.

The monitoring. Whether management's own sampling exists, is genuine, and results in corrective action. See sampling automated transactions.

Segregation, as it actually is. Not the approval matrix, but who can change rules, review output, amend master data, release payment and edit logs. See segregation of duties when software posts.

Where transaction testing still earns its place

Not obsolete — repurposed.

To test the rule, not the population. A small number of transactions examined carefully tells you whether a rule is producing correct results. You are validating the logic, not estimating an error rate.

On the manual residue. Exceptions, overrides and manual journals are handled individually and therefore are independent. Traditional sampling applies to them properly, and they are disproportionately where problems concentrate — a manual journal in an account that normally receives only automated entries deserves attention every time.

At the boundaries. Transactions just under a threshold. If a review threshold is RM 10,000 and there is a cluster at RM 9,900, that is worth understanding.

Across time. The same transaction type at different points in the year, to detect when behaviour changed.

The three findings that recur

In automated finance functions, the same issues come up repeatedly:

Thresholds nobody has revisited. Set at implementation, never reviewed, no longer proportionate. Nobody owns the review, so it does not happen.

Configuration changes without record. Made informally, often by the person who also reviews the output.

Monitoring that is described but not performed. Management believes there is oversight of automated processing; no evidence of any sampling exists.

All three share a cause: these are new responsibilities that no existing role picked up, because they did not exist in the manual process.

Testing the boundaries properly

The most useful technique available, and the least used: try to break it.

Submit a transaction from an unapproved supplier. Submit one above the amount ceiling. Submit a duplicate. Submit something in a category that should require human classification.

Reading a configuration screen tells you what should happen. Attempting the action tells you what does. The gap between the two is where findings live, and it is a gap that documentation review cannot detect by construction.

Do it in a test environment where one exists. Where it does not, do it with small real transactions and reverse them, with the process owner's knowledge.

For businesses without an internal audit function

Most small and mid-sized businesses have no internal audit. The reduced version, performed by an owner, a director or an external accountant, once or twice a year:

1. What are the thresholds, and when were they last reviewed?
2. What configuration changed this year, and who authorised it?
3. Show me the sampling that has been done.
4. Who can change rules, review output, amend suppliers, and release payment — and how many names is that?
5. Take five transactions from the exception queue and ask what was decided and why.

Half a day. It catches the three recurring findings above, which is most of what matters.

Common questions

How does internal audit change with automated accounting?

The unit of testing moves from the transaction to the rule. Traditional sampling assumes each transaction was handled independently so errors are independent, but automated transactions are outputs of the same logic — if the rule is wrong they are all wrong, and a sample tells you about the rule rather than about a rate. Testing therefore focuses on configuration, change history, boundaries, exception handling and management's own monitoring.

Is transaction sampling still useful?

Yes, repurposed. A small number of transactions examined carefully validates whether a rule produces correct results, and traditional sampling still applies properly to the manual residue — exceptions, overrides and manual journals — which are handled individually and are disproportionately where problems concentrate. Transactions clustered just below a threshold are also worth examining.

What are the most common findings in automated finance functions?

Thresholds set at implementation and never revisited, configuration changes made without record, and monitoring that management describes but cannot evidence. All three arise because they are new responsibilities that no existing role absorbed, since none of them existed in the manual process.

How do you test whether the controls actually work?

By attempting to breach them rather than reading the configuration. Submit a transaction from an unapproved supplier, one above the amount ceiling, a duplicate, and something in a category that should require human classification. Documentation tells you what should happen; attempting the action tells you what does, and the gap between them is where findings are.

Related: controls that survive automation · sampling automated transactions · documenting an automated process for review