Six minutes of work, two days of latency. Purchase approval thresholds set by risk instead of seniority - with a tier table you can take to your next ops meeting.
The first objection to any approval process is always the same: it will slow us down.
It is worth taking seriously, and then it is worth turning over, because it has the causation backwards. You already have an approval process. Every company does. Yours is undocumented, and it runs at the speed of one person's inbox.
Time a single email approval honestly. Someone writes the request: two minutes. The approver reads it and replies: one minute. Someone forwards the reply to whoever places the order: thirty seconds. Someone pastes the details into the purchase log: two minutes. Call it six minutes of actual work.
Now time the same approval end to end. The request goes out at 4:40pm on Tuesday, after the approver has stopped reading email. It surfaces on Wednesday morning behind nineteen other things and gets read at 11:15. The approver has a question about which budget it lands on, asks it, and gets an answer Thursday morning because the requester is on site. Approved Thursday at 09:50. Six minutes of work, two days of latency.
The latency is not caused by approval. It is caused by the absence of routing. That is the whole argument of this article: the problem we described last week is not that decisions get made, it is that they get made in a queue with one server.
One approver is not a control
Take the contractor from last week's piece: forty to sixty requests a week, all to the managing director, roughly two thirds of them under $500. Nothing rejected last year. Not one.
A rule that has never produced a rejection is not scrutiny. It is a tollbooth. And a single approver generates three costs, of which only the first is obvious.
Latency is the visible one. Everything waits for one calendar.
Inattention is the one nobody admits. Judgement does not survive volume. At fifty decisions a week, forty of which are drill bits and fuel, the approval degrades into a keystroke - and the one request that genuinely needed twenty minutes of thought gets the same four seconds as the rest, because it arrived in the same inbox in the same format.
Workarounds are the expensive one. When the official route reliably costs two days, people with a deadline stop using it. They buy first and seek approval after, or put it on a card, or ask someone else to add the item to an order already going out. The spend does not stop. It leaves the process - and spend outside the process cannot be routed, budgeted, matched or reported on.
So the objection is real but misdirected. The fix for a slow approval process is not fewer approvals. It is more routes.
A starter tier table you can copy
Thresholds should be set by how much judgement a decision needs, not by how senior someone is. Here is a table you can take to your next ops meeting and adapt.
| Order value | Approver | Why |
|---|
| Under $500 | Team lead / department manager | High volume, low value, almost never refused |
| $500 – $5,000 | Finance or ops lead | Where budget coding and vendor choice actually matter |
| Over $5,000 | Owner / director | A genuine commitment, worth a conversation |
| Any value, new vendor | Finance, regardless of tier | Vendor risk is separate from spend size |
| Any value, over remaining budget | Owner | The exception that should always escalate |
The dollar bands are a starting point to adapt, not a benchmark. A $5,000 order is routine in a fabrication shop and a board-level event in a four-person agency. What matters is not the numbers, it is that each band exists because a different kind of judgement is needed there - volume handling at the bottom, coding and vendor choice in the middle, commitment at the top.
The interesting rows are the last two, and they are the ones most tier tables leave out. A first order from an unknown supplier carries risk that has nothing to do with its size: payment terms nobody checked, an entity nobody verified, a bank detail arriving by email. Route it to finance at any value. And an order that would take a budget past its remaining balance is not the same decision as an order of identical value that fits - one is a purchase, the other is a decision to spend more than was planned. Those two rows are what separate a routing rule from a spending limit.
Foxpedite's workflow builder routes on conditions like these - amount bands, department, vendor, off-catalog lines, budget state - and lets you simulate a rule against a sample order before it goes live, so you can see where a request would land without discovering it in production. Workflows are on the Advanced plan. (Workflows → · Pricing →)
The number your budget check should be using
Row five of that table only works if you can answer "is this over the remaining budget?" at the moment the order is raised. Most companies can't, and the reason is the three numbers again.
Paid has left the bank. Invoiced has been billed. Committed is what you are on the hook for the moment an order is approved. Only the third one supports a control, because only the third one exists early enough to stop anything.
Here is the trap in practice. Two department heads report 62% of a $100,000 budget used. Same percentage, same budget size, same month.
The first genuinely has $38,000 left. Everything approved has been invoiced; there is nothing in flight.
The second also shows $62,000 spent - but has $21,000 of approved orders that suppliers have not invoiced yet and $17,000 sitting in drafts in the approval queue. Their real remaining balance is zero. They are not at 62%. They are at 100% and about to find out in six weeks.
Neither number is wrong. They are answers to different questions, and the percentage does not tell you which question it answered. So before you trust a budget utilisation figure, ask one thing: are pending orders in the numerator? If they are not, the number is a history lesson.
Foxpedite computes remaining as total minus spent minus allocated, which means a draft order sitting in the approval queue has already reduced the number you are looking at. And overspend prevention is a per-budget configurable hard block, enforced in the database rather than as a browser check - so it holds whether the order arrives from the app, the API or an integration. Two qualifiers matter and both are load-bearing: it is configurable per budget, so a budget with the switch off will not block; and the ceiling applies only to operations that add to committed spend, so releasing a cancelled order or moving an allocation to spent on approval is never blocked by it. (Budgets → - Regular plan)
Write rules about roles, not about people
Here is a failure that takes eighteen months to show up, which is why almost nobody designs against it.
Month one: the rule is written. Orders over $10,000 route to Maria in finance. It works. Month fourteen: Maria leaves. Her account is deactivated on her last day, correctly, as part of offboarding. Month fifteen: a $12,000 order is raised, routes to a deactivated account, and sits.
It does not error. It does not bounce. It reports its status as "pending", which is true and completely useless, and it stays that way for three weeks until the requester chases the supplier, the supplier says they never received a PO, and somebody finally opens the record.
The fix is a one-word discipline: a rule names a position, never a login. "Finance lead" survives Maria leaving. "Maria" does not. Foxpedite supports role-based assignment, multi-level approvals and escalation rules - including time-based escalation, which is the second half of the same fix, because the right answer to a request sitting untouched for three days is for it to move on rather than to wait more politely.
While you are at it, test the thing nobody tests: deactivate a test account that appears in a rule and see what the system does with the next request. Whatever it does is what it will do in month fifteen.
Putting this in place this week
None of the following requires our software, or any software.
- Write down the tiers. Three rows is enough to start. Do it in a shared document today rather than a perfect policy next quarter.
- Name a role for each tier, not a person. Then separately record who currently holds that role.
- Add the two exception rows - new vendor, and over remaining budget. These are where the actual risk lives.
- Decide, per budget, whether it may be overspent, and write that decision down. Some budgets genuinely should be hard ceilings and some genuinely should not; what causes damage is not knowing which is which.
- Check whether your budget number includes pending commitments. If it doesn't, maintain the committed figure by hand until your tooling can do it. It is tedious and it is still cheaper than finding out in arrears.
If you want the system to enforce it rather than you, that is what Foxpedite does. Budgets, projects, committed spend, purchase orders and multi-currency are on the Regular plan at $30 per seat per month, minimum five users. The visual workflow builder, with role-based routing, multi-level approvals, escalation and simulation, is on Advanced at $35 per seat. Both come with a 14-day trial and no credit card. (Pricing →)
Next week: what happens after the order is approved and the goods actually turn up - goods receipt, three-way matching, and why the invoice that matches your purchase order perfectly is the one worth worrying about. (Three-way match, explained for teams without a procurement department →)
The dollar amounts and scenarios in this article are illustrative, written for this piece. They are not customer data or measured results.