ERP Approval Workflow: Delegation Matrix Guide

An ERP approval workflow is usually configured during the project, based on the org chart of the moment. Six months later, a director goes on leave, a department is reorganized, and an urgent order has to go out before noon. The workflow jams, and the company invents its own rules: shared passwords, approvals by email, orders placed outside the system. Internal control didn’t disappear through bad faith. It was bypassed out of necessity.

This guide is for CFOs, CIOs and heads of procurement or finance. It offers a method for designing approval flows that survive real life (absences, reorganizations, emergencies) while remaining defensible in front of an auditor.

Why Approval Workflows Generate More Workarounds Than Control

An approval flow pursues two objectives that seem to pull in opposite directions: making sure no sensitive spend or journal entry goes through without legitimate sign-off, and not slowing the business down. When the second objective is sacrificed, users restore speed by other means.

The 5 Classic Design Mistakes (and Their Countermeasures)

The most common workarounds are always the same. Each has a design cause and a specific answer.

1. Credential sharing

The trap: a director’s colleague logs in with the director’s account to “unblock” approvals during an absence.
The consequence: the audit trail becomes false, which is worse than having no trail, and the auditor can no longer attribute a decision.
The countermeasure: a named, dated delegate that users can set up in self-service, plus a permanent backup approver for each role.

2. Order splitting

The trap: three orders of €4,000 instead of one of €12,000 to stay under the approval threshold.
The consequence: the real commitment escapes the intended approval level, and signing authority is bypassed.
The countermeasure: a cumulative check by supplier and by period, with an alert to the workflow owner.

3. Uncontrolled retroactive approval

The trap: the goods are ordered or the service is delivered, then the request is entered after the fact with no mention of the exception.
The consequence: the budget was not checked before the commitment, and the exception becomes the norm.
The countermeasure: an official emergency path, with a mandatory reason and a later review (see below).

4. Approval outside the ERP

The trap: an email or chat message stands in for approval, and the ERP only receives the final order.
The consequence: the evidence of approval is scattered, unverifiable and unusable in an audit.
The countermeasure: approval from email or mobile, but recorded in the ERP, and a measured bypass rate.

5. The over-approver

The trap: a single executive receives every request “just in case.”
The consequence: a bottleneck, approvals that are never read, and a total stall every time that person is away.
The countermeasure: tiered thresholds, intermediate roles and capped delegations.

These behaviors have design causes, not disciplinary ones. A flow that makes no provision for absence, urgency or reorganization mechanically pushes people toward convenience fraud. The right answer is not to tighten the flow but to design it with its exceptions.

Start From the Delegation of Authority, Not the Org Chart

The org chart describes who reports to whom. The delegation of authority describes who can commit the company, for what amount, on what type of spend and in which entity. These are two different documents, and only the second should drive ERP configuration.

The Threshold x Category x Entity Matrix

The delegation matrix is a three-dimensional table:

Dimension	Examples
Threshold	Commitment amount, often in bands (below X, between X and Y, above Y)
Category	Goods purchases, professional services, capital expenditure, travel expenses, bank payments
Entity	Company, site, cost center, country

Each cell of the matrix names a role (not a person): cost center manager, site director, CFO, CEO. The role is then linked to named people, along with their delegates.

Design Principles

Think in roles. A flow that names “Jane Smith” breaks at the first departure. A flow that names “budget owner of the cost center” survives the arrival of a successor.
Align the matrix with legal documents. The amounts in the matrix must match formally documented delegations of authority (articles of association, board or executive decisions, internal procedures). The ERP doesn’t create authority, it reflects the authority that exists.
Limit the number of levels. Beyond three approval levels, lead times grow and the quality of approvals drops. Better a few well-configured levels than five ritual ones.
Name a business owner for each flow. IT configures, but the flow owner (the head of procurement for procure-to-pay, the CFO for journal entries and payments) decides the rules and approves changes.
Version the matrix. Every change (threshold, role, entity) is dated, justified and approved. An auditor must be able to reconstruct the rule in force on the date of a transaction.

Versioning is often neglected, yet all it takes is a document under document management, with a version number, an effective date and an approver. The ERP applies the current version, and the file keeps the previous ones.

The 5 Families of Approval Flows

Not all flows are designed the same way. Here are the five families to cover, with the usual approvers and the controls to build in for each. Thresholds are deliberately left as variables: they depend on company size and risk appetite, and must come from your own matrix.

Family	Typical approvers	Threshold logic	Associated controls
Purchase requisition	Cost center manager, then head of procurement or site director depending on amount	Estimated amount, type of spend	Available budget, cost allocation, existing catalog or framework contract
Purchase order	Buyer, then head of procurement, CFO or CEO depending on amount	Total order amount, approved or unapproved supplier	Validated supplier, negotiated terms, no order splitting
Supplier invoice	Goods receiver (service confirmed), then budget approver, then accounting	Variance against order, amount, no-PO invoices	Three-way match (order, receipt, invoice), variance tolerances
Expense report	Direct manager, then accounting; executive team for executives’ expenses	Amount, category, supporting documents	Compliance with expense policy, receipts, duplicates
Journal entries and payments	Accountant (entry), financial controller or CFO (approval), two signatories for payments	Type of entry (manual, reversal, closing), payment amount	Separation of entry and approval, dual approval of transfers, changes to supplier bank details

A few design remarks:

A requisition and a purchase order don’t play the same role. The requisition validates the need and the budget, the order validates the commitment to the supplier. Merging them into a single approval weakens both.
The supplier invoice is the noisiest flow. It helps to separate confirmation of the service received (by the business user who received it) from accounting approval. The first attests, the second controls.
Changes to supplier master data (bank account, legal name) deserve their own flow. This is a classic vector for bank-detail change fraud, and it is handled through independent dual approval, not an editable field.
Manual journal entries must be approved by someone other than the person who entered them, with stricter requirements during period close.

For details on the purchasing cycle itself, see our guide to ERP procurement and procure-to-pay.

Absences, Delegates and Automatic Escalation

This is where most flows fail. Treat it as a design rule, not a special case.

Rules for Temporary Delegation

A named, dated delegate. The delegator designates a delegate for a defined period, from within the ERP. Never share an account.
A delegate of equal or higher level. An approver doesn’t delegate to someone whose own limit is lower than theirs, unless the delegation is explicitly capped.
A delegation cap. A delegation can be limited by amount: the delegate approves up to a threshold, above which the request moves up.
A default backup. Every approver role has a permanent backup designated in advance, who is activated if no delegation has been entered. You don’t depend on the foresight of the person who is away.
No self-approval through delegation. If a user becomes the delegate of the person who approves their own requests, the system must block approval of their own documents.

Deadlines and Reminders

A flow without deadlines is a flow that stalls. For each step, provide for:

An automatic reminder after a short delay, sent to the approver.
An escalation after a longer delay, to the delegate and then to the next management level.
A blockage alert to the flow owner, to deal with requests stuck for a long time.

Exact delays depend on your business: an industrial replenishment flow doesn’t run at the same pace as a capital investment flow. What matters is that they are explicit, configured and monitored. An escalation must be recorded as such: it is not a silent approval. Automatically approving a request after a period without response is a bad idea in most contexts, because it turns inaction into approval.

Handling Exceptions: Emergencies, Retroactive Approval, Documented Waivers

Even a well-designed flow will meet out-of-the-ordinary cases: a production breakdown on a Saturday, a critical supplier to pay before a deadline, an executive who can’t be reached. If the ERP doesn’t provide an exception path, users will create one.

Three mechanisms to put in place:

The emergency procedure. An “urgent” status is open to designated roles, with a mandatory reason. The order can go out, but it is flagged and subject to review.
Retroactive approval. For certain strictly listed categories of spend (emergency repairs, safety of people), approval may come after the commitment, within a short, defined window. After that window, a reminder goes to the flow owner.
The documented waiver. When a rule has to be lifted (unapproved supplier, threshold overrun), the waiver is requested, justified, approved by a higher level and stored with the transaction.

The shared principle: the exception is allowed, but never invisible. Every exception generates a trace that can be consulted, and periodic reporting gives the flow owner the volume. An exception that becomes frequent is a signal: either the standard flow is badly calibrated, or a workaround practice is taking hold.

Linking Delegation to Segregation of Duties

The delegation matrix and segregation of duties (SoD) are two sides of the same control. The first says who can approve what, the second prohibits dangerous combinations.

The basic rule: the same user must not create and approve the same document, whether it is a requisition, an order, an invoice or a payment. This principle must hold under every configuration:

At delegation, as noted above: the delegate does not approve their own entries.
At role changes, when an employee temporarily holds two functions after a reorganization.
For high-privilege profiles, such as administrators, who should not be able to approve in the business flows they configure.

A point often forgotten: whoever can modify an approval flow can potentially grant themselves the approval. Access to workflow configuration must be restricted, logged and kept separate from approval rights.

These topics are covered in more detail in our articles on 12 SoD controls to implement before the annual audit and on ERP access governance.

Measuring: Average Approval Time, Escalation Rate, Bypass Rate

An unmeasured flow degrades without anyone noticing. Three indicators are enough to start:

Indicator	What it reveals	How to read it
Average approval time (by family and by step)	Bottlenecks	A time that lengthens on one step points to an overloaded approver or a rule that is too broad
Escalation rate	The reliability of approvers and delegations	A high rate on a role suggests a missing delegate or a badly placed threshold
Bypass rate	The share of transactions processed outside the standard flow	Counts: orders without a requisition, invoices without an order, waivers, retroactive approvals

The bypass rate is the most revealing, and the hardest to produce. It is built by cross-referencing ERP data: orders created without a prior requisition, invoices without a purchase order, gaps between the commitment date and the approval date. No universal threshold exists; what matters is the trend and the comparison between entities or departments.

These indicators should be presented to the flow owner at regular intervals. Without this feedback loop, the configuration stays frozen while the organization evolves.

Configuration Examples in SAP, Dynamics 365 / Business Central and Odoo

The principles below are deliberately generic: screens and options vary by version and edition, and must be checked against the official documentation for your version before any configuration.

SAP.

Strengths: purchasing release strategies determine, based on criteria such as amount or purchasing group, which release codes are required on a purchase requisition or purchase order. This maps naturally onto a threshold x category x entity matrix. Workflow and substitution mechanisms also let you reroute tasks to a replacement, and document traceability is strong.
Limits: configuration is technical and relies on criteria (classes, characteristics) that must be maintained. A matrix poorly prepared upstream results in numerous release strategies that are hard to review. Every organizational change calls for specialist intervention.
Target fit: groups and mid-market companies with many entities and a need for fine-grained control, with teams or partners able to maintain the strategies. Less suited to an SME without dedicated in-house skills.
Watch-out: prepare the delegation matrix before opening the configuration, and limit the number of release strategies to what the flow owner can review. Test absence and substitution cases with real users, check that substitution doesn’t allow people to approve their own documents, and make sure approval logs can be extracted for audit.

Microsoft Dynamics 365 and Business Central.

Strengths: ready-made approval workflow templates, with approvers, per-user approval limits and the ability to designate substitutes. In Business Central, the approval user setup (direct approver, amount limit, substitute) structures the approval chain in a way a finance manager can easily read.
Limits: per-person limits are easy to create but hard to maintain if you don’t think in roles: every departure or promotion means revisiting the user records. Complex cases (multiple entities, varied spend categories) call for custom workflows.
Target fit: SMEs and mid-market companies already in the Microsoft ecosystem, who want flows the business can understand and little custom development.
Watch-out: before go-live, test how the system behaves with an absent approver and no substitute, a requester who is also an approver, and an amount sitting exactly on a threshold. Also check who can change the approval limits: that configuration right must be separated from approval rights, and its changes logged so they can be shown to the auditor. This point is too often handled late, yet it determines the credibility of the whole flow.

Odoo.

Strengths: purchase order approval triggered above a minimum amount, simple to enable, and an ecosystem of modules and customization tools that let you add multi-level flows depending on the edition used.
Limits: coverage depends heavily on the installed modules and the edition. You need to verify that the approval feature covers each flow family (requisition, order, invoice, expense report, payment) and that its audit trail is enough for an auditor. Substitutions and escalations may require additional development.
Target fit: SMEs and growing companies that accept scoping their functional perimeter precisely and documenting their configuration, with an integrator who masters the chosen modules.
Watch-out: document, for each flow family, which module carries the approval, who the business owner is and how access rights are granted. On a modular ERP, adding a module or upgrading a version can change how a flow behaves: rerun your absence and threshold tests after every significant change, and keep a record of the matrix versions applied. This discipline prevents a flow validated at launch from silently drifting through updates.

In all three cases, three checks are required before go-live:

The absence test: simulate an approver leaving, a delegate without sufficient rights, and an approver who is also the requester.
The threshold test: check behavior just below and just above each band.
Logging: make sure every approval, delegation, escalation and waiver is recorded with the user, date and document, and that the auditor can extract it.

Annual Review Checklist

An annual review of the matrix and the flows is generally enough; it should also be triggered after every significant reorganization.

Going Further

An approval workflow is only as solid as the access governance behind it. Start with our ERP access governance guide, then apply the SoD controls before audit. To frame your delegation matrix or audit your current flows, get in touch.

ERP Approval Workflows: Designing a Delegation Matrix That Doesn't Stall the Business

Why Approval Workflows Generate More Workarounds Than Control

The 5 Classic Design Mistakes (and Their Countermeasures)