Maverick Spend: How to Find It, Measure It, and Reduce It

Ask a finance leader how much of their spend goes off-process and the answer is usually a confident underestimate. Ask for the number with evidence and it tends to double.

A working definition

Maverick spend covers three overlapping behaviours: buying without approval, buying from a supplier outside the preferred list, and buying at a price worse than the one already negotiated. The third is the most expensive and the least visible.

How to measure it

Start with addressable spend — the categories you actually intend to control. Payroll, tax, and rent are not maverick spend candidates. Then calculate:

Why people go off-process

Nobody wakes up wanting to violate a procurement policy. In interviews the reasons are consistent and reasonable:

• The compliant route takes four days and the need is today.
• Nobody knows a preferred supplier exists for this category.
• The request form asks for information the requester does not have.
• The approver is on holiday and there is no delegate.
• The policy threshold has not moved in six years and no longer reflects real costs.

Each of those is fixable, and each is a design problem rather than a compliance problem.

A reduction plan that works

1. 1Publish the top ten categories with their preferred suppliers where requesters will see them.
2. 2Cut the requisition form to the fields an approver genuinely needs.
3. 3Set auto-approval under a low-risk threshold so small purchases stop clogging the queue.
4. 4Require a delegate for every approver.
5. 5Report the maverick rate by department monthly, visibly, without blame.

That last step does more than the other four combined. Teams respond to a number they can see moving.

What good looks like

Mid-market organisations that take this seriously typically move from somewhere around a third of addressable spend off-process to under ten percent within two or three quarters. The savings come less from catching rogue purchases and more from routing volume back into contracts that were already negotiated and underused. Two caveats: the rate will rise again the first time an approver goes on leave without a delegate, and a category with genuine urgency — emergency maintenance, clinical supply — may never get below twenty percent, which is a reasonable place to stop optimising. The mechanics of the fix are in approval workflow design and the one-page policy.

Start with the operating case, not the feature list

Context matters in maverick-spend reduction because the visible transaction is only the final record of several earlier decisions. Consider this operating case: A department buys the approved software product through a reseller at list price because the contracted supplier is hard to find. The purchase follows budget authority but still leaks negotiated value. The useful question is not whether a form was completed. It is whether the evidence available at that moment was sufficient for a named owner to make a reversible, explainable decision. That distinction keeps the process practical: control is attached to consequence, not paperwork.

Trace one ordinary case and one awkward case from the first request to the final accounting entry. Record who knew what, which system held it, and what happened when the expected path failed. This exposes handoffs that a workshop diagram misses: the spreadsheet used to repair supplier names, the inbox where an approver asks for context, or the monthly reconciliation that makes reports believable after the fact.

Evidence to assemble before changing the process

Do not begin configuration with a blank workflow canvas. Build a small evidence pack first. It should be compact enough for the working team to challenge line by line, and representative enough that a successful pilot means something. The minimum useful pack contains the following inputs.

• Invoice and card transactions with supplier, requester, category, and amount
• Valid contracts and preferred-supplier rules by category
• PO and approval records linked to paid transactions
• Exception reasons separated from genuinely uncontrolled purchases

The decisions the workflow must make explicit

A dependable maverick-spend reduction process does not ask everyone to approve everything. It identifies a small set of decisions, assigns each to the person with the authority and information to make it, and records enough context to explain the result later. If two reviewers are checking the same fact, remove one. If nobody can state what would cause rejection, the step is probably ceremonial.

• Which definition of maverick spend answers the management question
• Whether leakage is supplier, process, price, or approval non-compliance
• Which categories justify enforcement and which need a lighter path
• Whether the compliant route is fast enough to deserve adoption

Write these decisions as testable statements. For example: approve when the budget is available and the need is valid; route to security only when company data enters the service; reject when the supplier identity cannot be verified. Testable rules make demos, implementation workshops, and post-launch audits materially more useful than labels such as finance review or procurement check.

A practical implementation sequence

Sequence matters because teams otherwise automate the cleanest diagram and discover the real exceptions after launch. Keep the first release narrow, but do not make it artificially easy. Include enough volume to observe behaviour and at least one category with meaningful exceptions. A sensible sequence is:

1. 1Calculate several rates instead of forcing one blended number
2. 2Segment by department and category to find concentrated causes
3. 3Interview repeat requesters before changing policy
4. 4Fix discovery and cycle time before adding sanctions

At each step, preserve a manual recovery path and name the person allowed to use it. Recovery is not failure; invisible recovery is. An exception handled in a private message teaches the system nothing. An exception recorded with a reason can inform the next policy or configuration change.

Failure modes worth testing before launch

Happy-path acceptance testing proves very little. Build tests from the cases that cause delay, uncontrolled commitment, duplicate work, or misleading reporting. The following failures are common enough to deserve an explicit owner and expected response before rollout.

• Calling every no-PO invoice maverick without checking exclusions
• Publishing a company-wide percentage with no denominator definition
• Blocking urgent work without a controlled emergency route
• Treating individual employees as the cause of a badly designed process

Run these as tabletop exercises with the requester, approver, finance operator, and system administrator in the same room. If the answer depends on somebody remembering an unwritten convention, document it or redesign the path. If the answer requires administrator intervention for an ordinary exception, calculate that support load before declaring the workflow scalable.

Measure the control without gaming it

A metric needs a stable denominator, a reproducible source, and an owner who can change the result. Publish the definition beside the number. Show medians with a tail percentile where time is involved, and split rates by material populations rather than averaging unlike work together.

• No-PO spend as a share of addressable spend
• Off-contract spend where a valid contract existed
• Price variance against contracted rates
• Repeat exception rate after process changes

Review the underlying records monthly during rollout, then quarterly once behaviour stabilises. A rising exception rate can mean the process is deteriorating, but it can also mean the system has started recording exceptions that were previously invisible. Interpret the movement before rewarding or correcting anyone.

Limits and cases that need a different tool

No maverick-spend reduction design is universal. State exclusions before estimating benefits. That protects the business case from inflated addressable volume and tells operators where a different control, specialist system, or human judgement remains necessary.

• A lower rate does not prove savings were realised
• Some tax, utility, and statutory payments are not addressable
• Card data may not contain enough line detail for precise classification
• Enforcement without supplier availability can interrupt operations

Keep a decision record that survives the project

For each material choice, record the date, owner, evidence considered, option selected, rejected alternatives, and the condition that would trigger review. This is not meeting minutes. It is a compact explanation of why the company accepted a particular cost or risk. Six months later, a new operator should be able to distinguish an intentional compromise from an accidental omission without locating the original project team.

Use the record during monthly operations reviews. Compare the assumptions made at approval with actual volume, cycle time, exceptions, and supplier behaviour. When an assumption fails, change the rule or reopen the decision; do not quietly build manual work around it. That feedback loop is what turns a configured workflow into an operating system rather than a frozen implementation project.

The final design should be easier to explain than the process it replaces. If a requester cannot predict what information will be required and who will decide, complexity has merely moved behind the screen. Keep the common path short, make consequential exceptions visible, and revisit the rules when transaction patterns or organisational ownership change.