AI Agents and Human Approval: Where the Agent Must Stop

An agent that matches invoices, drafts purchase orders and prepares payment runs can take hours of clerical work off a finance team every day. The same agent, given one wrong permission, can release a payment to a fraudster's bank account. The difference is not the model. It is where you put the human approval step, what the approver sees, and whether the approval means anything.

This article is for CFOs, COOs, heads of operations and risk leaders at Saudi banks, finance companies, insurers and any organisation running an ERP. It sets out a practical rule for deciding which agent actions need a person, the approval points that matter most on the ERP side, and how to tell a working control from approval theatre.

The rule: reversibility and blast radius

Ask two questions about every action an agent can take.

1. Can it be undone cleanly? Drafting an email can. Sending money cannot, or not without a recovery effort that may fail.
2. How far does the damage spread if it is wrong? A typo in one internal note stays local. A changed bank account on a vendor record affects every future payment to that vendor.

The national guidance points the same way. SDAIA's AI Ethics Principles state that automated AI systems involving decisions with an impact that is irreversible or difficult to reverse should trigger human oversight and final determination. The same document holds the people who design, own and operate an AI system accountable for its outcomes. An approval step is how that accountability becomes a named person and a timestamp.

Four tiers of agent action

Tier	What the agent does	Human role	Examples
1. Read	Looks up, summarises, reports	None per action; periodic review	Aged payables report, balance enquiry, policy lookup
2. Draft	Prepares an action for a person to send or post	Person sends or posts	Purchase order draft, reply to a customer complaint, journal proposal
3. Act, reversible	Executes within tight limits; can be reversed	Sampled review, alerts on exceptions	Tagging a ticket, booking a meeting, routing an invoice to the right approver
4. Act, irreversible or high impact	Never executes alone	Named approver decides, with evidence	Payment release, vendor bank detail change, refund above limit, write-off

Most of the value sits in tiers 1 and 2, where the agent does the reading, matching and drafting. Tier 4 stays small and strict.

Where the human must approve on the ERP side

These approval points come up in almost every finance and procurement process. They are where agents save the most time and where a missing control costs the most. For how they sit inside a wider ERP design, see ERP and PMO.

Purchase orders

The agent can turn a request into a complete draft: supplier, items, prices from the framework agreement, budget line and delivery date. A human approves when the order exceeds the requester's limit, has no contract or agreed price behind it, exceeds the available budget on the cost line, or uses a supplier not on the approved list. The agent should flag a split order, where one purchase is broken into several just under a limit, rather than process it.

Invoice approvals

Matching an invoice to the purchase order and the goods receipt is ideal agent work. Clean matches within tolerance can flow through. A human approves any invoice with a price or quantity mismatch outside tolerance, no goods receipt, a duplicate invoice number or amount from the same supplier, or a supplier tax number that does not match the vendor record.

Payment releases

Payment release is always a human decision. The agent prepares the payment run, checks each line against approved invoices, highlights anything unusual, such as a first payment to a new account or an amount well above the supplier's normal range, and presents the run for approval. A person releases it. In most organisations a second person should too.

Vendor master changes

This is the most abused control in finance. A request to change a supplier's bank account, often by email and often urgent, is a classic fraud pattern. The agent can collect the request, compare it with the current record and show exactly what changes. A human approves, and only after verifying the change through a call to a contact number already on file, never one supplied in the request. Newly changed bank details should trigger an extra check on the next payment.

Credit notes, write-offs and closed periods

Credit notes above a limit, debt write-offs and any posting into a closed accounting period change reported numbers. They need a named approver, every time.

Where the human must approve on the customer side

In financial services the same rule applies to actions that touch customers:

• Refunds, fee reversals and goodwill credits above a set amount.
• Changes to limits, account status or contact details, since a changed phone number or email is often the first step of account takeover.
• Closing a complaint where the customer disputes the outcome.
• Anything involving credit data. The Personal Data Protection Law (Article 24) requires additional controls for credit data, including verifying the data subject's consent to its collection, disclosure or a change of purpose, and notifying them when another entity requests disclosure. An agent should never decide those questions alone.

Segregation of duties applies to agents too

Treat the agent as a user with its own identity, not as a shared service account. The NCA Essential Cybersecurity Controls require user authorisation based on need-to-know and need-to-use, least privilege and segregation of duties (control 2-2-3-3), plus privileged access management (2-2-3-4). The ECC binds government entities and private operators of critical national infrastructure, and the NCA encourages every other entity in the Kingdom to apply it.

In practice:

• The agent cannot approve what it drafted. The approver is never the agent and never the person who raised the request.
• The agent gets the narrowest permissions that work. Read on the vendor master, draft on purchase orders, no posting rights on payments.
• Approval limits follow the person, not the agent. If a manager can approve up to a set amount, that limit is enforced in the ERP, whichever route the request took.

What a real approval screen shows

An approval is only as good as the information behind it. Every tier 4 request should show:

1. The exact action proposed, in plain language.
2. The evidence: the documents, the match result, the record before and after.
3. The rule that triggered approval: over limit, mismatch, new bank account.
4. What happens on approve and on reject.
5. A required reason on rejection, and an optional one on approval.

For vendor master changes, show the old and new values side by side. For a payment run, show the lines that differ from the supplier's history first.

How to tell a control from theatre

An approval step can exist and still do nothing. Measure it:

• Time to approve. If approvals of high-value payments take seconds, people are not reading.
• Rejection and edit rate. A rate of zero over many weeks means either the agent is perfect or the approver is not looking. Investigate which.
• Post-approval reversals. Approved actions later reversed or corrected show where the evidence on screen was not enough.
• Queue time. If approvals wait for days, people will find ways around them. Set targets and escalate stale items.
• Exceptions caught. Count duplicates, mismatches and suspicious changes the step actually stopped.

Log everything: the agent's proposal, the evidence shown, the approver, the decision and the time. The ECC sets a minimum retention period of 12 months for cybersecurity event logs (control 2-12-3-5); keep approval logs at least that long, and longer where your auditors require.

Checklist: a human must approve when

• Money leaves the organisation, or a customer balance changes beyond a set limit.
• A master record changes that future transactions depend on: vendor bank details, customer contact details, credit limits.
• The action cannot be cleanly reversed.
• The amount or the case is outside the policy the agent was given.
• The data involved is sensitive or credit data, or the action discloses personal data to another party.
• The agent's confidence is low, the documents conflict, or the request looks urgent and unusual.
• The action would post into a closed period or change reported figures.

TQN builds AI agents that do the reading, matching and drafting in Arabic and English, connected to your ERP and core systems, with approval steps designed in from the first workshop and designed to support PDPL and NCA requirements. For banks, finance companies and insurers, see how this applies in financial services.

Map your approval points first

Bring one process, such as invoice-to-payment or customer refunds, to an Agent Opportunity Workshop. In 60 minutes we map which steps an agent can take, which need a person, and what the approver should see. The workshop is free.