Delegated spend-authority playbook for SMBs

Most spend-authority setups fail in the same quiet way. Not with fraud, not with a blown budget, but with a $4,200 vendor invoice that the office manager approved "because the CFO was out and the vendor was threatening to pause the project." Nobody did anything malicious. But there's no record of who decided the threshold could be bent, why, or whether anyone reviewed it afterward. Multiply that across a year and you've got a control that exists on paper and evaporates under pressure.

Delegated spend authority for an SMB isn't really about the threshold numbers. Everyone can pick numbers. The hard part is what happens at the edges — the overrides, the exceptions, the "I'll approve it now and we'll sort the paperwork later." That's where money leaks and audits get ugly. This playbook focuses on the parts people skip: override governance, exception SLAs, and audit trails small enough that a three-person finance team will actually maintain them.

Start with the threshold table, but treat it as the easy 20%

The role-by-role threshold table is the foundation, and it's the part most teams get roughly right. The mistake isn't the table itself — it's treating the table as the whole policy. A threshold without an override path and an audit rule is just a suggestion.

Two things people consistently miss when building this out.

The monthly cumulative cap matters more than the single-transaction limit. A department head with a $2,500 per-invoice limit can spend $40,000 in a month across sixteen invoices and never trip a single approval. In real operations, this is how budgets quietly blow past plan — not on one big purchase, but on death-by-a-thousand-approved-invoices. The cumulative cap is what catches it.

The new-vendor authority column is separate on purpose. Approving a $600 payment to an existing supplier is a completely different risk than onboarding a brand-new payee for the same amount. Most fraud and most duplicate-payment messes start at vendor creation, not at the invoice level. If you only remember one nuance from this section, make new-vendor setup its own gated action.

Override governance: the part everyone leaves undefined

Every threshold table will get overridden. That's not a failure — that's business. The vendor needs payment today, the CFO is on a flight, the deal closes Friday. The failure is having no defined way to handle that, which forces people to improvise, and improvisation is exactly what you can't audit later.

1. 1
   Who authorized the override (a named person one level above the normal approver, not a peer).
2. 2
   What the normal approval path would have been (so the deviation is explicit).
3. 3
   Why it couldn't wait (one sentence — "vendor threatened work stoppage," "payroll-critical," "contractual deadline").
4. 4
   A back-fill deadline — when the standard documentation or second approval will be completed, usually within 3 business days.

The piece most teams miss: an override should never skip an approval. It should defer it. The payment goes out, but the second approver still reviews it within the SLA window and either ratifies it or flags it. This distinction changes everything, because now an override creates more scrutiny after the fact, not less. People stop reaching for overrides casually when they know a review is coming regardless.

Something worth watching: when the same person is authorizing more than two or three overrides in a month, that's not an emergency pattern anymore — that's a broken threshold. Either the limit is set too low for how that role actually operates, or someone's routing around a control deliberately. The override log tells you which, but only if you're logging in a structured way instead of scrolling through old emails.

Exception triage and SLAs

Overrides are one kind of exception. There are others — a payment that fails a duplicate check, an invoice that doesn't match a PO, a vendor whose bank details changed since the last payment. Without a triage system, these all land in the same inbox and get worked in whatever order feels most urgent, which usually means the loud vendor gets paid and the suspicious one does too, because nobody had bandwidth to look closely.

Triage means sorting exceptions by risk before anyone touches them, with a response deadline attached to each tier.

SLAs matter here not for tidiness but because unresolved exceptions have a half-life. An override that isn't back-filled within three days will almost never get back-filled — the context is gone, the person's moved on, and whoever's reviewing is now reconstructing a decision from memory. Set the SLA short, because anything beyond a week becomes archaeology.

“

A same-day phone call to a known number (not the one in the email) kills almost all of it.

One practical note on the bank-detail change: this is the highest-value exception to enforce a call-back on. The scam is boring and consistent — a fake email from "your vendor" asking to update payment details right before a large invoice is due. A same-day phone call to a known number (not the one in the email) kills almost all of it. If your triage does nothing else well, do this one.

The monthly exception report

If exceptions get worked and then disappear, you learn nothing from them. The monthly exception report is where patterns surface — which role keeps hitting its cap, which vendor keeps triggering mismatches, whether overrides are trending up. It doesn't need to be elaborate. It needs to be consistent and land in front of whoever owns the budget.

A workable monthly template covers five things:

1. 1
   Override summary — count, total dollar value, and who authorized each. Anything unusual gets a one-line note.
2. 2
   SLA performance — how many exceptions were resolved inside their window vs. blown. A rising miss rate means the process is understaffed or the SLAs are unrealistic.
3. 3
   Repeat offenders — vendors or roles appearing three or more times. These are process-improvement targets, not disciplinary ones.
4. 4
   Threshold pressure — anyone who hit their cumulative cap or came within roughly 10% of it. This is your early signal that a limit needs revisiting.
5. 5
   Open items — exceptions still unresolved past SLA, with an owner and a date.

The most useful thing on this report is the trend, not the snapshot. One override in a month is noise. Overrides climbing from two to five to nine over a quarter is a control quietly failing, and you want to catch that before it becomes the new normal. Threshold governance overlaps a lot with how you segment and route suppliers in the first place — the working-capital side of that is worth reading alongside this in the AP working-capital playbook.

Where AP automation actually enforces this (instead of just recording it)

The honest gap in most SMB setups: the policy lives in a Google Doc, and the actual spending lives in the accounting system, the card platform, and the AP tool. Nothing connects them. So the threshold table describes what should happen while the software happily processes whatever it's told.

Here's a simple workflow that shows how the documented rules map to automated enforcement.

1. 1
   The approval routing in the AP tool reads the same threshold table you documented — so a $12,000 invoice physically cannot be approved by a department head, regardless of who clicks the button.
2. 2
   Overrides become a system action, not a workaround. The four required fields are form fields. The payment can go out, but the record is created automatically and the back-fill review is scheduled, not left to memory.
3. 3
   Exception triage is rule-based — bank-detail changes, duplicate flags, and PO mismatches route to the right owner with the SLA clock already running, instead of everything piling into one inbox.
4. 4
   The audit trail writes itself as a byproduct of normal work, so the monthly exception report is a query, not a weekend of copy-pasting.

The value isn't automation for its own sake — it's that enforcement stops depending on whoever's paying attention that day. When the rules live in the tool, the policy holds during the exact busy, short-staffed weeks when a manual process always caves. Card spend has the same failure mode, which is why an enforced card rulebook matters for the same reasons — this breakdown of automated card policies covers that side in detail.

Audit trails small teams will actually maintain

The reason audit trails collapse in small companies isn't discipline — it's friction. If logging a decision requires a separate step, it won't happen during a busy close. The only durable audit trail is one that's a byproduct of doing the work, not an extra task bolted on afterward.

For a small team, a workable audit trail captures, for every payment above the lowest threshold:

1. 1
   The requester and the approver, with timestamps.
2. 2
   The threshold rule that applied and whether it was met or overridden.
3. 3
   If overridden

   the authorizer, the reason, and the back-fill status.

4. 4
   Any exception flags raised and how they were resolved.

That's four things, captured automatically as part of the normal approval flow. What you're building toward is the ability to answer one question fast: "Show me every override in Q3 and who signed off." If you can pull that in under a minute, your audit trail works. If it takes an afternoon of digging through email and Slack, it doesn't — no matter how thorough your policy document looks.

A real scenario

A regional HVAC company, around 30 staff and roughly $6M in revenue, ran spend authority entirely through email approvals and a shared inbox. Their threshold policy existed but wasn't enforced anywhere — approvers just knew the numbers "in general."

The problem surfaced during a slow-season cash crunch. Reviewing three months of AP, the owner found roughly $80k in payments that had gone out on informal overrides — mostly legitimate, but a handful that shouldn't have cleared: two duplicate supplier invoices worth about $6,400 combined, and a bank-detail change to a vendor that nobody had verified (that one turned out fine, but only by luck). No single person could say who'd approved what or why.

After moving to an enforced threshold table with structured overrides and same-day triage on bank-detail and duplicate flags, the informal-override volume dropped to a handful per month, all documented. The two categories that had actually cost money — duplicates and unverified bank changes — got caught at the point of payment instead of three months later. The owner's summary was blunt: the money they'd lost wasn't from big decisions, it was from small ones nobody was watching.

When this level of structure makes sense — and when it doesn't

When it's worth it: Once you're past three or four people touching spend, or once any single person other than the owner can move more than a few thousand dollars, the informal approach starts costing more than the structure does. The tipping point is usually the first time you can't reconstruct why a payment went out.

When it's overkill: A two-person shop where the owner sees every invoice doesn't need a five-tier triage table. Adding this machinery to a company that small just creates friction with no offsetting control benefit. Match the governance to the number of hands on the money, not to what looks comprehensive.

Who should skip most of this: Solo operators and true micro-teams. If one person requests, approves, and pays, you don't have a delegation problem — you have a segregation-of-duties problem, which is a different conversation entirely. Building override governance for a workflow with no real delegation in it is solving the wrong problem.

The whole point of delegated spend authority in an SMB is to let people move fast without you watching every dollar — while still being able to see, after the fact, exactly what happened and why. Get the thresholds roughly right, but spend your real effort on the overrides, the exception SLAs, and an audit trail that maintains itself. That's what separates a policy that looks good in a folder from one that actually holds when the month gets busy.