Designing Financial Approval Chains That Don't Break Under Pressure

Financial approval chains fail in three ways: thresholds that were right when set but not maintained, delegation chains that create single points of failure, and approval workflows that can be routed around when they are inconvenient. All three are design failures. Not user failures, not compliance failures — design failures, made at implementation and compounded by every year the design is not reviewed.

We have audited approval chain designs on eight ERP implementations. We found threshold decay on six of them. We found delegation gaps on five. We found workaround evidence — usually split purchases — on three. In each case, the ERP was functioning correctly. The rules it was enforcing had become wrong.

Threshold decay

Dollar thresholds set at implementation reflect the spending patterns and risk tolerance of a specific moment. Three years later, inflation, growth, or a change in business model may have made those thresholds wrong without anyone explicitly deciding to change them.

The $2.5M committee review threshold was not reckless when it was set. In 2019, it caught the category of capital expenditure that genuinely warranted collective judgment. By 2024, cumulative inflation had moved several equipment categories that the committee was designed to review below that line. The system behaved correctly according to its rules. The rules had been overtaken by economic reality.

The fix is not complicated: build a threshold review into the annual budget cycle. Every dollar threshold in every approval rule gets explicitly reconfirmed or adjusted. A threshold that has not been reviewed in 18 months should be treated as potentially wrong — not because it definitely is, but because nobody has checked.

Delegation and single points of failure

A CFO-only approval requirement for anything above $50K means that when the CFO is unavailable — travel, illness, a 14-hour time zone gap on a roadshow — payments and commitments stack up. On one project we found a queue of 23 pending approvals sitting for 6 days because the approver was in the US with no mobile access to the ERP.

The approval chain had no delegation path. It had not been designed with a backup. The assumption was that the CFO was always reachable. That assumption is wrong at least several times a year at any active company.

Every approval chain above a certain threshold should have at minimum one designated delegate and a policy for when delegation activates. Not an informal understanding — a named delegate, documented in the ERP, with a defined activation condition: "CFO unavailable for more than 24 hours during business days." Delegation that activates informally activates inconsistently, which means your approval chain depends on institutional memory rather than system design.

The workaround problem

When approval chains are too slow or too rigid, people find ways around them. Split purchases — breaking a $60K commitment into three $20K purchase orders to stay below the review threshold — is the most common. We have found it on three separate implementations, in each case discovered during an audit 18 months after go-live.

In one case, a procurement manager had been splitting orders with a single construction contractor for over a year. The individual POs were all legitimate. The cumulative commitment had never gone through the review that the approval chain was designed to trigger. Nobody had done anything wrong in a deliberate sense — the approval process was slow, the projects were urgent, and the path of least resistance was to split.

The fix requires two things: monitoring for split purchase patterns (same vendor, similar items, close timestamps, within a 30-day window) and a conversation about why the workaround exists. If people are splitting purchases, the approval process is probably too slow or the thresholds are wrong. Punishing the behavior without addressing the process solves nothing.

Designing for speed without sacrificing control

Approval chains fail to get used when they are slower than the alternative. A 3-day approval cycle for a $5K equipment purchase creates pressure to work around the process — and the people working around it are often the highest performers, because they are the ones who feel the operational friction most acutely.

The right design: automatic approval for items below a threshold with a vendor in the approved supplier list. 24-hour SLA for mid-tier approvals with automated escalation if the SLA is missed — the item does not disappear into a queue, it routes to a backup approver after 24 hours. Committee review only for items above a threshold that genuinely warrants collective judgment.

The goal is not maximum control. It is appropriate control at appropriate cost. Maximum control applied uniformly across all purchase values produces the split purchase problem.

The audit trail that answers the question

Every approval decision should record not just who approved, but what information they had at the time of approval. A CFO who approved a $2.4M capex based on a one-line description in an email had materially less information than one who approved based on a full business case with cost-benefit analysis and three competing quotes.

The approval trail should capture the document version, the supporting materials attached at the time, and the stated justification. When an auditor asks "why was this approved?", the answer should be a click, not a reconstruction from email archives three months later. Build the approval trail to answer the auditor's question before the auditor asks it.

Split purchases are almost always a management failure, not an employee failure. If people are working around your approval chain, the approval chain is poorly designed. Fix the process — the speed, the thresholds, the delegation rules. Punishing the workaround without fixing the underlying friction produces compliance theater, not compliance.