Approval Workflow

Approval Workflow is the automated routing of documents such as invoices, purchase orders, and expense reports through authorization chains based on configurable rules like amount thresholds, department, or vendor type. Approval design is a control question: who may approve what value, what happens when an approver is away, and whether the routing can be edited by the requester.

Category: Accounts Payable Automation SoftwareBest Accounts Payable Automation Software

A $47,000 vendor payment sat in an approval queue for 12 days. The approver was on vacation and no backup was configured. The vendor started sending late payment notices on day 8. This is the second time this quarter. The approval workflow exists; it just doesn't reflect who is actually available to approve. An approval workflow is the defined sequence of review and authorization steps that a document (an invoice, purchase order, expense report, or contract) must pass through before an action is taken. In AP and procurement, approval workflows determine who signs off on spend, in what order, and under what conditions before a payment is released or a commitment is made. The workflow is a control: it makes sure that spending above certain thresholds, in certain categories, or with certain vendors has been reviewed by the right authority before money leaves the organization. The design of an approval workflow reflects the organization's spend policy. Dollar thresholds, department routing, category-specific approvers, and multi-level requirements for large amounts are all policy decisions encoded in workflow configuration. When the workflow matches how the organization actually operates, it works as intended. When it ignores delegation, absence, org changes, or who is reachable when an approval is needed, it becomes a source of payment delays and vendor friction.

How approval workflows function

An approval workflow defines who must approve (the approver), when they must approve (the trigger condition), what they are approving (the document and its attributes), and what happens if they don't act (the escalation or timeout rule). At its simplest, a workflow might route any invoice above $10,000 to the department head before the AP team releases payment. At its most complex, it might route on vendor category, cost center, project code, and invoice amount, with different approvers at each level and mandatory two-person approval above $100,000. The failure modes are predictable. Approver absence: the designated approver is unavailable, no backup is configured, and the invoice sits. Stale routing rules: the workflow routes to a manager who left six months ago, so it now routes to no one, or to whoever inherited that org node. Approval as rubber stamp: approvers get high volumes of low-dollar invoices and approve them in batches without review, which turns the approval step into paperwork instead of a real control. Approval as bottleneck: a single approver (often a founder or CFO in smaller organizations) is required for a large category of spend, so the queue grows whenever they are busy. Each of these can be fixed in workflow design. Delegation and backup approvers remove absence failures, org-aware routing removes stale routing, and tiered thresholds cut rubber-stamp volume by limiting what reaches senior approvers.

Where it gets complicated

Delegation lets an approver temporarily assign their approval authority to someone else, usually when going on leave. Without delegation, absence freezes the queue. With it, the approver names a backup before they leave and the workflow routes to that person for the duration. Some platforms handle this automatically through org chart awareness: if the primary approver doesn't act, the workflow escalates to their manager after a set time. Conditional routing rules add logic beyond simple dollar thresholds. An invoice from a specific vendor might need legal review in addition to financial approval. An invoice coded to a capital expense account might need CFO approval regardless of amount. An invoice that fails PO matching might need procurement sign-off before AP can process it. These conditions have to be configured explicitly; a basic approval setup won't produce them. Org structure changes are an ongoing maintenance problem. When a manager leaves and their direct reports are reassigned, workflows that route to that manager by name or role must be updated. If they aren't, invoices either queue to a departed employee's account or route incorrectly. The audit trail must capture every step: who approved, when, and from which device or IP address. It is the evidence in an audit that controls were operating. A workflow that routes correctly but doesn't log approvals properly gives less audit protection than it appears to.

How platforms handle it

In spend management and AP automation platforms, approval workflows are configured through a rules engine: if invoice amount is greater than $X, route to approver Y. Most platforms demo this scenario cleanly. Configuration gaps show up in the edge cases. Test what happens when an approver hasn't responded after 48 hours. Does the system escalate automatically, or does the invoice sit indefinitely? Test an invoice coded to a cost center with no designated approver. Does the workflow fail open (proceed without approval) or fail closed (hold until an approver is assigned)? Test an invoice whose GL coding changes after approval. Does the re-coded invoice need re-approval, or does the original approval stand? Test a conflict of interest, for example an approver reviewing an invoice from a company they have a personal relationship with. Does the workflow have any way to route around that approver? Standard demos don't cover these scenarios, but they are where approval workflows fail in practice. The answers tell you how reliable the workflow system really is.

Questions to ask

Does every approver have a configured backup or delegation path, and has that backup been tested when the primary approver was actually absent, not only in a demo?
What is the escalation rule when an approver doesn't act within a defined time window, and is that rule configured and active?
How does the workflow handle org structure changes? Is there a process to update routing rules when managers change, or does it rely on someone remembering to report it?
Are approval thresholds set based on documented spend policy, and have they been reviewed in the past year to reflect current risk appetite and spend volumes?
Is re-approval required when an invoice is re-coded to a different GL account, cost center, or project after initial approval?
Does the audit log capture enough detail (approver identity, timestamp, and document version) to satisfy an external auditor's review?

Common mistakes

Configuring approval workflows without testing for approver absence is the most operationally damaging oversight. Teams configure the standard path, test it with available approvers, and deploy. The first time a key approver is out for a week, the failure is discovered in production instead of in testing. Routing everything above $1,000 to the CFO is a common pattern in growth-stage companies where founders or finance leaders want to see all significant spend. It creates a CFO approval queue that grows faster than the company, turns the CFO into an AP bottleneck, and eventually leads to batched approvals where the CFO rubber-stamps 40 invoices at once without reviewing any of them. The volume defeats the purpose of the control. Set thresholds on materiality (what amount warrants which level of scrutiny), not on who the founder trusts to see everything. As the company grows, delegate approval authority for routine amounts to department heads and managers, and reserve CFO or senior finance review for commitments that are actually significant.

Comparing AP automation

AP tools separate on what happens to the exceptions: the invoices that do not match a PO, arrive without one, or need a second approver. Once approval workflow is settled as a requirement, read the Accounts Payable Automation Software category guide for how the market splits, then weigh the Stampli profile against the Tipalti profile on that requirement rather than on the feature list. Our Tipalti pricing breakdown records what the vendor publishes and what is quote-based. The BILL against Stampli comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the AP automation savings calculator so the business case is written down before a vendor writes it for you.

Approval Workflow questions

How is an approval workflow different from a procurement policy?

A procurement policy is a document setting out the rules for how the organization commits to spend: what requires a PO, what requires competitive bids, who can approve which amounts, and which categories need specific oversight. An approval workflow is the operational implementation of that policy in a software system. The policy might say that any spend above $25,000 requires CFO approval. The approval workflow encodes that rule in the AP or spend management platform so invoices above $25,000 route automatically to the CFO's approval queue. When the policy and the workflow drift apart, because the policy was updated and the workflow wasn't, or because the workflow has exceptions the policy never anticipated, the control breaks.

Should approval workflows be configured in the AP system or in the ERP?

It depends on where spend decisions are made. If procurement and spend authorization happen before the invoice arrives, through POs and budget approvals, the AP approval is mainly a final payment authorization and an ERP-based workflow may be enough. If the invoice is the first point where spend is reviewed and approved, an AP-specific workflow with exception handling, delegation, and notifications usually works better. Many organizations run both: procurement approvals in the ERP for PO creation, and invoice approvals in the AP system as a final check before payment release. The risk of running both is that approvals become redundant and people stop treating them as real controls.

What happens to in-flight approvals when an approval workflow is reconfigured?

Most AP and spend management platforms handle this inconsistently. Some apply updated routing rules only to documents submitted after the change, leaving in-flight documents on their original path. Others re-route in-flight documents under the new rules. Others do neither and need manual intervention for documents stuck in changed workflows. Before reconfiguring an approval workflow, especially during an org restructure, find out how the platform treats documents already in the approval queue. Test with a real in-flight invoice in a staging environment if you can. Silent misrouting, where documents keep going to the old approver with no notification, is the most dangerous failure because no one knows the document is stuck.

ACH Payment, AP Aging Report, and Duplicate Invoice Detection come up in the same workflow as approval workflow, and the rest of the AP automation cluster is indexed in the finance operations glossary.