Why "auto-approve everything under $X" is an AP governance anti-pattern
A single spend threshold is a policy with exactly one rule. Real accounts-payable exception handling needs independent layers — and the layer everyone skips is what happens after something executes.
One threshold isn't a policy
“Auto-approve anything under $5,000” sounds like governance but is really just one number. Our demo uses that number as one tier of three: under $5,000 executes autonomously, up to $25,000 escalates to a named human approver, and above that there is no execution path at all — not a higher approval tier, a hard stop. Collapsing that into a single cutoff either blocks routine variances that should auto-clear, or lets six-figure exceptions through unattended.
Scope has to be checked before spend
A spend threshold alone also can't catch an out-of-scope action — in our demo, an attempt to release a vendor's credit hold directly gets blocked on scope before the dollar amount is even evaluated, because that action type was never authorized for this agent regardless of size. A policy that only checks amount would let a $10 unauthorized action straight through.
The layer that catches what policy can't
Policy passing doesn't mean the underlying system should accept the change. In our demo, an invoice adjustment can clear every policy check and still get rejected because the vendor is on credit hold in the ERP itself — a fact the policy engine doesn't and shouldn't need to know about. Two independent layers catch different failure modes; collapsing them into one threshold loses both.
What we got wrong the first time
Building this demo, our first version of rollback let a single executed action be reversed more than once — click it twice and the underlying PO amount silently drifted further than it should. The fix was to make an executed action's reversal path disappear permanently once a rollback referencing it exists. Worth naming directly: even a system designed around governance from the start can miss an edge case like this — the fix is testing for it explicitly, not assuming a well-intentioned design gets it right by default.
See it built, not just described
AP Automation engagement is the engagement this pattern comes from.
AP Automation engagement →