A practical reference for finance and operations teams rethinking how invoice processing, approvals, and vendor coordination should work at scale - independent of any single ERP.
Most accounts payable teams outgrow their tooling long before they outgrow their ERP. The problem isn't the ledger. It's everything that happens before a transaction hits the ledger - routing, approvals, exceptions, vendor follow-ups, budget checks, and the dozens of Slack messages and email threads that hold it all together.
This repo documents an emerging architectural pattern: separating workflow execution from accounting control. The ERP stays as the system of record. But the operational layer - the messy, human, coordination-heavy part - moves into a purpose-built workflow layer.
This isn't a product pitch. It's a reference for teams evaluating how to structure AP operations as invoice volume, vendor count, and approval complexity grow.
AP teams at growing companies (roughly 200-2,000 employees) hit a specific inflection point. The symptoms are predictable:
Volume pressure. Invoice count grows 3-5x, but headcount stays flat. Manual processing that worked at 200 invoices/month breaks at 800.
Coordination complexity. A single invoice may require input from procurement, the budget owner, operations, and finance - often across time zones. The "who needs to approve this and why is it stuck" problem becomes the team's largest time sink.
ERP operational overload. Teams try to solve workflow problems inside the ERP (custom approval chains, scripted routing rules, bolt-on modules). This works initially but creates brittle configurations, expensive license tiers, and vendor lock-in on operational logic that changes frequently.
Exception handling as the default. In most growing AP teams, "exceptions" aren't exceptional. 30-50% of invoices require some form of manual intervention - PO mismatches, missing receipts, partial shipments, duplicate submissions, rate discrepancies. The system is optimised for the happy path, but the team lives on the unhappy path.
In a conventional setup, the ERP handles everything end-to-end:
flowchart LR
A[Vendor submits invoice] --> B[Manual data entry into ERP]
B --> C[Approval chain inside ERP]
C --> D[Exception? Email/Slack loop]
D --> C
C --> E[Payment batch]
This model has three structural weaknesses:
-
Approval logic is trapped inside the ERP. Changing routing rules, adding conditional approvals, or handling delegation requires ERP configuration changes - often needing admin or consultant involvement.
-
Vendor communication is fully external. The vendor has no visibility. They email the AP team, who checks the ERP, then emails back. Every status inquiry creates a mini-project.
-
Exceptions create invisible queues. When an invoice gets stuck, it enters an informal queue - someone's inbox, a shared spreadsheet, a Slack thread. Finance leadership has no real-time view of how much is blocked or why.
The alternative separates concerns cleanly:
flowchart TD
subgraph Vendor Layer
V1[Invoice submission]
V2[Status visibility]
V3[Query resolution]
end
subgraph Workflow Execution Layer
W1[Intake and extraction]
W2[Validation and matching]
W3[Routing and approvals]
W4[Exception handling]
W5[Vendor communication]
end
subgraph Accounting Control Layer - ERP
E1[GL posting]
E2[Payment execution]
E3[Reconciliation]
E4[Audit trail]
end
V1 --> W1
W1 --> W2
W2 --> W3
W3 --> W4
W4 --> W3
W3 --> E1
E1 --> E2
W5 --> V2
W5 --> V3
Key principle: The ERP remains the system of record for accounting. But the coordination, routing, and exception resolution - the parts that consume 70-80% of the AP team's time - move into a workflow layer that's designed for operational speed and flexibility.
This is not a new idea in software architecture. It mirrors patterns from DevOps (CI/CD pipelines separated from production infrastructure) and customer support (ticketing systems separated from CRM). AP is simply catching up.
This section covers patterns that show up repeatedly in mid-market AP operations but are rarely discussed in vendor documentation or analyst reports.
A single vendor invoice frequently references multiple purchase orders - especially in manufacturing, construction, and logistics. Traditional matching logic assumes 1:1 invoice-to-PO relationships. In practice, a $50,000 invoice might map to three POs across two departments with different budget owners.
The workflow layer needs to support split matching: decompose the invoice into line-level allocations, route each allocation to the relevant approver, and reconcile the aggregate before ERP posting.
When a vendor ships 60% of an order and invoices for the delivered portion, the AP team needs to reconcile against the PO, confirm receipt with operations, and track the remaining 40% as an open commitment.
This requires a stateful view that most ERPs don't surface well - the invoice isn't "matched" or "unmatched," it's "partially matched with a forward obligation." The workflow layer needs to carry this state and surface it clearly to both the AP team and the budget owner.
Budget owners travel. Managers change roles. Org structures shift quarterly. Approval routing that's hard-coded to specific individuals breaks constantly.
Effective workflow architectures support delegation rules (time-bound, threshold-bound, category-bound), automatic escalation after N days, and fallback routing to a department rather than a person. The approval graph should be a living structure, not a static tree.
In many organisations, the person approving the invoice is not the person who coded the GL account. This creates a disconnect: the approver validates the business need, but the coding may be wrong, resulting in downstream reconciliation work.
A better pattern pushes budget coding into the approval step itself - the approver sees the suggested coding, confirms or corrects it, and the ERP receives a clean, validated entry. This eliminates a significant category of month-end journal adjustments.
Simple duplicate detection (same vendor, same amount, same date) catches the obvious cases. But real duplicates are subtler - same vendor, similar amount, different invoice numbers, 30 days apart. Or the same underlying service invoiced under two different vendor entities after a corporate restructure.
Effective detection needs fuzzy matching with configurable sensitivity, a review queue rather than auto-rejection, and historical pattern analysis across at least 12 months.
Not every team needs full automation on day one. A useful framework for phasing:
flowchart LR
S1["<b>Stage 1: Visibility</b><br/>Centralise intake<br/>Track status<br/>Eliminate inbox-based processing"]
S2["<b>Stage 2: Routing</b><br/>Rule-based approvals<br/>Delegation logic<br/>Exception flagging"]
S3["<b>Stage 3: Automation</b><br/>Auto-matching<br/>Extraction and validation<br/>Vendor self-service"]
S4["<b>Stage 4: Intelligence</b><br/>Predictive coding<br/>Anomaly detection<br/>Spend analytics"]
S1 --> S2 --> S3 --> S4
Most teams underestimate the value of Stage 1. Simply having a single, shared view of every invoice and its current status - instead of scattered inboxes and spreadsheets - reduces processing time by 20-30% before any automation is applied.
A few metrics that matter more than "invoices processed per month":
Exception rate. What percentage of invoices require manual intervention after initial intake? Healthy target: below 20%. Most teams operate at 35-50% without realising it.
Cycle time by exception type. Average days from invoice receipt to payment, segmented by whether the invoice was straight-through vs. exception. The gap between these two numbers reveals the true cost of your exception handling process.
Approval queue depth. How many invoices are sitting in someone's approval queue right now? If any single approver has more than 15 items pending, you have a structural bottleneck - not a discipline problem.
Vendor inquiry volume. How many "where's my payment?" messages does the AP team handle per week? This is a direct proxy for vendor-facing visibility gaps. Target: near zero.
Patterns that feel like progress but create long-term problems:
"Automate everything" before understanding exceptions. Teams that rush to auto-approve based on simple rules often create more cleanup work when the rules don't account for edge cases. Map your exceptions first, then automate the clear paths.
Building workflow logic inside the ERP. ERPs are designed for transaction integrity, not operational flexibility. Custom approval scripts inside NetSuite, SAP, or Dynamics become expensive to maintain and painful to change. If your workflow rules change more than twice a quarter, they belong outside the ERP.
Treating AP as a back-office cost center. AP teams generate significant operational intelligence - vendor reliability patterns, budget consumption velocity, payment timing optimization. This data has strategic value that's invisible when the function is viewed purely as a processing pipeline.
- Reducing ERP License Costs by Moving Approvals to a Workflow Layer - a detailed look at the cost and operational case for separating approval logic from ERP user licensing.
- The Reality of AP Automation and ERP Integration - what actually changes when you move workflow execution outside the ERP.
If you run AP operations and see patterns we haven't covered - or disagree with something here - open an issue. This is meant to be a living reference, not a static document.
Particularly interested in:
- Industry-specific workflow patterns (healthcare, construction, logistics)
- Multi-entity / multi-currency complications
- Compliance-driven approval requirements (SOX, GST input credit, VAT recovery)
This work is licensed under CC BY 4.0. You're free to share and adapt it with attribution.
Maintained by the team at Rhocash - workflow infrastructure for accounts payable.