How do I route invoices for approval by department, GL account, location, or project?

Two workable models: route the whole invoice to each affected department owner (most defensible - every owner sees their share), or route to the primary owner with the split visible. What doesn't work is routing by whoever appears first on the coding and hoping. Decide the model once, encode it, and make sure each approver can see the full allocation, not just their lines - context drives review quality.

Orphans need a defined home, not improvisation: a fallback queue owned by AP or the controller, where someone identifies the owner, fixes the routing data, and ideally fixes the upstream cause (vendor not linked to a department, missing coding default, spend that should have had a purchase request). Track orphan volume monthly - it's a direct measure of routing rule coverage, and rising counts predict approval delays before they show up in aging.

Make GL account (or account range) a routing condition: invoices coded to marketing accounts route to the marketing budget owner's approval path. It works when coding happens before routing - which is the right order anyway - and it keeps approval aligned with the P&L line the spend actually hits.

Entity or location becomes the first routing dimension: each site's invoices route to local owners, with amount-based escalation to regional or corporate roles. The design question is where local authority ends - typically locals approve operational spend within band, and corporate approves above it or for sensitive categories.

Use the project/job code as the routing condition so the project manager - the person who knows whether the work happened - approves first, with the financial gate (controller, amount thresholds) layered after. Construction, professional services, and media companies live on this pattern.

Budget owner for authority, requester for knowledge - and when they differ, the requester verifies receipt while the budget owner approves the spend. Routing only to the requester invites self-approval of their own purchases; routing only to a distant budget owner invites rubber stamps.

Route to an owner in the entity bearing the cost (they're accepting the charge), with the originating entity's context attached. Keep intercompany on a distinct path with its own coding checks - it's a chronic source of close-time reconciliation pain when it free-rides on the standard workflow.

Centralize processing, decentralize judgment: shared services owns intake, coding, dispatch, and exception management; each subsidiary's budget owners approve their own spend under entity-calibrated limits. Pure central approval breaks down because central staff can't verify whether goods arrived at a site they've never seen.

Define precedence explicitly and encode it - common orders put the more specific rule (project) above the more general (department), with amount conditions overriding both. A documented precedence order is also an audit answer; "whichever rule fired" is not.

Stampli's workflow rules evaluate ERP-aligned invoice fields - department, GL account, subsidiary, location, amount, vendor - at dispatch and assign the matching approver path, so routing mirrors the customer's actual financial structure rather than a generic flow. Because the same synced ERP values drive both coding and routing, organizations with multi-entity, multi-location, or project structures route on the dimensions they already maintain. Misroutes have a governed correction path: approvers can flag "not mine," and AP can recall, fix, and re-dispatch with the history preserved.