Finance approvals

Expense, payment and capex approval workflows

An expense approval workflow is the process that checks a claim or a spend request against policy and routes it to whoever holds authority for the amount before money moves. Three related processes sit under that description and behave quite differently: expense claims, which are high-volume and reimburse money already spent; payment approvals, which authorise money leaving the business; and capital expenditure, which commits to an asset against a plan rather than a budget line.

The mechanics are shared — thresholds, routing, delegation, audit trail — but the risk profile is not, and a single workflow applied to all three usually ends up calibrated for none of them. Each is covered separately below, along with what changes between them.

Start with expense claims Compare the three

Covers policy checks and auto-approval, dual authorisation and payment security controls, and capex business cases and post-completion review.

Three processes, one toolkit

Overview

Same mechanics, different calibration

Expense claims

High volume, low value

Money already spent. The control that matters is policy compliance, applied consistently at scale.

Policy-led Shallow chain

Payment approvals

Money leaving the business

The only stage where funds actually move. Dual authorisation and change-detection controls dominate.

Fraud-sensitive Dual auth

Capital expenditure

Low volume, high value

Assessed against a plan and a business case rather than a budget line. Long chains are proportionate here.

Business case Board-level

Shared

Thresholds, delegation, audit trail

The same routing toolkit underlies all three. What differs is where the thresholds sit and how much scrutiny each stage adds.

Common layer

On this page

The distinction

Why these are three processes, not one

All three ask a version of the same question — is this spend legitimate and authorised? — but they ask it at different moments and about different amounts of money. An expense claim reimburses money an employee has already spent, so the decision is really about policy. A payment approval authorises funds to leave the business, which makes it the point where fraud is possible. Capital expenditure commits to an asset over years, so the decision is about the plan rather than the budget.

Those differences change the shape of the workflow. Expense claims need a shallow chain and aggressive automation because volume is the constraint. Payments need depth and verification because the risk is concentrated. Capex needs gates and documentation because the commitment outlives the people approving it.

A single approval chain applied to all three is usually calibrated for the middle case: too slow for expense claims, too shallow for payments, and too thin on documentation for capital expenditure.

Terminology

The terms used here

Finance vocabulary varies between organisations. These are the terms as used on this page.

Approval chain

The ordered set of stages a claim, payment or request must clear from submission to authorisation.

Glossary: approval chain

Approval routing

The logic deciding which approver receives a request at each stage, and in what order.

Glossary: approval routing

Dual authorisation

Requiring two independent approvers for a payment, so no single person can move funds alone.

Glossary: parallel approval

Auto-approval

Clearing a claim without human review when it satisfies stated conditions — used heavily in expense, rarely in payment.

Glossary: conditional approval

Capex gate

A decision point in a capital process where the request either proceeds to the next stage of work or stops.

Glossary: sequential approval

Separation of duties

The requester, approver and person executing payment must be different people.

Glossary: multi-level approval

For the wider category, see approval workflow software and the approval workflow definition.

Expense claims

Expense approval workflow — volume is the constraint

Expense claims are the highest-volume approval process most organisations run and the lowest-value per item. That combination makes them unusual: the cost of reviewing a claim can genuinely exceed the amount at risk in it. A well-designed expense workflow therefore spends its effort on consistency and throughput rather than on depth of scrutiny.

Policy checks do most of the work

The useful control in expense is the policy check, not the approver. Per-diem limits, receipt requirements above a value, categories that need a reason, mileage rates, alcohol rules, class of travel — these are rules a workflow can apply to every claim identically, which no human reviewer does at volume. Run them at submission, show the claimant which rule they have broken before they submit, and most non-compliant claims correct themselves without ever reaching an approver.

Auto-approval is the main lever

Auto-approving low-value claims that pass every policy check removes the bulk of the queue and loses very little control. Set a ceiling, require that all policy checks pass, exclude categories where judgement matters, and record the rule that permitted each auto-approval so an auditor can see why the claim carries no human approver. Sampling auto-approved claims periodically is a stronger control than reviewing all of them badly.

Receipts, and what to do about missing ones

Missing receipts are the most common exception. Decide the rule in advance rather than case by case: a value below which no receipt is required, a declaration process for genuinely lost receipts, and a cap on how often one person can use it before it becomes a conversation. Extracting the amount, date and merchant from a receipt image also catches the mismatches — a claim entered as 40 with a receipt showing 60 — that manual review reliably misses.

Keep the chain shallow

One approval is usually right for expense: the claimant's manager, who has the context to know whether the trip happened and the spend was reasonable. A second stage in finance adds delay without adding much, because finance is checking coding rather than legitimacy and can do that after the fact. Reserve deeper chains for claims that break policy or exceed a higher threshold.

What works

Automate the checks, not the judgement

Policy validation at submission, with the reason shown to the claimant.

Auto-approval below a ceiling when every check passes.

Receipt data extracted and compared to the claimed amount.

One approval stage for compliant claims, more for exceptions.

What fails at volume

Reviewing everything equally

Approvers batch-approve without reading, so the stage adds delay only.

Policy is enforced inconsistently between managers.

Claims bounce back weeks later for a missing receipt.

Reimbursement timing becomes an employee relations problem.

Payment approvals

Payment approval workflow — where the money actually moves

Payment approval is the last control before funds leave the business, which makes it structurally different from every other approval on this page. An expense claim approved in error costs the claim amount. A fraudulent payment approved in error can cost far more, and the mechanism is rarely a forged invoice — it is usually a change to where a legitimate payment is sent.

Dual authorisation above a threshold

Requiring two independent approvers above a threshold is the core control. Independence is what makes it work: two people in the same team approving each other's payments satisfies the letter of the rule and none of its purpose. Above a higher band, requiring a quorum from a named group of signatories keeps the control intact without depending on two specific calendars.

Bank detail changes deserve their own workflow

The most common payment fraud is a supplier bank detail change, requested by email from an address that looks right. Treat a change of payee details as a separate approval with its own verification — a call to a known number held on file, not the number in the request — and never process the change and the payment in the same run. A change followed immediately by a payment is the pattern worth alerting on.

Separation of duties, enforced not assumed

The person who raises a payment, the person who approves it and the person who releases it should be three different people. Detect the collision at routing time and substitute the next authority up, and make sure delegation cannot recreate it — an approver whose delegate is the requester defeats the control silently.

What the approver needs to see

An approver shown only a payee and an amount cannot meaningfully approve anything. The decision needs the supporting invoice, the purchase order if one exists, the match status, whether the payee details have changed recently, and whether this payee is new. Most weak payment approvals are weak because the approver had nothing to go on, not because they were careless.

Timing and release are separate decisions

Approval authorises a payment; it does not schedule it. Keeping them separate lets treasury manage cash and take early-settlement discounts without reopening approvals, and keeps the record clean — the approver agreed to the amount and payee, not to the date. Payment runs should also be re-verified at release, since an approval given three days ago predates any bank detail change made since.

Capital expenditure

Capex approval workflow — committing against a plan

Capital expenditure is the mirror image of expense claims: very low volume, very high value, and a commitment that outlasts the people approving it. Long chains and heavy documentation are proportionate here in a way they never are for a taxi receipt. The capex approval process is also the one most often run outside any system, on a spreadsheet and a slide deck, which is why the records are usually the weakest part.

The business case is the artefact

A capital expenditure request is assessed on its case, not just its amount: what the asset is, why now, the expected return and over what period, the alternatives considered including doing nothing, the whole-life cost rather than the purchase price, and who owns the outcome. Capturing these as structured fields rather than as an attachment is what later makes a portfolio of requests comparable.

Gates rather than a single approval

Large capital projects are better approved in stages than in one decision. An initial gate authorises the work of building a full case, a second approves the spend in principle against the plan, and a third releases funds once quotes and a supplier are in place. Each gate is a genuine stop-or-continue point, which stops the organisation spending months on a case for something that was never going to be funded.

Thresholds are set differently

Capex thresholds usually reflect governance rather than budget: a level at which the finance director signs, another at which the executive committee does, and one at which the board must. Because these are tied to delegated authority documents rather than to cost centres, they change rarely and should be maintained where the people who own that document can see them.

Phasing and the danger of approving a total

Capital spend arrives in phases across periods, and approving a headline total without the phasing leaves finance unable to plan cash or the depreciation profile. Capture the expected spend per period at approval, and treat a material change in phasing as a change requiring re-approval, not just a note.

Post-completion review closes the loop

The step almost always skipped: comparing what the asset cost and delivered against what the business case promised. Without it, the estimates in future business cases have nothing to calibrate against, and the same optimistic assumptions recur. Scheduling the review at approval — rather than intending to do it later — is what makes it happen.

Compared

What changes between the three

Read down the columns rather than across the rows: the pattern is that each process optimises for something different, and the design choices follow from that.

Dimension	Expense claims	Payment approvals	Capital expenditure
Volume	High	Medium	Low
Value per item	Low	Medium to high	High
Primary risk	Policy drift and inconsistency	Fraud and misdirected funds	Poor investment decisions
Main control	Automated policy checks	Dual authorisation and verification	Business case and staged gates
Chain depth	One stage, often none	Two or a quorum	Three or more gates
Auto-approval	Appropriate and valuable	Rarely appropriate	Never
Speed matters because	Employees are out of pocket	Supplier terms and discounts	Rarely urgent; quality of decision wins
Audit focus	Was policy applied consistently	Who authorised, and was payee verified	Was it approved at the right level, and did it deliver

The practical consequence is that these should be three configurations of the same platform rather than three separate systems. The routing, delegation and audit machinery is common; the thresholds, the checks and the depth are what get tuned per process.

Shared mechanics

The layer all three depend on

Four mechanics appear in every one of these processes. Their depth is covered on the multi-level approval workflow page; what follows is what changes in a finance context.

Thresholds

Bands that select the chain

Bands must be contiguous and closed so every request lands in exactly one, and small in number so the routing paths stay testable. In finance the common error is setting them once and never revisiting them — a band set five years ago now catches routine spend it was never meant to.

Delegation

Cover without losing control

A delegate holds standing authority during an absence, recorded as acting for the original approver. Cap delegated authority below the delegator's own ceiling, particularly for payments — otherwise a dual-authorisation requirement can be satisfied entirely by substitutes.

Separation of duties

Requester, approver, executor

Detect collisions at routing time and substitute the next authority up rather than dropping the stage. Delegation loops are the version that slips through: an approver whose delegate is the requester removes the control without anything looking wrong.

Audit trail

Actor, time, decision, basis

Log what each approver saw as well as what they decided. Auto-approvals need the rule recorded, delegated decisions need both parties, and timeouts and overrides need to appear as events — a trail with silent gaps is harder to defend than one showing an override.

Failure modes

Where finance approvals quietly degrade

Expense, payment and capex approvals usually start as a form, an email and a spreadsheet of what is outstanding. The failure is rarely dramatic — the process keeps running while the control inside it stops working.

Teams graduating from brittle scripts and shared sheets recognise all three of these.

Expense

Approval becomes a reflex

An approver receiving forty claims a week approves them in a batch without opening any. The stage still exists in the process diagram and no longer constitutes a review of anything.

Payment

Verification gets skipped under time pressure

A payee detail change arrives on payment-run day and the callback is skipped because the run is going out. The control was designed correctly and bypassed exactly when it mattered.

Capex

The case is never revisited

The approved business case sits in a folder and nobody compares it to what the asset actually cost or delivered. The next round of estimates has nothing to calibrate against.

Tooling

What to look for when these run on one platform

Because the three processes share machinery but differ in calibration, the useful question is whether one configuration can be tuned three ways without becoming three separate systems.

Independent configuration

Can expense, payment and capex each have their own thresholds, checks and chain depth without duplicating the whole workflow?

One platform, three tunings

Policy rules as data

Can finance edit limits and rules themselves, or does every policy change need a developer or a support ticket?

Editable by the owner

Dual authorisation and quorum

Can a stage require two independent approvers, or N of M, with independence actually enforced?

Not just two tasks

Delegation with caps

Can a delegate be set with dates and a lower authority ceiling, with both parties recorded on the decision?

Loop detection too

Accounting write-back

Does the approved item post to your ledger, or produce an export someone re-keys at the last moment?

No manual re-entry

Pricing unit

Is the charge per user, per claim, or per workflow run? Expense volume makes per-item pricing expensive fast.

Model at 3x volume

The pricing unit matters more here than on any other finance process, because expense claims are the highest-volume approval most organisations run. Per-claim or per-run pricing means the cost of the process scales with headcount and travel activity rather than with the value it protects. Solutions like Zenphi, for example, address this by charging neither per workflow run nor per item, so a busy expense month does not change what the process costs. Whichever direction you go, model the bill at two or three times current volume before committing.

Related approval processes

The same routing toolkit underlies each of these, calibrated for a different document and a different risk.

Overview

Approval workflow software

The category overview: evaluation criteria, routing mechanics and how approval tools differ from one another.

Routing

Multi-level approval workflow

Sequential, parallel and conditional routing in depth, with quorum rules, delegation and the hard cases.

Finance

Invoice approval workflow

Three-way matching, tolerances and the AP handoff — the process that usually sits before a payment approval.

Procurement

Purchase order approval workflow

Approval before the commitment, with threshold bands, delegation and budget commitment at PO issue.

Operations

Document approval workflow

Drive-native routing with automatic locking during review and approval bound to a specific revision — relevant to capex business cases.

Google Workspace

Google Forms approval workflow

Form submissions as the entry point to a chain — the usual intake route for a claim or a capital request.

FAQ

Expense, payment and capex approvals — common questions

The category splits three ways, and which fits depends on where your constraint sits. Dedicated expense platforms such as SAP Concur, Expensify, Ramp and Brex are built around the claim itself — receipt capture, card feeds, mileage, per-diem rules — and suit organisations where travel and card spend are the dominant problem. Accounting platforms including QuickBooks and Xero handle expense approval adequately at lower volume and keep everything in one ledger. General workflow platforms are the right answer when the constraint is the routing rather than the claim: bands that differ by entity, approval rules finance needs to change without raising a ticket, or expense sitting alongside payment and capex in one consistent process. Solutions like Zenphi, for example, fall in that third group, which is worth considering if the same platform also needs to carry your payment and capital approvals. The filter that narrows the list fastest is the pricing unit — expense is high volume, so per-claim charging scales badly.

Move the effort from reviewing claims to validating them. Run policy checks at submission and show the claimant which rule they have broken before the claim enters the queue, which resolves most non-compliant claims without an approver seeing them. Auto-approve low-value claims that pass every check, and record the rule that permitted it. Keep the compliant path to a single approval — usually the claimant's manager — and reserve deeper chains for exceptions. Then measure where claims actually wait, because the bottleneck is normally one approver rather than the process design. The common obstacle is that changing a policy limit requires a developer or a vendor ticket, so nothing gets tuned; solutions like Zenphi, for example, address that by keeping the limits in a spreadsheet the finance owner edits directly, with the workflow reading from it.

To varying degrees. Most dedicated expense platforms let you configure approval levels, amount thresholds and policy rules through an administration interface, and that covers the majority of requirements. Where teams tend to hit limits is with conditional logic on several attributes at once — routing differently by entity, project, funding source and category together — with chains that need to branch mid-flow, or with steps that have to call another system before deciding. Some platforms also gate deeper customisation behind higher tiers or professional services. The practical test before committing is to take your two most awkward real cases and try to configure them, rather than checking a feature list. Where the required logic exceeds what an expense tool exposes, workflow platforms are usually more flexible because routing is their primary job; solutions like Zenphi, for example, let the branching and the external lookups be built directly into the chain.

SAP Concur is a dedicated travel and expense platform, and its approval handling is built around the claim: expense reports are assembled from receipts, corporate card feeds and mileage entries, policy rules are applied as the report is built, audit rules flag items for review, and reports then route through configurable approval levels — typically the reporting manager, with additional approvers added by amount, cost object or exception. Approvers act from the web interface or the mobile app, and approved reports pass to reimbursement and to the ledger. It is a strong fit where travel and card spend are the main problem and the approval structure is close to the organisation's reporting lines. Two things commonly send teams looking further: routing that has to depend on several attributes at once or branch mid-chain, and expense being only one of several finance approvals that need to behave consistently. That is the gap workflow platforms address — solutions like Zenphi, for example, let the routing be built to whatever shape the process actually is, and carry no per-workflow-run or per-claim charge, so a heavy expense month does not change what the process costs.

Payment approval is usually served from one of three places. Accounts payable and payables automation platforms such as Bill, Tipalti and Stampli are built around the payment run and generally include dual authorisation and payee verification. Banking portals and treasury systems enforce authorisation at the point of release, which is the strongest control but the least connected to the approval that preceded it. Accounting platforms including QuickBooks, Xero and NetSuite cover it where volume is modest. The gap in most setups is between the approval and the release — an approval given three days ago predates any payee change made since, and few setups re-verify at release. Workflow platforms are often used to close that gap and to handle payee detail changes as a separate verified approval; solutions like Zenphi, for example, can sit across the accounting system and the approval chain so the two stay connected. Whatever you use, check that independence between the two authorisers is genuinely enforced rather than assumed.

Six steps are typical. The payment is raised, usually from an approved invoice, with payee, amount, date and coding. Supporting documents are attached — the invoice, the purchase order and the match status — because an approver shown only a payee and an amount cannot meaningfully assess anything. The payee is verified, particularly if the bank details are new or recently changed. The payment routes to one approver, or to two independent approvers above a threshold. It is then released into a payment run, which should be a separate action from approval and ideally re-verify the payee details at that moment. Finally the payment posts to the ledger with the approver record and document references attached, so the payable carries visible authority. The step most often missing in practice is the re-verification at release, because approval and release usually live in different systems; solutions like Zenphi, for example, are used to bridge that gap so the check happens without someone remembering to do it manually.

Five measures do most of the work. Dual authorisation above a threshold, with independence between the two approvers genuinely enforced rather than assumed. Separation of duties, so the person raising, approving and releasing a payment are three different people, including when a delegate is substituted in. Payee verification through a channel you control — a call to a number already held on file, never the number in the request. Treating a bank detail change as its own approval, never processed in the same run as a payment, with a change followed immediately by a payment flagged for review. And a complete audit trail recording what each approver saw, not only what they decided, with overrides and delegated decisions logged as events. Add multi-factor authentication on the accounts that can approve, and cap delegated authority so a dual-authorisation requirement cannot be satisfied entirely by substitutes. The recurring difficulty is that these controls are easiest to bypass under time pressure, on payment-run day; solutions like Zenphi, for example, help by making the verification and the separation checks part of the flow itself rather than steps a person can skip.

Next steps

Talk it through with an automation expert

If you are designing or reworking any of these three processes, a call with one of our automation experts is a practical way to pressure-test the decisions — where to set thresholds and auto-approval ceilings, how to handle dual authorisation and payee verification, or how to gate a capital request. We can also map an existing workflow with you during the call and point out where it will strain.

Book a call with an automation expert Learn about approval automation software

Expense approval best practices Payment approval controls Capex gates and business cases Map a workflow on the call