Who is accountable for an automated entry?

An entry is wrong. It was posted automatically, reviewed by nobody, under a rule configured eighteen months ago by someone who has since left.

Who is responsible?

The question sounds theoretical until it is being asked by an auditor, and at that point the absence of a prepared answer is itself a finding. It is worth settling in advance, and it takes about an hour.

The answer that does not work

"The software did it."

No regulator, auditor, tax authority or court has shown any appetite for treating software as an accountable party, and there is no sign of that changing. The obligations attach to the business and to the individuals who hold professional or statutory responsibility.

Automation redistributes work. It does not redistribute responsibility, and any vendor implying otherwise is selling you a problem rather than a solution.

The four roles that need names

Accountability for automated processing splits into four distinct responsibilities. In a small business one person may hold several, which is acceptable — as long as it is deliberate and written down.

The process owner. Accountable for the automated process producing correct results: what it does, where thresholds sit, what routes to review. This is the primary accountability and it is the one most often unassigned, usually absorbed informally by whoever implemented the system.

The reviewer. Accountable for the exceptions they handled — that they looked properly, not merely that they clicked. Their accountability is bounded to what they saw.

The configurer. Accountable for changes made to rules and thresholds, with a record of what was changed, when and why. In many teams this is the same person as the process owner, which is workable if someone independent samples the output.

The signatory. Whoever signs the accounts. Their accountability is unchanged by automation and always has been the broadest.

What the record has to show

For accountability to mean anything, the record must support it. Per transaction:

• What was posted and on what evidence
• Which rule or model version produced the treatment
• The confidence level
• Whether a human reviewed, who, and when
• Any amendment, with author and reason

Plus, at process level: who owns it, what the thresholds are, when they were last reviewed, and a log of configuration changes.

Missing any of these creates a question you cannot answer. The one most often missing is the configuration change log — and it is the one that matters most when something has been wrong for a period, because without it you cannot even establish when the behaviour changed.

The uncomfortable middle case

Straightforward cases are easy. A reviewer who approved something without looking is accountable for not looking. A signatory is accountable for the accounts.

The hard case: an entry nobody saw, produced by a correctly-configured rule, that was wrong because the business changed.

Nobody made a mistake. The rule was right when set. The business moved and nobody revisited it.

This is the characteristic failure of automated accounting, and it lands on the process owner — not for making an error, but for not having a review cycle. Which is why "when were these thresholds last reviewed against how the business now operates" is the question worth asking yourself quarterly. It is also the question that makes the accountability real rather than nominal, because it creates something specific the owner is expected to do.

In a small business

Where one person is finance, the four roles collapse into one, and segregation is not available. The honest response is not to pretend otherwise.

What works:

• Write down that this person owns the automated processes, so it is explicit rather than assumed
• Have someone outside finance — an owner, a director, an external accountant — sample periodically and review configuration changes
• Keep bank-side controls that finance cannot alter unilaterally
• Accept and document that segregation does not exist, and compensate with visibility

A business that knows it has a concentration and compensates is in a much better position than one that has the same concentration and a control document describing a separation that does not exist.

The hour that saves you later

Before automating anything, write down:

1. Who owns each automated process
2. Who may change its configuration, and who is told when they do
3. Who reviews exceptions, and what they attest to
4. How often thresholds are reviewed, and by whom
5. Who samples the output, and how often

One page. It answers most of what an auditor will ask about automated processing, and it is very much easier to write now than to reconstruct during an investigation.

Common questions

Who is legally responsible for an automated accounting entry?

The business and the individuals holding professional or statutory responsibility for the accounts. Software is not treated as an accountable party by auditors, regulators or tax authorities, so automation redistributes the work without redistributing the responsibility — which means someone must be named as accountable for each automated process.

What roles need to be defined for automated accounting?

Four: the process owner accountable for the automated process producing correct results, the reviewer accountable for the exceptions they actually examined, the configurer accountable for changes to rules and thresholds, and the signatory whose responsibility for the accounts is unchanged. In a small business one person may hold several, which is acceptable if it is deliberate and documented.

Who is at fault when a correctly-configured rule produces wrong entries because the business changed?

This lands on the process owner, not for making an error but for not having a review cycle. It is the characteristic failure of automated accounting — nobody made a mistake, the rule was right when it was set, and the business moved without anyone revisiting it — which is why scheduled threshold review is what makes the ownership meaningful rather than nominal.

What if only one person handles finance?

Then the roles genuinely collapse into one and segregation is unavailable, so the useful response is documenting that explicitly and compensating with visibility: someone outside finance sampling periodically and reviewing configuration changes, bank-side controls that finance cannot alter alone, and an external accountant who knows what to ask. That position is far stronger than a control document describing a separation that does not exist.

Related: segregation of duties when software posts · documenting an automated process for review · evidence an auditor will accept