The manager who receives a purchase request is not always the person allowed to approve it. When the amount is above their limit, the request can sit in their inbox for days before anyone notices. It then has to start again with someone more senior, while the supplier keeps asking about the order.
Often, nobody is at fault, because the rules about who approves what were never written down. New requests go to whoever approved the last one, and when that person is on leave, they all wait.
The same gap affects client files and contracts, where a wrong approval costs more. A high-risk client can be accepted by someone who should have sent the file to compliance. Later, nobody can show who was meant to sign off.
Most companies already have rules for their approval process, scattered across old emails, policies and people’s memories. An approval matrix puts them in one table. For each type of decision, it shows who approves, up to what limit, in what order and by when.
Some companies call it an authorization matrix, an authority matrix or a delegation of authority (DOA) matrix. Whatever the name, it does one job. It tells people who can approve each request, and what happens if that person does not answer in time.
The matrix also sets the approval chain, which is the order in which approvers see a request. That order matters, because a request that skips a level can be paid or signed without that level’s check.
Make every approval someone's responsibility.
Copy this sample approval matrix into a spreadsheet, then change each row to match your own policy.
|
Decision type |
Threshold or condition |
First approver |
Second approver or escalation |
Time limit |
|---|---|---|---|---|
|
Purchase or invoice |
Within the budget owner’s limit |
Budget owner |
Backup approver |
Before the payment run |
|
Purchase or invoice |
Above the budget owner’s limit |
Budget owner |
Finance director |
Before the payment run |
|
Supplier bank details |
New or changed account |
Accounts payable |
Second person in finance |
Before the next payment |
|
Client onboarding file |
Low or medium risk |
Onboarding analyst |
Compliance officer, if a check fails |
Before the start date |
|
Client onboarding file |
High risk or politically exposed person |
Compliance officer |
Senior management |
Before the relationship starts |
|
Contract |
Changed liability, payment or termination terms |
Legal team |
Manager with signing authority |
Before signature |
|
Job offer |
Outside the salary band |
Hiring manager |
HR director |
Before the offer goes out |
These three examples cover money going out, clients coming in and contracts or job offers being signed. Each one includes a row that teams often forget until something goes wrong.
In accounts payable, most rows depend on whether an invoice matches an approved purchase order. A matching invoice may need only an accounts payable check, while one with no order goes to the budget owner. Above the budget owner’s limit, the finance director approves too.
Each limit also needs a clear unit, such as per invoice, per order or per supplier each year. Without one, a large order can be split into several small invoices that each stay under the limit.
Supplier bank details need their own row, because a fake change request can send a payment to the wrong account. A good vendor onboarding process has a second person in finance check them before the first payment. The same check should follow every change.
A client file can pass every identity check and still need a more senior approver. In know your customer (KYC) work, an onboarding analyst usually approves low-risk files. High-risk files go to a compliance officer after enhanced due diligence.
Some rows are set by law, such as the one for people who hold or have held prominent public roles. In the EU, anti-money laundering rules require senior management approval to start or continue a business relationship with such a politically exposed person (Directive (EU) 2015/849, Article 20). Senior management means someone who knows the firm’s money laundering risk and can decide on it, not always a board member (Article 3(12)).
In the US, the customer due diligence rule has no extra steps for these clients. The federal banking agencies and the Financial Crimes Enforcement Network said so in 2020. Each bank therefore sets that row from its own risk rating.
Who should approve a contract that comes back from the client with edits? If the matrix looks only at value, the sales manager may sign it before legal sees a changed liability clause.
A better row looks at what changed as well as the amount. Standard terms can stay with the contract owner, while changed liability, payment or termination terms go to legal first. If a contract lets a supplier handle personal data, your data protection lead should see it too.
Job offers follow the same idea. An offer inside the salary band needs only the hiring manager, while one outside it also needs the HR director.
Build the matrix from real requests, not the org chart, and start with decisions that already cause delays. The first four steps fill in the template’s columns, and the fifth checks that the matrix works.
Look through recent approval emails, chat threads and policies to see which decisions keep coming back. Common rows include:
Leave out decisions one person can safely make alone, since people stop reading a matrix with too many rows.
A limit like “large purchases” means something different to every approver. Write an amount, a risk level or a named condition instead, such as spending outside the approved budget.
The template names each limit by role because every company sets its own amounts. In your copy, write the real figure with its currency, and say whether tax is included.
For client files, copy the risk levels from your customer risk assessment, so the matrix never contradicts it.
A matrix that names people stops working the day someone changes jobs. Name the role instead, such as finance director, and keep a separate list of who holds each role today.
Keep requesters and approvers apart, too. Nobody should approve their own purchase, and whoever sets up a new supplier should not approve its first payment. This is called segregation of duties, and it means one person’s mistake or fraud must get past a second person.
Together, these roles form your approval hierarchy, from team leads on routine requests to senior management on the riskiest ones.
Approvers go on leave, fall ill or miss a notification. Every row therefore needs a time limit and a named backup, so one absence does not hold up other requests.
Count each time limit back from the real deadline, such as the payment run or the client’s start date. That leaves time to escalate a late approval while it can still make a difference.
Escalate to the backup or the next level up, never to someone with less authority than the row requires.
Would the matrix have sent last month’s requests to the right people? Run a few recent purchases, client files and contracts through it, and rewrite any row that gives an unclear answer.
Once it works, have senior management approve the matrix and publish one version in the place where people raise requests. Review it whenever roles, limits or rules change, and keep a dated record of each version.
For the rows on client files, regulated firms may need this approval anyway. In the EU, firms under anti-money laundering rules need senior management approval for their policies, controls and procedures (Directive (EU) 2015/849, Article 8(5)).
A matrix in a spreadsheet still relies on people to read it, check each amount and chase late approvers.
In Clustdoc, the matrix runs inside the process instead. Our approval workflow applies its rules to client-facing work, such as a new client’s onboarding file or a supplier’s setup:
Approvals can also go to people outside your company, such as auditors or partners. Every update is logged in order, so your team can check each request’s history, status and assignee at any time.
Book a demo call and bring the approval chain that stalls most often in your team. We will look at where it waits today and show how its rows could run as rules in Clustdoc.
An approval matrix is a table showing who approves each type of decision, such as a purchase or a contract. Each row sets the limit or condition, the approvers in order and the time they have to decide.
An authorization matrix usually means the same as an approval matrix: who can authorize which transactions, up to what limit. For computer systems, the term can also mean a table showing which user roles can open which screens and functions.
The approval hierarchy is the order of roles that approve requests, from the least authority to the most. A team lead may approve routine spending, while larger amounts go up to a director and then senior management. The approval matrix applies this hierarchy to each type of decision.
List the decisions that need approval, and give each one a clear threshold, a first approver and a backup. Add a time limit and an escalation path, test the matrix on recent requests, then have senior management approve it. In Clustdoc, each row can run as a routing rule with its own due date.
Still stitching emails, files, and approvals together?
Clustdoc gives teams one place to run client-facing work, boost customer engagement and increase compliance.
Claire writes about customer onboarding, digital processes, and the day-to-day challenges faced by operations teams. At Clustdoc, she focuses on practical insights: how organizations collect information, guide customers through complex steps, and improve service delivery with automation.
