01Approvals are patches
An approval usually gets added after something goes wrong. A supplier is paid twice, a discount goes through that shouldn't have, someone gets access they never needed. The cause usually sits underneath: the data was unreliable, the rules weren't clear, or nobody owned the decision. Fixing that takes time, so someone senior signs instead.
Years later the signature is still there, and the cause underneath it was never fixed. Each new incident adds another. A request that once needed one approval now needs four, and each approver assumes the one before them checked.
People work around this. They know which numbers to double-check, which approver actually reads, and who to call when something looks wrong. The process runs because the people in it carry what the process can't.
02Why AI agents expose them
An AI agent has none of that knowledge. Put an agent into a process held together by sign-offs and one of two things happens. It prepares the request in seconds and then waits in the same queue, so the speed the business paid for never arrives. Or the approvals are switched off so the agent can run, and the few that were doing real work go out with the rest.
Both outcomes have one cause. The approvals were covering for problems the process never solved, and an agent can't cover for them the way people did.
03The approval audit
Before an agent goes into any process, ask what each approval is really covering for.
| What it covers for | How to tell | The fix |
|---|---|---|
| Bad data | The approver checks the figure against another system or a spreadsheet | Fix the data at the source, so the figure can be trusted |
| Unclear rules | Two approvers would decide the same request differently | Write the rule down, so a system can apply it |
| No owner | The request goes to several people, and none of them would call it theirs | Name one owner for the decision |
| A regulator requires it | It is written into a standard, a licence condition or a delegation | Keep it, and give the approver what they need to judge it |
Most approvals fall into the first three rows. Fix the cause and the approval has nothing left to do.
04Real control sits where the risk is
What survives the audit is real control: a small number of decisions where a named person is accountable and has to look properly. Sorting the steps of a process into three layers shows where they are.
| Layer | What it is | An example |
|---|---|---|
| Process | Repeatable and rules-based. A system does it, and people supervise | Matching an invoice to its purchase order |
| Judgement | Needs experience to interpret. Tools help, and a person decides | Resolving a disputed quantity with a supplier |
| Control | A named person is accountable, and it can't be delegated | Approving a change to a supplier's bank details |
Take invoice to pay, a process every organisation runs.
| Step | Layer | Why |
|---|---|---|
| Receive the invoice | Process | A system can take it in from any channel |
| Capture the details | Process | The fields can be read automatically |
| Match to purchase order and receipt | Process | A rule decides whether it matches |
| Fix a mismatch | Process or Judgement | A $2 variance is a rule; a disputed quantity needs someone who knows the supplier |
| Route for approval | Process | A rule should decide who approves |
| Approve | Control only where the risk is | See below |
| Pay | Process, with a Control gate | Releasing the payment run usually needs dual authorisation |
Now look at the approve step. A manager approving a $300 invoice from a supplier used for five years, already on a purchase order and matched to the receipt, has nothing new to judge.
A request to change that same supplier's bank account is different. Redirecting payments to a new account is a well-known route for fraud, often through an email that looks like it came from the supplier. That request needs a named person who calls the supplier on a number already on file before anything changes.
Real control lives in a handful of places like that:
- a new supplier, customer or product being set up
- bank details or payment instructions changing
- access to systems or money being granted
- an amount above delegation
Everything else can run on rules, with review by exception. An agent can do that work. The Control decisions stay with a named person, who now has time to look.
The same pattern holds well beyond payables. In every regulated business, real control sits in a few high-risk decisions:
| Sector | Where the risk is | The control |
|---|---|---|
| Banking | A transaction that looks like money laundering | A named AML officer reviews it and reports it |
| Insurance | A claim payment above delegated authority | One named claims manager signs |
| Any regulated business | A change to a critical system | A named owner approves it, with a rollback ready |
Each one is a single named person looking properly, instead of a chain of sign-offs.
05Worked example: the month-end close
The same sort applies to the close. Most month-end journals carry a second signature, and most of those signatures check a number a rule already decided.
| Step in the close | Layer | Why |
|---|---|---|
| Recurring accruals and reversals | Process | Same amount or formula every month, reversed on a rule |
| Standard allocations and recharges | Process, Judgement when disputed | The basis is agreed; a dispute needs a person |
| Provisions, impairments and estimates | Judgement | Someone who knows the business decides and owns the number |
| Manual entries posted after close | Control | High risk, and rare enough to deserve a proper look |
| Entries to accounts that rarely move | Control | Unusual by definition |
Auditors already work from this map. The auditing standard on fraud, ISA 240 (ASA 240 in Australia), requires them to test journal entries for the risk of management override, and its application material points to entries to unusual or seldom-used accounts, entries by people who don't usually post journals, entries at period end or after close with little explanation, and round numbers. Those are the entries where a named person should approve and look properly.
06Before an agent goes in
- Run the audit. List the approvals in the process and what each one covers for.
- Fix the causes. Clean the data, write the rules down, name the owners.
- Sort the work. Mark every step Process, Judgement or Control, and give each Control a named person.
- Then put the agent in. It runs the Process layer, prepares the Judgement calls, and hands Control to the person who owns it.
New engine, same factory explains why that order pays back, with a century-old lesson from electrification.
Check any change to approvals, thresholds and delegations with your auditor, and with your regulator where one applies, before you make it.