Invoice approval workflow: thresholds, multi-approver routing and AP handoff
Learn how approval thresholds decides the depth of a chain, how multi-approver routing behaves when several people must sign off, what a clean handoff to accounts payable actually requires, and the exceptions that consume most of an AP team's time.
What an invoice approval workflow controls
An invoice approval workflow exists to answer one question before money leaves the business: is this invoice legitimate, correct, and authorised by someone whose remit covers the amount? Everything in the process serves that question. Extraction makes the invoice data usable. Matching establishes that the goods or services were ordered and received. Routing puts the decision in front of the right people. Handoff records the outcome where the ledger can see it.
Three mechanics carry most of the weight — thresholds, which decide how many approvals an invoice needs; routing, which decides who those approvers are and in what order; and the handoff to AP, which determines whether the approval is usable evidence or just a message someone sent.
The measure of an invoice approval process is not how fast it clears clean invoices. It is how it behaves on the ones that do not match.
The terms that matter
Invoice approval borrows vocabulary from both accounts payable and general approval workflow. These are the terms used on this page.
Approval threshold
An amount boundary that changes how many approvals an invoice requires, or who must give them.
Approval chain
The ordered set of stages a given invoice must clear, from submission to authorisation.
Glossary: approval chainApproval routing
The logic that decides which approver receives an invoice at each stage, and in what order.
Glossary: approval routingThree-way match
Reconciling the invoice against the purchase order and the goods receipt before approval is sought.
Coding
Assigning the general ledger account, cost centre and tax treatment an invoice will post against.
Exception
Any invoice that cannot proceed on the standard path — no PO, quantity mismatch, price variance, duplicate.
For the wider category — how approval processes work outside accounts payable — see approval workflow software and the approval workflow definition.
How approval thresholds set the depth of the chain
A threshold is an amount boundary that changes what an invoice has to clear. Below the first band an invoice may need one approval, or none if it matches a purchase order cleanly. Above the top band it may need two signatories acting together. Thresholds are the main reason invoice approval is conditional rather than fixed: the chain is selected from the invoice's own data at the moment it arrives.
| Amount band | Approvals required | Typical rationale |
|---|---|---|
| Under 1,000, PO matched | None — auto-approved | The purchase order already carried an approval. Re-approving the same commitment adds delay without adding control. |
| Under 1,000, no PO | Cost centre owner | No prior authorisation exists, so someone with budget responsibility confirms the spend was intended. |
| 1,000 – 10,000 | Cost centre owner | Single approval by the budget holder, who has the context to recognise whether the charge is correct. |
| 10,000 – 25,000 | Cost centre owner, then finance | Finance adds a second check on coding and cash timing at a level where an error is material. |
| Above 25,000 | Cost centre owner, finance, then any 2 of 3 signatories | Authority is held collectively at this level, and a quorum keeps the final stage from depending on one person's availability. |
Designing the bands
Two rules prevent most of the trouble. The bands must be contiguous and closed — an invoice for exactly 10,000 has to land in one row and only one row, and a gap between bands is an invoice with no chain. And the number of bands should stay small: each additional band multiplies the routing paths that need testing, and three or four covers most organisations.
Auto-approval is a threshold decision too
Approving low-value matched invoices automatically is usually the single largest efficiency gain available, because it removes the highest-volume, lowest-risk work from the queue entirely. It is also the decision most worth documenting. Record the rule, the ceiling, and the conditions the invoice had to satisfy, so an auditor can see why a payment carries no human approver.
Thresholds on the wrong basis
Amount is the obvious basis and rarely the only useful one. Supplier risk, whether a purchase order exists, spend category and whether the invoice is a first from a new supplier all change how much scrutiny is warranted. An invoice for 800 from an unknown supplier with no PO deserves more attention than one for 8,000 against an open, matched order.
Multi-approver routing for invoices
Once a threshold decides that more than one approval is needed, the next question is how those approvals relate to each other. The three patterns behave very differently on elapsed time and on what happens when someone is away. All three appear in invoice processes, often in the same chain.
One after another
Each approval gates the next. The cost centre owner confirms the spend was intended, and only then does finance review coding and cash timing — so finance is never asked about an invoice the budget holder would have rejected. Total time is the sum of every stage, which makes each added level a real cost.
Glossary: sequential approvalAll at once
Approvers are notified together and respond in any order, so elapsed time is set by the slowest rather than the sum. This suits genuinely independent checks — a departmental sign-off and a technical confirmation that the service was delivered. Decide the clearing rule first: all approvers, any one, or a quorum.
Glossary: parallel approvalDivided across cost centres
One invoice covering several cost centres routes each portion to its own owner, then reassembles for a single finance approval. This is specific to invoices and is where many implementations struggle, because the invoice is one document with several separately-owned parts.
Most real invoice chains combine these — sequential from cost centre to finance, with a parallel quorum at the top band. The routing mechanics are the same as any other approval process, so the depth on ordering, delegation and escalation lives on the multi-level approval workflow page, and the concept itself in the multi-level approval definition.
Handing the approved invoice to accounts payable
Approval is not the end of the process, it is the point at which the invoice becomes payable. A handoff that loses information here undoes much of the value of the approval itself, because the ledger ends up holding a payable with no visible authority behind it.
What the handoff has to carry
At minimum: the coding the invoice posts against, the identity of every approver and the time of each decision, a reference to the invoice document itself, and the match status that let it through. If the invoice was auto-approved, the rule that permitted it needs to travel too — otherwise the ledger shows a payable that nobody appears to have authorised.
Write to the ledger, don't re-key it
Manual re-entry after approval is where the process usually leaks. It introduces transcription errors at the last possible moment, duplicates the coding work already done during approval, and detaches the ledger entry from the approval record. A workflow that writes the bill directly into the accounting system keeps a single source of the coding and a single record of who approved it.
Duplicate prevention belongs at both ends
Duplicate invoices are the most common source of overpayment, and they arrive by ordinary means — the same invoice emailed twice, or sent by both the supplier and a chasing account manager. Check for duplicates at capture, on supplier and invoice number together, and again before posting, since an invoice can be entered through another route while the first copy is still in approval.
Payment timing is a separate decision
Approval authorises payment; it does not schedule it. Keeping the two separate lets AP manage cash and take early-settlement discounts without reopening approvals, and it keeps the approval record clean — the approver agreed to the amount, not to the payment date.
The exceptions that consume the AP queue
Clean, matched invoices are the easy majority. These are the cases that take the time, and the ones worth designing for explicitly rather than handling by email each month.
The invoice has no purchase order
Route on cost centre and category instead, and require an approver with budget authority rather than a matching check. Non-PO invoices are normal in most organisations — subscriptions, professional fees, utilities — so treating them as errors creates a permanent exception queue. What they lack is prior authorisation, which means the approval carries more weight and the routing should not be shorter than the PO-matched equivalent.
Quantity or price does not match the order
Set a tolerance, auto-clear variances inside it, and route anything outside it to the person who raised the order. A tolerance expressed both as a value and as a proportion handles small invoices and large ones sensibly. The important part is who receives the mismatch: the requester knows whether a partial delivery or a price change was expected, and finance does not.
The same invoice arrives twice
Check supplier and invoice number at capture, and check again immediately before posting. One check is not enough, because a second copy can enter through a different route while the first is still in approval. Flag rather than silently discard — a supplier occasionally reuses an invoice number legitimately, and a discarded genuine invoice becomes a payment chase weeks later.
The approver is on leave and the invoice ages
Configure a delegate, a timeout and an escalation target on every stage. Ageing invoices carry real cost — late fees, lost early-payment discounts, and suppliers who deprioritise you. Escalate to the approver's manager on timeout rather than auto-approving, since auto-approval on a high-value invoice removes exactly the control the stage was added to provide.
The invoice is coded to the wrong account
Let approvers correct coding within the workflow, and record that the change happened. Coding errors found during approval are cheap to fix and expensive to fix after posting. Allowing the correction in place avoids a rejection cycle for what is often a one-field change, but the audit trail needs to show the original coding, the correction and who made it.
The approver is also the requester
Detect the collision at routing time and substitute the next authority up. This happens routinely to cost centre owners who raise their own purchases. Removing the stage entirely is the wrong fix, because it silently reduces the number of approvals on exactly the invoices where separation of duties matters most. The same rule should catch delegation loops where an approver's delegate is the requester.
What to look for in invoice approval workflow software
The category spans dedicated AP automation platforms, general workflow tools, and approval features inside accounting systems. Rather than comparing feature lists, these are the questions that tend to separate tools once an implementation is underway.
Conditional routing depth
Can the chain be selected from amount, supplier, category and PO status together, or only from amount?
Run-time approver resolution
Are approvers resolved from your directory when the invoice arrives, or named in the rule?
Matching and tolerances
Does it support two- and three-way matching with tolerances set by value and by proportion?
Accounting write-back
Does it write the coded bill into your ledger, or export a file someone re-keys?
Pricing model
Is the cost per user, per invoice, or per workflow run? Volume-based pricing turns growth into a rising bill.
Audit trail completeness
Does it log actor, timestamp, decision, coding changes, overrides and auto-approval rules as events?
The pricing question deserves more attention than it usually gets. Per-invoice and per-run pricing is common in this category, and it means the cost of the process scales with the volume of invoices — which is the opposite of what automation is meant to achieve. Model the bill at two or three times your current volume before committing.
Where manual invoice approval comes apart
Invoice approval usually starts as a shared mailbox, a spreadsheet of what is outstanding, and a habit of forwarding PDFs to whoever owns the budget. It works at low volume and fails predictably as volume grows.
Teams graduating from brittle scripts and shared sheets recognise all three of these. None of them announce themselves — each surfaces as an invoice that aged past its terms.
Nobody knows where an invoice is
The status lives in a mailbox and a spreadsheet that disagree. Answering "has this been approved" means asking three people, and the supplier asks before anyone internally notices the delay.
Approval is a reply, not a record
The evidence that an invoice was authorised is an email saying "fine by me", detached from the invoice version and the coding it referred to. It proves someone agreed; it does not establish to what.
Ageing carries a real bill
Invoices that sit past terms attract late fees and forfeit early-settlement discounts. The cost is spread thinly enough across the month that it rarely gets attributed to the approval process that caused it.
Invoice approvals for teams already working in Google Workspace
The criteria above are the ones we would apply to any tool in this category, including our own. Where Zenphi differs is narrow and worth stating plainly rather than as a claim to be best at everything.
We build Zenphi natively for Google Workspace, so an invoice process runs where the team already works — invoices arriving in Gmail, approval requests answered in Gmail or Google Chat, threshold tables maintained in Google Sheets by the finance owners rather than by an administrator, and intake forms built in Google Forms. Approvers resolve from the Google Directory at run time, so the chain survives a reorganisation.
Native to the Google tools in use
Docs, Sheets, Forms, Gmail, Drive and Chat are first-class rather than reached through a generic connector. Finance owners can maintain the approval matrix in a Sheet the workflow reads directly.
No per-invoice or per-run pricing
Cost does not scale with invoice volume or with the number of times a workflow runs, so processing more invoices does not raise the bill for the process itself.
AI agents inside the platform
Zenphi lets teams choose AI agents across three providers — Gemini, OpenAI, and Claude — and use them within the workflow for invoice data extraction, summarising supporting documents, and classifying invoices for routing.
First-class accounting actions
QuickBooks, Xero and other accounting platforms are supported as first-class actions, so the approved and coded bill writes back without a custom integration project.
Related approval processes
Thresholds and routing work the same way across finance processes. What changes is the document, the match, and what the chain ends in.
Approval workflow software
The category overview: evaluation criteria, routing mechanics and how approval tools differ from one another.
Read more →Purchase order approval workflow
The approval that happens before the invoice arrives, and the reason a matched invoice can often clear without a second one.
Read more →Multi-level approval workflow
Sequential, parallel and conditional routing in depth, with delegation, escalation and the hard cases.
Read more →Expense approval workflow
Shallow chains at high volume, where policy checks and auto-approval rules matter more than approval depth.
Read more →Document approval workflow
Drive-native document routing with automatic locking during review and approval bound to a specific revision.
Read more →Google Forms approval workflow
Form submissions as the entry point to a chain — useful for non-PO invoice intake and coding requests.
Read more →Invoice approval workflows — common questions
Set your thresholds before you build the chain
Thresholds, matching tolerances and exception handling are the decisions worth settling first — they are much harder to retrofit than an extra approval stage. Our docs cover how each maps to a Zenphi flow, and the community is a good place to compare notes with finance teams running AP on Google Workspace.