A delegation of authority (DoA) says who in your business is allowed to commit money, and up to what amount. An approval matrix is the working version of it: a table that lists each type of transaction (a purchase order, a capital purchase, a contract, a credit note, a change to supplier bank details) against the role that can approve it at each dollar limit. Writing it down is the easy half. The hard half is making your purchasing, job and accounting systems actually enforce it, so approvals don't depend on people remembering a document nobody has opened since it was signed.
This guide explains both terms in plain English, gives a sample delegation of authority matrix you can adapt, and shows how it maps into the systems where approvals really happen.
Delegation of authority vs approval matrix
- Delegation of authority is the policy. The owners or board delegate authority to roles (general manager, finance manager, project manager) to make commitments on the business's behalf, with limits and conditions.
- The approval matrix is the table that puts the policy into practice. For each transaction type, it shows the approval route and the dollar limits.
Many businesses have one without the other: a board-approved DoA that never became a usable matrix, or a matrix built up from habit with no policy behind it. You need both, and they need to agree.
A sample approval matrix (illustrative only)
The roles and limits below are placeholders to show the structure. They are not advice on what your limits should be. Set real figures with your owners, board and accountant. "Limit A" is your lowest limit, "Limit C" your highest.
Purchase orders, budgeted operating spend
- Up to Limit A: team leader or site supervisor
- Limit A to Limit B: department or project manager
- Limit B to Limit C: finance manager
- Above Limit C: general manager or owner
Capital purchases (capex approval process)
- Budgeted, up to Limit B: general manager
- Budgeted, above Limit B: owner or board
- Not in the budget, any amount: owner or board, with a short written case
Contracts and subcontracts
- Standard terms, within the job budget: project manager up to Limit B, then general manager
- Non-standard terms, or longer than an agreed period: general manager, plus legal review
Job variations and price changes
- Within the job's contingency: project manager
- Beyond contingency, or reducing margin below the agreed level: general manager
Credit notes, write-offs and discounts
- Up to Limit A: accounts receivable lead
- Above Limit A: finance manager
Payroll and supplier master data
- New supplier or change of supplier bank details: finance manager, after a call-back check using a known phone number
- Pay rate changes: general manager
Payments
- Payment runs released by two people, neither of whom entered the bills
Rules that sit alongside the matrix
The limits matter less than the rules around them. These are the ones that tend to get skipped:
- Approve by role, not by name. When someone leaves or goes on leave, the matrix shouldn't break.
- No self-approval. The person who raises a purchase requisition can't approve it.
- No splitting. Breaking one purchase into several smaller POs to stay under a limit counts as one purchase.
- Separate the key duties. The person who sets up a supplier or changes bank details shouldn't be the person who releases payments.
- Cover for absence. Say who approves when the usual approver is away, and for how long.
- Budget status counts. Unbudgeted spend usually needs a higher approval than the same amount within budget.
- Review it once a year, or whenever the structure of the business changes.
Where approval matrices break down
The usual pattern is a matrix that lives in a Word document or a policy folder, while approvals actually happen by email, text or a quick "yep, go ahead" in the corridor. Then each system has its own idea of the rules:
- The purchasing or job system has approval limits set up years ago, by name, for people who have since left.
- The accounting software lets anyone with bill-entry access approve bills.
- The bank has dual authorisation, but the two people approving can't see the PO or the receipt behind each payment.
- Variations are agreed on site and approved after the work is done.
Each system enforces a slightly different version of the rules, or none at all. When something goes wrong, nobody can show who approved what, when, and against which limit. That record is what an audit trail is for.
Making your systems enforce the approval matrix
The goal is one set of rules, applied in every system where money is committed or paid. Here is how the matrix typically maps across:
- Purchasing or stock system: PO and purchase requisition approval limits by role, multi-level approval routes for higher amounts, and a block on sending an unapproved PO to a supplier.
- Job or project system: POs and subcontracts checked against the job budget, with variations routed for approval before work starts. Over-budget commitments go to a higher approver automatically.
- Accounting software: user roles that separate entering bills from approving them, supplier bank detail changes restricted to named roles, and bills only approved once they're matched to an approved PO.
- Bank: payment batches released by two authorised people, with the approved bills attached.
- One record across all of them: each approval logged with the approver, date, amount and the rule that applied, so you can answer "who approved this?" in seconds.
When the systems don't share users or approval rules, a connecting layer can hold the matrix in one place and push decisions to each system. That avoids keeping three copies of the same rules up to date. We've built purchase order approval systems that clients have relied on daily for more than a decade, and the lesson is consistent: get the matrix agreed first, then build it in once.
When it's working, a project manager raises a PO against a job, the system knows it's over their limit and over the job budget, sends it to the general manager's phone with the budget position shown, and the approved PO goes to the supplier. The bill that arrives later can only be approved because it matches that PO. Nobody had to look up a policy document.
Our post on purchase order approvals across systems covers the options in more detail, from built-in approval features to connected approval workflows.
Frequently asked questions
What is a delegation of authority matrix?
It's a table that sets out who can approve each type of financial commitment, and up to what amount. It turns the business's delegation of authority policy into a practical approval route for each transaction type.
What should be included in an approval matrix?
At minimum: transaction types (POs, capex, contracts, variations, credit notes, payments, supplier and payroll changes), dollar limits, the approving role at each level, whether the spend is budgeted, and rules for absence, splitting and self-approval.
How do you set up a multi-level approval workflow?
Write the matrix first. Then set up each system so that amounts above a limit route to the next approver automatically, by role. Where systems can't share the same rules, connect them so the approval happens once and is recorded in one place.
What is a typical capex approval process?
Usually a short written request (what, why, cost, budgeted or not), approval by a senior manager up to a set limit, and owner or board approval above it or for anything unbudgeted. The limits are a decision for your business and accountant.
Is the approval matrix the same as the purchase order approval process?
The PO approval process is one part of it. The matrix also covers capital spend, contracts, variations, credit notes, payments and changes to supplier or payroll details.
Next step
If your approval rules live in a document while the real approvals happen by email, book a free initial chat. We'll talk through where your approvals sit today and what it would take for your systems to enforce them. Our approval workflow system implementation service builds the matrix into the purchasing, job and accounting systems you already use.