Most AP approval workflows are built once and patched repeatedly. The original design made sense for the organization at the time it was configured. As the business grows, new entities are added, new cost center structures emerge, and new approval policies are layered on top of the original logic. The result is an approval hierarchy that is difficult to understand, difficult to maintain, and prone to routing errors that either delay payments or create control gaps.
A scalable approval hierarchy is not more complex than an unscalable one. It is better structured. The logic is defined at the policy level rather than the individual approver level, which means the hierarchy adapts to organizational change without requiring a full rebuild.
The Failure Modes of Email Based Approval
Before designing a structured approval hierarchy, it helps to be specific about what goes wrong with email based approval chains at scale:
- Invoices sit in inboxes unacted upon because there is no escalation mechanism and no visibility into how long they have been waiting
- Approvers on leave or out of office create complete blockages because there is no defined delegate or alternative path
- Approval of the wrong invoice because the email chain has become too long to see which document is being approved
- Approvals that happen outside the documented policy because someone verbally authorized a payment and the AP team processed it without a system record
- Audit trails that require reconstructing approvals from email archives rather than drawing from a system log
These are not occasional failures in high volume periods. They are structural weaknesses that manifest daily and compound as organization size increases.
The Four Design Principles for Scalable Approval Hierarchies
Design 1: Policy based routing, not individual based routing
The most common design mistake is building approval routes that are specific to named individuals. When those individuals change roles, leave the company, or are unavailable, the route breaks. Scalable approval hierarchies route by role, not by name. The system assigns approval to whoever currently holds the relevant role. When role assignments change, the routing updates automatically.
This requires discipline in role definition. The roles used in approval routing must be maintained in the system as people change. An approval hierarchy built on roles is meaningless if role assignments are not kept current. This is an ongoing HR and finance operations responsibility, not a configuration task done once at implementation.
Design 2: Risk proportionate approval depth
Not all invoices carry the same risk. A $200 office supplies invoice from a long standing vendor processed against an approved purchase order requires a different level of approval scrutiny than a $50,000 professional services invoice from a new vendor with no purchase order.
Approval depth should be proportionate to risk. Low value, routine, PO backed invoices from established vendors can auto approve within defined thresholds. Mid value invoices route to a single manager level approval. High value invoices require senior approval. Invoices above a materiality threshold require CFO or finance director approval regardless of other attributes.
Applying the same approval depth to every invoice regardless of value is inefficient and creates the same processing delays that email based approval produces. The escalation triggers should be based on a deliberate risk assessment, not default conservatism.
Design 3: Automatic escalation with defined timelines
Every approval step should have a defined response window and an automatic escalation action when that window is not met. An invoice that has been waiting for manager approval for three business days should automatically escalate to the manager's superior with a notification. The escalation removes the need for AP staff to chase approvals manually and ensures that no invoice can be indefinitely delayed by an unresponsive approver.
Escalation design requires two things that are often absent: a defined escalation path for each approval role, and organizational acceptance that escalation is a normal process function rather than a criticism of the approver. Communicating the escalation policy to approvers before implementation reduces friction when it activates.
Design 4: Delegation management built into the system
Approvers go on leave. They attend conferences. They have periods of reduced availability. In email based approval, the AP team works around this through informal awareness of who is available and manual forwarding. In a system based approval hierarchy, delegation should be a formal function: approvers configure a delegate before going on leave, the delegate receives approval requests during the period, and the delegation expires automatically when the approver returns.
Delegation management that lives in email out of office settings is not governance. It is an informal workaround that creates audit trail gaps and does not actually guarantee that approval happens in the approver's absence.
Multi Entity Approval Design
For organizations operating across multiple legal entities, approval hierarchy design becomes significantly more complex. The options:
Entity specific hierarchies
Each entity has its own approval matrix configured to its specific cost structure, currency, and local management accountability. The complexity is proportionate to the number of entities but provides the most granular control. Maintenance overhead increases with each new entity.
Group level hierarchy with entity overrides
A standard group level approval matrix applies by default, with entity specific overrides for cases where local policy differs from group policy. This is the more scalable design for acquisition driven growth: new entities inherit the group hierarchy immediately and overrides are added only where genuinely necessary.
Shared service center with entity attribution
A centralized AP team processes invoices for all entities, but approval routing still reflects the entity responsible for the spend. Cost center owners in each entity approve their own invoices regardless of where the processing occurs. The shared service structure reduces AP headcount while maintaining accountability at the entity level.
What to Document and Review
Approval hierarchies should be documented as formal policy, not just as system configuration. The documentation should state:
- The approval thresholds by invoice value, vendor type, and entity
- The role responsible for each approval level
- The escalation timeline and path for each approval level
- The delegation policy and how delegation is recorded
- The review cycle for the hierarchy, typically annual
An annual review of the approval hierarchy against the current organizational structure and invoice population catches the accumulated drift between documented policy and actual system configuration that builds up as businesses grow and change.
