How to build a purchase order approval matrix (with template)

Every growing business reaches the point where "just ask the boss" stops working for purchase orders. Orders wait in inboxes. People approve things they should not. And when audit asks who signed off a large order, nobody is quite sure which rule applied.

A clear purchase order approval matrix fixes that. Here is how to build one that people will actually follow.

What a purchase order approval matrix is

An approval matrix is a table that says who must approve a purchase order, based on facts about the order. The most common facts are:

• Value of the order
• Cost centre or department
• Category of spend, such as IT, capital or marketing
• Supplier status, for example new or on a watch list
• Budget position, in budget or over budget

It is your delegation of authority, written down in a form a system can use. For a short definition, see what is an approval matrix.

Step 1: List the decisions, not the people

Start by writing the question the matrix answers: "Who must approve this purchase order?" Then list the facts that change the answer. Resist the urge to start with names. People change roles; the policy should not need rewriting when they do. Use roles such as budget holder, head of department, finance director.

Step 2: Set value bands

Pick a small number of value bands. Four or five is usually plenty. Too many bands and nobody remembers them; too few and senior people drown in small orders. Agree whether the bands are for the order total or the value per line, and whether they include VAT.

Step 3: Add the exceptions

Most matrices have a handful of exceptions that override the bands. Common ones:

• Capital expenditure always needs finance sign-off
• New suppliers need procurement approval as well
• Over-budget orders go one level higher
• IT and software purchases need the IT manager

Write each exception as a short sentence. If you cannot say it in one sentence, it is probably two rules.

Step 4: Put it in a table

Here is a simple template to adapt. Replace the bands and roles with your own.

Step 5: Decide what happens at the edges

The hard cases are what cause arguments later. Agree up front:

1. What happens if an approver is the person who raised the order?
2. Can orders be split to stay under a band? (They should not be. Say so.)
3. Who approves when the usual approver is away?
4. What happens when an order is amended after approval?

Step 6: Make it easy to change

This is where most matrices fail. The table gets built into the ERP, a Power Automate flow or custom code. Six months later finance wants to change a band and it becomes a dev ticket and a wait for the next release. Meanwhile, people work around it.

Keep the numbers in a table that finance owns, separate from the logic that uses them. When a limit changes, you change one row, not the code.

Step 7: Test it with real orders

Before you switch it on, run ten or twenty recent orders through the new matrix and check the answers with the people who approved them. You will find at least one surprise. Better now than in the audit.

Step 8: Keep a record of every decision

An approval matrix is only as good as your ability to show it was followed. For each order you want to know which rule applied, with which values, and which version of the matrix was live at the time.

How Condexa helps

Condexa turns the matrix into a decision any system can call. You build the logic on a visual canvas, keep the value bands and approvers by cost centre in a lookup table finance can edit, and test with real orders before publishing. Your ERP, Dynamics 365 or Power Automate flow asks "who must approve PO-24019?" and gets the answer back in milliseconds, with a trace showing exactly why.

When the finance director changes a limit, it is a change to a table row and a new published version, not a release.

Next steps

See the full purchase order approval use case, or read why spreadsheet decision logic causes trouble at scale. To see your own matrix running, book a 30-minute demo.