Most AP automation projects treat approval thresholds as a settings screen. Pick a dollar limit, name a backup approver, save. The agent runs, invoices flow, and the controller notices six months later that a $9,800 recurring charge from a vendor nobody remembers has been posting every month without a human ever looking at it.
Thresholds are not a settings screen. They are the boundary between what an agent may commit the company to and what a human must see. Under SOX, they are also a control that has to be documented, tested, and defensible to an auditor. The framework below is how to design that boundary so approvals route to humans by policy rather than by whoever notices first.
Start With Authority, Not Automation
Before an AP agent posts anything, the delegation of authority matrix has to exist on paper. Who can approve $5,000. Who can approve $50,000. Who signs off above $250,000. Which cost centers each approver owns. Whether capital purchases route differently from opex. This is finance hygiene that predates agents, but agents make it enforceable in a way email approvals never were.
The reason to start here is regulatory. SOX Section 404 requires public companies to establish and assess internal control over financial reporting, including designing controls, setting thresholds for material variances, and maintaining documentation. An agent that approves invoices without a documented authority matrix behind it is not a control. It is an unlogged risk.
The practical output is a table with four columns: dollar band, GL account class, approver role, and evidence required. Every row is a rule the agent will enforce. Every row is also a rule your external auditor can test by pulling a sample and checking the trail. If a row cannot be tested that way, it does not belong in the matrix.
Dollar Thresholds Are the Floor, Not the Ceiling
Dollar limits are the easiest lever and the most misused. A single flat threshold ("agent auto-approves under $2,500") ignores that a $2,400 invoice to a new vendor with a mismatched remit-to address is riskier than a $40,000 invoice on a three-way-matched PO from a supplier of ten years.
A workable dollar framework has three bands. Below the low band, the agent posts if the invoice matches a PO and receipt within tolerance. Between the low and high bands, the agent codes and routes to the budget owner, who approves in one click with the match evidence attached. Above the high band, the agent prepares the packet but the payment requires two approvers, at least one of whom is outside AP. Where full segregation of duties is not possible, compensating controls include management review of all transactions above a defined threshold and dual authorization requiring two approvers. Dual authorization above a band is the compensating control most agent deployments skip.
The dollar numbers themselves should be calibrated to invoice volume, not pulled from a template. If 90% of your invoices are under $1,000, an auto-approve ceiling at $1,000 means the agent is doing almost nothing. If your median invoice is $8,000, a $2,500 ceiling routes everything to humans and defeats the point. Pull twelve months of AP history, plot the distribution, and set the low band where the volume actually is.
Vendor Risk Changes the Threshold
The same $10,000 invoice carries different risk depending on the vendor. A tiered vendor risk score, computed at onboarding and refreshed quarterly, should modify the dollar thresholds the agent uses. The inputs are boring and effective: age of vendor relationship, cumulative spend history, whether the vendor is on a master agreement, whether bank details have changed in the last 90 days, and whether the vendor appears on any sanctions or debarment list.
A new vendor with no history should have a much lower auto-approve ceiling than a five-year supplier on a signed MSA. Bank detail changes are the highest-signal event in the entire AP process. The ACFE's 2026 report identifies billing schemes and check and payment tampering among the fraud categories with the most significant combined frequency and financial damage. Both usually begin with a change to vendor master data. Any invoice from a vendor whose bank details changed in the last 30 days should route to a human regardless of amount, and the human should be someone who did not authorize the change.
GL Account Sensitivity Is Its Own Axis
Dollar and vendor are not enough. A $3,000 invoice coded to office supplies is a different animal from a $3,000 invoice coded to a legal reserve, a related-party account, or a manual journal-adjustment clearing account. GL sensitivity is the third dimension of the threshold matrix.
Rank your chart of accounts into three sensitivity classes. Routine opex (supplies, utilities, standard SaaS) sits in the low class and inherits the normal dollar bands. Accounts that touch estimates, accruals, or capital (legal accruals, restructuring, capitalized software, prepaids over 12 months) sit in the medium class and drop one dollar band, so the agent routes to a human sooner. Accounts flagged as fraud-adjacent or judgment-heavy (intercompany, related party, suspense, contra-revenue) sit in the high class and always require human approval regardless of amount.
| Low GL sensitivity | Medium GL sensitivity | High GL sensitivity | |
|---|---|---|---|
| Established vendor, no recent changes | Agent auto-approves within band | Route to budget owner | Always route to human |
| Established vendor, recent bank change | Route to human, not the requester | Route to controller | Route to controller + CFO |
| New vendor (under 90 days) | Route to budget owner | Route to controller | Route to controller + CFO |
This is where the agent earns its keep. A human reviewing every invoice cannot hold three dimensions in their head at once. An agent can evaluate dollar band, vendor tier, and GL class on every line, apply the intersection, and route accordingly. The controller reviews the routing logic quarterly, not each invoice.
Duplicate and Anomaly Signals Route Around the Matrix
Some signals should force human review even when the matrix would auto-approve. Duplicate invoice detection is the obvious one, and it is worth being specific about what counts as a duplicate. Same vendor, same amount, same invoice number is trivial. Same vendor, same amount, different invoice number, within 30 days is the pattern worth catching. Same amount across two vendors with similar names in the same week is the pattern that catches vendor-master manipulation.
Other override signals: invoice date more than 90 days before receipt, PO amount exceeded by more than tolerance, first invoice from a vendor in the current fiscal year, and any invoice that would push a budget line over its annual cap. Each of these should trigger a hold with a specific reason code, not a generic "review required" flag. Reason codes are how the controller later measures which signals actually catch things and which are noise.
The stakes here are not theoretical. The ACFE analyzed 2,402 fraud cases across 143 countries and reported a median loss of $104,000 per case with an average exceeding $1.4 million. In an earlier ACFE study, over half of occupational fraud cases were linked to a lack of internal controls or management override of controls. An agent with a well-designed override layer is a control. An agent that trusts its own matrix is a management-override risk.
Segregation of Duties When the Agent Is One of the Duties
SOX segregation of duties assumes humans in each role. When the agent handles coding, matching, and payment preparation, the segregation question becomes: who can override the agent, and who reviews what the agent did? Segregation of duties best practice calls for multi-level invoice approvals based on amount thresholds and board or business-owner sign-off on high-value payments. That maps cleanly to agent-run AP if two conditions hold.
First, the person who can change the agent's rules is not the person who approves payments. The controller sets thresholds. The CFO approves the threshold policy annually. AP clerks work exceptions but cannot alter the matrix. Second, every agent action is logged with the rule that fired, the inputs it evaluated, and the human who ultimately released the payment. This is the same trail an auditor would want from a manual process, produced automatically. Structural limits on what an agent can and cannot do inside a ledger are covered in what an agent structurally cannot do, and the authority design here sits on top of those limits.
The erp.io platform enforces this split by role: the AP agent proposes, a named human approves, and a deterministic shadow ledger reconciles every posting the next morning. Threshold changes themselves route through a separate approval workflow, so the audit trail covers not just invoices but the rules that governed them.
Test the Matrix the Way an Auditor Would
A threshold matrix that has never been tested is a hypothesis. Quarterly, pull a stratified sample of agent-approved invoices across each dollar band, vendor tier, and GL class. Confirm the routing matched the policy, the evidence was captured, and the approver had authority for that combination. Then pull the exceptions: invoices the agent held. Confirm the hold was resolved by the right person and the resolution was documented.
Two metrics matter more than the rest. First, false-hold rate: invoices the agent routed to humans that were then approved without any change. A high false-hold rate means thresholds are too tight and the agent is offloading work it should own. Second, post-approval exception rate: invoices approved by the agent that were later reversed, disputed, or found in error. This is the number that tells you whether the auto-approve bands are set correctly. Both should be reviewed in the same monthly cadence as the close itself, which is discussed in closing faster is mostly a reconciliation problem.
What a Good Threshold Policy Looks Like on Paper
The finished artifact is short. One page defining the dollar bands and the roles that approve each. One page defining vendor tiers and how they modify the bands. One page listing GL sensitivity classes and any accounts that require human approval regardless of amount. One page of override signals with reason codes. One page describing the quarterly test procedure and who owns it. Five pages, signed by the CFO, reviewed annually, referenced in the SOX narrative.
Agents make AP faster and cheaper. APQC benchmarking puts the median cost to process an invoice at $10.18 for top-quartile organizations and $21.40 at the overall median, and agent-driven workflows compress that further. But the speed is worth having only if the thresholds behind it are the ones the CFO would defend in a boardroom. Thresholds are the policy. The agent is the enforcement. Keep those in the right order.
The same policy-before-enforcement logic applies anywhere two systems or two teams can both touch the same fact: deciding which side owns a field before wiring up a two-way sync, designing a chart of accounts around the reports you need rather than copying the old one, building a rollback condition into the cutover plan instead of just a go-live date, keeping custom fields from becoming ungoverned system design, and designing the first consolidated close before migrating the first entity.