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, made at implementation and compounded by every year the design goes unreviewed. Users and compliance teams are not the cause.

In each case the ERP is functioning correctly. The rules it enforces have 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, simply 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 traveling, ill or 14 time zones away on a roadshow, payments and commitments stack up. A queue of 20 pending approvals can sit for a week because the one approver has 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. That means a named delegate, documented in the ERP, with a defined activation condition, not an informal understanding: "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, where a $60K commitment is broken into three $20K purchase orders to stay below the review threshold, are the most common. They tend to be discovered during an audit, long after go-live.

A procurement manager can split orders with a single contractor for over a year this way. Every individual PO is legitimate. The cumulative commitment never goes through the review that the approval chain was designed to trigger. Nobody has done anything deliberately wrong. The approval process was slow, the projects were urgent, and splitting was the path of least resistance.

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 feel the friction most.

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, so the item routes to a backup approver after 24 hours instead of disappearing into a queue. 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 who approved and what information they had at the time. 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 friction behind it produces compliance theater.