Try it now, capture a real invoice
Free plan · No credit card · Your data stays yours
Delegation of authority: the short answer
A delegation of authority (DOA) is the formal rule that says who can commit company money, and up to what dollar amount. It is usually written as a matrix: rows for roles, columns for spend categories, cells for approval limits. A manager might approve up to $5,000, a director to $25,000, a VP to $100,000, and anything above that goes to the CFO or the board.
Without one, approval defaults to whoever happens to be around, which is how companies end up with a junior employee approving a $60,000 invoice because their manager was on vacation and the vendor was chasing payment.
What is a delegation of authority?
Authority to bind the company legally sits with the board, which delegates it to the CEO, who delegates it downward. The DOA is the written record of that chain. It covers more than spend in most companies (signing contracts, hiring, opening bank accounts, granting refunds), but the part that touches accounts payable every single day is spend approval.
It is a control, not a bureaucratic formality. Auditors test it, and it is one of the standard accounts payable internal controls. If a payment went out approved by someone without the authority to approve it, the control failed, no matter how legitimate the invoice was.
What is a delegation of authority matrix?
The matrix is the DOA in a form people can actually use. It answers one question in one glance: given this amount and this type of spend, who signs off? A good one is short enough to fit on a page and specific enough that nobody has to ask.
Two things a matrix must define that most drafts forget. First, whether limits are per transaction or cumulative per vendor per year, because a $4,000 monthly retainer is a $48,000 annual commitment that no one ever formally approved. Second, what happens when the approver is unavailable, because an undefined delegate is how approvals get rubber-stamped by whoever is at their desk.
Delegation of authority matrix example
A workable example for a mid-sized US company. Treat the numbers as a starting point and tune them to your spend profile:
| Role | Operating expense (per invoice) | Capital expenditure | New vendor contract | Vendor bank detail change |
|---|---|---|---|---|
| Team lead | Up to $1,000 | None | None | None |
| Manager | Up to $5,000 | Up to $5,000 | None | None |
| Director | Up to $25,000 | Up to $25,000 | Up to $25,000 annual value | None |
| VP / department head | Up to $100,000 | Up to $50,000 | Up to $100,000 annual value | None |
| CFO | Up to $250,000 | Up to $250,000 | Up to $500,000 annual value | Approve (with AP verification call) |
| CEO | Above $250,000 | Up to $1,000,000 | Above $500,000 annual value | Not applicable |
| Board | Not applicable | Above $1,000,000 | Strategic or multi-year commitments | Not applicable |
Note the last column. Changing a vendor's bank account is not a spend decision, so it does not belong on a dollar scale, but it is arguably the most dangerous action in the whole AP process. A criminal who changes the bank details on an approved vendor never has to get a fake invoice past anybody. That row deserves its own rule: senior approval plus an out-of-band callback to a phone number you already had on file, never one from the email requesting the change.
Delegation of authority policy: what to include
- Scope. Which entities, departments, and spend types the policy covers.
- The matrix itself. Roles, categories, and limits, with amounts stated in USD and whether they are pre-tax.
- Per-transaction vs annual commitment. State explicitly how recurring spend is measured.
- Delegation during absence. Who acts when an approver is out, and whether that delegate inherits the full limit or a reduced one.
- Escalation. What happens when spend exceeds the top of someone's band: it moves up, it does not get split.
- Conflicts of interest. Nobody approves their own expenses, their own team's bonuses, or a vendor they have a relationship with.
- Emergency spend. A defined path for genuine urgency, with mandatory retrospective approval, so people do not invent their own.
- Review cadence. Reviewed at least annually and whenever the org chart changes, because a matrix listing people who left is not a control.
Approval limits should start upstream, at the request rather than the invoice. If spend is approved when someone raises a requisition, before a commitment exists, AP is verifying a decision that was already made properly. Teams that route approvals at the point where purchase orders are raised catch overspend while it can still be stopped, rather than after the goods have shipped and the invoice has landed.
Invoice splitting: the loophole every DOA matrix creates
The moment you set a $5,000 approval limit, you create an incentive to submit two invoices for $4,800. This is the single most common way DOA controls get defeated, and it is rarely fraud. Usually it is a manager who wants their project moving and finds the escalation slow.
Splitting is also the classic pattern in real AP fraud: repeated invoices priced just below a threshold, from the same vendor, in the same period. It looks like nothing on any single transaction and obvious on the aggregate.
Detecting it needs a control that looks across invoices rather than at one at a time. Practical checks: flag any vendor with multiple invoices in a short window that individually fall just under a threshold; approve against cumulative vendor spend for the period rather than the single invoice in front of you; and review spend just below each limit as a routine analytic. Automated duplicate and pattern detection catches this far more reliably than an approver who only ever sees one invoice at a time.
How to set approval thresholds that actually work
The most common design mistake is setting limits so low that senior people spend their week approving small invoices. When a VP has 200 approvals in a queue, they stop reading them. A control that is universally rubber-stamped is worse than no control, because it produces evidence that a review happened when it did not.
Calibrate against your actual data. Pull twelve months of invoices, sort by amount, and look at the distribution. If 80% of invoices are under $2,000 and they consume 90% of approval time while representing 15% of spend, your thresholds are wrong. Raise the lower bands so that routine, low-risk, PO-backed spend clears with minimal friction, and concentrate human attention on the tail where the money actually is.
Risk should modify the threshold, not just the amount. A $50,000 invoice matching an approved PO with a receipt is lower risk than a $6,000 invoice from a brand-new vendor with no PO. A sensible matrix lets a clean three-way match flow through on a lighter approval, and routes exceptions and non-PO spend to a human every time.
Delegation of authority and segregation of duties
They are related but they are not the same control, and conflating them leaves a gap. The DOA governs how much a person can approve. Segregation of duties governs which combinations of tasks one person can hold at all.
You can be perfectly compliant with your DOA matrix and still be exposed. If the director who approves a $20,000 invoice can also create the vendor and release the payment, the limit is irrelevant, because they can pay themselves within their own authority and nobody else ever touches the transaction. Both controls have to hold. The DOA sets the ceiling; segregation ensures more than one pair of hands is involved beneath it.
How to enforce the matrix in software
A DOA that lives in a PDF on the shared drive is an aspiration. The gap between the written matrix and what actually happens is where audit findings come from, and it is almost always the same failure: the policy says $5,000, the system lets anyone with AP access post and pay, and the difference is covered by people being conscientious.
Enforced properly, the rules are configured once and the system routes every invoice by amount, category, department, and vendor status. Someone without the authority cannot approve, not because they are told not to, but because the option does not exist. When an approver is out, the delegate rule applies automatically instead of the invoice sitting for a week. Every approval is stamped with a user and a time, so evidence for an auditor is an export, not an email hunt.
That is exactly what our invoice approval software does: approval routing by threshold and role, automatic escalation and delegation, and a complete audit trail behind every payment. Pair it with accounts payable audit software and the threshold controls, duplicate detection, and evidence trail all run off the same record. Our guide to the invoice approval process walks through the workflow design in more depth.
Frequently asked questions
Who should approve a delegation of authority policy? The board, or the audit committee where one exists. Since the board's own authority is the source of every delegation below it, a DOA approved only by management is circular.
How often should a DOA matrix be reviewed? At least annually, and immediately after any reorganization, acquisition, or change of CFO. Stale approver names are the most common defect auditors find.
What is the difference between a DOA and an approval workflow? The DOA is the policy: who may approve what. The approval workflow is the mechanism that carries it out inside your systems. The policy without the workflow is unenforced; the workflow without the policy is arbitrary.
The bottom line
A delegation of authority matrix is a genuinely useful control and it takes an afternoon to write. Set the bands from your real invoice distribution, define what happens when an approver is away, treat vendor bank changes as their own high-risk category, and watch for spend clustering just below your thresholds. Then put it in a system that enforces it, because the version people follow is the one the software makes them follow, not the one in the PDF.