What is an approval matrix?

What an approval matrix is

Every organisation limits who can commit its money and make exceptions. A team leader might approve spend up to 1,000, a department head up to 10,000, and anything larger goes to the finance director. An approval matrix writes those limits down in one table so everyone applies them the same way.

Approval matrices appear under many names: delegation of authority (DoA) matrix, authority matrix, approval limits, signing authority or sign-off matrix. They cover purchase orders, invoices, expenses, discounts, credit limits, contracts, write-offs and hiring. The idea is always the same: a type of request and a value on one axis, a role and a limit on the other.

What goes into an approval matrix

A practical approval matrix usually includes:

• Request type: purchase order, invoice, expense, discount, contract, credit limit and so on.
• Value bands: the thresholds that change who must approve, such as up to 1,000, 1,000 to 10,000, over 10,000.
• Approver role: a role rather than a named person, so the matrix survives people changing jobs.
• Scope: cost centre, department, entity or region, since limits often differ between them.
• Extra conditions: capital spend, new suppliers, non-budgeted items or restricted categories that need an additional approver.
• Rules for combinations: whether approvals are sequential or parallel, and whether a higher approver replaces or adds to a lower one.

A worked approval matrix example

The example table on this page shows a simple purchase order approval matrix. For a 7,500 operating purchase in the marketing cost centre, the matrix says the department head must approve. If the same purchase were from a new supplier, the procurement lead would also need to approve. If it were capital spend over 25,000, both the finance director and the managing director would need to sign it off.

Even this small table raises questions a real policy has to answer. Is the limit per line or per order? Can someone split a 12,000 order into two 6,000 orders? Who approves when the approver is also the requester? Good approval matrices answer these explicitly, because they are exactly the gaps that cause problems in an audit.

The same structure works well beyond purchasing. A discount approval matrix swaps order value for discount percentage and spend type for customer tier. A credit limit matrix uses the requested limit and the customer's risk rating. Once you see the pattern, most sign-off policies turn out to be approval matrices of one kind or another.

Common problems with approval matrices

Most approval matrices start life in a spreadsheet or a policy PDF. That works while the business is small, but a few problems tend to appear as it grows:

• Several versions circulate, and people apply whichever one they have.
• Systems do not follow it. The ERP has its own approval setup that was configured once and not updated.
• Changes are slow. Moving a limit means a change request to IT or an ERP consultant.
• Exceptions are handled by email, and nobody can later show who approved what and why.
• Audit questions are hard to answer, such as which limit applied to this PO in March.

Good practice when designing one

A well-designed approval matrix is short enough to read on one page and precise enough that two people applying it always reach the same answer. A few habits help.

Use roles, not names. Map roles to people in a separate list, so the matrix does not go out of date every time someone changes job or goes on leave. Make bands continuous, so every value falls into exactly one band, and say clearly whether limits include or exclude VAT. State how approvals combine: does a higher approver replace the lower one, or do both sign? Are they sequential or in parallel?

Close the obvious loopholes. Say whether limits apply per order, per line or per supplier per month, so large purchases cannot be split to avoid a higher approver. Say what happens when the approver is also the requester. Plan for absence, with a named delegate role for each approver. And review it on a schedule, at least yearly and whenever the organisation changes shape, with a record of what changed and when.

Finally, test it. Take a sample of real requests from the past year, including awkward ones, and check the matrix gives the answer the business expects for each. Those cases become the test set for every future change.

Keep the matrix itself separate from the list of who holds each role. The matrix changes when policy changes; the role list changes when people join, leave or cover for each other.

How to automate an approval matrix

Automating an approval matrix means letting systems ask "who must approve this?" and get a consistent answer every time. The steps are straightforward: agree the matrix, including the edge cases; keep the limits in a table the finance team owns; build the logic that reads the table and applies the extra conditions; test it with real past requests; and connect it to the systems that raise requests, such as the ERP, a Power App or an approval workflow.

With Condexa, the matrix becomes a lookup table of approval limits by cost centre and role, and a short workflow applies the extra rules for capital spend or new suppliers. Your ERP or Power Automate flow asks Condexa who must approve and gets the answer in milliseconds, with a trace showing the row and rules used. The purchase order approval page shows a full example.