Segregation of duties when software does the posting

Segregation of duties rests on a simple idea: the person who initiates a transaction should not be the one who approves it, and neither should be the one who records it. Collusion becomes necessary, which is a much higher bar than opportunity.

It has worked for centuries because it targets the right risk — a person with end-to-end control over a transaction type.

Then software takes over initiation and recording, and the control needs rethinking. Most implementations do not rethink it. They keep the old approval matrix, which now separates duties that no human performs, while leaving genuinely concentrated power in places nobody classified as a duty.

Where the power actually moves

To whoever configures the system. A person who can change a coding rule, adjust a tolerance or lower a confidence threshold has more influence over the accounts than any individual processor ever had. One configuration change affects every future transaction.

In many small finance functions, that person is also the one reviewing exceptions and reconciling. That is end-to-end control over a transaction class — precisely what segregation of duties exists to prevent — and it usually appears on no control matrix, because "configuring the system" was never a duty in the original scheme.

To whoever sets the master data. Adding a supplier, setting bank details, defining payment terms. Combined with approval rights, this is a well-understood fraud path and it does not depend on AI at all — but automation increases the leverage, because a supplier once created is paid repeatedly without further scrutiny.

To whoever can bypass. Every system has an override. Who has it, when it can be used, and whether use is logged and reviewed matters more than the routine approval hierarchy, because the override is where the routine controls do not apply.

The separations that matter now

Rewritten for an automated function:

Configuring must be separate from reviewing. The person who sets thresholds should not be the only one checking what those thresholds let through. If the same person does both, a mistake — or worse — is invisible by construction.

Master data must be separate from payment. Whoever can create or amend a supplier's bank details should not be able to release payment to it. This is the single highest-value separation in a small finance team and it survives every technology change.

Override must be visible to someone else. Not prevented — overrides are necessary — but logged, and reviewed by a person who did not use them.

Someone outside the process must sample. Independent verification that the automation is doing what it is supposed to. In a small team this may be an owner, a director, or an external accountant, and it does not need to be frequent to be effective. See sampling automated transactions.

What software cannot separate

Worth being direct: software cannot enforce segregation against whoever administers the software.

If one person holds full administrative rights, they can change the rules that constrain them, and any log they can edit is not evidence. Every control in the system runs at their discretion.

The mitigations are organisational rather than technical:

• Administrative rights held by someone outside daily finance operations, where the business is large enough
• Configuration changes requiring a second approval, with the log written where the administrator cannot alter it
• Periodic independent review of configuration changes
• Where none of that is possible — a genuinely small business with one finance person — an owner who periodically looks, and an external accountant who knows what to ask

That last case is common and honest. The right answer is not pretending the control exists; it is knowing it does not and compensating with visibility.

The practical exercise

For each of your automated processes, name the person who can:

• change the rules that govern it
• review its output
• amend the relevant master data
• release payment
• override it
• see the log of who did what

If one name appears in more than two, that is the concentration to address — regardless of what the formal approval matrix says.

Most small finance functions running this find the same name three or four times, and it usually surprises them, because the formal control document describes a separation that the automated process has quietly bypassed.

A control that proves who approved something is not the same as a record of why it was approved — see transactions are not decisions for the distinction and why it matters once an exception is questioned later.

Common questions

How does segregation of duties change with automated accounting?

The risk moves from the people processing transactions to the people configuring the system, since one change to a rule or threshold affects every future transaction. The separations that matter become configuration versus review, master data versus payment release, and override use versus override monitoring — while the traditional initiate-approve-record split increasingly separates duties no human performs.

What is the most important separation in a small finance team?

Whoever can create or amend a supplier's bank details should not be able to release payment to that supplier. It is a long-standing fraud path that does not depend on technology, and automation increases the leverage because a supplier once created is paid repeatedly without further scrutiny.

Can software enforce segregation of duties?

Not against whoever administers the software. A person with full administrative rights can change the rules constraining them, and any log they can edit is not evidence. The mitigations are organisational — holding administrative rights outside daily finance operations, requiring second approval for configuration changes, writing logs where the administrator cannot alter them, and independent periodic review.

What if we only have one person in finance?

Then segregation genuinely does not exist and the honest response is to compensate rather than pretend otherwise. Practical measures are an owner or director who periodically reviews configuration changes and samples transactions, an external accountant who knows what to ask, and bank-side controls such as payment limits that finance cannot alter unilaterally.

Related: controls that survive automation · keeping a human in the loop · who is accountable for an automated entry