Approval Matrix Template: Roles, Limits & Escalation Rules

An approval matrix gives a small business a clear way to define who can request, approve, execute, review, and escalate a decision. The accompanying approval matrix template is built around those roles, plus approval limits, documentation, workflow, and a segregation-of-duties check. I recommend using the template as the working model for this guide: complete one row for each decision or transaction that needs defined authority, then review how the roles overlap. 

The goal is to give employees clear boundaries without forcing a small team into an enterprise-style process. The examples cover purchases, expenses, payments, contracts, refunds or discounts, unbudgeted spending, and policy exceptions.

Use the free approval matrix template as your working model

Start with the approval matrix sheet and complete one row for each decision or transaction that needs defined authority. The template keeps the policy visible in one place: who starts the request, who can approve it, how far that authority goes, who carries out the decision, who reviews it, and what sends it upward.

The workbook also includes a separate Segregation of Duties Review, filled examples, and a Size & Staffing Guide. Those supporting sheets are most useful after the main matrix is drafted because they help you test whether the roles you assigned make sense for the way your team actually works.

The main template asks you to complete these fields:

• Decision / Transaction: Name the specific action that needs an approval rule, such as a purchase, reimbursement, vendor contract, refund, or policy exception. Keep this specific enough that employees know when the row applies.
• Category: Group similar decisions together, such as Purchase, Expense, Payment, Contract, Refund / Discount, Unbudgeted Spending, Policy Exception, or Other. This makes the matrix easier to scan and maintain.
• Requester Role: Identify the role that starts the request. This is the person who asks for the purchase, reimbursement, contract, payment, or other action to move forward.
• Approver Role: Identify the role that has authority to approve the request within the limits you set. In a small business, this could be a manager, finance lead, general manager, or owner.
• Approval Limit ($): Enter the highest amount that role can approve under the normal process. Amounts above this limit should move to the next approver instead of being handled informally.
• Payment / Execution Role: Identify who actually carries out the approved action. Depending on the transaction, this could mean making the payment, processing the refund, placing the order, or completing another approved step.
• Reviewer Role: Identify who performs an independent check after or around the transaction. This field is especially useful when the same employee handles several parts of the process.
• Escalates To: Name the role that receives the request when the normal approver cannot approve it. This gives employees a clear next step instead of leaving exceptions to judgment.
• Escalation Trigger: Define exactly what causes the request to move upward. Examples in the template include exceeding an approval limit, going outside budget, requesting a policy exception, or meeting another condition that needs higher review.
• Documentation Required: List what should support the decision, such as an invoice, receipt, contract, reimbursement documentation, or other records. This helps make the approval easier to review later.
• System / Workflow: Record where the transaction or approval process takes place. For bill payments, this could be QuickBooks Bill Pay; other rows may use email, a banking platform, or another internal workflow.
• SOD Check: Review whether the same role appears in multiple important steps. The segregation-of-duties check helps flag overlaps that may need a second review.
• Setup Status: Track whether the row is still being drafted, ready for review, approved, or needs revision. This prevents unfinished rules from being treated as active policy.

1. List the decisions and transactions that need approval

The first column asks a simple question: what action needs a defined approval path? I recommend starting with decisions that already cause someone on the team to stop and ask who can authorize them. The template gives you categories for purchases, expenses, payments, contracts, refunds or discounts, unbudgeted spending, policy exceptions, and other situations that matter to your business.

Do not turn the matrix into a list of every routine action employees take. Its value comes from defining the decisions where authority, money, documentation, or an exception needs to be clear. If employees already have permission to handle a routine task without approval, that can stay outside the matrix unless you need to document the boundary.

2. Assign who requests and approves each decision

Next, complete the Requester Role and Approver Role fields. Use roles rather than employee names where practical so the matrix describes responsibility, not a single person. The workbook includes role choices such as Employee / Individual Contributor, Department Manager, Operations Manager, Finance / Accounting Lead, General Manager, Owner / Founder, and Other.

The requester is the role that starts the transaction. The approver is the role that has authority to say yes within the rule you set. For a routine purchase, for example, the sample matrix has an employee request the purchase and an operations manager approve it. A different transaction can use a different chain if the responsibility sits elsewhere in the business.

3. Set the approval limit

The Approval Limit ($) field gives the approver a clear boundary. Enter a limit that fits your business and the responsibility of that role. A lower-level approval can cover routine decisions, while larger or unusual commitments can move to the role named in Escalates To.

The Examples sheet uses sample amounts to show how the model works: $1,000 for a routine purchase, $500 for an employee expense reimbursement, $5,000 for a vendor contract, and $250 for a customer discount or refund. It uses $0 for unbudgeted spending and policy exceptions, so those examples always move into a defined exception process. These are sample values, not universal recommendations, and the workbook specifically tells you to replace them with limits that fit your business.

For commitments that extend beyond one immediate payment, define the limit to match the commitment you want employees to evaluate. The vendor-contract example, for instance, uses the total commitment in its escalation trigger rather than treating the first payment as the whole decision.

4. Assign who executes, pays, and reviews the transaction

Approval is only one part of the row. The template separately asks for the Payment / Execution Role and the Reviewer Role. This distinction matters when one employee is allowed to approve something but another role actually carries out the payment, contract action, refund, or other approved step.

Use the Reviewer Role to name the person responsible for the independent check you want around that transaction. The workbook examples frequently place Finance / Accounting Lead in the execution role and Owner / Founder or General Manager in the review role. Your assignments can be different. What matters is that the row shows who owns each part of the process rather than leaving the handoff informal.

5. Check for segregation-of-duties conflicts

Segregation of duties is the workbook's check for situations where one role controls multiple parts of the same process. The main Approval Matrix compares the requester, approver, payment or execution role, and reviewer. The separate SOD Review adds the recorder role so you can look at the process in more detail.

When the workbook finds the same role in more than one checked step, it marks the row REVIEW OVERLAP. When the named roles are different, it shows NO OBVIOUS OVERLAP. The workbook is careful about what that second message means: it is only a structural check and does not prove that the workflow is fully controlled.

For a small team, overlap is not automatically wrong. If the same person has to perform more than one step, use the Planned Control / Second Review field on the SOD Review sheet to document the extra check you want. The sample scenarios show this approach repeatedly. When finance both pays and records a routine purchase, for example, the owner reviews payment activity. When finance handles vendor setup, payment, and recording, the owner reviews new-vendor details and first payments.

What if your team is too small to fully separate duties?

Use the template to identify the overlap first, then add an independent second review where practical. The Size & Staffing Guide assumes that very small teams may have heavy role overlap and keeps the focus on the highest-risk overlaps, clear documentation, and owner review rather than adding unnecessary layers.

6. Define escalation rules

Complete Escalates To and Escalation Trigger together. Escalates To tells employees who receives the decision next. Escalation Trigger tells them exactly what condition moves it upward. A dollar limit can be one trigger, but the template also uses outside-budget spending, policy exceptions, unusual terms, and other defined conditions.

The sample rows show the difference clearly. A routine purchase escalates to the owner above $1,000 or when it is outside budget. An employee reimbursement escalates above $500 or for a policy exception. A vendor contract escalates above a $5,000 total commitment, when it runs longer than 12 months, or when its terms are unusual. The customer discount or refund example escalates a refund above $250, a discount above 10%, or any request outside policy. Those thresholds are examples only, but the format is the model to copy: name the next role and write the trigger so an employee can tell when the normal limit no longer applies.

7. Record where the workflow happens

The System / Workflow field connects the approval policy to the way the work actually moves through the business. For bill-related rows, you can note QuickBooks Bill Pay when it is the system used to create, approve, or pay bills. Other transactions may use email, a banking platform, or another internal process.

Featured example: QuickBooks Bill Pay

If QuickBooks Bill Pay is part of your bill-payment workflow, note it in the System / Workflow field where applicable. The approval matrix remains the policy model for who requests, approves, pays, reviews, and escalates the transaction. QuickBooks Bill Pay Elite can add bill-specific roles and approval workflows, but keep the approval limit and escalation rule in the matrix so the business policy remains clear.

8. Adjust the matrix to your team size and responsibilities

The Size & Staffing Guide intentionally uses staffing patterns rather than fixed employee-count cutoffs. That keeps the model focused on how responsibilities are divided, which is especially useful when employees wear several hats.

• Very small team: The owner remains a key approver or reviewer, and roles may overlap heavily. Prioritize simple role assignments, documentation, and an independent second review where practical.
• Growing small team: Managers can receive defined authority for routine decisions while the owner keeps higher-level exceptions. Add manager limits, clearer escalation rules, and targeted separation of requesting, approval, payment or execution, and review.
• More structured team: Functional or department responsibilities can be divided more deliberately. Clarify ownership across request, approval, execution or payment, and review without adding unnecessary approval layers.

9. Use the completed examples as a model

The Examples sheet is useful because every sample uses the same columns as the blank Approval Matrix. Read each row from left to right and then replace the sample roles, limits, triggers, documentation, and workflow with your own.

In the routine-purchase example, an employee requests the purchase, an operations manager approves up to $1,000, finance handles execution, and the owner reviews. Anything above $1,000 or outside budget escalates to the owner, and the row requires an invoice or receipt. The workflow is recorded as an accounting or purchasing workflow.

The vendor-contract example uses a department manager as requester and a general manager as approver with a $5,000 sample limit. Finance handles execution, the owner reviews and receives escalations, and the trigger covers a higher total commitment, a term longer than 12 months, or unusual terms. The required documentation is the contract and supporting documents.

The customer discount or refund example assigns the employee as requester, the sales manager or lead as approver, finance as the execution role, and the general manager as reviewer. It escalates to the owner when the refund, discount, or policy condition falls outside the sample rule. These examples are most useful as patterns for structuring a row, not as preset policies to copy unchanged.

10. Put the approval matrix into practice

Once the rows are filled in, review them before treating the matrix as active policy. The Setup Status field gives you four stages: Draft, Ready to Review, Approved, and Needs Revision. That makes it easier to separate rows that are still being designed from rows the team can rely on.

A completed row should tell an employee what they can request, who can approve it, the applicable limit, who carries it out, who reviews it, what documentation is required, what system or workflow is used, and what condition sends it upward. If any of those answers are missing, keep the row in Draft or Needs Revision until the responsibility is clear.

After approval, share the relevant rules with the people who use them. The matrix works best when employees do not have to guess where their authority ends or who handles the next step.

11. Review and update the matrix as responsibilities change

Treat the matrix as a working policy rather than a one-time setup. Revisit a row when responsibilities move to a different role, approval limits no longer match the way the business operates, the workflow changes, or the same exceptions keep appearing.

Team growth does not automatically mean adding more approval layers. The staffing guide points in a more practical direction: as roles become more defined, separate responsibilities where staffing allows and delegate routine authority with clearer limits. Keep escalation paths focused on the decisions that genuinely need a higher level of review.

Common approval matrix mistakes to avoid

• Making the owner approve every routine decision instead of defining practical delegated authority.
• Setting an approval limit without naming the next approver and the trigger for escalation.
• Leaving the payment or execution role and reviewer role informal.
• Treating NO OBVIOUS OVERLAP as proof that the whole process is controlled.
• Using employee names where a role would make the policy easier to maintain.
• Copying the sample dollar limits as if they were universal recommendations.
• Leaving documentation or the System / Workflow field blank when employees need that information to finish the process.
• Failing to revise the matrix after responsibilities, limits, or workflows change.