Ask a finance director how their AP approval workflow works and you'll usually get some version of the same answer: invoices route to the department head, who approves anything under a threshold, escalates to the VP for anything over it, and everything above a certain dollar amount goes to the CFO. The system has been in place for years. Everyone knows how it works.
The problem is what "department head" actually means in practice. Most org-chart-based approval workflows break down the moment any of the following happens: the department head is traveling, has left the company, or is on leave. A shared service provider invoices across multiple cost centers. A recurring vendor has a slightly different invoice description this month. A new employee in the purchasing role doesn't appear in the routing rules yet.
These aren't edge cases. In a mid-market company processing 3,000 invoices per month, they're daily events. And each one creates a delay, a manual workaround, or an invoice that sits in someone's email inbox for two weeks while the finance team chases approvals.
The Core Problem with Org-Chart Routing
Org-chart-based approval routing has a fundamental structural flaw: it conflates managerial authority with budget ownership. These overlap often enough that the system works some of the time — which is exactly why it persists.
But spend authority doesn't actually follow reporting lines. It follows budget allocations. The VP of Engineering is the approver for invoices charged to the Engineering department — but the specific GL accounts under that umbrella may be controlled by different people. Hardware purchases under account 1500 - Fixed Assets might require Capital Expenditure committee approval regardless of which department initiated the purchase. Cloud infrastructure under 6350 - Software & SaaS might route to the IT Director who controls that budget, not the VP of Engineering whose headcount uses the software.
When routing logic is built on org chart position rather than account code, these distinctions get lost. Invoices route to whoever sits at the right level of the hierarchy, not to whoever actually controls the budget line being charged. The result is approvers signing off on invoices they don't have full context on, or worse, escalating them back down the chain to find the right person — adding days to processing time for no reason other than the routing logic doesn't know about GL accounts.
How GL-Code Routing Works
The alternative is to invert the logic: route invoices based on the GL account code being charged, not the position of the approver in the org chart.
When an invoice arrives and is coded to 6200 - Maintenance & Repairs, the routing rule fires: invoices on that account route to the Facilities Manager for amounts under $5,000 and to the VP Operations for amounts over $5,000. If the same invoice were coded to 7100 - Professional Fees, it routes to General Counsel for legal services or to the CFO for accounting and advisory fees, depending on the vendor category.
GL-code routing rules are stable in a way that org charts are not. Account codes don't change when people are promoted, leave the company, or get a new title. The chart of accounts is defined annually and changes infrequently. Budget ownership maps cleanly to account code ranges because that's how the budget was built. The routing logic reflects actual financial authority rather than assumed managerial authority.
A Concrete Example
Consider a growing professional services firm with around 180 employees processing approximately 2,200 invoices per month. Their AP team has two people handling everything from invoice receipt through payment. Under their previous org-chart-based system, all invoices went first to department heads by cost center — a list of roughly 12 people who each had varying levels of attentiveness, availability, and understanding of what they were approving.
Their average invoice cycle time from receipt to approved was 9.3 days. Their exception rate — invoices that required more than one routing step or missed a payment terms window — was running around 28%.
After mapping their chart of accounts to GL-code routing rules, they reduced their active approver list to 7 people, each of whom owned specific account ranges with clear dollar thresholds. Invoices for facilities spend under 6100–6299 went directly to the Operations Manager. Marketing spend under 7200–7299 went to the VP Marketing. Any invoice over $15,000 added the CFO as a second-level approver regardless of account code.
Within 90 days, their average invoice cycle time dropped to 4.1 days. Their exception rate fell to 11%. The operations manager wasn't approving marketing software invoices anymore. The marketing VP wasn't rubber-stamping facilities maintenance they knew nothing about. Each approver was seeing invoices directly relevant to their budget responsibility.
Building GL-Code Routing Rules That Actually Hold
The practical challenge in implementing GL-code-based routing is the mapping work upfront. Most finance teams know their chart of accounts well, but formalizing the logic — "account code X routes to person Y for amounts under $Z, and to person W for amounts over $Z" — requires sitting down with every budget owner and documenting what they actually control versus what they just sign off on as a formality.
A few principles that make the rule-building phase cleaner:
Start with account ranges, not individual codes. Most charts of accounts are structured in ranges that reflect spending categories — 6000s for operating expenses, 7000s for G&A, 1000s for assets. Building routing rules at the range level (all accounts 6100–6299 route to Facilities) is more maintainable than building them code by code and having 200 individual rules that break every time the chart of accounts gets updated.
Separate approval authority from notification. Not every account code needs an approval — some just need the right person to be notified. Putting everyone who touches a budget line into the approval chain creates bottlenecks. Build rules that distinguish between approvers who must act before the invoice advances and stakeholders who receive a copy for awareness. The difference matters for cycle time.
Set dollar thresholds that reflect actual risk tolerance. A $250 invoice for office supplies doesn't need the same scrutiny as a $25,000 invoice for professional services. Calibrate your threshold levels to match where your finance policy actually draws the line, not where it was drawn five years ago when invoice volumes were lower.
The Problem with "We'll Handle Exceptions Manually"
We're not saying org-chart routing can't work — in very small finance teams or organizations with simple expense structures, the distinction between GL-code routing and org-chart routing is minimal. If you have three departments, a flat reporting structure, and 200 invoices per month, the overhead of formalizing GL-code routing rules may not be worth it relative to the gains.
But at mid-market scale — 1,500 to 10,000 invoices per month across 100-plus vendors — the "we'll handle exceptions manually" fallback becomes a primary workflow rather than an edge case. The exceptions pile up. The manual interventions eat the AP team's capacity. The cycle time stretches. And because the routing logic doesn't formally recognize the exceptions, they're invisible in reporting — finance leadership sees an average cycle time of 8 days but can't identify that 30% of their invoices are causing 70% of the delay because they're routing to the wrong approvers or routing into inboxes nobody actively monitors.
GL-code routing makes the exception rate visible because the routing logic is explicit and auditable. When an invoice misroutes or stalls, the system can identify where in the approval chain it happened and why. That diagnostic visibility is what enables continuous improvement — you can see which account codes generate the most exceptions, which approvers have the longest response times, and which dollar thresholds are creating unnecessary escalations.
The Month-End Close Connection
There's a direct line between GL-code routing quality and month-end close accuracy. When invoices route to approvers who don't own the relevant budget line, coding errors multiply. An approver who doesn't know whether an expense belongs in 6350 - Software & SaaS or 6400 - IT Infrastructure will code it to one or the other and move on. The GL balance ends up wrong. The controller finds the error during reconciliation, creates a journal entry correction, and loses 20 minutes chasing down the original invoice to understand what it was for.
When routing logic reflects actual budget ownership, approvers code to the right account because they know that account — it's the one they're responsible for. Coding accuracy improves. GL reconciliation is faster. The controller's month-end close work focuses on genuine variances rather than correcting routing-induced miscodes.
The approval workflow isn't just an operational process — it's a data quality process. The routing logic determines who touches the invoice and what decisions they make. Build the routing around who owns the financial accountability, and the data quality follows.
