The demonstrations now show a process running end to end without a person in it. An invoice arrives, is matched, coded, approved and scheduled for payment; a customer order is validated, allocated, confirmed and invoiced. Nothing about the mechanics of those sequences requires a human, and vendors are right to show them. The interesting question is no longer what can be automated. It is which of the approval steps in your current process exist because someone genuinely has to decide, and which exist because nobody has revisited them since the system was configured.
Most approval steps do not encode judgement. They encode the last argument somebody lost, and the automation project is the first time anyone has read them
Here is how to tell the difference, before you automate a control you actually needed or keep one you never did.
The three kinds of approval step
Deterministic checks disguised as judgement. Does this match the purchase order, is the vendor approved, is there budget, is the coding consistent with history. These are rules, they were always rules, and a person performing them is performing a rule badly and slowly. Genuine judgement under uncertainty. Should we pay this disputed invoice to preserve a supplier relationship. Is this customer's credit position deteriorating in a way the ageing does not yet show. Does this unusual transaction reflect a legitimate change in the business. These require context that does not exist in the system. Accountability steps. A person signs because someone must be answerable, not because they add analytical value. These cannot be automated away, but they can be relocated — from per-transaction approval to periodic review of a population, which is what audit actually wants. The second category is much smaller than the process documentation implies. The third is the one organisations remove by accident.
| Step type | Article's proposed treatment |
|---|---|
| Deterministic rule | Enforce the agreed check in the system. |
| Judgement | Retain a reviewer who can assess missing context and uncertainty. |
| Accountability | Design population review with a named owner, subject to control requirements. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What genuinely stays human
Four things, consistently. Decisions with no precedent in the data, because the model has nothing to reason from. Decisions where the cost of being wrong is not recoverable — a payment to a new bank account, a contract commitment, a statutory filing. Decisions requiring information held outside the system, which is most relationship judgement. And the periodic question of whether the automated population as a whole looks right, which no per-transaction control substitutes for.
The step that gets removed and should not
The review of outliers. When exceptions fall from eight per cent to one, the remaining one per cent is a different and harder population, and the natural staffing response — fewer people, because fewer exceptions — puts your least experienced reviewers on your most difficult cases. Staff the exception queue with your strongest people, not your spare capacity.
Practical Guidance for ERP Autonomy Roadmap
- Classify every approval step as rule, judgement or accountability.
- Automate the rules and stop calling them controls.
- Relocate accountability to population review, not per-transaction sign-off.
- Keep humans on irreversible actions regardless of volume.
- Staff the exception queue with senior people.
- Test the automated population monthly, not the individual cases.
- Document why each retained step exists so the next review is faster.
- Re-examine the list annually; the boundary moves.
The Regional Angle
The first consideration specific to this region is that statutory filings are the clearest example of an irreversible action, and the compliance environment here is unforgiving about them. Saudi e-invoicing submissions, Emirati value added tax and corporate tax returns and wage protection filings go to a government system and cannot simply be corrected with a journal entry; an automated process that files something wrong creates a regulatory event rather than an accounting one. Keep a human confirmation on the submission itself even where everything upstream is autonomous, because the cost asymmetry is enormous and the confirmation is cheap. The second concerns documentation, which is where regional organisations most often find themselves unable to answer the question this article poses. A great deal of process knowledge in Gulf finance functions lives with individual long-serving staff rather than in written procedures, which means the exercise of classifying approval steps requires interviewing people rather than reading documents. That is slower, and it has a hidden benefit: it is frequently the first time anyone has written down why a particular approval exists, and several of them turn out to exist because of a single incident a decade ago involving a person who has left. The third is about who actually holds the delegated authority, which regional group structures complicate. Approval matrices in family-owned and multi-entity Gulf groups frequently route decisions upward to a very small number of principals, and the reason many steps exist is not analytical but proprietorial — the owner wants to see payments above a threshold. Automation does not resolve that and should not attempt to; the productive move is to distinguish those steps explicitly as ownership visibility rather than control, and offer a daily summary instead of a per-transaction queue.
The objection worth taking seriously
The strongest objection is that this reasoning underestimates why controls accumulate. Approval steps that look redundant often are not — they exist because of a loss, a fraud, an audit finding or a regulatory observation whose circumstances nobody remembers but whose absence would be noticed immediately. Removing controls on the basis that their rationale is no longer documented is precisely how organisations rediscover the rationale. And a segregation-of-duties structure built from human approvals does not translate cleanly into a system where one automated process performs steps that were deliberately separated. That is right, and the segregation point in particular is the substantive technical objection. The reconciliation is that classification is not removal. The purpose of sorting steps into rules, judgement and accountability is to preserve every control's function while changing its mechanism — a rule enforced by the system is a stronger control than the same rule performed inattentively by a person at four o'clock on a Thursday, and an accountability step relocated to population review is still an accountability step with a named owner. What should genuinely worry you is not the classification exercise but the version of it performed by an implementation team under time pressure, where steps are removed because they are inconvenient and the control narrative is written afterwards. Do the exercise with internal audit in the room and the objection largely dissolves.
Common Questions
How much of a typical finance process is genuine judgement?
Less than most people expect — often a small single-digit percentage of transactions. The judgement is concentrated in exceptions rather than distributed across the population.
Does removing human approval weaken segregation of duties?
It changes its form. The control becomes configuration authority and monitoring rather than transactional separation, and it must be designed deliberately rather than inherited.
What should stay manual regardless of confidence?
Irreversible external actions: payments to new beneficiaries, statutory submissions and contractual commitments.
What should we expect over the next twelve months?
Expect vendors to ship autonomy defaults that are more aggressive than most organisations want, requiring deliberate configuration to restrain. Expect auditors to ask for the control narrative before the control. Expect the exception queue to become the most valuable role in the function. And expect the first meaningful failures to occur in processes where accountability steps were removed without replacement.
ERP Autonomy Roadmap — we sort your approval steps into rules, judgement and accountability, and automate only the first.