How to build an approval matrix that doesn’t slow your company down
Every company already has an approval matrix. In some, it’s a signed policy that everyone knows. In others, it’s a habit: “send it to whoever usually signs”. Both decide where money goes, but only one of them can be explained to an auditor.
Get the matrix wrong in one direction and anyone can commit the company to anything. Get it wrong in the other and your finance director spends Monday morning approving Rp 150,000 taxi claims while a Rp 400 million purchase waits behind them. Both cost money, just in different ways.
This guide explains what an approval matrix is, what goes into one, an example you can adapt, and the rules that separate a matrix that works from one that just slows everyone down.
What is an approval matrix?
An approval matrix is a table that sets out who can approve which transactions, up to what amount and in what order. It is the working version of your delegation of authority (DoA): the board delegates authority to management, and management delegates parts of it down the organisation, with limits at each level.
A complete matrix answers four questions for every request:
- What kind of transaction is it? An expense claim, a purchase request, a new vendor and a payment carry different risks.
- How much is it? Thresholds decide how many levels of approval a request needs.
- What else is true about it? The cost centre, project, legal entity, vendor, or whether it is over budget or outside policy.
- Who approves, and in what order? Named by role, sequential or in parallel, with a backup for every approver.
What goes into the matrix
Start by listing every type of transaction that commits or moves company money. For most companies, that includes:
- Employee expense claims and cash advances
- Purchase requests and purchase orders
- Vendor invoices, especially those without a PO
- Payments and payment runs
- New vendors and changes to vendor bank details
- Contracts and recurring commitments
- Budget transfers and capital expenditure
Not every type needs its own column. Many companies use one matrix for spend (expenses and purchases) and a separate, stricter one for payments, vendor changes and capital expenditure.
An example matrix
Here is a simple matrix for purchase requests at a mid-sized company. The amounts are only illustrative; yours should come from your own data.
| Request value | Approvers, in order |
|---|---|
| Up to Rp 5 million | Department head |
| Over Rp 5 million, up to Rp 50 million | Department head, then finance manager |
| Over Rp 50 million, up to Rp 250 million | Department head, finance manager, then CFO |
| Over Rp 250 million | Department head, finance manager, CFO, then President Director |
On top of the amount tiers, add conditions that apply whatever the amount:
- Over budget or outside policy: add the finance controller to the chain.
- Coded to a project: add the project owner, so the person accountable for the budget sees the spend before it is committed.
- New vendor: vendor verification by procurement must be complete before the first PO can be approved.
- Capital expenditure: route to the CFO, whatever the amount.
Eight rules for a matrix that works
1. Name roles, not people
“Head of Operations”, not “Budi”. People change roles, go on leave and leave the company. A matrix written in names breaks the day one of them does, and requests quietly pile up behind someone who is no longer there.
2. Set thresholds from your data, not your org chart
Pull the last twelve months of requests and look at how they are distributed. In most companies, a small number of large requests make up most of the value, while most requests by count are small. Set thresholds so that the bulk of requests need a single approver, and senior people spend their time on the few that carry real risk. If your CFO approves hundreds of small requests a month, the thresholds are too low and those approvals have become a reflex rather than a control.
3. Define exactly what the amount means
Is the threshold before or after VAT? Per invoice, per purchase order or over the life of the contract? In rupiah, or in the original currency converted at which rate? Every ambiguity is a loophole. Write the definition into the policy.
4. Close the splitting loophole
If Rp 50 million needs the CFO, someone will eventually raise two requests for Rp 49 million. Your rules should look at the total commitment to the same vendor for the same purpose, and someone should regularly review requests that land just below a threshold.
5. Enforce segregation of duties
No one should be the final approver of their own request. The person who creates or edits a vendor shouldn’t be the one who approves payments to it. The person who approves a payment run shouldn’t be able to change the bank details in it. These are the combinations behind most internal fraud, and they are easy to block if the matrix is designed with them in mind.
6. Plan for absence
Every approver needs a backup. Delegation during leave should be time-limited, recorded, and never handed to the person who raised the request. Without this, the matrix works perfectly until the first long weekend.
7. Give approvals a deadline
Set a target time for each level, for example two working days, with an automatic reminder and then escalation to the next level or a backup. An approval that takes longer than the purchase itself is a sign the matrix is failing, not that the control is working.
8. Allow for emergencies, on the record
Some things genuinely can’t wait. Rather than letting urgent requests bypass the system over WhatsApp, define a short emergency path with a mandatory justification, and review every use of it afterwards. If the same person uses it every month, that’s a conversation worth having.
A good approval matrix isn’t the one with the most signatures. It’s the one where every signature actually means someone made a decision.
A note for Indonesian companies
For a PT, management’s authority itself has limits. The articles of association (anggaran dasar) often require approval from the Board of Commissioners (Dewan Komisaris) or shareholders for certain transactions, such as taking on large loans or pledging company assets. Your approval matrix has to sit inside those limits, so check it against the articles and any standing board resolutions before you publish it.
If your group has several PTs, each entity needs its own matrix, because each has its own directors, budgets and authority limits. A shared template is fine, but an approval in one entity should never quietly cover spend in another.
Signs your approval matrix needs work
- Directors approve small, routine claims every day.
- Approvals happen in email and WhatsApp, and can’t be found a few months later.
- People regularly ask finance, “Who should approve this?”
- Requests cluster just below a threshold.
- Requests are stuck behind an approver who is on leave, or who left the company.
- Auditors find payments with no evidence of who approved them.
- The approval takes longer than the purchase.
How to build or fix yours in five steps
- List every transaction type that commits or moves company money, and decide which share a matrix.
- Analyse twelve months of data: the number and value of requests by type, department and amount.
- Draft tiers, roles and conditions, including backups, deadlines and an emergency path.
- Check it against your articles of association, board resolutions and segregation-of-duties rules, then have it approved by the directors.
- Publish it, put it into your systems and review it every year, or whenever the organisation changes.
Once the matrix is written down, it also becomes the rulebook for automation. When you let an AI agent clear low-value approvals, the matrix is what sets its limit.
How Procapy helps
ProcApprove, the approval engine behind every part of Procapy, runs your matrix exactly as written. Rules can use amount, cost centre, product, expense category, expense type, project, vendor or any other attribute your policy depends on, with as many levels as you need, conditional branches and different chains per legal entity. The same engine routes expense claims, purchase requests and payments, so you configure the matrix once.
Requests are checked for required fields, attachments, policy limits and budget before they enter the chain. Approvers act from their phone with policy and budget warnings on the same screen, and high-volume approvers can review a batch in one pass while anything flagged is held back for individual attention. Reminders, out-of-office delegation and escalation past the deadline run on their own. If a request is edited after submission, the chain re-evaluates itself, so an approval never silently covers a different amount.
Self-approval, circular chains and single-person payment paths are blocked when the matrix is configured, and an emergency path with a mandatory justification keeps urgent requests on the record. Every action is timestamped on the transaction, and auditors can have their own read-only access.
See how approvals work in Procapy, or book a 30-minute walkthrough. Bring your delegation-of-authority policy and we will configure the first chain live.