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.

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. First, the monthly cumulative cap matters more than the single-transaction limit. A per-invoice limit can be bypassed by many small invoices in a month, and the cumulative cap is what actually catches budget drift.

Second, the new-vendor authority column is separate on purpose. Approving a payment to an existing supplier is a different risk than onboarding a brand-new payee. Make 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 — e.g., "vendor threatened work stoppage", "payroll-critical").
4. 4
   A back-fill deadline — when the standard documentation or second approval will be completed, usually within 3 business days.

An override should never skip an approval. It should defer it: the payment can go out, but the second approver still reviews within the SLA window and either ratifies it or flags it. That creates more scrutiny after the fact and reduces casual overrides.

Watch frequency. If the same person authorizes more than two or three overrides in a month, that's no longer emergency behavior — it's either a threshold set too low or someone routing around controls. A structured override log reveals which.

Exception triage and SLAs

Overrides are one kind of exception. Others include duplicate-payment flags, invoice/PO mismatches, and vendor bank-detail changes. Without triage, these all land in the same inbox and get worked in whatever order feels most urgent, which usually misses the highest-risk items.

SLAs matter because unresolved exceptions have a short half-life. An override not back-filled within three days will almost never be back-filled later — the context vanishes. Keep SLAs short; anything beyond a week becomes archaeology.

Practical note on bank-detail changes: require a same-day phone call to a known number (not the one in the update email). That callback kills almost all vendor-bank-change scams.

The monthly exception report

If exceptions get worked and then disappear, you learn nothing. The monthly exception report is where patterns surface — which role keeps hitting its cap, which vendor triggers mismatches, whether overrides are trending up. It needs to be consistent and land in front of the budget owner.

1. 1
   Override summary — count, total dollar value, and who authorized each; one-line notes for unusual items.
2. 2
   SLA performance — resolved inside window vs. blown; a rising miss rate signals understaffing or bad SLAs.
3. 3
   Repeat offenders — vendors or roles appearing three or more times; targets for process improvement.
4. 4
   Threshold pressure — anyone who hit or came within ~10% of their cumulative cap.
5. 5
   Open items — exceptions unresolved past SLA, with an owner and a date.

Make the monthly exception report a CSV export. Ask your AP/ERP team to produce one CSV per reporting window with this header row:

paymentid,invoiceid,paymentdate,amount,currency,vendorid,vendorname,requesterid,requesterrole,approverid,approverrole,thresholdrule,overridden,overrideauthorizerid,overridereason,overridebackfilldue,exceptiontype,exceptionstatus,resolutiondate,audit_timestamp

1. 1
   Window

   choose calendar-month or a rolling 30-day window and state it.

2. 2
   Cadence

   schedule the export on the first business day after the window closes.

Governance: require a documented override reason, an explicit backfill due date, and periodic review to preserve segregation of duties and limit ad hoc approvals (see Addressing Problems with the Segregation of the Duties in Smaller Companies: https://digitalcommons.kennesaw.edu/cgi/viewcontent.cgi?httpsredir=1&article=2304&context=facpubs).

1. 1
   paymentid and invoiceid

   auto-linking and reconciliation

2. 2
   overridden + overrideauthorizerid

   flag exceptions and route for secondary review

3. 3
   vendorbankhint + exception_type

   trigger vendor-change hold/verification

4. 4
   overridebackfilldue

   drive SLA reminders and monthly exception lists

The most useful thing on this report is the trend, not the snapshot. Overrides climbing quarter-over-quarter is a control quietly failing. See related guidance: Finance evidence lifecycle & master index for SMBs (A Finance Evidence Lifecycle and Master Index for Smbs) and the AP working-capital playbook (Dont Let Ap Erode Your Runway a Working Capital Playbook for Supplier).

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

Most SMBs have the policy in a doc and the spending in disconnected systems. Integrating AP automation with your spend-authority rules makes the threshold table enforceable instead of advisory.

1. 1
   Approval routing reads the documented thresholds and blocks approvals that exceed them.
2. 2
   Overrides are a system action with form fields and a scheduled back-fill review.
3. 3
   Exception triage is rule-based and routes cases with the SLA clock running.
4. 4
   The audit trail is created automatically as part of normal approvals so reporting is a query.

The value isn't automation for its own sake — it's that enforcement no longer depends on whoever's paying attention. Card spend has the same failure mode; see this breakdown of automated card policies: Stop Loose Card Policies from Breaking Your Close an Automated.

Audit trails small teams will actually maintain

Audit trails collapse in small companies because logging is friction. If recording a decision is an extra step, it won't happen during a busy close. The durable audit trail is a byproduct of work, not an add-on.

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.

If you can answer "Show me every override in Q3 and who signed off" in under a minute, your audit trail works. If it takes an afternoon of digging through email and Slack, it doesn't.

A real scenario

A regional HVAC company (~30 staff, ~$6M revenue) ran spend authority entirely through email approvals and a shared inbox. Their threshold policy existed but wasn't enforced; approvers only "knew the numbers in general."

During a cash crunch, the owner found roughly $80k in informal overrides over three months — mostly legitimate but including two duplicate invoices (~$6,400) and one unverified bank-detail change. No one could say who approved what or why.

After moving to an enforced threshold table with structured overrides and same-day triage on bank-detail and duplicate flags, informal overrides dropped to a handful per month and the costly categories were caught at payment instead of months later.

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

When it's worth it: Once you have three or four people touching spend, or when any non-owner can move more than a few thousand dollars, the informal approach usually costs more than the structure. The tipping point is 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. That machinery adds friction without control benefit; match governance to the number of hands on the money.

Who should skip most of this: Solo operators and true micro-teams. If one person requests, approves, and pays, delegation rules solve the wrong problem; you're facing a segregation-of-duties issue instead.

The goal of delegated spend authority in an SMB is to let people move fast without watching every dollar — while still being able to see, after the fact, exactly what happened and why. Get thresholds roughly right, but focus on overrides, 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.