Free tool

Delegation of Authority Matrix Builder

A delegation of authority matrix turns approval policy into a table finance can test. Instead of “ask your manager, and for big things ask finance,” it states — in rows anyone can read — who can approve which expense, at which amount, for which entity or department, and who steps in when the named approver is away.

Most companies already have one; it just lives in the wrong places. Part of it is in an org chart from last year, part in a policy PDF, part in whoever remembers what happened the last time a large claim appeared. The result is approvals that depend on memory and messages, which is exactly the evidence an auditor cannot accept and a new joiner cannot follow.

The builder below assembles the table interactively and exports it as CSV. It runs entirely in your browser — nothing you type is sent anywhere or stored. The guide underneath covers what each dimension of the matrix means, how to set amount bands without copying someone else’s numbers, why the matrix and the approval workflow are different artifacts, and when to re-review the table you build.

Written by

Clara Global Editorial Team

Finance operations content

Updated August 13, 2026

10 min read

Summarize this article with:

Table of contents

Build your matrix

Add one row per amount band, category, and entity. Name roles, not people. Runs entirely in your browser — nothing you type is sent anywhere or stored.

Market

Sets the currency your amount bands are denominated in. The bands themselves stay yours — this tool suggests no thresholds. Currently USD, carried into the exported CSV header.

Row 1

Amount band (USD)

What a delegation of authority matrix defines

Each row of the matrix answers one complete question: for this kind of spend, in this part of the organization, up to this amount — who decides? The columns that make the answer usable:

Amount band. The range the row covers, in a stated currency. Bands must be contiguous and non-overlapping — a claim that fits two rows has two possible approvers, which in practice means whoever is asked first.
Spend category. Travel, meals, software, professional services. Category matters because risk does: a modest software subscription can commit the company for longer than an expensive flight.
Entity and department. Authority is granted within a legal entity, and often within a budget line. A matrix that ignores entity boundaries assigns approvals to people with no authority over the money being spent — the multi-entity version of this problem has its own dedicated treatment in the multi-entity guide.
Primary approver, by role. Name roles, not people. “Finance manager, entity X” survives a resignation; “María” does not.
Backup approver. Who decides when the primary is on leave or is the submitter. A matrix without backups routes exceptional claims to nobody, and urgent claims to whoever is willing.

Internal-control frameworks treat this as core design material rather than bureaucracy: COSO’s Internal Control — Integrated Framework organizes effective internal control into interdependent components and is explicit that internal control has value beyond compliance and external financial reporting, and the GAO’s Green Book — the U.S. federal internal-control standard, revised May 15, 2025, effective from fiscal year 2026, and harmonized with COSO — emphasizes prioritizing preventive control activities. An authority matrix is precisely that: a preventive control, deciding who may commit the company before the money moves.

Build the table

The builder collects rows with the six fields above and renders the matrix as a finance-readable table you can check by eye before exporting. Guidance per field:

Field-by-field guidance for building a delegation of authority matrix: what to enter and what to avoid.
Field	What to enter	What to avoid
Amount band	A contiguous range in one stated currency, e.g. 0–500, 500–5,000	Overlapping bands; bands in mixed currencies; an open top band with no escalation row
Category	The spend categories your policy already uses	Inventing categories for the matrix that the expense system does not have
Entity / department	The legal entity, and the department when authority is budget-line specific	“Group” as an entity — someone specific pays every claim
Primary approver	A role: manager, department head, finance manager, CFO	Named individuals; roles no one currently holds
Backup approver	The role that decides in the primary’s absence or conflict	Leaving it blank; naming the submitter’s peer
Notes	Escalation conditions, exception owners, effective date	Policy prose — the matrix is a table, not a document

Two properties make the output survive contact with reality. Completeness: every plausible claim should land in exactly one row — including the very large one, which needs an explicit top band routed to executive or board authority rather than an implicit “that never happens.” Readability: if a row needs explaining, it needs rewriting. A matrix that only its author can interpret will not survive an audit walkthrough or a new manager’s first week.

The matrix is authority; the workflow is execution

A delegation matrix and an approval workflow answer different questions, and conflating them breaks both. The matrix says who has the authority to commit the company — it is a policy artifact, owned by finance leadership, reviewed on a cadence, shown to auditors. The workflow says how a specific claim moves — who is notified, in what order, what evidence is collected, what happens on timeout — and it is a system configuration that should be derived from the matrix, never the other way around.

The distinction shows up in practice as layered review: the line manager approves the business purpose of a claim, while finance reviews the tax evidence or the currency conversion before reimbursement. One claim, two decisions, each by the person with authority over that dimension. When the two artifacts drift — the workflow routes to someone the matrix does not authorize, or the matrix names authority the workflow never enforces — the approvals still happen, but they stop meaning what the policy says they mean.

Clara Global sits on the execution side of this line: it routes each expense to the approver named by the approval rules your finance team defines, so the workflow can be set to mirror the matrix you build here. How that routing works — and where human judgment stays in the loop — is covered in automated expense approvals, and the wider control design around it in spend controls.

The rules are configured per company and evaluated on the expense itself, so the routing your matrix defines holds for an employee in any country submitting in any currency.

Set amount bands from your own data

There are no universal thresholds, and this page deliberately does not suggest any. A band that routes most claims to senior approvers in one company is a rounding error in another — copying a template’s numbers imports someone else’s spend distribution along with them.

Pull your last two quarters of claims
Look at the distribution by amount, per entity. The bands should follow the distribution’s natural breaks, not round numbers chosen in a meeting.
Put the routine bulk in the lowest band
If the majority of claims sit under some amount, that is your first boundary — those claims get the lightest authority that your risk tolerance allows, so attention concentrates where amounts are exceptional.
Size the top of each band by attention, not prestige
Each escalation adds a busier person to the chain. A band boundary that sends a third of claims to the CFO does not add control; it adds a queue that gets skimmed.
Denominate per entity
The same numeric threshold means different things in different markets. Set bands in each entity’s own currency, with a group floor if you need consistency — the reasoning is the same as for spend-control thresholds generally.
Record the effective date
Bands are calibrated to a spend distribution that will drift. A dated matrix tells the next reviewer what era its numbers belong to.

Backups, conflicts, and exceptions

The rows cover the normal case. Three abnormal cases decide whether the matrix works under pressure:

Absence. The backup column exists so that a claim never waits on one person’s vacation. The backup inherits the same band and category scope — a backup with wider authority than the primary is a quiet escalation nobody approved.
Conflict. When the approver is the submitter — or the cost benefits the approver’s own budget in a way that compromises review — the claim must route around them, upward or sideways to finance, never downward. The duty-splitting logic behind this is covered in segregation of duties in expenses.
Exception. Someone will eventually need to approve outside the matrix — a new category, an amount above every band, an entity with no local approver yet. The matrix should name who may grant exceptions and require that each one is recorded with its reason. An exception without a record is indistinguishable from a control failure.

Review the matrix when the company changes

A matrix is calibrated to an org structure and a spend distribution, and both drift. Review it quarterly, and immediately when any of these occur:

A new entity or market opens
New currency, new local roles, new rows.
Reporting lines change
Roles in the matrix may no longer exist or may have moved entities.
Budgets reset
Annual planning changes what a “large” claim is.
An audit finding names an approval gap
The matrix is the artifact the remediation lands in.
The exception log grows
Repeated exceptions in one row mean the row is mis-calibrated; the exception has become the real policy and should be promoted into the table or explicitly rejected.

The quarterly pass itself is short if the matrix is a table: check that every role still exists, every band still matches the distribution, every backup is still valid, and the exception log has nothing recurring. Date the review — an undated matrix is presumed stale by exactly the people it is meant to convince.

Methodology

The builder assembles rows from user input and renders them as a table; the CSV export contains exactly the rendered rows, in the same order, with no additions. No thresholds, roles, or bands are suggested by the tool — every number and name comes from the user, because approval thresholds are company-specific by nature and this page deliberately declines to present any default as universal.

The framework citations (COSO, GAO Green Book) describe those documents’ identity and stated emphases only, verified to resolve before citation; no matrix content is attributed to either. The builder runs entirely in the browser: no input is transmitted or stored.

Frequently asked questions

What is a delegation of authority matrix?

A delegation of authority matrix is a table that defines who can approve spend, by amount band, role, department, entity, and spend category. Each row answers one question completely: for this kind of expense, in this part of the organization, up to this amount, this role decides — and this backup role decides in their absence.

Its value is that it makes approval authority testable: a finance team can check any claim against the table and get one answer, an auditor can walk the table against actual approvals, and a new manager can learn their limits without asking around. It is a policy artifact, distinct from the approval workflow that executes it, and it is one of the clearest examples of a preventive control — it decides who may commit the company before money moves, rather than detecting problems afterwards.

Is a delegation matrix the same as an approval workflow?

No, and keeping them separate is the point. The matrix defines authority — who is entitled to approve what. The workflow executes routing — how a claim moves through notifications, evidence collection, escalation, and timeouts. The matrix is owned by finance leadership, reviewed on a cadence, and shown to auditors; the workflow is a system configuration that should be derived from the matrix.

The practical test of health is agreement between them: every route in the workflow should correspond to an authority the matrix grants, and every authority in the matrix should be enforced by some route. When they drift apart, approvals keep happening but stop meaning what the policy says — the workflow approves through people the matrix never authorized, or the matrix names authority nothing enforces.

What amount bands should we use?

Nobody else’s. Bands copied from a template import another company’s spend distribution, and they will either catch everything (creating queues that get skimmed) or nothing (making the matrix decorative). Build bands from your own data: pull two quarters of claims per entity, find the distribution’s natural breaks, put the routine bulk in the lowest band, and size each escalation by how much attention the added approver can genuinely give.

Denominate bands in each entity’s own currency, because one number means different things in different markets. And always include an explicit top band — very large claims need a named authority (executive or board level), not an implicit assumption that they never happen. Date the result: bands are calibrated to a distribution that drifts, and the date tells the next reviewer what era the numbers belong to.

Who should own the delegation of authority matrix?

One named owner in finance leadership — typically the controller or CFO, depending on company size — with the authority to change it and the obligation to review it. Ownership matters more than placement: a matrix without an owner cannot be changed safely, so people route around it, and every workaround erodes the authority of every remaining row.

The owner runs the review cadence, keeps the exception log, and signs the changes; entity-level finance proposes the local calibrations, because they know what a reasonable threshold is in their market. Auditors will ask two questions of whoever owns it: when was this last reviewed, and does the system actually enforce it. A dated table and a workflow derived from it answer both.

How often should the matrix be reviewed?

Quarterly as a baseline, and immediately on structural change: a new entity or market, changed reporting lines, a budget reset, an audit finding that names an approval gap, or a growing exception log. The quarterly pass is short if the matrix is a genuine table — confirm every role still exists, every band still matches the current spend distribution, every backup remains valid, and no exception repeats.

Repeated exceptions are the most informative signal in the whole system: they mean a row is mis-calibrated and the exception has quietly become the real policy, at which point the honest options are to promote it into the table or explicitly reject it. Date every review; an undated matrix reads as stale to auditors and new joiners alike.

Sources

Internal Control — Integrated Framework guidance — COSO. Retrieved 2026-08-13. Cited for the framework’s organization of effective internal control into interdependent components and its stated position that internal control has value beyond compliance and external financial reporting. No matrix or threshold content is attributed to it.
Standards for Internal Control in the Federal Government (Green Book), GAO-25-107721 — U.S. Government Accountability Office. Retrieved 2026-08-13. Cited for the document’s identity and currency — published May 15, 2025, effective from fiscal year 2026 with early implementation permitted, harmonized with COSO — and its stated emphasis on prioritizing preventive control activities.

About this guide

The builder renders exactly what you enter and suggests no thresholds — approval authorities are company-specific by nature. Framework citations are limited to what the cited COSO and GAO pages verifiably state, each URL verified to resolve before citation.

Operational tool and guidance for finance teams. Not legal, audit, or accounting advice. Appropriate approval authorities, thresholds, and review cadences depend on company size, sector, regulatory regime, and auditor expectations.

Continue reading

Build the matrix, then make the workflow obey it

Design your authority table here, export it, and configure Clara’s approval rules to mirror it — so each claim routes to the approver your matrix names and every decision lands inside the authority you defined.

Get started Talk to sales