Approval Limits and Delegation of Authority Inside Your ERP

Almost every approval matrix I inherit started life as a table in a finance policy document. It reads cleanly on paper: purchases up to a value go to a manager, above that to a director, above that to the board. Then someone tries to load it into an ERP workflow engine, and it falls apart within a week of go-live. The reason is simple. A policy document is written for humans who apply judgement. A workflow engine applies rules with no judgement at all. This guide is about designing a delegation of authority (DoA) that behaves the same in both worlds, and about the control logic that stops the failures I see over and over.

Why the finance-manual matrix dies in the engine

The finance manual assumes a reader who knows the context. It says "the department head approves up to 50,000" and trusts a human to know which department, which head, whether tax is included, and what to do when that head is on annual leave. The workflow engine knows none of this. It needs every one of those assumptions turned into an explicit, machine-readable rule, and where a rule is missing it does one of two things: it stops dead, or worse, it lets the document through.

The classic failures follow a pattern. The matrix has value bands but no rule for what "value" means, so the engine reads gross where the policy meant net. It names roles like "department head" but the ERP holds people, not roles, so a leaver still sits in the approval chain. It assumes one approval per document, but a requester adds a line after submission and no one re-checks it. And it never says what happens when the only approver in a band is also the person raising the request. A policy tolerates these gaps because a human fills them. An engine cannot.

So the design job is translation. Take the policy intent and express it as dimensions the engine can read: value band, spend category, legal entity, and a named fallback for every approver. Get those four right and most of the pain disappears. For the workflow mechanics that sit under this, see my companion piece on designing approval workflows; this article stays deliberately on control design, not platform buttons.

A delegation-of-authority table that works

Below is the shape of a DoA I would actually load. Notice what the finance manual usually omits: category overrides that cut across the value bands, an entity dimension so a shared services centre does not approve for a subsidiary it has no mandate over, and a named escalation path for absence and departures. Values are illustrative and pre-tax net.

Two columns earn their place here. The category overrides (capex, IT, subcontract, and separately MRO consumables which usually route on a lighter chain because they are low-value and high-frequency) mean the same 30,000 spend takes a different path depending on what it buys. And the escalation path is not a note in a manual; it is a named person or a named rule the engine can resolve when the primary approver is unavailable. "Route to their manager" is a rule. "Someone will sort it out" is not.

The four rules that stop the common failures

Bands and categories decide where a document goes. These four rules decide whether the routing can be trusted. Each one exists because I have watched its absence cause a real problem.

1. No self-approval, ever.

A requester must never appear as an approver on their own document, at any band, even when they hold the authority for that value. This sounds obvious and is violated constantly, because the person who raises a small purchase is often the person authorised to approve one. The engine must compare requester identity against every approver in the resolved chain and block a match outright, not just warn.

2. The cost-centre owner needs a second pair of eyes.

A subtler version of the same problem: the approver is not the requester, but is the owner of the cost centre the spend hits, and the requester reports to them. That is one person controlling both the request and the budget it draws down. Above the lowest band, force a second independent approver who does not own that cost centre. One signature over a budget you control is not a control.

3. Band checks read the net, not the gross.

The single most common band error. A 48,000 net order with tax reads as 50,400 gross. If the engine bands on gross, it escalates a purchase the policy intended to keep at department level, and users learn to distrust the matrix. If it bands on net when the policy meant gross, a 50,000 purchase slips under the line. Pick one, write it down, and make sure the field the engine reads is the pre-tax net value on every document type.

4. A changed line re-triggers approval.

Approval is granted against a specific document state. If a requester or buyer edits a line after approval, adds quantity, swaps an item, raises a price, the original approval no longer describes what is being bought. The rule: any change to value, quantity, item, or vendor after submission invalidates prior approvals on the affected bands and re-routes. Without this, approval becomes a one-time gate anyone can walk through and then move the goalposts behind. This is where approval design meets requisition and approval automation most directly.

The segregation-of-duties matrix

Approval limits control how much one person can commit. Segregation of duties (SoD) controls the combinations of steps one person can perform, so no single individual can run a transaction end to end unobserved. The value bands and the SoD matrix are two different controls and you need both. ISACA's control glossary frames SoD as splitting authorisation, custody, and recording; in a procure-to-pay flow that maps onto five roles.

Read it as: the person who receives goods must not be the person who pays for them; the buyer who chooses the vendor must not approve their own purchase order; the AP clerk who releases payment must not do anything else in the chain. The "Caution" cells are combinations that are tolerable in a small team with a compensating control (a review report, a second sign-off) but should never be granted casually. In the ERP, these are not just policy, they are role assignments; two conflicting roles on one user account is the finding an auditor circles first.

A worked abuse pattern: the split PO

Here is the pattern the value bands invite if you stop at them. Suppose the department-head band tops out at 50,000, above which a division head must approve. A buyer wants to place a 147,000 order but does not want it seen at division level. So they raise three purchase orders of 49,000 each, to the same vendor, in the same week, for the same project. Each PO sits comfortably under the 50,000 band and clears at department level. The control was real, and it was defeated by arithmetic.

No single approval rule catches this, because each document is individually compliant. This is why you need a detective control alongside the preventive bands. The detective control is an aggregation report: same vendor, same requester or cost centre, POs summing above a band threshold inside a rolling window (say 30 days), flagged for review. It does not block the transaction; it surfaces the pattern to someone who can ask why. Preventive controls stop what they are shaped to stop. Detective controls catch what slips between the shapes.

Twelve scenarios to test before go-live

A DoA is only as good as its behaviour under edge cases, and you find those in user acceptance testing, not in production. Run this script against a copy of your real matrix before go-live. Each row should produce the expected outcome exactly; anything else is a design gap to close now, not after the auditors arrive.

Scenario 12 catches the boundary ambiguity that no one writes down: is 50,000 in the band below or the band above? The matrix must state it, and the engine must match. For where this sits in the wider procure-to-pay chain, see my walkthrough of the PR to PO to GRN workflow.

Bringing it together

A delegation of authority that works is not a bigger table than the one in the finance manual; it is a more honest one. It names what "value" means, it names the fallback when an approver is absent or gone, it separates the roles that must never combine, and it pairs preventive bands with detective reports for the abuse the bands invite. Test it against the twelve scenarios before go-live and you close the gaps in a sandbox rather than in an audit finding. The workflow engine will do exactly what you tell it. The whole discipline is telling it the right thing, completely, with nothing left to a reader's judgement.

If you want a reference for how one major platform models these approval hierarchies and conditional routing, Microsoft's Dynamics 365 Finance documentation is a solid, vendor-neutral read on workflow approvals, though the control design in this article applies to any ERP.

Independence note: I do not resell or take commission from any ERP vendor. The platforms named here are references for illustration, not recommendations, and the control design stands independent of any product.