How do I design an invoice approval workflow from scratch?

Fewer than most companies run. One approver is enough for low-dollar, low-risk invoices - a second level adds value only when it brings different knowledge (budget ownership vs. financial control) or when the amount exceeds the first approver's authority. A practical pattern: one approver below a materiality threshold, two for mid-range amounts, executive sign-off only for genuinely large or unusual spend. Every level beyond what the DOA requires adds cycle time without adding control.

Around roles, conditions, and rules - never named individuals. People-based workflows break every time someone leaves, changes jobs, or goes on vacation, and "stuck with a departed approver" is one of the most common AP failure modes. Rules keyed to invoice attributes (amount, department, entity, GL) with role-based assignment survive turnover; when a person changes, you update the role mapping once instead of rebuilding the workflow.

Route on data, not memory; align limits to a current DOA; keep levels minimal; build exception paths into the system; enforce authority automatically; review the rules after every reorg; and make sure every decision leaves system evidence.

Don't map the chart - map spend ownership. Identify who owns each budget (department, project, entity), assign approval responsibility there, and use the management chain only for amounts above the owner's authority.

Audit each level: what would each approver actually catch that no one else does? Collapse levels that exist for visibility (give those people reporting instead), raise low-dollar thresholds so small invoices stop touching executives, and keep dual review only where the DOA genuinely requires it. Most six-level chains compress to two or three with no control loss.

Yes - every workflow needs a defined fallback (typically AP manager or controller) so unmatched invoices surface immediately instead of stalling silently. Track fallback volume: it tells you which rules are missing.

AP needs a controlled correction path - misroutes and coding changes are real. The control is making the override visible: restrict it by permission, log every re-route with the reason, and review override frequency. An override nobody can see is a control gap; an override everyone can see is exception handling.

Approve the arrangement once (contract or recurring profile with expected amount and cadence), then auto-clear in-tolerance occurrences and route only variances - a new amount, an extra invoice in a period, or a change in terms - to a human.

Rules give consistency, speed, and auditability but require maintenance; manual assignment flexes to edge cases but depends on institutional knowledge, varies by person, and is hard to defend to auditors. Best practice: rules for the predictable majority, controlled manual handling for documented exceptions.

One page per flow: the routing attributes, the rule table (condition -> approver path), authority limits, exception procedures, and the system of record for evidence. Keep it versioned and dated so you can prove what the design was at any point in time.

Who owns each budget now? Which routing attributes changed (departments, entities, reporting lines)? Whose authority limits moved? Which in-flight invoices are routed to people who no longer hold the role? And who approves the new design itself?

Stampli evaluates each invoice at dispatch against configurable workflow rules built on ERP-aligned fields - vendor, GL account, subsidiary, amount, department, location - and assigns the matching approver path, including multi-stage chains. Fixed mode locks workflow-assigned approvers for high-governance environments; Flexible mode allows controlled runtime adjustment for exception-heavy ones. When no published workflow covers an invoice, Stampli AI can suggest approvers based on organizational structure and past behavior, with AP staying in control of dispatch.