Approval workflows in AP automation

Buyer requirement: Approval workflows must route invoices to approvers scoped to the correct production, so that approvers from one production cannot approve invoices belonging to another, and approval chains can be configured independently per production. The routing logic must respect the same profit-center-based isolation that governs invoice visibility, ensuring the approval stage does not create a cross-unit exposure that the visibility layer prevents at the inbox stage.

For a media production company with 9 profit centers inside one Sage Intacct entity, Stampli's Predefined Approval Workflows provide the foundational routing mechanism: <cite index='3-4'>Stampli's Predefined Approval Workflows enable AP clerks to create and maintain intelligent workflows that automatically assign invoices to the appropriate approvers based on predefined criteria. The routing key can include department or custom fields drawn directly from the invoice: <cite index='3-6,3-8'>approvers can be assigned based on up to 5 invoice field values such as vendor, company, amount, and department, and controls are enforced at the time of approval assignment. Because Stampli mirrors ERP dimensions at the field level, <cite index='6-4'>Stampli mirrors your chart of accounts, dimensions, entities, and approval logic at the field level, meaning Sage Intacct profit-center or department codes synced from the ERP can serve as the routing key, creating separate approval chains per production. To enforce boundary integrity, the buyer must configure workflows in the fully hardcoded fixed mode: <cite index='25-1,25-2'>with a fixed approval system, assigned approvers cannot be changed unless the workflow is changed; the flexible process alternatively allows approvers to be added or removed with less effort. The ceiling is here: <cite index='16-1'>users can bypass departmental or organizational hierarchies and select any approver under the flexible/dynamic workflow mode, meaning cross-unit approval isolation is a configuration choice, not a system-level constraint enforced regardless of mode. Billy AI suggests approvers based on historical patterns and imported ERP attributes like department and location, but those are suggestions, not mandatory scope restrictions on who is permitted to approve. The approval workflow stage therefore provides dimension-based routing to the correct production approver but does not provide a hard system-enforced permission mask that prevents an approver from one production from being manually added to another production's invoice by AP staff with admin access.

Limitations: Approval isolation holds only in the fully hardcoded fixed workflow mode; in the flexible configuration, Stampli explicitly allows any user with access to add or substitute approvers, which can breach cross-unit isolation without a configuration-level safeguard. There is no documented per-approver permission mask that restricts approval authority to invoices tagged with a specific profit center at the workflow engine level, meaning the isolation relies on correct workflow configuration discipline rather than a structural enforcement layer.

Buyer requirement: The system must support configurable approval routing for requisitions that exceed a soft-stop threshold, routing the override request to a designated budget owner or finance approver for the relevant department or dimension before the commitment proceeds. This is implied by the soft-stop model the buyer described: a soft stop without a structured approval path is just a dismissible warning, not a control.

For a mid-market buyer whose budgets live in Workday Adaptive Planning and who needs soft-stop overages to trigger a mandatory approval gate before commitment proceeds, Stampli Procurement's Budget Management and pre-defined approval workflow modules together cover this requirement. On the budget side, when a purchase request would exceed a budget limit, the system can either automatically block approval or alert approvers with a notification while still allowing them to proceed if necessary, giving finance the choice between a hard block and a structured soft-stop. That soft-stop is not a dismissible warning: spending thresholds and condition-based rules automatically determine when additional reviewers must be involved, and conditional approval logic adjusts workflows based on request type, amount, department, or other criteria, creating appropriate oversight for each transaction. Routing to the correct budget owner is handled dimensionally: approvers are assigned based on various request attributes such as vendor, location, and department, and user properties such as level and title, to ensure the right stakeholders review each procurement request. The FAQ on the dynamic-approval-workflows page confirms that Stampli Procurement allows you to configure different approval requirements based on multiple variables; you can establish different approval chains for capital expenditures versus operational expenses, set dollar thresholds that trigger additional approval levels, and create department-specific workflows. Budget context is surfaced to the approver inline: when a purchase request is submitted, approvers can see how it impacts the relevant budget before making a decision. Finance teams can configure these settings based on organizational policies and can set different rules for different departments or budget categories; additionally, budget owners receive automatic notifications when spending approaches critical thresholds, allowing for proactive management before limits are reached. With complete visibility into approval status and a comprehensive audit trail, bottlenecks are quickly identified and resolved.

Limitations: Documentation describes threshold-triggered insertion of additional reviewers and department-aware routing but does not specify whether the trigger is budget-consumption percentage (remaining balance vs. threshold) or requisition dollar amount in isolation; buyers who need a trigger based strictly on remaining-budget percent rather than a spending-limit ceiling should confirm this distinction during a demo. Additionally, Stampli's procurement module is a separate add-on from its core AP automation product, so the buyer will need to confirm that both modules are included in their contract for the end-to-end control described.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a mid-market distributor whose three-way match today collapses because receiving records are never entered, Stampli's AI Line-Level PO Matching module addresses both the detection and disposition halves of this requirement. On the tolerance side, Stampli automatically performs 2-way and 3-way matching of header, line-level, and footer PO data, and automatically skips invoice approvals when POs and invoices match based on customer-defined tolerances. Admins configure percentage and dollar thresholds per their policies; invoices within those bands are auto-approved without human escalation, directly solving the noise problem the buyer describes. On the exception side, Stampli will automatically flag any discrepancies from matches and provide details directly next to the match in question, with all discrepancies and exceptions surfaced alongside the match. The system automatically identifies exact matches between header and line-level PO data, matches items with identical descriptions, quantities, rates, and amounts, and flags discrepancies when line items do not match. The invoice card functions as the shared workspace: Stampli AI performs line-level PO matching and surfaces and resolves exceptions in context before they create downstream cleanup; the invoice becomes the shared workspace for AP, approvers, and vendors, with questions, answers, supporting documents, and approvals all staying attached to the transaction. For routing exceptions to a defined handler rather than a generic queue, Stampli Procurement allows configuration of different approval requirements based on multiple variables, including different approval chains for capital versus operational expenses and dollar thresholds that trigger additional approval levels. Stampli's own best-practice guidance explicitly describes routing exceptions by invoice category to named roles, such as software invoice discrepancies to the IT Director and facility-related discrepancies to the Operations Manager, using the platform's configurable workflow rules.

Limitations: Stampli's product pages confirm discrepancy details are shown 'alongside the match' in a unified view, but publicly available documentation does not explicitly demonstrate a named system-level feature that keys exception routing to the variance TYPE (price vs. quantity vs. line-item) as a distinct routing criterion; the buyer should confirm during a demo that the approval workflow builder supports variance-type as a routing dimension, not only dollar amount or invoice category. Additionally, invoices are matched to purchase orders and receiving records and the system flags discrepancies for review before payment, meaning the receiving record must actually exist in the system for true three-way match exceptions to fire; this buyer's core receiving-gap problem (no one logs receipts) must be solved upstream before exception routing on three-way mismatches is possible.

Buyer requirement: Approval routing for purchase requests and POs must dynamically assign approvers based on spend category, dollar threshold, and department, supporting the mid-market distribution context where different categories of operational spend (freight, inventory replenishment, services) may have different approval chains. Approvers must see the remaining budget for the relevant cost center or department at the time they act, not just the request amount in isolation.

For a mid-market distributor on NetSuite needing differentiated approval chains for freight, inventory replenishment, and services spend, Stampli Procurement provides two complementary routing engines. The pre-defined workflow builder lets admins configure conditional approval logic using a visual interface, with routing rules driven simultaneously by request type, dollar threshold, department, cost center, vendor, and user-level attributes drawn from an uploaded org hierarchy. Conditional approval logic adjusts workflows based on request type, amount, department, or other criteria, creating appropriate oversight for each transaction. Admins can establish different approval chains for capital expenditures versus operational expenses, set dollar thresholds that trigger additional approval levels, and create department-specific workflows. The AI layer (Billy) augments this by learning historical approval patterns across requestor, department, location, vendor, purchase type, and dollar amount dimensions. Billy analyzes historical approval patterns in your organization based on multiple factors including requestor, department, location, vendor, purchase type, and dollar amount, and learns from every approval decision made, continuously improving its recommendations over time. On the budget visibility side, Stampli has a dedicated Budget Management module that surfaces remaining budget context inline at the moment of approval action. By integrating budget oversight directly into the approval workflow, teams can instantly see how each purchase request impacts available funds, enforce spending limits, and receive proactive notifications when budgets reach critical thresholds. The solution provides immediate visibility into how each purchase request affects available budget during the approval workflow, eliminating the need to reference separate systems or spreadsheets. Approvers can also be blocked from approving when a request would exceed the relevant budget. When a purchase request would exceed a budget limit, the system can either automatically block approval or alert approvers with a notification while still allowing them to proceed if necessary, giving complete control over how strictly to enforce budget compliance; finance teams can configure these settings based on organizational policies and can even set different rules for different departments or budget categories.

Limitations: The primary ceiling for this NetSuite buyer is the budget data source: Stampli's budget module allows flexible budget creation based on department or project-specific requirements, or can otherwise be imported via CSV, which suggests Stampli maintains its own budget ledger rather than pulling live encumbrance data directly from NetSuite's budget tables. If purchases or commitments are entered in NetSuite outside of Stampli, the remaining-budget figures shown to approvers could lag or diverge from the ERP's actual budget position. Additionally, the entire account uses either predefined or dynamic workflows; it cannot be set on an individual invoice basis, so the buyer must commit to one routing mode organization-wide rather than mixing approaches per spend category.

Buyer requirement: Approval routing must operate across all 14 NetSuite OneWorld subsidiaries from the shared-services AP team while enforcing per-subsidiary book isolation: approvers in Subsidiary A must not be able to view, act on, or influence invoices belonging to Subsidiary B's books unless explicitly granted cross-entity access. The routing architecture must support threshold-based and context-aware chain adaptation (by subsidiary, GL account, or cost dimension) so that the correct entity's controllers and budget owners are engaged at the cost-allocation and terms-verification stages without manual queue management by the AP team.

For a shared-services AP team running 14 NetSuite OneWorld subsidiaries at 8,000 invoices per month, Stampli operates across the cost-allocation and approver-engagement stages (pre-processing journey steps 3 through 5) using two complementary routing modes. First, its Predefined Approval Workflows engine assigns approvers based on up to 5 invoice field values including company/subsidiary, vendor, amount, and department, with condition-based threshold rules that automatically add reviewers for higher-value transactions; this covers the threshold-based and attribute-driven routing the buyer requires. Second, its AI-powered dynamic workflows (Billy the Bot) identify approvers from historical patterns, invoice data, and organizational logic, and can add approvers on the fly without rebuilding rules, which addresses context-aware mid-flow adaptation. Stampli's OneWorld-specific integration mirrors subsidiary data natively: many-to-many filtering ensures only valid subsidiary/GL/department combinations are presented during coding, and the platform explicitly supports consolidated cross-entity views while maintaining subsidiary segregation. Role-based access controls and Trays (team-based work queues) are documented as the mechanism for keeping shared-services and subsidiary-level approvers separated in the same account. The material ceiling is subsidiary-level data isolation: Stampli's documentation confirms consolidated reporting with subsidiary segregation and role-based visibility, but does not provide explicit help-center evidence of a hard access barrier that enforces zero cross-subsidiary invoice visibility at the approver level by default; the isolation appears to depend on Tray configuration and role assignments rather than a system-enforced per-subsidiary permission wall, and Predefined Approval Workflows carry a documented constraint of routing criteria limited to 5 invoice fields, with the entire account forced into either predefined or dynamic mode, not both simultaneously per invoice type.

Limitations: The 5-field cap on Predefined Approval Workflow criteria and the account-wide mode lock (predefined versus dynamic cannot be mixed per invoice type) may force SOX-sensitive subsidiaries with complex routing logic onto a single architectural pattern that does not fit every entity's approval chain. Explicit documentation of a hard, system-enforced access barrier preventing Subsidiary A approvers from viewing Subsidiary B invoices was not found in help center documentation; isolation appears to rely on Tray and role configuration, which is configurable but not a guaranteed architectural wall without correct setup.

Buyer requirement: The approval routing engine must support multi-level, configurable chains that can adapt based on legal entity, financial dimension values, invoice amount thresholds, and vendor attributes across the three legal entities, so that each entity's approval hierarchy is enforced independently within a shared workflow system. The engine must also support delegation and auto-escalation on timeout, since approvers who work primarily in Teams may be unavailable and the workflow must not stall at a single point.

For a three-legal-entity D365 Finance environment, Stampli's approval engine operates in the pre-processing journey at stages 2 through 5 (PO match through cost allocation), with routing decisions made inside Stampli before any transaction posts to D365 F&O. Stampli can be configured to align with existing approval hierarchies in D365 F&O, including multi-entity scenarios and delegation-of-authority rules, with its flexible workflow engine mapping approval routes within Stampli's own interface so approvers never need F&O licenses or training. Per-entity isolation is directly addressed: Stampli provides configurable coding structures, approval workflows, and vendor lists tailored to each individual company, with each entity able to carry its own GL accounts, approval workflows, and compliance requirements. The workflow builder supports two architectural modes: predefined (rule-based) workflows and dynamic (AI-driven) workflows. For the rule-based mode, approvers are assigned based on up to 5 invoice field values such as vendor, company, amount, and department, with support for drop-down list, yes/no, and numerical field types. Routing conditions include amount thresholds and vendor attributes: approval chains can be set up based on department, dollar amount, category, vendor, or any combination of these factors. For the buyer's D365 financial dimensions specifically, dimensions are fully supported in all objects exported from Stampli, with unlimited dimensions carried without remapping, enabling AP to split charges across any combination of entities, projects, and cost centers before posting. On delegation and escalation: fallback routing automatically redirects requests to designated backup approvers when primary approvers are unavailable, approvers can designate temporary substitutes for specific date ranges, authorized users can reassign pending approvals without disrupting the entire process, and configurable escalation rules automatically route requests to alternative approvers if they remain pending too long. The critical gap for this buyer is the Teams interface requirement. Stampli's approver channel is an email notification plus a mobile app: Stampli's mobile app allows on-the-go invoice approvals, and automated reminder notifications are sent to approvers to ensure timely review. No evidence was found in Stampli's product documentation of a native Microsoft Teams app, adaptive card, or Teams bot that lets approvers take approval actions from within Teams without navigating to the Stampli portal. The buyer's explicit requirement for Teams-native approval actions (approve, reject, comment without a separate login) is not substantiated by any Stampli source found.

Limitations: The 5-field cap in Stampli's predefined (rule-based) workflow builder may constrain complex routing logic that simultaneously evaluates legal entity, multiple financial dimension values, amount tier, and vendor attribute; buyers relying on the structured rule engine rather than AI-suggested dynamic workflows should validate this ceiling during evaluation. More materially for this buyer, Stampli has no documented native Microsoft Teams integration that allows approvers to act on invoices from within Teams: the product relies on email notifications and a mobile app as the approver interface, which means Teams-primary approvers will still need to navigate to the Stampli portal to complete approvals.

Buyer requirement: Approvers must be able to receive, review invoice details and coding, and take approval actions (approve, reject, request information, delegate) directly within Microsoft Teams, without being required to authenticate into a separate AP portal or web application. The Teams-native experience must surface the full invoice image, line-level coding, and any attached supporting documents so that approvers can make informed decisions without context-switching, addressing stage 5 approval routing in the buyer's primary collaboration environment.

For a Microsoft Teams-centric finance organization running D365 Finance across three legal entities, the buyer's requirement is that approvers complete all four approval actions (approve, reject, request information, delegate) without leaving Teams. Stampli's documented approver notification mechanism does not support this. Stampli notifies approvers via email and mobile push notifications, and when a non-regular user is messaged, they receive an email with a direct link that opens the Stampli web portal to view and act on the invoice. When someone is messaged through the platform, "they'll receive an email notification with a direct link to respond" and "can click the link to view the transaction and respond" inside Stampli. The full approver experience, including the invoice image, line-level coding, supporting documents, and approval actions, lives exclusively inside the Stampli web UI. Stampli presents approvers with the invoice, supporting documents, approval history, and all other needed context on a single screen; approvers can message AP, team members, or vendors directly within Stampli; and can approve, reject, or reassign invoices with a single click. Mobile access is offered through Stampli's own app, not Teams. The Stampli Mobile App sends push notifications to alert users when approvals or other information is needed, but this is Stampli's own application, not the Microsoft Teams client. Across Stampli's website, help center, D365 Finance integration page, and approver experience documentation, there is no mention of a Teams bot, Teams adaptive card, Teams app tab, or any mechanism that delivers approval actions natively within the Teams canvas without redirecting to the Stampli portal.

Limitations: Stampli has no documented Microsoft Teams integration of any kind: no Teams bot, no adaptive card, no Teams app, and no Power Automate connector for in-Teams approval actions. Approvers in this buyer's Teams-primary environment will be redirected to the Stampli web portal via email link for every approval action, which directly violates the stated requirement of no separate portal login.

Buyer requirement: Approval routing must be configurable to route each invoice line, or a split-coded invoice, to the owner of the specific dimension values coded on that line (e.g., the project manager for the project dimension, the department head for the department dimension), not just a fixed sequential chain applied at the invoice header level. This satisfies stage 5 of the pre-processing journey: the budget owner, not AP, must validate cost allocation, and that owner is determined by the dimension values on each line.

For a multi-entity SaaS company on Sage Intacct with dimension-driven cost allocation at the line level, Stampli addresses stage 5 of the pre-processing journey through two routing modes: Predefined Approval Workflows and dynamic AI-powered routing. In the Predefined mode, approvers can be assigned based on up to 5 invoice field values, with support for drop-down list, yes/no, and numerical field types as criteria, meaning an admin can configure rules such as 'if Department = Engineering, route to Engineering VP.' Unlike most ERPs that limit you to rigid, linear approval chains, Stampli supports complex conditional logic and multi-dimensional routing rules. In the dynamic mode, Stampli AI identifies approvers automatically using historical patterns, invoice data, and approval logic built around your company's policies. However, both mechanisms resolve routing at the invoice header level: the routing engine evaluates invoice-level field values to assign a single workflow chain. The entire account uses either Predefined or Dynamic workflows; it cannot be set on an individual invoice basis. The specific requirement here is that a split-coded invoice with Line 1 coded to Project A (owner: PM Sarah) and Line 2 coded to Department B (owner: VP John) simultaneously routes Line 1 to Sarah and Line 2 to John as distinct per-line approvals resolved from the dimension value on each distribution line. No Stampli documentation, including the Predefined Approval Workflows product page, the Sage Intacct integration page, or the dynamic workflows pages, describes this per-line dimension-to-approver resolution mechanism. Dynamic routing and on-the-fly approver additions keep invoices moving, but these are invoice-level constructs, not line-level dimension-owner forks.

Limitations: Stampli's routing engine evaluates up to 5 invoice-level fields to determine the approval chain for the whole invoice; there is no documented mechanism that reads dimension values coded on individual distribution lines and forks the invoice simultaneously to the project manager for line 1 and the department head for line 2 based on those specific dimension values. For this buyer's Intacct environment with 5 or more dimensions allocated at the line level across multiple owners, the system will not enforce that each dimension owner validates only the lines relevant to their cost center or project, which is precisely what stage 5 of the pre-processing journey requires.

Buyer requirement: Approval routing must be conditional on two independent variables simultaneously: the legal entity on the invoice (US parent or either UK subsidiary) and the invoice amount threshold, producing different approval chains for each entity-threshold combination. The routing engine must support mid-flow context-aware branching so that a UK invoice above a defined threshold follows a different chain than a US invoice at the same amount, without requiring separate workflow configurations for every permutation.

For this buyer's 3-entity Sage Intacct environment, Stampli's Predefined Approval Workflows engine is the relevant mechanism. The platform's product documentation confirms that approvers can be assigned based on up to 5 invoice field values, including vendor, company, amount, and department — meaning legal entity ('company') and invoice amount are both named, co-equal fields that can be evaluated simultaneously within a single workflow rule, rather than requiring separate sequential workflows for each variable. At the multi-entity level, coding structures, approval workflows, and vendor lists can be configured and tailored to each company's needs within a single Stampli account, and for this buyer's Sage Intacct setup specifically, Stampli mirrors Intacct's entities, Smart Rules, and custom fields with five-minute list updates and two-hour sync cycles, with support for parent-child entities, multi-location models, and entity-based user restrictions that flow automatically from Intacct. Stampli's own mid-market documentation confirms that approval logic routes dynamically based on thresholds, entities, and accounts, treating all three as co-equal routing dimensions rather than sequential single-variable gates. The combinatorial result: a UK subsidiary invoice above a defined threshold evaluates entity and amount simultaneously against the configured rule set and resolves to a different approver chain than a US invoice at the same amount, without requiring a fully discrete workflow definition per permutation. The system supports as many approval levels as needed, with conditional logic that can trigger different approval paths based on countless variables including request type, amount, vendor, department, or custom fields. For mid-flow flexibility, dynamic routing, on-the-fly approver additions, and a robust validation engine keep invoices moving, and approvers can be added on the fly to handle one-offs without redefining the whole workflow. This covers pre-processing journey stage 5 (cost allocation and routing) and the approval chain stage; it does not replace stage 4 (receipt confirmation), which is handled separately via PO matching.

Limitations: The platform enforces an account-wide choice between Predefined Workflows (deterministic, rule-driven chains) and Dynamic Workflows (AI-suggested approvers based on historical patterns): Predefined and Dynamic workflows cannot be mixed on an individual invoice basis; the entire account uses one or the other. This means the buyer must commit to Predefined mode to guarantee deterministic entity-threshold chains, which forfeits Billy's AI-driven mid-flow approver suggestions for edge cases — a relevant trade-off given the buyer's simultaneous desire for 'mid-flow context-aware branching.' Additionally, while 'company' and 'amount' are both documented as supported criteria fields, the published documentation does not explicitly describe the internal branching architecture (true AND-matrix versus hierarchical per-entity sub-trees), so the exact configuration model should be confirmed with Stampli's implementation team before sign-off.

Buyer requirement: The system must enforce a fixed two-tier sequential approval chain, manager review followed by CFO approval, configurable per vendor or per invoice amount threshold, with auto-escalation when an approver does not act within a defined time window and delegation capability when either approver is unavailable. This maps directly to the buyer's stated process and sits at the legitimacy and cost-allocation stages; approvers must see the full coded invoice (vendor, amount, GL account, line detail) inside the approval interface without needing to open QuickBooks Online separately.

For a 50-person SaaS startup needing manager-then-CFO sequential approvals on contractor and software-vendor invoices, Stampli operates squarely at the legitimacy and cost-allocation stages of the pre-processing journey. The mechanism works as follows: after Billy the Bot extracts and codes an incoming email PDF, the invoice enters a configurable approval chain. Stampli supports both predefined fixed chains and dynamic routing; a fixed two-tier sequential chain (manager first, CFO second) is set up either via predefined workflows for strict compliance or via dynamic rules triggered by vendor identity or invoice amount threshold. Stampli can require sequential sign-offs from multiple tiers, with conditional logic that triggers different approval paths based on request type, amount, vendor, department, or custom fields. For the inline approver experience, Stampli provides a single screen containing everything an approver needs to review and approve invoices, including the invoice itself, supporting documents, approval history, and other context. Stampli centralizes the invoice, related documents, approval context, and communication in one workspace, meaning neither the manager nor the CFO needs QuickBooks Online credentials to review the fully coded invoice. On timing enforcement, after an invoice is coded it enters the first approver's queue, and you can set the frequency of auto-reminders to get invoices approved in a timely manner. For delegation and absence coverage, Stampli's fallback routing automatically redirects to designated backup approvers when primary approvers are unavailable; approvers can designate temporary substitutes for specific date ranges; authorized users can reassign pending approvals for urgent situations; and configurable escalation rules automatically route requests to alternative approvers if they remain pending too long. Coded data syncs post-approval to QuickBooks Online, so the ERP remains the system of record without approvers ever needing to open it.

Limitations: The help center documentation confirms auto-reminder frequency is configurable but does not expose a specific "hard escalation after N hours" timer with automatic reassignment at the AP-automation layer distinct from procurement workflows; for invoice AP specifically, the primary escalation mechanism documented is reminder frequency plus manual reassignment, which is sufficient for most 50-person teams but falls short of a guaranteed hard-stop reassignment at a defined timeout. Initial workflow configuration for predefined chains is done with Stampli's Customer Success team rather than fully self-serve, which adds a small setup dependency.

Buyer requirement: For non-PO invoices, the solution must support a department-initiated coding and pre-approval workflow where the department owner can code, annotate, and approve their portion of an invoice before it reaches the central AP team, matching the buyer's described split where departments manage their invoices and hand off ready-to-code items to AP. This covers pre-processing stage 5 (cost allocation) and must preserve all department-entered dimension values when the record is handed to AP and subsequently posted to SAP S/4HANA.

The buyer's scenario, specifically 6,000 monthly non-PO invoices coded and pre-approved by department owners before reaching central AP, maps directly onto three interlocking Stampli mechanisms. First, AP Assignments routes each non-PO invoice to the correct department Tray (a team-based work queue) based on criteria such as vendor, department, or custom field, granting department users access only to invoices relevant to them while controlling which users can view invoices, change coding, authorize payment, or modify assignments (stampli.com/ap-assignments). Second, within each department Tray, users act in distinct 'coder' roles: Billy the Bot codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from payment and accounting history, then routes the invoice to the right people, so the department owner reviews, annotates, corrects, and approves the AI-suggested coding before the record ever reaches central AP (fact sheet supporting claims cabc71f8, 017835a0). Third, Stampli's predefined workflows support both fully fixed configurations and flexible configurations where approvers can be added or removed during coding and routing, with conditional logic triggering different approval paths based on department, amount, or custom fields, so the buyer can enforce a hard gate requiring department coding completion before the invoice progresses to the central AP queue (stampli.com/predefined-approval-workflows). On the SAP S/4HANA dimension-preservation question, the Stampli SAP integration explicitly exposes native SAP fields, including G/L, WBS, Profit Center, Cost Centers, and profitability segment fields, within the Stampli coding interface, and the bi-directional bridge syncs these values back to SAP so all dimension values entered or confirmed by the department are preserved and posted without re-entry by AP (stampli.com/erp/sap/). This covers pre-processing stage 5 (cost allocation) end to end: department owns dimension entry, workflow gates progression, and SAP S/4HANA receives the complete coded record.

Limitations: Stampli's documentation confirms the building blocks (Trays, coder roles, fixed workflow gates, SAP dimension field pass-through) but does not explicitly describe an out-of-the-box 'department coding must be 100% complete before any AP user can view the record' hard lock as a single toggle; the buyer should validate during implementation that the combination of fixed workflow configuration and role-based Tray visibility enforces the coding-first handoff at the strictness their controls require. Additionally, because the entire account uses either predefined or dynamic workflows (not a mix per invoice), the buyer needs to confirm that predefined mode works for their PO-based invoice population as well, or that a separate configuration approach is available for the two invoice classes.

Buyer requirement: The approval workflow must support a configurable 2-step sequential routing chain with per-step delegation rules, so that an approver can assign a named substitute without breaking the chain or requiring AP staff to manually reroute. Auto-escalation on timeout must be included so that the 1,200 monthly invoices do not stall silently when an approver is unavailable. This covers stages 2 and 3 of the pre-processing journey (PO match confirmation and terms verification by the appropriate role).

For this mid-market manufacturer running 1,200 invoices per month through Sage Intacct, Stampli addresses pre-processing journey stages 2 and 3 (PO match confirmation and terms verification) through its Predefined Approval Workflows engine. Administrators configure a fixed sequential chain in advance, defining as many approver levels as needed and assigning specific approvers based on up to five invoice fields such as vendor, department, amount, and custom GL dimensions. Predefined Approval Workflows allow creation of fixed approval chains in advance based on specific invoice criteria, enabling AP teams in complex organizations to automatically assign invoices to specific approvers based on predefined criteria. The chain respects strict sequencing: invoices are automatically sent to the right approvers in the right sequence according to the organization's approval hierarchies and policies. For delegation, fallback routing automatically redirects purchase requests to designated backup approvers when primary approvers are unavailable, and the system supports out-of-office settings where approvers can designate temporary substitutes for specific date ranges; for urgent situations, authorized users can reassign pending approvals without disrupting the entire process. On timeout, configurable escalation rules automatically route requests to alternative approvers if they remain pending for too long, ensuring the process continues moving even when key personnel are unavailable. Billy identifies approvers automatically using historical patterns, invoice data, and approval logic built around the company's policies, routing every invoice to the right people and keeping the process on track. The Sage Intacct integration is a Stampli Recommended Solution, meaning ERP dimensions flow into the approval routing criteria without a data layer gap.

Limitations: One account-level constraint is worth noting: Stampli does not allow mixing Predefined and Dynamic workflows at the individual invoice level; the entire account uses one mode or the other. Additionally, while delegation and fallback routing are documented, the platform's product pages do not explicitly confirm whether a named substitute occupies the original approver's chain position with full audit attribution preserved, versus being added as a new step; buyers should verify this specific chain-position behavior with Stampli during implementation scoping.

Buyer requirement: For the roughly 1,050 non-PO invoices processed each month (the remaining 30% of 3,500), the system must support AI-assisted GL coding and cost allocation routing to the appropriate budget owner for approval, since these invoices do not have a PO or GR document to anchor a 3-way match. The coding model must suggest SAP cost objects (cost center, GL account, plant) based on vendor history and invoice content, and must route to the correct budget owner based on the suggested cost allocation rather than defaulting to a fixed AP-team approval chain.

For this manufacturer's approximately 1,050 non-PO invoices per month, Stampli's Billy AI handles all five pre-processing stages without requiring a PO anchor. When a non-PO invoice arrives, Billy detects that the invoice is not associated with a purchase order and automatically identifies the cost center and expense type, then codes the invoice in Stampli. The coding model draws on learned history: Billy reads the header, line items, tax amounts, and even freight splits, then proposes coding based on historical patterns. For the SAP cost object fields this buyer requires, Stampli's SAP S/4HANA integration syncs WBS elements, cost centers, and project codes alongside standard GL and PO data, so Billy's suggestions are drawn from live SAP master data, not a flat list. For recurring non-PO vendors, templates can be tailored to specific vendors for consistent coding, and the system provides context-aware template selection so coders only see templates relevant to the invoice they are working on. On the approval side, the routing is explicitly dynamic and cost-object-aware: drag-and-drop conditions, including amount, cost center, and project stage, define who needs to sign off on requests, and Stampli provides a choice between fixed and dynamic workflows, where dynamic workflows use ML technology to learn cost accounting and approval processes and automatically sense and adapt when business rules change, with no IT rework needed. The approver resolution is not a fixed AP-team chain: Billy identifies approvers automatically using historical patterns, invoice data, and approval logic built around the company's policies, routing every invoice to the right people and keeping the process on track. The SAP integration is a pre-built bridge connector that syncs bi-directionally every few minutes, keeping systems aligned across purchase orders, receiving details, vendor information, general ledgers, cost centers, item categories, custom fields, and invoice specifics.

Limitations: Billy's approver resolution for non-PO invoices is ML-learned from historical patterns rather than a rules-configured cost-center-to-budget-owner lookup table, meaning routing accuracy for infrequent or brand-new cost center and vendor combinations will be lower early in deployment and will require AP-team review until Billy accumulates sufficient signal. There is no documented hard-coded mapping interface where an admin can explicitly define cost center X routes to budget owner Y without relying on pattern learning.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a $120M services company running bi-weekly check runs and monthly ACH batches through Sage Intacct, the relevant mechanism is Stampli Direct Pay's payment approval workflow layer, which sits downstream of invoice coding and approval. Stampli documents a distinct 'Approve payment' step in the Direct Pay flow that is separate from invoice-level coding approval: Stampli offers robust and customizable approval workflows to ensure proper separation of duties and compliance, with the ability to customize the approval process based on invoice amounts so payments are made according to company policies. The payment-level approval can be role-configured with named approvers: each workflow can have its own set of routing rules, approval thresholds, and authorized approvers based on the specific needs and compliance requirements of that unit. This ensures funds are only released according to your corporate policies and maintains proper separation of duties for compliance. The audit trail closes the loop: the system sends remittance emails with detailed payment information and maintains a clear audit trail of all payment activities. However, the documented trigger mechanism is amount-threshold-based: with Stampli Direct Pay, you can set up approval workflows based on an amount below, in between, or above a certain threshold. This means the CFO or Controller gate fires when a configured dollar threshold is crossed, not unconditionally on every batch regardless of size. The buyer's requirement calls for ALL payment batches to require CFO or Controller electronic approval before release, which is a universal batch-level mandate, not a threshold-triggered one.

Limitations: The documented Stampli Direct Pay approval model is amount-threshold-based, meaning batches composed entirely of invoices below the configured threshold may not require CFO or Controller sign-off, creating a gap in the buyer's universal batch-approval mandate. The buyer should confirm with Stampli whether a zero-dollar floor threshold (or an explicit 'all batches' rule) can be configured to enforce the CFO gate on every payment run regardless of batch total.

Buyer requirement: Approval routing must be configurable per entity so that each of the 8 real estate entities can enforce its own chain of approvers, spending thresholds, and GL-account-based escalations, all within a single AP workflow managed by the 4-person team. Stage 5 of the pre-processing journey (cost allocation sign-off) requires that budget owners see only the invoices and dimensional data belonging to their entity: role-based, entity-scoped visibility controls are required so one entity's approvers cannot view or act on another entity's payables.

For a real estate portfolio operator running 8 separate legal entities in NetSuite, Stampli's multi-entity architecture directly addresses this requirement. The platform supports an unlimited number of companies or subsidiaries within a single Stampli account, and each entity receives its own independently configured coding structure, approval workflow, and vendor list. Stampli allows an unlimited number of companies or subsidiaries within a single account, and provides configurable coding structures, approval workflows, and vendor lists tailored to each individual company's needs. Approval routing is driven by Stampli's Predefined Approval Workflows engine, which assigns approvers based on invoice-level criteria including company, vendor, amount, and department: this involves creating and maintaining fixed workflows using an interface based on criteria for invoice fields, with specific approvers assigned based on up to 5 invoice field values such as vendor, company, amount, and department. Spending thresholds and GL-account-based escalations are configurable natively: spending thresholds and condition-based rules automatically determine when additional reviewers must be involved, and Stampli allows distinct approval workflows for different departments, business units, or entities, each with its own set of routing rules, approval thresholds, and authorized approvers. For Stage 5 cost allocation sign-off, entity-scoped visibility is enforced through role-based access controls built into the platform's Trays and routing architecture: Trays route invoices to the right teams automatically, dynamic approval workflows adapt to the approval logic, and role-based visibility keeps access tight; shared services teams, business units, and local approvers can work in the same system without losing governance. On the NetSuite side specifically, the integration enforces many-to-many dynamic filtering so only valid combinations of subsidiaries, locations, vendors, GL accounts, and custom fields appear for each user during coding: Stampli enables dynamic filtering of field values based on many-to-many relationships (entities, locations, vendors, GL accounts, and custom fields), so only valid combinations of values are presented. The NetSuite integration also carries full OneWorld multi-subsidiary support including subsidiary and intercompany field mirroring and consolidated reporting across entities while maintaining subsidiary segregation: Stampli fully supports NetSuite's OneWorld functionality, allowing management of multiple subsidiaries under a single account, with subsidiary and intercompany field mirroring and consolidated reporting across entities while maintaining subsidiary segregation. Billy's AI layer learns the approval logic, cost centers, and vendor behaviors per entity and continues to refine routing as patterns change: it learns approval logic, cost centers, vendor behaviors, and ERP configurations, improving with every cycle.

Limitations: The predefined versus dynamic workflow mode is an account-wide toggle: the entire account uses either Predefined or Dynamic workflows; it cannot be set on an individual invoice basis. This means the buyer must choose one architectural mode across all 8 entities, which limits the ability to run fixed entity-specific chains for some entities while using AI-driven dynamic routing for others simultaneously. Additionally, a third-party review notes that some users have reported challenges with duplicate supplier management in multi-subsidiary NetSuite environments, which is worth validating during implementation.

Buyer requirement: The system must support dynamic approval workflows where the responsible person's approval authority and visible data are scoped to their role: the approver must be able to see request details, vendor context, and budget availability at the point of decision before committing to a fulfillment path.

For this buyer's intake-to-fulfillment process, Stampli Procurement operates as the approval decision layer between request submission and fulfillment path selection. When a request arrives, the responsible approver sees request details, vendor history, and live budget impact on a single screen inside the approval workflow -- no context-switching to a separate module required (stampli.com/budget-management, stampli.com/the-approver-experience). Approval authority is scoped by role through conditional routing rules keyed to amount thresholds, department, vendor, and custom ERP-imported attributes, so each approver only acts within their configured authority limits (stampli.com/dynamic-approval-workflows, stampli.com/pre-defined-approval-workflows). Post-approval, Stampli's rules engine governs the fulfillment path: the same workflow can branch to PO creation, virtual card issuance via Stampli Cards, or a service ticket, all within one platform and synced back to SAP ECC via a pre-built in-house integration (stampli.com/procurement, stampli.com/procurement-cards, stampli.com homepage).

Limitations: Approval authority scoping is enforced primarily through routing rules (amount thresholds, department, vendor) rather than a granular per-field data-masking model; buyers requiring fine-grained visibility restrictions -- where an approver literally cannot see data outside their authority window -- should validate the depth of Stampli's role-based access controls in the procurement module during a demo. The virtual card fulfillment path (Stampli Cards) requires that the card program is activated as part of the Stampli deployment; it is not a zero-configuration default.

Buyer requirement: The system must enforce strict multi-entity isolation so that each subsidiary or business unit operating within the NetSuite instance maintains its own chart of accounts mapping, approval chains, and vendor records. Users assigned to one entity must be prevented at the permission layer from viewing, coding, or approving invoices belonging to another entity, replicating the subsidiary-level segregation native to NetSuite.

For a mid-market NetSuite OneWorld customer with 1,500 invoices per month, Stampli structures multi-entity isolation through its 'Companies' model and AP Assignments feature. Stampli allows an unlimited number of companies or subsidiaries within a single account, and provides configurable coding structures, approval workflows, vendor lists, and other settings tailored to each individual company. On the approval routing side, Predefined Approval Workflows allow fixed approval chains built on specific invoice criteria, with approvers assignable based on up to five invoice fields including vendor, company, amount, department, and custom fields, enabling per-entity approval chains. For user access scoping, AP Assignments support limiting user access to specific assignments; admins can grant AP individuals access to any combination of assignments dependent on their role, and can also configure which AP individuals can change an invoice's assignment. On the NetSuite integration side, Stampli fully supports NetSuite OneWorld, goes beyond basic multi-entity support, and mirrors intercompany fields from NetSuite so intercompany transactions can be processed and posted back to NetSuite. The ceiling is that Stampli's user isolation for NetSuite relies on AP Assignments configuration rather than automatically inheriting NetSuite's subsidiary-level user permission rules; by contrast, for Sage Intacct, Stampli explicitly documents that it enforces the same security presets set in Intacct, including entity-based user restrictions that flow automatically from the ERP. No equivalent automatic ERP-inherited subsidiary permission enforcement is documented for the NetSuite connector.

Limitations: The permission-layer blocking the buyer requires (users in Entity A cannot see or touch Entity B invoices) is achievable through AP Assignments configuration, but it is a configured routing-layer control, not an automatically inherited data-layer lock mirroring NetSuite's subsidiary security model as documented for Stampli's Intacct integration. Buyers should verify in a demo whether Stampli's NetSuite connector enforces subsidiary-level access at the data layer automatically, or whether it relies on AP Assignment configuration discipline that an admin could inadvertently override.

Buyer requirement: Exception routing for 3-way match failures must feed into a configurable approval workflow that presents approvers with the specific discrepancy details (PO line, receipt line, and invoice line side by side) and routes to the correct entity-specific approver role based on the invoice's subsidiary, cost center, and dollar threshold. Approval chains must support parallel and sequential routing without requiring IT intervention to modify.

For a 1,500-invoice-per-month NetSuite OneWorld environment, Stampli's workflow engine handles the full exception-to-approval chain as follows. When a 3-way match fails, live PO, receipt, and item-receipt data flow into Stampli every few minutes, enabling true three-way matching, split PO scenarios, and rapid exception handling — all within the AP application, so approvers do not need to navigate back into NetSuite to see match data. Billy the Bot performs line-level PO matching and surfaces and resolves exceptions in context — before they create downstream cleanup. Routing from those exceptions feeds into a configurable approval engine: Stampli provides highly configurable approval workflows that can set up approval chains based on department, dollar amount, category, vendor, or any combination of these factors, and the system accommodates multiple approval stages, parallel approvals, delegate approvers for vacations, and escalation processes to ensure nothing gets stuck in the workflow. Subsidiary-level isolation is handled natively: fixed approval workflows require no IT — finance builds and maintains structured flows directly in Stampli, and with built-in OneWorld support, Stampli lets businesses manage multiple subsidiaries from a single Stampli account. Routing dimensions include cost center and subsidiary: the intuitive workflow builder allows configuring approval sequences visually, defining routing rules based on attributes like department, cost center, or spending threshold. The key limitation for this buyer is the side-by-side discrepancy display: while Stampli confirms line-level PO and receipt data is present in the approver interface, no documentation explicitly describes a structured three-column panel placing PO line, receipt line, and invoice line in a formal side-by-side comparison view — the discrepancy context is surfaced via the activity feed and line-level fields rather than a dedicated discrepancy comparison UI.

Limitations: The buyer's requirement for a formal side-by-side PO line / receipt line / invoice line discrepancy panel in the approver view is not explicitly documented; Stampli surfaces line-level exception context within its collaborative invoice interface but whether this constitutes a structured three-column comparison layout (vs. contextual line-level data) is unconfirmed and would need direct product demonstration. Additionally, while parallel approvals are documented at the PO workflow level, the explicit confirmation of true parallel gating (all parallel approvers must act before the chain advances, as opposed to CC-style notification) on AP invoice approval chains specifically should be validated during a demo.

Buyer requirement: The solution must support dynamic approval routing that can be configured by NetSuite department, class, or project segment, allowing entertainment production budgets and overhead spend to follow separate approval chains, with role-specific invoice data visibility so that approvers see only the entities and cost centers they are authorized to approve.

For this entertainment company on NetSuite, Tipalti's Bills module syncs Department, Class, Location, and Project fields from NetSuite 2.0 into Tipalti, where they can appear as coded fields on bill headers and lines; administrators can also create additional custom fields mapped to these NetSuite dimensions for bill-level coding (Tipalti NetSuite 2.0 Setup, help.tipalti.com). Multi-approver chains are supported: AP processors assign one or more users holding the 'Bill Approver' role to each bill from a 'Bill approver(s)' selection field, and third-party analysis of the platform characterizes this as 'multi-tier approval routing based on amount thresholds, departments, or custom rules' (Tipalti help center Quick Start Guide; ProcureDesk Tipalti vs Stampli comparison). For entity-level access, Tipalti's multi-instance setup scopes each user to an assigned entity or subsidiary so that approvers can only view and act on bills within their entity (Tipalti 'Switch entities with multi-instance setup,' help.tipalti.com). However, the help center documentation retrieved does not show a self-configuring conditional routing rules engine that automatically fires a separate approval chain when a bill's NetSuite Department value equals 'Production' versus 'Overhead': the approver assignment step appears to rely on AP team selection per bill or per matching policy, rather than a fully automated segment-triggered branch that requires no manual routing decision per invoice.

Limitations: The documented mechanism does not confirm that Tipalti can automatically branch production-budget invoices to a separate approval chain from overhead invoices purely based on synced NetSuite Department, Class, or Project values without AP team involvement at the routing step; sub-entity (department- or class-level) invoice visibility restriction for approvers is not explicitly documented in the help center, meaning cost-center-scoped data visibility may require entity-level isolation rather than dimensional filtering within a shared entity.

Buyer requirement: Approval workflows must route invoices to approvers scoped to the correct production, so that approvers from one production cannot approve invoices belonging to another, and approval chains can be configured independently per production. The routing logic must respect the same profit-center-based isolation that governs invoice visibility, ensuring the approval stage does not create a cross-unit exposure that the visibility layer prevents at the inbox stage.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, the buyer needs approval chains that auto-route to the correct production's approvers based on GL dimension coding, with the system enforcing that Production A's approvers cannot act on Production B's invoices. Tipalti's Bills module operates at approval stage 2 of the pre-processing journey (legitimacy and internal authorization). Approver assignment is primarily a per-bill, AP-initiated manual selection: if your process requires an approver or multiple approvers, you can select them from the 'Bill approver(s)' field; if you do not see the required approvers in the dropdown list, you can add them one at a time to the system, for use in this bill and future bills. Tipalti's marketing describes AI routing that 'determines the correct approver based on factors like amount, department, and vendor type,' but no help-center documentation surfaces a configuration interface where an admin defines per-production approver pools keyed to a Sage Intacct class, department, or profit-center dimension value, with system-enforced approval authority restrictions. The structural isolation mechanism documented in Tipalti's architecture is the 'payer entity' model: an entity can be a subsidiary, division, business unit, brand, etc. of your organization; entities can have similar or different AP processes and workflows. However, using separate Tipalti payer entities for each production maps each to a separate Sage Intacct entity and a separate virtual funding account, which is the anti-pattern the buyer explicitly rejected: the Sage Intacct setup requires selecting either 'Single entity' or 'Multi entity.' Bill lines can carry department, location, project, and cost center coding fields: bill lines mirror lines on the invoice and are used to allocate expenses among department, location, project, etc.; someone in your company can create additional custom fields on the bill header or bill line level for collecting details such as Department, Class, or Location; these custom fields display in bill filters and reporting. But there is no documented policy-engine layer that reads those dimension values at routing time and enforces production-scoped approver authority, keeping cross-unit approval access closed at the workflow level the same way it is closed at the visibility level.

Limitations: The material gap for this buyer is that Tipalti's documented approver-assignment mechanism is per-bill and AP-selected, not a rule-based engine that reads profit-center coding and enforces approver scoping automatically; the only workflow-level structural isolation Tipalti documents is the payer-entity model, which would require mapping each production to a separate Tipalti entity and ERP subsidiary, directly breaking the consolidated single-entity payment runs the buyer requires.

Buyer requirement: Approval routing for purchase requests and POs must dynamically assign approvers based on spend category, dollar threshold, and department, supporting the mid-market distribution context where different categories of operational spend (freight, inventory replenishment, services) may have different approval chains. Approvers must see the remaining budget for the relevant cost center or department at the time they act, not just the request amount in isolation.

For a mid-market distributor on NetSuite needing differentiated approval chains across freight, inventory replenishment, and services spend, Tipalti Procurement (built on the acquired Approve.com platform) provides a rule-based approval routing engine that automatically assigns approvers based on org-chart hierarchy, dollar thresholds, and department or location dimensions: admins configure predefined workflows for various budget levels, departments, and locations while accommodating unlimited budget owners. Approval routing happens automatically based on custom logic tied to the organisational chart, budget lines, and policy-based rules, and approvers can take action immediately, adding context or looping in finance, IT, or legal if necessary. Approvers have full visibility into the entire approval chain including completed and pending steps and overall budget status, enabling them to see whether a purchase fits within their budget range; parallel approval also allows multiple functional approvers to review and approve requests simultaneously. Critically for this NetSuite buyer, approvers are empowered with real-time budget status visibility to enable well-informed spend control decisions, with budget consumption data restricted to relevant stakeholders only; this feature is noted as for NetSuite users only. However, the documented routing dimensions are department, dollar threshold, and location; spend category as an explicit, standalone routing axis (e.g., a discrete policy field that distinguishes freight from inventory from services approval chains) is described only in general 'policy-based rules' language and is not documented at the mechanism level with a named configuration object.

Limitations: The spend category dimension required by this buyer (separate chains for freight, inventory replenishment, and services) is not confirmed as a discrete, first-class routing attribute in Tipalti's approval policy builder; the documented axes are department, budget level, and location, which may require workarounds such as using separate form types or custom fields to approximate category-based routing. Real-time inline budget remaining is confirmed only for NetSuite users, which matches this buyer, but the depth of encumbrance or budget-consumption logic (e.g., whether committed-not-yet-invoiced spend is deducted from the remaining balance shown to approvers) is not documented.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a distribution company on NetSuite whose three-way match is broken, Tipalti's PO Matching module addresses the tolerance and routing requirement in meaningful but incomplete ways. On tolerance, administrators can create tolerance thresholds based on amounts or percentages at the bill or line level, so invoices are still considered matched if they are within the threshold; discrepancies in quantity, price, or value that fall within the set tolerance range result in automatic approval without manual intervention, while those that exceed the range are flagged for further review. On exception routing, Tipalti's matching exception console streamlines exception reconciliation by enabling the user to view PO and bill lines side-by-side and drag-and-drop line items; and customizable exception rules route invoices that cannot be auto-matched based on the established tolerance ranges to ensure fast approvals. The product page documents clear highlights of exceptions, where they occur, and steps to resolve them, along with the ability to configure exception approval rules so the buyer can approve or reject directly via email. However, the documented side-by-side console covers PO and bill lines; explicit evidence of a simultaneous three-document view (PO line vs. goods-receipt line vs. invoice line in a single pane showing which of the three diverges) is absent from available documentation, as is evidence of tiered escalation logic that routes small variances to an AP clerk, larger variances to a procurement manager, and the largest to a CFO based on dollar thresholds.

Limitations: The material ceiling for this buyer is the exception context depth: Tipalti documents configurable tolerance thresholds and email-based exception approval routing, but the documented matching exception console appears to compare PO and bill lines rather than presenting all three documents (PO, GRN, invoice) simultaneously with per-document delta attribution; there is also no documented evidence of tiered role-escalation by variance magnitude, meaning large and small exceptions may route through the same handler path rather than auto-escalating up the authority chain.

Buyer requirement: Approval routing must operate across all 14 NetSuite OneWorld subsidiaries from the shared-services AP team while enforcing per-subsidiary book isolation: approvers in Subsidiary A must not be able to view, act on, or influence invoices belonging to Subsidiary B's books unless explicitly granted cross-entity access. The routing architecture must support threshold-based and context-aware chain adaptation (by subsidiary, GL account, or cost dimension) so that the correct entity's controllers and budget owners are engaged at the cost-allocation and terms-verification stages without manual queue management by the AP team.

For a shared-services AP team operating across 14 NetSuite OneWorld subsidiaries, Tipalti structures entity separation through its payer entity model: each Tipalti payer entity maps to a distinct NetSuite subsidiary, and each entity can be configured with its own AP processes and workflows. At the data level, subsidiary book isolation is enforced by requiring that all bill field values (GL accounts, departments, classes, custom fields) match the subsidiary assigned to the bill in Tipalti before a sync to NetSuite will succeed. On the approval side, the documented mechanism in the Bills module is manual approver selection: the AP processor chooses one or more approvers from the 'Bill approver(s)' field per bill, and those designated approvers receive an email notification to action the bill. A 'Segment rules' and 'Approval flow' feature is documented in Tipalti's newer Procurement module for purchase requests, which suggests some rules-based routing capability exists in the platform, but no help-center documentation confirms that automated threshold-based or context-aware approval chain adaptation (triggering subsidiary-specific controllers and budget owners based on invoice amount, GL account, or cost dimension) is available for AP bills without manual AP team selection. The 'Switch entities with multi-instance setup' navigation structure further indicates that cross-entity visibility for approvers is managed by explicit entity-context switching rather than a unified queue with row-level subsidiary permission enforcement.

Limitations: The buyer's core ask, fully automated approval routing that engages the correct subsidiary controllers and budget owners based on threshold, GL account, or cost dimension without manual AP team queue management, is not evidenced for the AP bills workflow in Tipalti's help-center documentation; the documented mechanism is manual per-bill approver assignment. Per-subsidiary approver isolation (preventing an approver in Subsidiary A from seeing Subsidiary B's bills) is not explicitly documented at the row-level in a shared bills queue, which is a material gap for a SOX-controlled 14-subsidiary shared-services operation.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a $120M multi-location services company running 1,800 invoices per month across 2 Sage Intacct entities, Tipalti's approval architecture spans two distinct modules: the Bills module (covering non-PO invoices, roughly 45% of this buyer's volume) with a dedicated 'Bill routing' configuration layer, and the Procurement module's Advanced PO Approval Workflows (covering the 55% PO-backed volume). On the PO side, workflows are configurable by budget level, department, and location, with unlimited budget owners and parallel approval support for simultaneous multi-stakeholder review. On the invoice side, the Approval Routing AI determines the correct approver based on factors including amount, department, and vendor type, and applies company-specific rules to handle both simple and complex approval flows. The Sage Intacct integration is confirmed as a named partnership: the solution captures bills with OCR and machine learning including advanced approval rules, 2-way and 3-way PO matching, and syncs with Sage Intacct. Tipalti's help center confirms 'Bill routing' and 'Matching policies' as distinct named configuration sections within the Bills module (from vendor help center navigation, help.tipalti.com), and approval routing happens automatically based on custom logic tied to the organizational chart, budget lines, and policy-based rules, with approvers able to loop in finance, IT, or legal mid-process. The gap for this buyer is that while dollar threshold, department, vendor, and entity/location are confirmed routing dimensions, GL account, expense type, and project as independent routing trigger conditions in the Bills module are not explicitly confirmed in documentation: these fields appear as AI auto-coding targets rather than as discrete routing rule conditions, and there is no documented evidence of AND/OR compound logic stacking multiple attributes simultaneously within a single bill routing rule.

Limitations: The buyer requires routing by 7 distinct attributes simultaneously (dollar threshold, department, GL account, vendor, entity, expense type, and project); Tipalti's documented routing conditions cover amount, department, vendor type, entity, and location clearly, but GL account and project as routing triggers in the non-PO Bills module are not confirmed in available documentation, and compound multi-attribute AND/OR rule logic within a single routing policy is not evidenced, meaning complex cross-cutting rules like 'GL 6200 AND entity B AND amount over $10K routes to the CFO' may require workarounds or Tipalti implementation team configuration rather than self-service rule building.

Buyer requirement: Approval routing must be conditional on two independent variables simultaneously: the legal entity on the invoice (US parent or either UK subsidiary) and the invoice amount threshold, producing different approval chains for each entity-threshold combination. The routing engine must support mid-flow context-aware branching so that a UK invoice above a defined threshold follows a different chain than a US invoice at the same amount, without requiring separate workflow configurations for every permutation.

For a 3-entity services company (US parent plus 2 UK subsidiaries) needing entity-plus-amount combinatorial routing, Tipalti addresses the requirement through entity-scoped approval rule sets rather than a single compound-condition engine. Each payer entity in Tipalti operates as its own workflow container: the multi-entity architecture lets administrators configure entity-specific approval processes and workflows per subsidiary (support.tipalti.com Administrative Operations; tipalti.com/ap-automation/multi-entity/). Within each entity's scope, the Bill Approval Rules engine (Administration > Bill settings > Bill approval rules) allows configuring approval chains conditioned on amount thresholds and custom fields, and Tipalti's role-based access support enables payment approval rules based on conditions including payment amount (tipalti.com/faqs/). The practical result is that a UK subsidiary invoice above a defined threshold does follow a different chain than a US invoice at the same amount — but this is achieved by maintaining separate per-entity approval rule configurations, not by a single workflow definition that evaluates entity as a co-equal mid-flow branching variable alongside amount. This is architecturally the entity-scoped separate rule-set pattern the buyer's requirement explicitly wanted to avoid, even though all entities are managed within one unified Tipalti Hub console.

Limitations: Tipalti's approval architecture makes the legal entity the structural container for routing logic, not a runtime condition within a shared rule engine: administrators must configure amount-threshold approval chains inside each entity's settings separately, which is the 'separate configuration per entity' pattern the buyer's requirement explicitly excluded. There is no documented mechanism for a single rule definition that evaluates entity context AND amount simultaneously as co-equal AND-joined conditions to produce a unified combinatorial approval matrix without per-entity rule maintenance.

Buyer requirement: For non-PO invoices, the solution must support a department-initiated coding and pre-approval workflow where the department owner can code, annotate, and approve their portion of an invoice before it reaches the central AP team, matching the buyer's described split where departments manage their invoices and hand off ready-to-code items to AP. This covers pre-processing stage 5 (cost allocation) and must preserve all department-entered dimension values when the record is handed to AP and subsequently posted to SAP S/4HANA.

This buyer routes roughly 6,000 non-PO invoices per month through department owners who code, annotate, and approve before handing off to central AP. Tipalti's 'Invoice Processing' bill flow supports this split: invoices enter a 'Pending review' queue where AP or a designated approver can code dimensions, and the record then routes to bill approvers before moving to payment. The platform's Bill Coding Preferences feature is explicitly scoped to non-PO-backed bills, allowing administrators to define which GL accounts and custom fields (department, location, cost center, project, expense account) are mandatory, at which stage they must be filled, and whether bill approvers can edit them. Auto-Coding AI learns coding patterns at header and line-item level, including those custom fields, reducing manual entry before the record reaches department approvers. Tipalti Comments lets approvers tag colleagues and attach documents inside the platform, and approvers can act via email without logging in, which covers the annotation and collaboration requirement. For SAP S/4HANA, Tipalti documents that it syncs 'suppliers, purchase orders, receiving data, supplier invoices, payables, account coding, payments, and supplier credits,' and its general custom-field mapping framework carries dimension values into the ERP on sync. The material gap is routing architecture: Tipalti's documented bill approval policies route bills to assigned bill approvers after AP review, but there is no documented mechanism for a department owner to initiate coding and pre-approve their portion of an invoice before it ever touches central AP. The flow is AP-first (AP reviews, then routes to approvers), not department-first (department codes and pre-approves, then hands off to AP). This inverts the buyer's described sequence at pre-processing stage 5, where the department owner acts before AP, not after. Additionally, the SAP S/4HANA integration documentation describes data sync at a category level but does not confirm that SAP-specific dimensions such as profit centers, WBS elements, or internal orders are individually mapped fields, introducing ERP fidelity risk for an S/4HANA environment.

Limitations: The approval architecture routes AP as the first actor and department approvers as downstream reviewers, which is the reverse of the buyer's department-initiated pre-approval model; implementing Tipalti as-is would require AP to touch every non-PO invoice before the department owner acts, preserving rather than eliminating the bottleneck. The SAP S/4HANA integration's dimension fidelity for S/4HANA-specific fields (profit center, WBS element, internal order) is not explicitly confirmed in available documentation, creating downstream posting risk.

Buyer requirement: The approval workflow must support a configurable 2-step sequential routing chain with per-step delegation rules, so that an approver can assign a named substitute without breaking the chain or requiring AP staff to manually reroute. Auto-escalation on timeout must be included so that the 1,200 monthly invoices do not stall silently when an approver is unavailable. This covers stages 2 and 3 of the pre-processing journey (PO match confirmation and terms verification by the appropriate role).

For a mid-market manufacturer processing 1,200 invoices per month on Sage Intacct, Tipalti's Bills module supports a sequential multi-step approval chain: once the first approver acts, the system automatically sends the bill to the next approver in the assigned sequence, covering stages 2 and 3 of the pre-processing journey (PO match confirmation and terms verification). The bill then goes to the next level for approval if more than one approval is required, or moves to 'Pending payment' once all approvers have acted. Tipalti uses AI-driven routing that automatically directs invoices to the right approvers based on organizational structure, and custom approval flows can be configured at both header and line-item levels. For escalation, the Bills module includes an 'Escalate bills to' configuration: if escalation settings are enabled, you can select an 'Escalate bills to' checkbox and assign a named manager from a dropdown, where the manager must have an approval limit greater than the approver being configured. However, this escalation is amount-threshold-based, not timeout-based. The 'Remind approver' action exists but is manually triggered by AP staff: from the bill list, AP can select 'Remind approver' for the 'Invoice processing' or 'Self-billing with internal approval' flows, meaning invoices do not automatically reroute or advance on timeout without AP intervention. Per-step named substitute delegation for bill approvers is not documented as a self-service approver action; a third-party review notes that approval delegation functionality is limited, requiring admin involvement to reassign approvals when users are unavailable rather than allowing self-managed delegation. The role-based access model does confirm conditional multi-approver rules: Tipalti has role-based access support, letting companies set rules for who can approve payments and if multiple people are required based on conditions such as payment amount.

Limitations: The two safeguards the buyer specifically requires to prevent stall across 1,200 monthly invoices are not fully documented: timeout-based auto-escalation that automatically reroutes a bill when an approver is unavailable is absent (only a manual 'Remind approver' action exists), and per-step named substitute delegation that approvers can self-configure without AP staff involvement is not documented for the Bills module. Both gaps mean AP staff must manually intervene when an approver is unreachable, which is precisely the scenario the buyer is trying to eliminate.

Buyer requirement: For the roughly 1,050 non-PO invoices processed each month (the remaining 30% of 3,500), the system must support AI-assisted GL coding and cost allocation routing to the appropriate budget owner for approval, since these invoices do not have a PO or GR document to anchor a 3-way match. The coding model must suggest SAP cost objects (cost center, GL account, plant) based on vendor history and invoice content, and must route to the correct budget owner based on the suggested cost allocation rather than defaulting to a fixed AP-team approval chain.

For the 1,050 monthly non-PO invoices arriving at this manufacturer, Tipalti's Auto-Coding AI handles stage 5 of the pre-processing journey (cost allocation) through its Smart Scan and auto-coding engine. Tipalti's AI automates coding by recognizing consistent coding patterns at the header and line-item levels, including custom fields like department, location, tax codes, and expense accounts. Tipalti's Auto-Coding AI predicts the correct GL for each line with up to 95% accuracy and also learns to predict other bill fields including cost centers, expense accounts, location, projects, and departments. Non-PO invoices are recognized as a distinct path: the system lets you set up rules to determine if an invoice is PO-backed and if it should go through the matching process, routing non-PO invoices to a coding-and-approval flow rather than a match flow. On the approval side, AI-driven routing automatically directs invoices to the right approvers based on your organizational structure, with custom approval flows configurable at both header and line-item levels. The system routes invoices to the right stakeholders for approval based on rules and context, and the AI also learns from past activity to recommend faster, more accurate approval paths. For SAP S/4HANA, Tipalti syncs data with SAP S/4HANA ERP for suppliers, purchase orders, receiving data, supplier invoices, payables, account coding, payments, and supplier credits, and Tipalti helps SAP S/4HANA clients strengthen controls and accelerate visibility, with advanced sync logic that ensures entity-specific sub-ledgers are accurately synced in real time. However, two material gaps prevent a 'supported' rating for this specific requirement. First, no Tipalti documentation confirms that 'plant' (an SAP MM organizational dimension this manufacturer will need for cost object completeness) is among the synced or suggested dimensions; Tipalti names cost centers, departments, locations, and GL accounts but not plant codes. Second, approval routing happens automatically based on custom logic tied to the organizational chart, budget lines, and policy-based rules, which describes configuration-time rule mapping, not a runtime resolution of the budget owner from the AI's suggested cost center against SAP cost center master data. The buyer's requirement is that the approver is determined at runtime by following the suggested cost allocation back to its owner in SAP's CO hierarchy, rather than by a pre-configured vendor-to-approver rule; this dynamic resolution mechanism is not documented.

Limitations: Tipalti does not document 'plant' as a suggested SAP cost object dimension, which is a gap for a manufacturer whose non-PO spend must be coded to the correct plant before posting. More critically, approver resolution appears to be driven by pre-configured organizational rules rather than a runtime lookup against the SAP cost center hierarchy, meaning the buyer would need to manually maintain an approver-to-cost-center mapping in Tipalti rather than inheriting it dynamically from SAP CO master data; any cost center hierarchy change in SAP would require a parallel update in Tipalti's routing configuration.

Buyer requirement: Approval routing must be configurable per entity so that each of the 8 real estate entities can enforce its own chain of approvers, spending thresholds, and GL-account-based escalations, all within a single AP workflow managed by the 4-person team. Stage 5 of the pre-processing journey (cost allocation sign-off) requires that budget owners see only the invoices and dimensional data belonging to their entity: role-based, entity-scoped visibility controls are required so one entity's approvers cannot view or act on another entity's payables.

For a portfolio operator running 8 separate real estate entities, Tipalti's Multi-Entity module addresses this requirement directly at pre-processing Stage 5 (cost allocation sign-off). The core mechanism works as follows: each of the 8 entities is configured as a separate subsidiary in Tipalti, and the system enforces entity-scoped user access by design. As documented in Tipalti's 2021 Multi-Entity launch, 'users can only view and process invoices for the entities they manage, keeping them focused on their own bill data' (BusinessWire / CPA Practice Advisor). This means an approver assigned to Entity 3 (residential) cannot see the invoice queue for Entity 7 (commercial) at all. User assignment to specific entities is handled through role-based access controls: the platform lets administrators 'secure financial data by separating payables by entity and assigning users to specific entities' and 'grant users access to different entities based on their roles and responsibilities' (tipalti.com/ap-automation/multi-entity/). On top of that visibility firewall, each entity maintains its own independently configured approval chain. Tipalti documents 'entity-specific workflows for payment methods, approval processes, reconciliation, and reporting,' and the Sage Marketplace product listing confirms that 'machine learning drives approval sequences based on criteria, such as supplier and GL account,' which directly supports the GL-account-based escalation requirement. Spending threshold routing is confirmed across multiple sources: 'thresholds for amounts that trigger different approvers' are configurable within the workflow rules engine (Versich integration guide). The 4-person central AP team retains a consolidated headquarters view for payment release, while entity approvers operate within their scoped queues. The mechanism covers Stage 5 (budget owner sign-off with entity-scoped dimensional data) and the full approval chain architecture (threshold-based, GL-based, and role-based routing), all within one platform.

Limitations: Tipalti's multi-entity architecture is optimized for separate legal entities with separate books; full integration fidelity for all 8 entities requires NetSuite OneWorld (not standard NetSuite) on the ERP side, since the Tipalti-NetSuite sync routes journal entries to entity-specific sub-ledgers. If the buyer migrates to NetSuite on a single-company plan rather than OneWorld, entity-level GL segregation at the ERP layer will be incomplete, regardless of Tipalti's own entity isolation. The GL-account-based escalation capability (approval chain changes based on GL code mid-workflow) is documented via the Tipalti Pi / ML-driven routing engine, but configuring that granularity across 8 entities with distinct charts of accounts requires careful implementation work and should be validated during a scoped demo.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a 3-person AP team at a $120M services company running bi-weekly check runs and monthly ACH batches, Tipalti enforces payment batch authorization at the system level before funds move. Once an AP user uploads or submits a payment batch, the batch enters a hold state and cannot be released to the bank or payment rails until a designated approver acts: "upon uploading a payment batch to Tipalti, the payer has to approve it, unless you have a no-approval workflow." The CFO or Controller is configured as a named payment approver; a dedicated 'Pending my approval' view in the Tipalti Hub surfaces queued batches specifically for Controllers, CFOs, and other finance managers, and approval rules are set up to assign specific users as payment approvers by contacting the Tipalti implementation team. Payment instructions are first submitted to Tipalti, then validated before going through payer and payment provider approval processes, with payers notified of payment success or failure upon release. This operates at the payment batch stage, after invoice-level approvals are already complete, making it a genuine second authorization gate that enforces segregation of duties between the AP processor who submits and the senior finance officer who authorizes disbursement. Tipalti's approval logs track the who, what, and why of approvals, providing comprehensive documentation for audit purposes.

Limitations: Configuration of approval rules and designated approver assignments requires coordination with Tipalti's implementation team rather than self-service admin setup, which adds a change-management step if the buyer needs to reassign the CFO or Controller role during staff transitions. The documentation does not confirm whether multi-tier sequential payment approval (e.g., Controller approves first, then CFO approves second on batches above a dollar threshold) is self-configurable or must be requested through Tipalti support.

Buyer requirement: The solution must support dynamic approval routing that can be configured by NetSuite department, class, or project segment, allowing entertainment production budgets and overhead spend to follow separate approval chains, with role-specific invoice data visibility so that approvers see only the entities and cost centers they are authorized to approve.

For an entertainment business running NetSuite, Medius imports all coding dimensions directly from NetSuite during onboarding, including both standard dimensions (department, class) and custom dimensions such as project. The structure of coding dimensions, including both standard and custom dimensions, is determined during the data gathering phase of the customer onboarding process, and Medius imports all coding dimensions directly from Oracle NetSuite. Once those dimensions are live in Medius, administrators configure approval rules against any chosen dimension as the "approval object": approval rules in MediusGo are set up in different roles based on a coding dimension, which dimension you use as approval object you choose in the Coding String. This means a production budget invoiced against a specific NetSuite project or class can be routed to a separate approval chain from overhead spend coded to a different department, with each chain carrying its own amount thresholds and role assignments. Special approval rules are not controlled by the approval object dimension, but rules can be created freely on all dimensions of the coding string; they are used to assign a user or role a unique approval right for a given combination of, for example, account and cost center. For role-specific data visibility, each dimension can be flagged to "Filter the coding values depending on role settings," and then under Organisation-Roles each role is given coding rights restricted to only the values in that dimension that the role is authorized to see and use. This means a production approver only sees project codes or cost centers within their scope, satisfying the entity- and cost-center-level access control the buyer requires. Approvals are assigned automatically based on role, spend threshold, cost center, and entity, and routing rules reduce ambiguity and remove dependence on individual knowledge.

Limitations: The standard approval object is configured as a single primary dimension per coding string setup; separating production-budget and overhead chains simultaneously across all three dimensions (department, class, and project) requires layering standard approval rules with special approval rules, which demands careful configuration during implementation. If you use something other than Account, such as Cost Center or Department, as an approval object, you need to decide how rows that do not have an approval object value should be handled, meaning any invoice line missing a value in the routing dimension must have a fallback rule explicitly defined to avoid unrouted exceptions.

Buyer requirement: Approval workflows must route invoices to approvers scoped to the correct production, so that approvers from one production cannot approve invoices belonging to another, and approval chains can be configured independently per production. The routing logic must respect the same profit-center-based isolation that governs invoice visibility, ensuring the approval stage does not create a cross-unit exposure that the visibility layer prevents at the inbox stage.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, Medius implements per-production approval scoping through its dimension-based approval rules engine, with no multi-entity structure required. Approval authority in Medius is attached to roles at the coding-dimension value level: each role is granted approval rights on specific coding values (e.g., the cost center or department code corresponding to a given production), and the system enforces those boundaries at the row level during approval. As the MediusGo portal documents, approval rules in MediusGo are set up in different roles based on a coding dimension, and if the approval box is gray, this means that you do not have permission to approve that row. This is the enforcement mechanism: a Production A approver's role carries approval rights only on Production A's coding dimension values; when an invoice coded to Production B reaches the shared AP queue, the Production A approver is systemically blocked at the row level, not just by convention. Beyond standard approval rules, in addition to the ordinary approval rules, which are based on one or more approval-controlling coding dimensions, there is the possibility of administering special approval rules; a special approval rule means that for a certain unique combination of account and coding dimensions, a user or role can be assigned a unique approval right. This allows per-production approval chains to be configured independently, including distinct amount thresholds and multi-level hierarchies per production. Medius offers multiple ways to automate approval flows, including creating authorization groups per vendor, using the reference field on the invoice to identify the first approver and routing according to the default authorization hierarchy, creating unique business logic to ensure invoices route to the correct approver, and applying different approval flows for each invoice line so that invoices can be distributed to multiple approvers simultaneously with each seeing only the cost they are responsible for. The Sage Intacct integration syncs chart-of-accounts and dimension data into Medius's coding string, meaning Sage Intacct profit center codes feed directly into the routing rules without manual re-entry. This operates at pre-processing stage 5 (cost allocation and approval), covering the full approval stage of the pre-processing journey within a single-entity structure that preserves the consolidated payment run.

Limitations: The dimension-based enforcement applies at the coding row level; an approver with a production-scoped role cannot approve rows coded to another production, but an administrator-level user retains cross-company visibility by design, so role governance at the admin tier must be configured carefully to close that potential cross-unit exposure. The per-production approval chain configuration requires initial setup of separate roles and coding value assignments for each of the 9 productions, and any profit center code changes in Sage Intacct must be resynchronized to Medius to keep routing rules current.

Buyer requirement: Approval routing for purchase requests and POs must dynamically assign approvers based on spend category, dollar threshold, and department, supporting the mid-market distribution context where different categories of operational spend (freight, inventory replenishment, services) may have different approval chains. Approvers must see the remaining budget for the relevant cost center or department at the time they act, not just the request amount in isolation.

For a distribution company on NetSuite with varied operational spend categories, Medius Procurement (the requisition and purchasing module) supports configurable approval workflows where approvers are assigned based on department and dollar threshold: policy enforcement occurs automatically within the workflow, and approvals are routed based on entity, department, or spend threshold. Budget visibility for approvers is addressed at the product level: the system can enforce a hard stop at checkout, or allow spend to continue with additional approval through the workflow, and budget holders can approve/reject spend and view how much budget is spent within their scope. However, the specific requirement for distinct approval chains by spend category (freight vs. inventory replenishment vs. services) is documented for the Contracts module, where the system has a highly configurable contract structure and flexible approval rules on any number of criteria such as user permissions, business entity, value thresholds, category and contract strategic importance, but equivalent per-category routing for purchase requisitions is not explicitly confirmed in available product documentation. The inline budget display mechanism is described at a marketing level for budget holders, but granular documentation confirming a live, real-time pull of NetSuite encumbrance or remaining-budget data surfaced in the approver action screen at the moment of decision was not found.

Limitations: The category dimension of approval routing (freight, inventory, services each getting a distinct chain) is clearly documented for Medius Contracts but not confirmed at mechanism depth for purchase requisitions, meaning this buyer may need to rely on department or account coding as a proxy for category rather than a true category-keyed rule. The real-time budget-remaining display for approvers is stated as a capability for budget holders within scope, but the source of that data in a NetSuite integration context and whether it reflects live encumbrances inline at the approval moment versus a separately navigated dashboard is not documented with sufficient precision to confirm the full requirement is met.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a mid-market distributor on NetSuite whose three-way match today is broken by missing receiving records, Medius addresses both halves of this requirement: tolerance-based auto-approval and defined-handler exception routing. On the tolerance side, Medius exposes configurable 'Deviation Tolerances' and 'Connection Tolerances' at the company and supplier level, set as either a flat amount or a percentage, with separate limits for positive and negative deviations; invoices whose variances fall within those bands are auto-approved and flow straight to ERP posting without human touch. On the exception-routing side, the platform's standard 'Analyze' workflow stage receives every invoice with an out-of-tolerance deviation, routes it to the responsible user with full context across the PO, goods receipt, and invoice documents, and surfaces unit price deviations and quantity deviations as distinct line-level fields so the handler can see exactly which document diverges and by how much. A 'Show goods receipt deviation first' toggle additionally lets the buyer prioritize missing-GR exceptions over price deviations, routing them sequentially rather than simultaneously. The three-way matching rules and tolerances live in Medius rather than in NetSuite's native logic, and Medius connects to NetSuite via a pre-packaged connector.

Limitations: The buyer must align tolerance settings in both Medius and NetSuite; if NetSuite's own matching thresholds are tighter than what Medius approves, invoices can re-queue for manual attention inside the ERP after Medius has already cleared them, creating a dual-approval burden that requires configuration discipline at go-live.

Buyer requirement: Approval routing must operate across all 14 NetSuite OneWorld subsidiaries from the shared-services AP team while enforcing per-subsidiary book isolation: approvers in Subsidiary A must not be able to view, act on, or influence invoices belonging to Subsidiary B's books unless explicitly granted cross-entity access. The routing architecture must support threshold-based and context-aware chain adaptation (by subsidiary, GL account, or cost dimension) so that the correct entity's controllers and budget owners are engaged at the cost-allocation and terms-verification stages without manual queue management by the AP team.

For your 14-subsidiary NetSuite OneWorld environment, Medius operates what it calls entity-aware routing: the platform's 'company' object maps to each legal entity, and roles are scoped per company so that a user assigned only to Subsidiary A's company record cannot act on invoices belonging to Subsidiary B. Each company to which a role belongs can be assigned different characteristics and permissions, and approval rights are granted at the role/company level, creating the per-entity isolation wall. On top of that access layer, dynamic routing in Medius handles approvals by entity, spend type, threshold, or cost center, with changes made through configuration rather than code, satisfying the requirement for threshold-based and context-aware chain adaptation. Invoices are captured, matched, routed, and approved through a central platform that supports entity-aware rules, meaning each legal entity can maintain its own approval hierarchies while still following a standardized workflow that provides audit-ready visibility across the entire organization. The routing model covers stages 3 (terms verification) and 5 (cost allocation) of the pre-processing journey: the approval dimension drop-list controls which dimension values (GL account, cost center, project) a role may approve, with configurable amount limits per value, so the correct entity controller and budget owner are automatically engaged at each stage without AP manually managing queues. Routing logic standardized by role, spend threshold, and entity restores predictability, and embedded SLA expectations with escalation paths prevent invoices from stalling without visibility.

Limitations: Public documentation confirms the role/company scoping architecture as the isolation mechanism, but does not explicitly describe a hard data-visibility block preventing a cross-entity read at the invoice-detail level; a SOX audit will require your implementation team to verify during a proof of concept that Subsidiary B's invoices are not readable (not just non-routable) by Subsidiary A approvers. Virtual company scenarios may require the REST API rather than the FX connector for full flexibility, adding integration complexity for a 14-subsidiary OneWorld setup.

Buyer requirement: The approval routing engine must support multi-level, configurable chains that can adapt based on legal entity, financial dimension values, invoice amount thresholds, and vendor attributes across the three legal entities, so that each entity's approval hierarchy is enforced independently within a shared workflow system. The engine must also support delegation and auto-escalation on timeout, since approvers who work primarily in Teams may be unavailable and the workflow must not stall at a single point.

For a three-legal-entity D365 Finance environment, Medius builds its approval routing engine on dimension-aware approval rights configured at the role level: each role is assigned a set of coding dimension values (GL account, cost center, department) it may approve, together with a general approval amount and a maximum per-invoice amount threshold. The approval hierarchy takes effect when multiple roles are authorized on the same coding value at different amount limits, so a lower-amount role triggers automatic escalation to the next tier. In addition to ordinary approval rules, special approval rules allow approval rights to be set on a combination of coding dimensions, enabling vendor-specific or cross-dimension routing logic. Medius's platform supports entity-aware rules so each legal entity can maintain its own approval hierarchies while following a standardized workflow that provides audit-ready visibility across the organization. For approver unavailability, Medius provides a temporary delegation feature that automatically kicks in on the day an approver leaves and reverts tasks when they return, with an admin override option for unplanned absences. Approvals are assigned automatically based on role, spend threshold, cost center, and entity, and routing rules are configured without custom code. Approvers receive reminders before an SLA expires, with escalation paths triggered when deadlines are missed, keeping invoices moving even when key approvers are unavailable. However, the buyer requires approvers to act from Microsoft Teams without logging into a separate system. Medius documents an 'actionable emails' feature that allows approvers to approve or reject invoice lines with comments directly from Outlook, without logging into the application, using O365 authentication — but no Medius-native Teams app or Teams adaptive card that surfaces approval actions inside the Teams interface was found. The platform's mobile capability and actionable email channel cover the 'no separate login' intent for Outlook users, not Teams-channel-first users.

Limitations: The material ceiling for this buyer is the Teams-native approval action surface: Medius's documented frictionless-approval channel is Outlook actionable emails (O365 auth, approve/reject in inbox), not a Teams bot or adaptive card that lets approvers act inside a Teams channel or chat without any redirect. For a team that lives primarily in Teams rather than Outlook, the approver experience requires either navigating to the Medius portal or switching to Outlook, which partially undermines the buyer's collaboration model. Additionally, while SLA-based escalation reminders are described at the marketing/blog level, the configuration mechanism for timeout-triggered escalation (as distinct from delegation) is not as granularly documented as the approval hierarchy itself.

Buyer requirement: Approvers must be able to receive, review invoice details and coding, and take approval actions (approve, reject, request information, delegate) directly within Microsoft Teams, without being required to authenticate into a separate AP portal or web application. The Teams-native experience must surface the full invoice image, line-level coding, and any attached supporting documents so that approvers can make informed decisions without context-switching, addressing stage 5 approval routing in the buyer's primary collaboration environment.

For this buyer's Microsoft-centric organization, where approvers must act entirely within Teams without authenticating into a separate system, Medius's documented approval channel is its own browser-based web portal and a mobile-responsive web UI. The Microsoft AppSource and Azure Marketplace listings for Medius AP Automation for Dynamics 365 Finance describe the approver access model as an 'intuitive mobile solution for buyers to easily and quickly approve invoices from anywhere, at any time,' and the Medius Customer Center describes 'actionable emails for approvers' as the notification and action path. No Microsoft Teams app, Teams bot, Adaptive Card integration, or Teams-channel action surface appears in any Medius product documentation, AppSource listing, or help content. The reference to 'Teams' in one Medius life-hacks article points approvers to Microsoft's own documentation on creating Teams channels, confirming it is a user communication guidance tip, not a product integration. Medius Copilot, the AI assistant that guides approvers through invoice decisions, is documented as operating inside the Medius web application, not inside Teams.

Limitations: Approvers at this D365 Finance organization would need to leave Microsoft Teams, authenticate into the Medius web portal, and complete their review and action there: precisely the context-switching the buyer's requirement rules out. No Teams Adaptive Card mechanism, delegation action, or request-information action within Teams is documented; the gap is architectural, not configurable.

Buyer requirement: Approval routing must be configurable to route each invoice line, or a split-coded invoice, to the owner of the specific dimension values coded on that line (e.g., the project manager for the project dimension, the department head for the department dimension), not just a fixed sequential chain applied at the invoice header level. This satisfies stage 5 of the pre-processing journey: the budget owner, not AP, must validate cost allocation, and that owner is determined by the dimension values on each line.

For a multi-entity SaaS company on Sage Intacct with heavy dimensional coding, Medius addresses stage 5 of the pre-processing journey (budget owner cost allocation validation) through a dimension-value-to-approver mapping architecture built into its approval rules engine. Administrators configure an 'approval object' dimension on each role: approval rules in MediusGo are set up on roles based on a coding dimension, and 'the approval rules are based on the invoice's coding and it is coding rows with amounts that are approved.' Roles are then granted rights against specific values within that dimension, and on the user form it is possible to specify dimension values linked to users, so invoices coded with those values have the connected user proposed as the recipient, and if invoices are posted via coding suggestions, they are sent directly to that user. For more complex dimension combinations (e.g., project + cost center together), Medius supports 'Special Approval Rules': special approval rules are 'not controlled by the approval object dimension, but rules can be created freely on all dimensions of the coding string,' and they are used to assign a person who normally has a lower approval amount on an account, a higher approval amount for a given combination of, for example, account and cost center. Approval happens at the coding row level, not just the invoice header: approvers open the invoice and mark the box in column A on each coding row; if the approval box is gray, 'this means that you do not have permission to approve that row.' However, the routing model operates primarily as sequential row-by-row forwarding within a single invoice rather than as a native parallel fork that simultaneously dispatches each line to its respective dimension owner: when approval rights are missing on one or more coding rows, the approver must open the invoice, check only the rows they can approve, and 'click Forward and select another recipient in the approval step who can approve the other rows.' There is no documented evidence of automatic resolution of approvers from Sage Intacct's own dimension master data fields (e.g., pulling the Intacct project manager field to auto-populate the approver); the dimension-to-approver mapping must be configured and maintained within Medius's own administration tool.

Limitations: The approval object architecture typically designates one dimension as the primary routing driver per role, and while Special Approval Rules allow multi-dimension combinations, this buyer's requirement for dynamic resolution of approvers from Intacct's dimension master data (project manager field, department head field, custom dimension owner) is not confirmed: approver-to-dimension mapping must be replicated and maintained inside Medius independently of Intacct's own ownership records. Additionally, the routing model for split-coded invoices is sequential pass-the-invoice forwarding rather than a true parallel dispatch, meaning a five-dimension invoice with five distinct owners cannot simultaneously route each line to its owner; each approver must handle their rows and forward the invoice to the next, adding cycle time and manual coordination for complex cost allocations.

Buyer requirement: Approval workflows must route invoices to approvers scoped to the correct production, so that approvers from one production cannot approve invoices belonging to another, and approval chains can be configured independently per production. The routing logic must respect the same profit-center-based isolation that governs invoice visibility, ensuring the approval stage does not create a cross-unit exposure that the visibility layer prevents at the inbox stage.

For a media production company running 9 profit centers inside one Sage Intacct legal entity, AvidXchange's AvidInvoice module uses a departmental workflow model as the primary isolation mechanism: administrators configure separate workflow templates and approver role groups per department (or, in the property management analog, per property), and the platform routes each invoice to the correct queue based on how the invoice is coded. The official AvidXchange workflow blog documents this directly: roles can be defined by each department, which simplifies routing; with departmental setup, a department can only see invoices sent to that department, not others in the company. This covers pre-processing stage 5 (cost allocation routing) and the approval handoff at stage 3 (contract/coding verification). The property management customer story is the closest structural analog to this buyer's scenario: a 100-property operator reports that 'indexing between AvidInvoice and [their ERP] because we have 100 properties — all that indexing goes to each of their workflows and approval processes,' and they execute payment as a single consolidated batch: AvidPay allows the team to 'pay all their invoices in a batch by uploading a single file instead of 20 for each property,' preserving centralized payment runs. The AvidInvoice permissions system provides the administrative foundation: the application is configured with default roles that correlate to specific permissions, designed to give the Portal Administrator full control over what business functions should be enabled or restricted from internal users. Routing rules extend to department, GL account, invoice amount, and vendor: teams can configure approval paths based on business rules such as invoice amount, vendor type, cost center, department, or GL account.

Limitations: The documented isolation mechanism is queue-based routing with departmental visibility scoping, not a hard engine-level prohibition on cross-unit approval authority: AvidXchange's own documentation describes the protection as 'your department can only see invoices sent to your department,' which means isolation depends on correct invoice coding and queue routing rather than a systemic block that prevents a Production A approver from taking action on a Production B invoice even if the coding is wrong or an admin reassigns the invoice. Additionally, no source confirms how Sage Intacct's profit center dimension specifically flows into AvidXchange's routing rules, leaving a configuration risk that must be resolved during implementation.

Buyer requirement: Approval routing must operate across all 14 NetSuite OneWorld subsidiaries from the shared-services AP team while enforcing per-subsidiary book isolation: approvers in Subsidiary A must not be able to view, act on, or influence invoices belonging to Subsidiary B's books unless explicitly granted cross-entity access. The routing architecture must support threshold-based and context-aware chain adaptation (by subsidiary, GL account, or cost dimension) so that the correct entity's controllers and budget owners are engaged at the cost-allocation and terms-verification stages without manual queue management by the AP team.

For a shared-services AP team managing 14 NetSuite OneWorld subsidiaries, AvidXchange's AvidInvoice workflow engine supports configurable approval routing with threshold-based (dollar amount) and attribute-based rules keyed to department, GL account, vendor type, and cost center. Its documented portal-level isolation model operates at the department level: "with departmental set-up, your department can only see invoices sent to your department — not others in the company," and AvidXchange digitizes invoices and routes them through configured approval workflows, with approvers reviewing invoices based on rules such as department, invoice amount, vendor, or GL category. AvidXchange also claims multi-entity capability at the payment layer: "AvidXchange is designed to support multi-entity organizations by allowing finance teams to manage payment execution centrally while maintaining entity-level approvals and accounting structures." The NetSuite API integration carries subsidiaries as a data object alongside accounts and currencies, with the integration configuration referencing Lists including Accounts, Currency, Subsidiaries, and Documents and Files. However, the documented isolation mechanism is portal-level departmental scoping, not per-NetSuite-subsidiary book isolation enforced against OneWorld's legal entity model. There is no documented evidence that the workflow engine enforces a hard per-subsidiary access boundary such that Subsidiary A's approvers are categorically blocked from Subsidiary B's queue through the NetSuite subsidiary dimension. Context-aware mid-flow chain adaptation keyed to the subsidiary dimension (i.e., the approver chain automatically reconfigures as subsidiary coding is determined) is not documented: "the best part is these automated approval workflows won't change your approval process because the workflow in your AvidXchange AP automation platform will be configured to mirror your current approval scenarios" and "the workflow engine will be configured and defaulted based on pre-determined rules and conditions applied to the workflow," which describes a pre-configured fixed/threshold model rather than a context-aware adaptive chain.

Limitations: The documented per-entity isolation model operates at the AvidXchange portal's department level, not at NetSuite OneWorld's subsidiary dimension, meaning the hard book-isolation boundary the buyer requires (Subsidiary A approvers categorically blocked from Subsidiary B invoices) has no confirmed enforcement mechanism in the AP layer. Context-aware chain adaptation driven by subsidiary, GL account, or cost dimension mid-flow is not documented; the workflow engine's configuration model is pre-defined at implementation rather than dynamically adaptive, which for 14 subsidiaries means the shared-services team will need to manually maintain a large matrix of fixed workflows rather than having the system resolve the correct chain from invoice attributes at runtime.

Buyer requirement: Approvers must be able to receive, review invoice details and coding, and take approval actions (approve, reject, request information, delegate) directly within Microsoft Teams, without being required to authenticate into a separate AP portal or web application. The Teams-native experience must surface the full invoice image, line-level coding, and any attached supporting documents so that approvers can make informed decisions without context-switching, addressing stage 5 approval routing in the buyer's primary collaboration environment.

For a D365 Finance organization whose approvers live in Microsoft Teams, AvidXchange's approval mechanism is portal-centric, not Teams-native. When an invoice reaches a routing stage, the AP software system automatically routes invoices needing approvals to the approver's queue and sends notifications and reminders via email. Once the invoice is fully validated and goes through the approval part of the workflow, relevant people involved will usually be emailed with the information, and it is up to them to approve the invoice by logging into the AvidXchange web platform. Once the invoice is in the workflow portal, it can be viewed and approved electronically, and approvers can see exactly where the invoice is in the approvals process at all times — but this visibility and action all occur inside the AvidXchange portal, not inside Teams. The software allows accounts payable teams to view statuses of current invoices and approve payments from a single software platform, which is AvidXchange's own web application. No Teams bot, Adaptive Card action, Teams app tab, or in-Teams approval mechanism is documented anywhere in AvidXchange's product materials, help center, or Microsoft AppSource listing; the full set of approval actions (approve, reject, request information, delegate) and the invoice image, line coding, and supporting documents are only accessible through the AvidXchange portal after the approver navigates away from Teams.

Limitations: AvidXchange's approval experience is entirely portal-bound: approvers receive an email notification and must authenticate into the AvidXchange web application to view the invoice image, line-level coding, and take any action. This directly breaks the buyer's requirement for Teams-native approval without a separate portal login, and no published AvidXchange roadmap item or Teams app in the Microsoft AppSource catalog addresses this gap. Additionally, AvidXchange's D365 Finance and Operations integration is file-based rather than API-based, compounding the integration depth concern for this Microsoft-centric buyer.

Buyer requirement: The approval routing engine must support multi-level, configurable chains that can adapt based on legal entity, financial dimension values, invoice amount thresholds, and vendor attributes across the three legal entities, so that each entity's approval hierarchy is enforced independently within a shared workflow system. The engine must also support delegation and auto-escalation on timeout, since approvers who work primarily in Teams may be unavailable and the workflow must not stall at a single point.

For a three-legal-entity D365 Finance organization that needs dimension-driven, per-entity routing enforced inside Microsoft Teams, AvidXchange's AvidInvoice workflow engine covers the basics but hits several material ceilings. The engine does support amount-threshold routing and approver rerouting on absence: the software determines which leaders should approve which invoices based on the company's rules and workflow restrictions tied to dollar amount thresholds, and approvals can be rerouted in the absence of the approver to keep business running as usual. Role-based routing is also configurable: administrators can set up approvers in groups ("roles") so that multiple people belong to one role, and any member of that role can approve the invoice without the administrator chasing down each individual user. However, the integration with D365 Finance (F&O) is file-based, not API-based: AvidXchange has API integrations with Business Central and GP, but only file-based integrations with AX, NAV, F&O, and SL. A file-based connection cannot read D365 financial dimension values in real time, which means routing rules cannot dynamically branch on department, cost center, business unit, or other dimension values as they exist in D365 Finance at the moment of processing. There is no documented evidence of native Microsoft Teams adaptive card or bot integration that would allow approvers to act from within Teams without logging into the AvidXchange portal; AvidXchange's documented notification mechanism is email-based. The invoice approval workflow software determines which leaders should approve which invoices and automatically sends invoices to the appropriate leaders based on the company's rules, but the delivery surface is the AvidXchange platform, not a Teams-native action. Per-entity independent hierarchy enforcement (three separately configured approval chains sharing one instance) is also not documented.

Limitations: The file-based D365 Finance integration is the primary ceiling: routing cannot branch on live financial dimension values pulled from D365, so the buyer's requirement for dimension-aware, per-entity conditional chains is not achievable without custom middleware. The absence of a documented Teams-native approval action (adaptive card or bot) means Teams-based approvers will still need to context-switch into the AvidXchange portal, directly contradicting the buyer's stated no-separate-login requirement.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a $120M services company moving from email-chain approvals to structured AP automation across 2 Sage Intacct entities, AvidXchange's AvidInvoice module operates as the pre-processing layer covering stages 1 through 3 of the pre-processing journey: legitimacy, initial coding, and approval routing. The software determines which approvers should handle which invoices and automatically routes them based on the company's rules and restrictions, including dollar amount thresholds set during implementation. Conditional steps allow automatic routing to specific approvers under defined circumstances; for example, invoices exceeding a threshold are escalated to a CFO-level approver. Role-based approval groups let multiple people share a role, so an invoice routes to the role rather than requiring manual identification of an individual approver. The AvidInvoice product page describes 'AI-enhanced custom workflows' with the ability to manage and monitor approvals from anywhere. For Sage Intacct specifically, AvidXchange describes 'flexible approval workflows' and notes that AvidStrongroom for Sage Intacct includes 'next-level data syncing, including invoice images and custom dimensions.' However, the publicly documented routing conditions cover dollar threshold, role, and vendor-level defaults clearly; routing by GL account, expense type, and project as independent trigger conditions within the same rule engine is not specifically documented in any available source. A third-party comparison notes that AvidXchange 'provides routing and supports approval rules based on amount, roles, and other conditions, but the depth of workflow customization varies significantly by module,' and that many organizations rely on more straightforward approval logic because advanced workflows are not consistently supported across all modules. The buyer's 7-dimension requirement (dollar threshold, department, GL account, vendor, entity, expense type, and project) exceeds what AvidXchange publicly documents as simultaneously configurable routing triggers in AvidInvoice.

Limitations: Three of the buyer's seven routing dimensions (GL account, expense type, and project as independent trigger conditions) are not documented as available routing triggers in AvidXchange's workflow engine, and a third-party assessment specifically flags that advanced workflow depth varies by module. The buyer should require a live demo that demonstrates all seven conditions firing simultaneously within a single invoice's routing chain before assuming full coverage.

Buyer requirement: Approval routing must be configurable per entity so that each of the 8 real estate entities can enforce its own chain of approvers, spending thresholds, and GL-account-based escalations, all within a single AP workflow managed by the 4-person team. Stage 5 of the pre-processing journey (cost allocation sign-off) requires that budget owners see only the invoices and dimensional data belonging to their entity: role-based, entity-scoped visibility controls are required so one entity's approvers cannot view or act on another entity's payables.

For a portfolio of 8 real estate entities managed by a 4-person AP team, AvidXchange's real estate product (AvidSuite for Real Estate, powered by AvidInvoice) directly addresses property-level approval routing: the platform has evolved to meet the needs of real estate and property management companies with "flexible workflows so you can assign permissions and approvals based on properties or units." At Stage 5 of the pre-processing journey (cost allocation sign-off), AvidInvoice automatically codes invoices and assigns them to the appropriate workflow, and automates multi-level invoice approvals with customizable steps based on vendor or amount. Role-based access is configured at the user level: users must be assigned user roles to access certain permissions and areas of the application, and roles can be edited from the Portal Customization tab. The supporting tier confirms spend and compliance management through customizable workflows with a full audit trail and built-in protection. However, the documented routing triggers are vendor type and invoice amount; GL-account-based escalation as a discrete routing dimension is referenced only indirectly via "customized workflows: automate GL allocation and multi-level approval routing," without confirming that GL account alone can drive a separate approval chain per entity. Critically, the entity-scoped visibility isolation requirement (one entity's approvers cannot view or act on another entity's payables) is described at the property/unit permissions level, but no source documents a hard data wall between entities within a shared AvidXchange account as opposed to access controlled purely by role assignment.

Limitations: The buyer's hardest requirement is strict entity-scoped visibility isolation: confirmed evidence only establishes property/unit-level role permissions, not a hard data boundary that positively prevents cross-entity invoice visibility within a single AvidXchange account. GL-account-based escalation as a standalone, per-entity routing trigger is not confirmed in any source, meaning the buyer may need to approximate that requirement through vendor-type or amount-threshold rules rather than true GL-driven branching.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For this buyer's 3-person AP team processing 1,800 invoices per month across 2 Sage Intacct entities, AvidXchange addresses the CFO/Controller payment authorization gate through a dedicated payment-layer control that is architecturally separate from invoice-level approvals. The mechanism sits inside AvidPay, AvidXchange's payment module, and is called the 'Pay Control Workflow.' Once invoices complete their approval chain in AvidInvoice, they are batched for payment, but funds do not move until a designated approver acts in the AvidPay Approvals tab. As AvidXchange's own FAQ states, the customer 'remain[s] in complete control of approving the payments to be issued' before AvidXchange disburses funds, confirming this is a system-enforced hold, not a notification. AvidPay's product page confirms that 'role-based access ensures your team sees only what they need, while built-in audit trails help you stay compliant,' and a third-party review of the platform notes that AvidXchange enables 'segregation of duties with workflows that create permissions, approval requirements and audit trails from initial Purchase Order to payment.' The CFO or Controller is assigned the payment approver role; AP staff who build and submit batches cannot release funds themselves, satisfying the segregation-of-duties requirement. The audit trail captures every approval action electronically, meeting the documentation requirement for a $120M multi-location services company subject to finance controls.

Limitations: The full configuration options of the Pay Control Workflow article could not be retrieved due to JavaScript rendering of the help center, so it is unconfirmed from documentation whether the system allows hard-locking a single named role (e.g., CFO only) with zero admin override path; buyers should confirm during demo whether an administrator with elevated permissions can bypass the payment approval gate in an emergency, which would weaken the hard-control posture.

Buyer requirement: The system must support multi-level, configurable approval routing for the non-PO invoice stream, including threshold-based chain escalation, delegation on approver absence, and auto-escalation on timeout, so that the cost-allocation confirmation at stage 5 of the pre-processing journey can be completed by the budget owner without requiring AP staff to manually chase approvals; the routing logic must be able to reference the coded GL fields from req_3 to direct invoices to the correct budget owner dynamically.

For a company processing ~1,850 non-PO invoices per month across 27 coding fields and needing budget owners to confirm cost allocation at stage 5 without AP chasing, AvidXchange's AvidInvoice module provides configurable approval routing through a rules-and-roles engine. AvidXchange allows businesses to integrate AvidInvoice into their current workflow by letting them set customized rules for their invoice approval processes. The routing engine supports threshold-based escalation: rules and restrictions help eliminate the hassle of reaching out to an approver every month about the same dollar amount threshold, and all approval amounts can be set during implementation for a smooth, streamlined process. Role-based groups organized by department handle approver assignment: AvidXchange uses invoice workflow automation to set up approvers in groups, known as 'roles,' allowing multiple people within each role to approve the invoice without the administrator chasing down each user to figure out who it should be routed to. For absent approvers, the documented mechanism is a role-group approach rather than an automated out-of-office substitution rule: if a director is out of office and unable to approve, it is helpful to have someone else able to do so; giving permission to someone in your department to approve an invoice in their absence, and setting up these workflow permissions ahead of time, keeps the invoice moving without delay. Third-party review data confirms multi-level invoice approvals with customizable steps based on vendor or amount, with timestamped approvals and paperless workflows. The critical gap for this buyer's specific requirement is the absence of documented GL-field-driven dynamic routing: the buyer needs the routing logic to read the coded GL dimension fields (department, cost center, GL account) written during coding to automatically resolve the correct budget owner. AvidXchange's documented routing criteria center on pre-configured departmental roles, vendor identity, and dollar amount thresholds set at implementation, not on dynamically resolving an approver from the specific coded GL combination on each invoice.

Limitations: The buyer's requirement that routing logic 'references the coded GL fields from req_3 to direct invoices to the correct budget owner dynamically' is not evidenced in AvidXchange's documented routing engine; the mechanism appears to resolve approvers from pre-set department role groups and amount thresholds configured at implementation, which means invoices coded to an unexpected GL combination or a new cost center may require manual reassignment by AP. Additionally, automated out-of-office delegation with date-range substitution (a hard requirement for no-chase SLA enforcement) is documented only as a manual role-group permission setup, not as a system-triggered substitution timer.

Buyer requirement: The system must support configurable approval routing for requisitions that exceed a soft-stop threshold, routing the override request to a designated budget owner or finance approver for the relevant department or dimension before the commitment proceeds. This is implied by the soft-stop model the buyer described: a soft stop without a structured approval path is just a dismissible warning, not a control.

For a mid-market company on Sage Intacct with budgets imported from Workday Adaptive Planning, Ramp converts soft-stop budget thresholds into structured gating approvals through its dedicated 'Budget-based approval workflows' feature. Once the buyer's Adaptive budgets are uploaded into Ramp Budgets (file upload replaces the active budget), admins configure budget-aware conditions that trigger a mandatory approval step when a purchase request exceeds a defined percentage of remaining budget: conditions such as 'If a purchase exceeds 80% of remaining budget' automatically involve budget owners in the approval chain, adjust approval paths based on real-time budget data, and display current budget status at the time of the approval request. Routing is dimension-aware: admins can extend Ramp users with a 'Budget owner' custom field, import each user's budget owner from a source of truth such as a CSV or SCIM, and configure approval workflows to route to those budget owners instead of the manager hierarchy, keeping the HR org chart intact while accurately reflecting who owns the budget for each user's spend. The procurement workflow builder enforces this as a gate, not a dismissible warning: requests route through the configured approval workflow so the right stakeholders review each purchase before it is committed. Within the workflow builder itself, policy outcomes can be used to conditionally route the request to the right next approvers, with the decision trail kept consistent and transparent for downstream approvers. Overrides and approver decisions are logged: feedback and overrides appear in the audit log.

Limitations: Budget-aware threshold conditions (percentage of remaining budget) require the buyer's Adaptive Planning budgets to be actively loaded into Ramp Budgets as the live tracking source; only one budget version can be active at a time, so scenario budgets must be managed outside Ramp and the desired version uploaded for Ramp to enforce against it. Additionally, the Custom User Fields feature that enables non-manager budget-owner routing is restricted to Ramp Plus tier, meaning the full dimension-aware routing capability carries a plan-tier dependency.

Buyer requirement: For non-PO invoices, the solution must support a department-initiated coding and pre-approval workflow where the department owner can code, annotate, and approve their portion of an invoice before it reaches the central AP team, matching the buyer's described split where departments manage their invoices and hand off ready-to-code items to AP. This covers pre-processing stage 5 (cost allocation) and must preserve all department-entered dimension values when the record is handed to AP and subsequently posted to SAP S/4HANA.

For the buyer's non-PO invoice split, Ramp Bill Pay supports a department-initiated coding and pre-approval workflow through its employee Bill Pay permissions model. Department owners can be granted 'Create bills' and 'Edit draft bills' permissions, allowing them to upload an invoice, fill in all necessary accounting fields (GL category, department, cost center, location), and submit it for AP review: employees can submit, code, and prepare their own bills for final review and payment by the AP team. A Bill Pay submission policy acts as a data-completeness gate: submission policies let admins define which fields must be filled before a bill can be submitted, ensuring bills contain required information such as accounting codes before they enter the approval workflow; they are separate from approval policies, which control who approves. Once submitted, department-entered dimension values travel with the bill through configurable multi-step approval chains: for Bill Pay approvals, Ramp can route to the department owner by identifying the department owner of the assigned vendor owner, and any user can add approvers to the approval chain while an approval is in-flight. Approvers can also edit accounting fields on in-flight bills: when approver editing is enabled, an approver can edit most fields on a bill in approvals, including descriptions, dates, line items, and accounting fields. The critical shortfall is the ERP integration leg. Ramp's direct accounting integrations cover NetSuite, Sage Intacct, QuickBooks, Xero, Workday, and Acumatica: importing bills from an accounting provider is supported for Sage, QuickBooks, NetSuite, Xero, QuickBooks Desktop, Acumatica, and Zoho Books. SAP S/4HANA does not appear as a supported direct accounting integration in Ramp's help center; the only SAP reference is SAP SuccessFactors as an HRIS provider. Ramp's own blog describes its SAP relationship as being used 'alongside' SAP ERP systems rather than through a native API integration: Ramp can be used alongside certain SAP ERP systems, offering features like OCR that auto-fills bills down to each line item and AI-driven auto-coding. Without a direct SAP S/4HANA integration, department-entered dimension values (cost center, WBS element, profit center, internal order) would exit Ramp via Universal CSV export, with no guarantee of field-fidelity mapping to SAP S/4HANA's full controlling object model.

Limitations: The department-first coding and pre-approval workflow is well-documented and operable in Ramp Bill Pay, covering pre-processing stage 5 correctly. However, the requirement's mandate that dimension values be preserved on posting to SAP S/4HANA cannot be met through a native direct integration: Ramp has no documented direct accounting integration with SAP S/4HANA, meaning the ERP sync would require Universal CSV export and manual import, breaking field-fidelity for SAP-specific dimensions (WBS elements, profit centers, business areas, controlling objects) and undermining the headcount reduction goal by reintroducing manual ERP data entry.

Buyer requirement: For the roughly 1,050 non-PO invoices processed each month (the remaining 30% of 3,500), the system must support AI-assisted GL coding and cost allocation routing to the appropriate budget owner for approval, since these invoices do not have a PO or GR document to anchor a 3-way match. The coding model must suggest SAP cost objects (cost center, GL account, plant) based on vendor history and invoice content, and must route to the correct budget owner based on the suggested cost allocation rather than defaulting to a fixed AP-team approval chain.

For a manufacturing company processing roughly 1,050 non-PO invoices monthly, Ramp's Bill Pay platform offers an AI auto-coding agent that learns from historical patterns and applies GL code suggestions at the line-item level: the AP Agent automatically assigns accounting codes and categories to invoice line items based on vendor historical patterns and provided invoice context, activated simply by uploading an invoice. On the approval side, there are multiple bill fields on which approvals can be routed, though conditions beyond amount-based routing require Ramp Plus, and for Bill Pay approvals, Ramp resolves the department owner by identifying the department owner of the assigned vendor owner, and the location owner by identifying the location of the assigned vendor owner. This means approver resolution is anchored to the vendor relationship in Ramp, not dynamically to the GL cost center suggested on a specific invoice line, which is the buyer's stated requirement. Most critically, Ramp's own documentation describes the relationship to SAP as being used "alongside certain SAP ERP systems" rather than as a native direct integration: Ramp's documented direct ERP integrations cover NetSuite, QuickBooks, Sage Intacct, Xero, Acumatica, and Microsoft Business Central, with no support.ramp.com help article documenting a native SAP S/4HANA connector. Without a verified native SAP S/4HANA integration, Ramp cannot pull SAP CO master data (cost center hierarchy, plant codes) as suggestion targets, nor can it post suggested cost objects back to SAP with the field fidelity required by an S/4HANA FI/CO environment.

Limitations: Two material ceilings apply simultaneously for this buyer: Ramp has no documented native SAP S/4HANA integration, so the required SAP cost objects (cost center, GL account, plant) cannot be synced as suggestion targets or written back with S/4HANA field fidelity. Even within its supported ERPs, Ramp's Bill Pay approver resolution for department-owner routing is anchored to the vendor's assigned owner, not dynamically to the cost center coded on the invoice, meaning budget-owner routing driven by suggested cost allocation rather than vendor relationship is not the documented mechanism.

Buyer requirement: Approval routing must be configurable per entity so that each of the 8 real estate entities can enforce its own chain of approvers, spending thresholds, and GL-account-based escalations, all within a single AP workflow managed by the 4-person team. Stage 5 of the pre-processing journey (cost allocation sign-off) requires that budget owners see only the invoices and dimensional data belonging to their entity: role-based, entity-scoped visibility controls are required so one entity's approvers cannot view or act on another entity's payables.

For a portfolio of 8 real estate entities, Ramp's Bill Pay approval workflow builder supports entity-aware routing through a condition-based architecture: administrators build a single global workflow where 'business entity' is available as a branching condition alongside amount thresholds and accounting categories (GL accounts), enabling different approver chains to fire depending on which entity a bill is tagged to. The workflow builder allows conditions checking bill fields such as amount, business entity, vendor name, and accounting categories to determine the correct approver, with approval steps then selecting specific approvers or groups. Amount-based routing is available to all customers, while entity-based and GL-account-based conditions require Ramp Plus. For entity-scoped visibility at Stage 5 (cost allocation sign-off), Ramp enforces access restrictions at the role level: AP Clerk access can be restricted to specific entities, with the question 'Can I limit an AP Clerk's access to bills from specific business entities?' answered affirmatively, managed through Bill Pay settings. If multi-entity restrictions are toggled on, an AP clerk is limited to bills tied to the entity they are assigned. The 4-person AP team can be configured so each member only processes the entities they are assigned. However, the approval chain is architecturally a single global workflow with entity branching, not 8 independently configured workflows, and Admins, Business Owners, and AP Clerks can see all bills that need approval on the Approvals page, meaning admin-level approvers retain cross-entity visibility by default. This is the pre-processing journey gap: entity-scoped visibility is enforced for AP Clerk and Bookkeeper roles but is not confirmed to extend systematically to budget-owner approvers (Stage 5), who may hold admin-level roles and would therefore see payables across all 8 entities.

Limitations: The approval architecture is a single global workflow with entity-as-a-condition branching rather than 8 isolated per-entity workflow configurations, which means a change to the global workflow logic affects all entities simultaneously. Entity-scoped bill visibility is explicitly enforced only for AP Clerk and Bookkeeper roles; budget owners participating as Stage 5 approvers who hold admin permissions will have cross-entity view access by default, which does not satisfy the buyer's requirement that one entity's approvers cannot view or act on another entity's payables.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a $120M multi-location services company replacing bi-weekly check runs and monthly ACH batches, Ramp Bill Pay delivers payment authorization control through two layered mechanisms. First, the bill-level approval workflow routes each invoice through a configurable multi-step chain before any payment object is created: admins configure the Bill Pay approval policy from Bill Pay settings, which redirects to an approvals workflow builder where complex and flexible approval chains can be built using conditions and outcomes. Ramp automatically routes every bill to the right approver, from routine spend to CFO signoffs. Second, and most directly relevant to this requirement, Ramp provides a dedicated Payment Release gate: the Payment Step Approvals feature adds an extra layer of control over the release of funds for bill payments, designed for companies that need clear separation of duties between the person approving bills and the person authorizing payments, ensuring no payment will be released until explicitly approved by a designated payer. Payment Release adds a second gate after bill approval; a designated payer must explicitly release each payment before funds are sent, configured via Bill Pay settings, Approvals, by enabling 'Require additional approval to release payment.' The audit trail is documented: every step in the approval process is tracked, with comprehensive audit trails showing who approved what and when. The sequencing relative to payment batching is confirmed: for customers using the Payment Release approval feature, bills are batched after payment release, meaning the CFO or Controller authorization gate fires before funds move.

Limitations: The Payment Release feature is only available on Ramp Plus; and at this time, only admins and AP clerks can be added as payers on Bill Pay. This is a material constraint: the buyer's CFO or Controller must hold an Admin-level role in Ramp to be designated as the payment releaser, which conflicts with Ramp's own best-practice guidance to limit admins to 1-3 people and may create role-permission tension in a 6-location, 200-employee environment. Additionally, admins are considered power users in Ramp; when an admin creates spend for other employees, those requests are always auto-approved without requiring approval, meaning the CFO-as-admin designation carries broader platform privileges than the buyer's internal controls may intend.

Buyer requirement: The system must support multi-level, configurable approval routing for the non-PO invoice stream, including threshold-based chain escalation, delegation on approver absence, and auto-escalation on timeout, so that the cost-allocation confirmation at stage 5 of the pre-processing journey can be completed by the budget owner without requiring AP staff to manually chase approvals; the routing logic must be able to reference the coded GL fields from req_3 to direct invoices to the correct budget owner dynamically.

For a company running ~1,850 non-PO invoices per month through NetSuite, Ramp Bill Pay's approval workflow builder covers three of the four mechanics the buyer requires. The builder supports multi-step, layered chains with conditions drawn from bill fields including amount, vendor, business entity, and accounting categories such as GL account, department, class, and location, allowing the coded dimensions from the non-PO invoice to drive which approver receives the bill at stage 5 of the pre-processing journey. Conditions can check bill fields including 'accounting categories' to help determine the correct approver, and approvers or groups are then added per the resolved condition. Amount-based routing is available to all customers, while GL-field and department-based conditions require Ramp Plus. Ramp Budgets supports budget-based approval workflows that enable routing to budget owners and automatic triggering based on remaining budget, displaying budget status during the approval process. Delegation on approver absence is a native feature: users can delegate an approver for their Ramp inbox when going out of the office, setting someone as their backup to unblock the team's spend, and the delegate receives approval requests on behalf of the delegator, including bills. However, the auto-escalation-on-timeout mechanic the buyer requires is not present as a hard reassignment: Ramp sends auto-reminders for bill approvals daily, Monday through Friday, with a 2-day and 3-day reminder sent to the designated approver if no action has been taken, but there is no documented mechanism that automatically reassigns or escalates the approval step to a different person after a configurable SLA window expires. Additionally, the 'Department Owner' approver role in Bill Pay is resolved from the department owner of the assigned vendor owner, not dynamically from the coded GL department field on the invoice line, which can misroute budget-owner resolution when the invoice department coding differs from the vendor owner's department. A further NetSuite-specific gap: for NetSuite Customers and Jobs, Ramp displays them in a single list, and approval chains must be manually updated for each new job, limiting dynamic GL-field-driven routing for job- or project-coded invoices.

Limitations: The absence of configurable auto-escalation on timeout is a real process gap: when a budget owner does not action a bill within a defined SLA, Ramp sends reminders but does not reroute the chain, meaning AP staff must intervene manually to break the logjam, which is the exact behavior the buyer is trying to eliminate. The dynamic budget-owner resolution mechanism relies on vendor-owner department assignment rather than the invoice's coded GL department, so organizations where vendor owners and invoice cost-allocation departments diverge will encounter misroutes that require manual correction.

Buyer requirement: The system must support configurable approval routing for requisitions that exceed a soft-stop threshold, routing the override request to a designated budget owner or finance approver for the relevant department or dimension before the commitment proceeds. This is implied by the soft-stop model the buyer described: a soft stop without a structured approval path is just a dismissible warning, not a control.

For a mid-market buyer whose budgets live in Workday Adaptive Planning and whose spend problem is enforcement at the moment of commitment, Zip's workflow engine is purpose-built for this control model. When a requester submits a purchase request through Zip's intake portal, the platform collects all relevant information upfront, including what is being purchased, from which vendor, for how much, and which budget it affects, before any commitment is made. The soft-stop-to-structured-approval chain is handled through Zip's no-code conditional logic layer: the workflow engine uses preset spending limits and rules to determine whether a request fits within allocated budgets, automatically flagging and rerouting requests that would exceed limits to approvers like finance managers or CFOs. Critically, this is not a dismissible warning; Zip distinguishes between different types of budget exceptions and routes them accordingly, so a request that slightly exceeds a department's monthly allocation might need only a director's approval, while one that would blow through an entire quarterly budget triggers executive review. The routing is dynamic and dimension-aware: Zip routes requests to the right cross-functional teams and dynamically selects appropriate approvers using queues and user hierarchies, and rules route approvals based on spend, vendor risk, or department. The no-code interface means finance can configure and update these rules without IT: the platform allows for conditional logic (e.g., requests over a certain amount require additional approvals) without any coding. For the buyer's Adaptive Planning integration specifically, at a more advanced maturity stage, organizations embed real-time budget and spend data into every approval, so approvers see current spend levels before approving requests. The audit trail for overrides is native: compliance ensures requests are automatically routed to the right teams, like finance for budget confirmation, before a purchase is made, and Zip's platform is designed to manage these complex, multi-step approval chains automatically.

Limitations: The depth to which live budget-consumption data from Workday Adaptive Planning (as opposed to a static dollar threshold configured in Zip) can serve as the conditional trigger in a workflow rule is not explicitly documented; the buyer should confirm during implementation that the Adaptive-to-Zip budget sync feeds a real-time consumption figure that workflow rules can branch on, not just a static requisition amount. Additionally, some G2 reviewers note that certain features could be more customizable, especially around notifications and approval routing, to better match unique internal processes.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For this $120M services company routing 1,800 invoices/month across 2 Sage Intacct entities, Zip's approval architecture is primarily an intake-first model: when a purchase request is submitted, Zip's no-code workflow builder (documented on ziphq.com/capabilities/approval-workflows) applies conditional logic to route requests dynamically 'to the right cross-functional teams using queues and user hierarchies.' Routing conditions including amount threshold, department, vendor, and entity are referenced across Zip's own product pages and blog content, and user-reported reviews confirm 'conditional logic for questions and customizable workflows' that 'enable only the necessary approval steps for each request type.' For the buyer's 55% PO-based invoices where a Zip intake request exists upstream, this mechanism is well-grounded: the invoice inherits the routing context established at intake, and Zip's AI matches it to the right PO and approval path. However, for the 45% non-PO invoices (utilities, subscriptions, insurance, professional services) arriving cold by email without a prior Zip request, the documented mechanism for driving GL-account-level and expense-type-level routing conditions on the inbound invoice itself is not explicitly confirmed in Zip's AP automation documentation; Zip's AP page describes routing as flowing from 'upstream context' captured at intake, which does not exist for vendor-initiated non-PO invoices.

Limitations: The buyer requires all 7 routing dimensions (dollar threshold, department, GL account, vendor, entity, expense type, project) to fire on inbound invoice attributes, but Zip's conditional workflow engine is primarily documented for the intake/procurement request side; GL-account-level and expense-type-level routing on cold-arriving non-PO invoices specifically is not confirmed, creating a ceiling for 45% of this buyer's invoice volume where no prior Zip request exists to provide routing context.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For this $120M, 2-entity Sage Intacct customer processing 1,800 invoices monthly, Zip's approval routing operates through a no-code workflow engine that sits primarily at the intake and pre-PO stages of the pre-processing journey (stages 1-2). Zip's system automatically determines the proper approval workflow based on factors like dollar amount, vendor risk level, and type of purchase. The platform uses a no-code approach that allows finance teams to configure approval chains without programming knowledge: a $500 software purchase might require only a manager's sign-off, while a $50,000 consulting contract could trigger reviews from finance, legal, and security teams simultaneously, with workflows adapting based on variables like purchase amount, vendor risk, and department policies. Zip routes requests to the right cross-functional teams and dynamically selects appropriate approvers using queues and user hierarchies, configurable via a flexible drag-and-drop interface without IT involvement. On the AP side, Zip captures GL coding details during intake and approval, including entity, department, cost center, project, location, and tax codes. Zip offers customizable approval workflows that can be tailored to business needs, supporting complex multi-level approvals based on criteria such as amount, department, or vendor to ensure compliance and internal controls. However, the routing architecture is most fully documented for intake-originated (PO-side) requests. For the buyer's 45% non-PO invoices arriving directly by email or mail without a prior intake request, the evidence that GL account code and expense type function as live routing triggers within the AP invoice module specifically is implied by the platform's design but not confirmed in granular technical documentation. At least one user review noted that approval workflow routing was not configured properly and often routed approvals to the wrong individual, signaling configuration complexity that a 3-person AP team managing 7 simultaneous routing dimensions across 2 entities should weigh carefully.

Limitations: Zip's routing engine is most fully evidenced and mature on the intake-to-procure side; for the buyer's 45% non-PO invoices that arrive without a preceding intake request, explicit documentation confirming that GL account and expense type act as independent routing triggers within the AP module is absent, creating a material gap for the two dimensions most critical to non-PO classification. A 3-person team managing 7 routing dimensions across 2 Sage Intacct entities will need to validate during a demo whether compound AND/OR rule logic spanning all seven dimensions is configurable in the AP workflow builder without creating unmanageable rule sprawl.

Buyer requirement: Configurable multi-level approval chains by dollar amount, department, category, vendor, and GL code

For a $250M tech company currently managing approvals via Slack and email with 35% maverick spend, Zip's Intake-to-Procure module acts as a no-code orchestration layer that captures every purchase request through a single intake form and immediately applies a rule-based approval routing engine. Zip uses a visual, drag-and-drop workflow builder that allows administrators to create conditional approval paths without coding, with routing based on spend amount, department, category, or custom fields. The engine routes requests to the right cross-functional teams and dynamically selects appropriate approvers using queues and user hierarchies, meaning a marketing request coded to a specific GL over $50K can simultaneously or sequentially engage procurement, finance, and legal as separate stages. Rules route approvals based on spend, vendor risk, or department, and multiple stakeholders can review in parallel instead of waiting in sequence; finance teams can update workflows instantly as policies change, eliminating IT bottlenecks. GL code routing is handled through custom fields captured at intake, which Zip's AI pre-populates and syncs directly to NetSuite, enabling GL-based conditions to trigger specific approval stages without manual re-entry. Zip markets configurable approval chains built for collaboration, with the ability to change workflows easily without the need for coding or help from IT, directly addressing the buyer's need for self-service policy reconfiguration as spend thresholds and organizational structure evolve.

Limitations: While spend amount, department, category, and vendor routing dimensions are explicitly documented, GL code as a standalone routing condition (distinct from a custom field mapping) is not directly confirmed in Zip's help center documentation found; buyers should validate during a demo that GL code can be used as a first-class conditional trigger in the workflow engine, not solely as an AI-suggested label. The platform operates as a front-end orchestration layer upstream of NetSuite, so final PO execution and financial posting remain in NetSuite, which means any approval logic that must run post-PO (e.g., change order re-approval) depends on Zip's change order workflow coverage.

Buyer requirement: Configurable multi-level approval chains by dollar amount, department, category, vendor, and GL code

For a $250M technology company moving from email-and-Slack approvals to a governed procurement process, Zip's Intake-to-Procure module is the core mechanism. When an employee submits a purchase request through Zip's intake portal, the platform's no-code workflow engine immediately evaluates the request against a configurable set of routing conditions. Zip's own published guidance documents that it offers 'flexible approval chains, letting you customize workflows based on department, amount, or vendor without complex coding,' and a third-party methodology review confirms Zip 'employs configurable approval matrices that route purchase requests based on amount thresholds, category types, and departmental hierarchies.' GL and cost center dimensions are captured at intake and flow into routing: Zip's orchestration documentation confirms requests are 'automatically route[d] to the correct cost center owners and technical approvers based on dynamic user hierarchies and request criteria,' meaning department and accounting-dimension ownership drives approver assignment. Both sequential and parallel approval paths are supported natively: the platform 'replaces slow, linear approval chains with parallel approval workflows,' allowing IT, Legal, Finance, and category managers to review simultaneously rather than in a bottleneck. The supporting tier's claim that Zip uses 'AI to route, validate, and enforce policy' is the operative control layer that sits upstream of NetSuite PO creation, ensuring every dollar of the buyer's $60M indirect and $30M direct spend passes through a defined approval gate before a PO is issued.

Limitations: GL code as a standalone, named routing trigger (distinct from department or cost center) is documented through cost-center-owner routing rather than a discrete 'GL code routing rule' field; buyers who need approval routing keyed specifically to individual GL account numbers (not just the broader cost center or department) should verify during implementation that this dimension is explicitly configurable as an independent condition in the rule engine. One verified user review noted that 'approval workflow routing isn't configured properly and often, approvals are asked of the wrong individual,' suggesting that complex matrix configurations may require careful initial setup and ongoing tuning.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a $120M multi-location services company running two Sage Intacct entities, Yooz addresses approval routing through what it describes as its BPMN2-based workflow engine. Automated AP workflows are driven by a Business Process Management (BPM) engine that routes invoices and documents based on predefined rules such as invoice value, department, cost centre, or supplier; Yooz uses BPMN2 as a visual modelling language, and once an invoice enters the system it follows the correct approval path, notifies approvers via email or mobile app, and logs every step for audit. The routing rule set explicitly covers the dimensions your team requires: Yooz provides a user-friendly interface for creating and customizing approval matrices, allowing users to define multiple approval levels, specify approvers, and set criteria for routing based on factors such as invoice amount, vendor category, or expense type, configurable to align with specific business requirements and compliance policies. Independent analysis confirms the engine extends to project-level routing: the workflow engine enables companies to customize approval paths based on invoice amounts, departments, or project codes, with adaptable approval paths that align with company-specific workflows while enforcing compliance and internal controls. On the Sage Intacct integration specifically, Yooz is a certified Sage Tech Partner and its integration allows workflow configuration to match exact processes, and as a trusted Sage Tech Partner Yooz delivers automation from invoice capture through approvals and payments with deep integration into Sage Intacct. The workflow engine operates during the pre-processing approval stage (stage 5 of the journey: cost allocation and authorization) and handles both PO-based and non-PO invoices across both of your Sage Intacct entities. Yooz provides unlimited combinations of workflow routes and users, with powerful rules that are easy to use and quick to set up.

Limitations: One user-reported limitation is that when multiple approvers at the same hierarchical level must each review an invoice sequentially, the process can feel slow; the approval structures can be inflexible when multiple staff of the same level need to approve something, as stepping through one at a time takes longer. Yooz acknowledged this feedback and indicated it is under review, but buyers who need true parallel routing for same-level approvers should confirm current behavior during a demo. Additionally, while all seven routing dimensions are documented in vendor marketing materials, the granularity of GL account-level routing as a standalone trigger condition (versus department or cost center) should be validated against your specific Sage Intacct chart of accounts configuration during implementation scoping.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a $120M multi-location services company running bi-weekly check runs and monthly ACH batches, Yooz addresses the payment batch authorization requirement through a dedicated 'Pay' stage that is architecturally distinct from the invoice approval ('Approve') stage. The LinkedIn product description explicitly separates the two: 'Approve' covers invoice validation rules by type, amount, department, and cost center, while 'Pay' covers automating payment approval and preparing payment files — meaning a batch cannot proceed to execution until the payment approval step is satisfied. Yooz documents configurable, role-based approval hierarchies designed to enforce segregation of duties, with 'payment authorization' called out as a distinct process step assigned to specific individuals separate from those who prepare or process invoices, supporting the buyer's requirement that a CFO or Controller role hold a mandatory electronic sign-off before any batch is released. The Captivea partner documentation for Yooz Rising confirms 'electronic payment approvals' is a named, discrete workflow action, and Yooz's payment approval documentation states organizations can 'establish clear and documented permission levels for various types and levels of transactions' with the explicit goal of ensuring 'payments are approved by the right individuals.' Audit-trail capture of the approver's identity and timestamp is documented as part of the compliance framework.

Limitations: Granular, help-center-level documentation of exactly how a payment batch is held in a 'pending release' queue and what happens if the designated CFO/Controller is unavailable (delegation rules, escalation timers) was not surfaced in search results; the buyer should confirm during a product demo that the batch-release gate cannot be bypassed and that a single role cannot both prepare and approve the same payment batch.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a $120M multi-location services company with bi-weekly check runs and monthly ACH batches, Quadient AP's Payments module addresses this requirement through a dedicated payment-level Approval Channel that is separate from the invoice approval workflow. The Payments module allows approving invoice payments based on the approval matrix setup before export to the accounting system. The CFO or Controller is configured as a named required approver within that channel: payment Approval Channels can be based on dollar amount, Org Units, or a combination of both, and only System Administrators can create or edit those channels. Once a payment batch is assembled, it cannot be released until every required approver has acted: each approver's action is recorded in the payment's Approval History, and if multiple approvers are in the workflow, the payment stays in Pending Approval status showing who is still required to approve. The Quadient payments page explicitly frames this as a gate: once payments have completed the approval process they can be released, and the company retains control over which payments are exported to the accounting software and when. The product also uses the phrase 'signing authorities' to describe this role: automated payment batches are submitted to signing authorities for approval in seconds. Approval delegation is also documented so the CFO or Controller can reassign authority during absences without disrupting the batch release control: Approval Channel Delegation allows transfer of approval authority to another colleague, either temporarily to cover a vacation or leave, or permanently.

Limitations: The approval channel configuration for payments is scoped to Org Unit and dollar amount as the routing criteria; the help documentation does not describe invoice attribute-based or vendor-based routing at the payment-batch level, so buyers needing highly context-aware payment gating (for example, routing by vendor category rather than org unit) should verify that level of granularity with Quadient. The Payments module must be enabled by a Customer Success Manager and is not self-serve on initial setup.

Buyer requirement: Approval routing must be configurable to route each invoice line, or a split-coded invoice, to the owner of the specific dimension values coded on that line (e.g., the project manager for the project dimension, the department head for the department dimension), not just a fixed sequential chain applied at the invoice header level. This satisfies stage 5 of the pre-processing journey: the budget owner, not AP, must validate cost allocation, and that owner is determined by the dimension values on each line.

For a multi-entity SaaS company on Sage Intacct with heavy dimensional coding, Quadient AP uses 'Approval Channels' as its routing engine. Channels are configured with criteria drawn from three sources: dollar-amount thresholds, ERP lists (which can include GL accounts, vendors, and other synced list items), and Org Units. Critically, the help center confirms that channel matching happens at the line-item level: the system checks whether any active channel matches the coding on each line when an invoice is submitted, and the error 'No Approval Channels match line items' fires if no configured channel covers the coded values. Approval Channels are built using a variety of criteria including dollar amounts, ERP lists, and Org Units, and a background process determines which Approval Channels a transaction matches when it gets submitted for approval. Org Units are subsections created under a Legal Entity that often mirror a company's department structure, and an Org Unit is assigned to each line of a transaction. This means the system can, in principle, route an invoice to a different channel based on which department (Org Unit) or GL account is coded on its lines. However, the approver identity within each channel is statically pre-configured: multiple approvers can be added to Approval Channels, and when a channel has multiple approvers the transaction goes one by one to each user for approval in the configured order. There is no documented mechanism for dynamically resolving the approver from the Intacct dimension value itself (e.g., reading the project manager field in Intacct and routing to that person). The buyer's requirement calls for the project manager for a given Project ID, or the department head for a given Department ID, to be resolved automatically from the dimension master data; Quadient AP's channel model instead requires an administrator to pre-build a separate channel per dimension value and manually assign the correct approver to each. Customized routing can create separate approval routes for invoices based on location, department, project, or vendor. This covers stage 5 of the pre-processing journey in a rules-driven way, but the resolution of 'which owner' for each dimension value is a static configuration task, not a dynamic lookup from Intacct dimension ownership data. For Intacct's full dimension set beyond Org Unit (project, class, location, and custom dimensions), these would be represented as ERP lists in channel criteria, but coverage of all Intacct custom dimensions as routing triggers and dynamic owner resolution from those dimensions is not documented.

Limitations: The material ceiling is that approver resolution is statically configured per channel rather than dynamically derived from Intacct dimension master data (e.g., the project manager field on a Project record), which means every new project, department, or custom dimension value requires an administrator to manually create or update an Approval Channel and assign the correct owner. For a buyer coding across five or more Intacct dimensions with many active values, this creates a large and fragile channel maintenance burden, and there is no documented path to auto-escalation or parallel split routing where each line's dimension value simultaneously forks to its respective owner.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a multi-location services company running bi-weekly check and monthly ACH batches through Sage Intacct, Concur Invoice Pay provides a dedicated batch release gate that directly addresses the CFO/Controller sign-off requirement. Within the Invoice Payment Manager module, administrators enable the 'Require Batches to be Released' checkbox in the check configuration and ACH funding account settings. Once enabled, every closed payment batch enters a 'Pending Release' status and is held from transmission to the payment provider until a user holding the 'Payment Release Manager' role takes explicit action. As SAP's Invoice Pay training documentation states, batches with this status 'must be manually released for payment by a user assigned to the Payment Release Manager role' and are released 'by selecting Release Payment from the Actions button.' The CFO or Controller is assigned the Payment Release Manager role, creating a hard electronic gate: no check run or ACH batch reaches the bank until that named individual acts. This separates payment creation (handled by AP staff with the Invoice Payment Manager role) from payment authorization (restricted to the Payment Release Manager), enforcing segregation of duties at the batch execution stage.

Limitations: The batch release gate operates within Concur Invoice Pay, so this control applies only to payments processed through that module; invoices paid outside Concur (marked as 'Client Pay' and executed in Sage Intacct directly) would bypass this gate entirely. The Payment Release Manager role can be assigned to multiple users, so the buyer should restrict assignment to CFO and Controller only to preserve the single-authority control they described.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a 3-person AP team at a $120M services company requiring mandatory CFO or Controller sign-off before any payment batch reaches the bank, SAP Concur Invoice provides this control through its Invoice Payment Manager module. Administrators enable the 'Require Batches to be Released' setting at the funding account or check configuration level; once enabled, every closed batch enters a 'Pending Release' status and is held in queue until a human action unlocks it. "By selecting the Require Batches to be Released (optional) setting, you can allow for manual approval/release of batches after their configured close time, before payments are sent to payment providers for processing." The mechanism enforces segregation of duties through a dedicated role: a new 'Release Payments' action releases pending-status payment batches to the provider, and a distinct 'Payment Release Manager' role exists specifically for separation of duty to authorize access to the approval/release process. The buyer assigns this role exclusively to the CFO and Controller user accounts, making their explicit electronic action the hard gate. Batches with Pending Release status must be manually released by a user assigned to the 'Is Payment Release Manager?' role, and are released by selecting 'Release Payment' from the Actions button. For check configuration specifically, it can be set so that an additional user's approval is required before releasing a batch for payment, by selecting the 'Require Batches to be Released' checkbox; the approving user must hold the Invoice Payment Manager and Payment Release Manager roles. This places the payment release control at the execution stage, after invoice-level approvals are complete, satisfying the buyer's requirement for a discrete payment authorization gate separate from the invoice approval workflow.

Limitations: The 'Require Batches to be Released' setting is opt-in and must be explicitly configured per funding account and check configuration; it is not on by default, so implementation discipline is required to ensure no payment channel is inadvertently left in auto-release mode. Additionally, this hard gate applies to payments processed through Concur's own Invoice Pay infrastructure (ACH and check); if the buyer instead exports a payment file to Sage Intacct or their bank directly, the release control must be enforced at the ERP or bank layer, not within Concur.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

This $120M, 6-location services company running 2 Sage Intacct entities needs approval chains that respond to seven distinct attributes: dollar threshold, department, GL account, vendor, entity, expense type, and project. MineralTree's Invoice Approval Rule engine, configured by an Accounting Manager via the Invoice Approval Rule tab, does support attribute-based routing: after global rules are set in the Customer Administration Application, users assign default approvers to different routing attributes within the Company Profile on the Invoice Approval Rule tab, defining how many tiers of approval are required, the dollar thresholds for each tier, and the names of approvers in each tier. As invoices arrive, approvers are assigned based on routing rules, and if more than one rule applies, a precedence ranking determines which attribute is used; accounting managers can also override rules for specific invoices as needed. On dollar thresholds specifically, at the global level, companies set invoice approval thresholds that determine how many approvals an invoice needs based on dollar amount; up to four levels of approval can be added, with configurable dollar thresholds at which each subsequent level is triggered. For Sage Intacct, the precedence table defines the attributes available for invoice approval routing by accounting system, with an example showing Location taking precedence over Department when both rules apply to the same invoice in Intacct. Vendor-name routing is documented: all invoices can require approval with high-dollar invoices requiring two approvals, and specific approvers can be assigned based on vendor name. The routing architecture is sequential by default: when an invoice requires more than one level of approval, invoice requests are sent sequentially, so second-level approvers are not notified until the first level has approved. The material gap for this buyer is the routing attribute set. The buyer requires routing by GL account, expense type, and project in addition to vendor, department, entity, and dollar threshold. Specific invoice attributes available for routing vary by accounting software, and the documented Intacct attribute examples reference Location and Department. GL account, expense type, and project as independent routing triggers are not confirmed in any help-center documentation found. Additionally, the approval architecture is fixed-sequential (up to four tiers) with a winner-takes-all precedence rule when multiple attributes match; there is no evidence of parallel routing or mid-flow dynamic addition of stakeholders, which limits coverage of the buyer's stage-3 (terms verification by contract owner) and stage-5 (cost allocation by budget owner) collaboration needs. A hospitality and property management customer noted that MineralTree's multi-entity capabilities and flexible design let them maintain their unique approval processes, suggesting the multi-entity routing the buyer needs across their 2 Intacct entities is workable, though confirmation that "entity" functions as a discrete routing trigger (not just a data tag) was not found in help-center documentation.

Limitations: The routing attribute set confirmed in help-center documentation covers vendor, dollar threshold, and location/department for Intacct, but GL account, expense type, and project as independent approval-routing triggers are not verified. The precedence-based rule engine (one winning attribute per invoice) means the buyer cannot simultaneously enforce department-level and GL account-level routing on a single invoice, which will require manual overrides for their mixed PO and non-PO invoice population.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For this $120M services company running bi-weekly check runs and monthly ACH batches through a 3-person AP team, MineralTree delivers a structurally enforced, two-step payment authorization model that directly meets the CFO/Controller gate requirement. The AP team (Accounting Manager role) builds the payment queue and submits it, at which point payments enter an 'Awaiting Payment Approval' state in a dedicated Payment Authorization application. Payment Authorizers log in to the Payment Authorization application to review summary or full payment details, approve payments for submission, or reject payments back to Accounting Managers for review and resubmission. Critically, the Payment Authorizer and Accounting Manager roles cannot be combined for the same user, which means the CFO or Controller cannot self-approve payments they also prepared: segregation of duties is a system-enforced control, not a policy overlay. Up to two levels of payment approval can be enabled before release, and by checking the 'Send request in sequential order' box, the second approver receives a notification only after the first approver has acted, supporting a sequential CFO-then-Controller chain if needed. The CFO or Controller is automatically notified once payments are set up, and can authorize with a single tap from any device. Standardized approvals, role-based permissions, and audit trails reduce risk and help ensure compliance.

Limitations: Payment approval thresholds are configured by dollar amount, so the buyer must set a $0 threshold to ensure every batch (including small ACH and utility payments) requires CFO or Controller sign-off; this is achievable but requires intentional configuration rather than a single 'require approval on all batches' toggle. The payment approval architecture supports a maximum of two approval levels before release, which is sufficient for this buyer's single-gate CFO/Controller requirement but would constrain any future need for a three-tier payment authorization chain.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a 3-person AP team routing 1,800 invoices per month across 2 Sage Intacct entities, Vic.ai's 'Autonomous Approval Flows' engine (documented in the help center at intercom.help/vicai) is the operative mechanism. Admins build named approval flow rules that evaluate invoice attributes as triggers: approval flows trigger based upon vendor, amount, GL account, as well as dimension, and delineate exactly which approver(s) need to be involved for every feasible scenario. Multiple trigger types combine using AND logic across different attribute types (e.g., vendor AND location) and OR logic within the same type (e.g., department is Engineering, HR, or Sales), with different triggers functioning as AND connectors while multiple instances of the same trigger function as OR connectors. An approval can be launched based on nearly any condition or set of conditions, including GL account, vendor, or amount, and dimensions such as location, class, and much more. The system evaluates flows top-to-bottom and applies the first matching rule, with a recommended fallback flow at the bottom for unmatched invoices. Critically for this buyer's 2-entity Sage Intacct environment, the platform creates distinct, tailored approval workflows for different entities under the same corporate umbrella, simplifying management and enhancing compliance. Mid-workflow recoding is handled dynamically: if an invoice is re-coded in a way that impacts routing triggers (e.g., project or dimension), Vic.ai automatically recalculates and updates the approval flow with no rejection or manual reset required. Escalation is also addressed: auto-escalation of invoice approvals via timed reminders and escalations notifies managers when approvals stall, preventing bottlenecks. Role-based routing is available via HRIS integration: by integrating directly with your HR system, Vic.ai can automatically assign individuals to approval flows based on their role and seamlessly update these workflows as your organization evolves. This covers pre-processing journey stages 1 (legitimacy), 3 (terms/cost allocation), and 5 (GL/dimension coding) through structured, rules-driven human review before ERP posting.

Limitations: The buyer's requirement names 'expense type' as a discrete routing dimension; Vic.ai's documented triggers use GL account and ERP dimensions (class, location, department, project) as the functional equivalent, but 'expense type' is not named as a discrete trigger label, so buyers should confirm this maps cleanly to their Sage Intacct dimension structure during implementation. Additionally, there is a maximum of 100 different Approval Flows per company that can be created, which is workable for this buyer's volume but should be factored into workflow design across 2 entities and 7 routing dimensions to avoid rule sprawl.

Buyer requirement: The solution must support dynamic approval routing that can be configured by NetSuite department, class, or project segment, allowing entertainment production budgets and overhead spend to follow separate approval chains, with role-specific invoice data visibility so that approvers see only the entities and cost centers they are authorized to approve.

For an entertainment business running NetSuite with separate production budget and overhead spend chains, BILL offers approval policies configured via Settings > Approval Routing. BILL's own AP Controls product page documents that 'Enhanced approval policies allow you to route transaction approvals automatically to designated approvers and approver groups' and lists vendor, location, department, and GL account as routing criteria. The NetSuite sync preserves classes, departments, subsidiaries, and locations as synced segments, meaning those dimensions are available inside BILL when building policies. However, BILL's documented routing criteria stop at vendor, location, department, and GL account; there is no documented mechanism to condition routing on NetSuite class or project segment specifically, which are the two dimensions this entertainment buyer needs to separate production budgets from overhead. On role-specific data visibility, BILL uses six predefined roles (Administrator, Controller, Accountant, Approver, Clerk, Payer) with dollar-threshold limits configurable per Approver, and custom roles available on higher plans; but no documentation confirms that approvers can be scoped to see only invoices belonging to specific entities or cost centers they are authorized for, as opposed to seeing all pending bills in their queue.

Limitations: BILL does not document routing conditions keyed to NetSuite class or project segment, so the entertainment buyer cannot configure separate chains for production vs. overhead spend based on those specific dimensions without workarounds. Approver-level data visibility scoped to specific entities or cost centers is not documented; BILL's role model gates actions (approve, pay) by role and dollar threshold, not by entity or cost-center partition.

Buyer requirement: Approval workflows must route invoices to approvers scoped to the correct production, so that approvers from one production cannot approve invoices belonging to another, and approval chains can be configured independently per production. The routing logic must respect the same profit-center-based isolation that governs invoice visibility, ensuring the approval stage does not create a cross-unit exposure that the visibility layer prevents at the inbox stage.

For a media production company running 9 profit centers inside one Sage Intacct entity, BILL's 'Enhanced Approval Policies' feature does allow routing conditions based on department, location, and general ledger account, meaning an invoice coded to Production A can be directed to the approver pool designated for Production A. BILL's product documentation states that enhanced approval policies let you 'route by vendor, location, department, general ledger account, and more' and 'route transaction approvals automatically to designated approvers and approver groups with an expanded set of routing criteria.' However, the critical gap for this buyer is at the permission enforcement layer: BILL's user roles are entity-wide. The six predefined roles (administrator, accountant, clerk, approver, payer, auditor) grant approval authority across the entire BILL organization, not scoped to a dimension or profit center. Custom roles 'may be available for more granular permissions settings, depending on the account's price plan,' but no documented mechanism restricts an individual approver's authority to only invoices coded to their assigned production. The Approver role surfaces all bills assigned to that user on a single Pending Approvals screen, with no system-enforced dimension mask. This means routing can send Production A invoices to Production A's approver, but that same approver, holding an entity-wide approver role, is not systemically blocked from acting on Production B invoices if they are manually reassigned or if policies overlap. The buyer's requirement that 'approvers from one production cannot approve invoices belonging to another' is a hard enforcement requirement that BILL's role architecture cannot satisfy at the system level.

Limitations: BILL's Enhanced Approval Policies provide dimension-based routing (the invoice goes to the right approver) but not dimension-scoped authority restriction (the approver cannot be prevented at the role level from acting on other productions' invoices), so cross-unit approval exposure is a policy discipline problem rather than a system-enforced control. Additionally, BILL maps Intacct dimensions to its own 'department' and 'location' fields, and whether Intacct profit centers map cleanly to these routing conditions without data loss requires implementation verification.

Buyer requirement: When automated three-way match produces a mismatch, whether on price, quantity, or line-item discrepancy, the system must route the exception to a defined handler with context showing exactly which of the three documents diverges and by how much, rather than returning the invoice to a generic queue. Exception workflows must support configurable tolerance thresholds so that minor variances within an acceptable percentage are auto-approved rather than escalating every discrepancy.

For a distribution company on NetSuite whose three-way match is currently broken, BILL offers a Link-Review-Approve flow: when a vendor submits an invoice, the AP user links the correct PO, and the reviewer goes over items, prices, received quantities (for three-way match), and BILL alerts if there are variances. Once matching is complete, the bill is automatically sent through the payment approval workflow, with automated approval workflows preassigned by the administrator. A third-party analysis comparing BILL's PO workflow capabilities notes that BILL does support invoice approvals, but it is not designed for complex workflows: you cannot route approvals based on department, project, or vendor, and you cannot set rules for who approves what. One aggregated comparison source does credit BILL with automated 2-way and 3-way matching across invoices, purchase orders, and receipts, with configurable tolerance limits, but BILL's own help documentation and feature blog provide no mechanism description for percentage-based tolerance thresholds, tiered escalation by variance type or magnitude, or a side-by-side diff view identifying exactly which of the three documents diverges. BILL's three-way match receipt population is also documented only for QuickBooks Desktop: item receipt quantities for three-way match users populate for goods marked received in QuickBooks Desktop, leaving the receipt-leg integration for NetSuite less clearly supported within BILL's own matching engine.

Limitations: The buyer's requirement for configurable tolerance thresholds that auto-approve minor variances, plus named-handler routing with document-level variance attribution (showing exactly which of PO, receipt, or invoice diverges and by how much), is not evidenced in BILL's own product documentation; variance alerts and administrator-preassigned approval chains exist, but the rule-based, context-rich exception escalation logic the buyer needs appears to sit outside BILL's current AP workflow capabilities. Additionally, BILL's receipt-leg of three-way match is only documented for QuickBooks Desktop, raising a material question about whether true three-way match (not two-way) can be executed inside BILL for this NetSuite-based buyer.

Buyer requirement: Approval routing for purchase requests and POs must dynamically assign approvers based on spend category, dollar threshold, and department, supporting the mid-market distribution context where different categories of operational spend (freight, inventory replenishment, services) may have different approval chains. Approvers must see the remaining budget for the relevant cost center or department at the time they act, not just the request amount in isolation.

For a mid-market distribution company needing category-differentiated approval chains (freight vs. inventory replenishment vs. services) with real-time budget visibility at the moment of approval, BILL offers a partial solution across two separate modules. In its core AP product, BILL's 'Enhanced Approval Policies' can route transaction approvals to designated approvers and approver groups using criteria including vendor, location, department, and general ledger account — offering some multi-dimensional routing. However, BILL's own developer API documentation shows the underlying policy engine is primarily amount-threshold-gated: a policy is created with a dollar threshold, and when a bill crosses that threshold, approvers are assigned — with the 'Smart Data' feature remembering and auto-assigning the same approvers for the same vendor on future bills. This vendor-memory approach is not a true AND-logic matrix across category, threshold, and department simultaneously, which means differentiating freight from inventory from services in separate approval chains is not clearly supported. In BILL Spend & Expense (the Divvy-derived card module), budgets can be mapped to departments and cards, and 'real-time visibility and alerts help prevent overspending'; but this module is oriented toward card-based spend, not PO-based purchase requests, and there is no documented mechanism that surfaces the cost center's remaining budget balance inline at the AP approver action screen at the moment they act on a PO-backed invoice.

Limitations: The critical gap for this buyer is twofold: first, BILL's AP approval engine does not demonstrate a self-service approval matrix where freight, inventory, and services spend each trigger distinct, independently configured chains — a third-party analysis of BILL specifically notes 'you can't route approvals based on department, project, or vendor' in the context of PO workflows; second, there is no documented inline budget-remaining widget surfaced to the approver at the moment of decision, which is the buyer's explicit requirement and which would require navigating to a separate dashboard, breaking the approval action context.

Buyer requirement: Approval routing must operate across all 14 NetSuite OneWorld subsidiaries from the shared-services AP team while enforcing per-subsidiary book isolation: approvers in Subsidiary A must not be able to view, act on, or influence invoices belonging to Subsidiary B's books unless explicitly granted cross-entity access. The routing architecture must support threshold-based and context-aware chain adaptation (by subsidiary, GL account, or cost dimension) so that the correct entity's controllers and budget owners are engaged at the cost-allocation and terms-verification stages without manual queue management by the AP team.

This buyer runs a shared-services AP team processing 8,000 invoices monthly across 14 NetSuite OneWorld subsidiaries and requires that approval routing automatically enforce per-subsidiary book isolation with context-aware chain adaptation by subsidiary, GL account, and cost dimension. BILL's Multi-Entity feature is architected as a collection of separate BILL organizations, each with its own approval policy, where users must manually switch between organizations rather than operating from a unified cross-entity AP queue: as documented in third-party user management analysis, 'users belonging to multiple Bill.com organizations must manually switch between orgs with no unified dashboard.' BILL's documented approval routing mechanism is amount-threshold-based: the developer API platform confirms that 'when an approval policy is in place for paying a bill, the bill payment requires approval if the amount is above the policy threshold,' with no documented routing conditions based on NetSuite subsidiary, GL account, or cost dimension. BILL's role model is a fixed predefined set with no granular custom role creation, meaning the per-subsidiary access control enforcement this buyer requires (approvers in Subsidiary A cannot view Subsidiary B invoices unless explicitly granted) cannot be configured at the object or subsidiary level. The combination of manual org-switching architecture, amount-only routing conditions, and fixed role model means the buyer's shared-services team would need to manually queue-manage invoices to the correct entity workflow, which is precisely the manual overhead this requirement is designed to eliminate.

Limitations: BILL's multi-entity model is designed for SMB accounting firms managing separate client organizations, not for a single enterprise running a shared-services AP function across 14 legal subsidiaries requiring automated context-aware routing, in-flight book isolation, and GL/cost-dimension-driven chain adaptation. The architecture cannot be configured to meet this requirement without rebuilding the buyer's AP process around manual entity switching, and even then the routing intelligence gap (no GL-account or subsidiary-context routing) remains unresolvable within the product.

Buyer requirement: Approvers must be able to receive, review invoice details and coding, and take approval actions (approve, reject, request information, delegate) directly within Microsoft Teams, without being required to authenticate into a separate AP portal or web application. The Teams-native experience must surface the full invoice image, line-level coding, and any attached supporting documents so that approvers can make informed decisions without context-switching, addressing stage 5 approval routing in the buyer's primary collaboration environment.

This buyer operates a Microsoft-centric finance organization where approvers live in Teams and the requirement is for full in-Teams approval actions, including invoice image, line-level coding, supporting documents, and approve/reject/delegate/request-information actions without an external portal login. BILL's documented approver experience operates through email notifications and its own mobile app: approvers receive a notification and take action inside BILL's own web or mobile UI. BILL's official integrations page lists a native Slack integration for spend and expense fund-request approvals, but lists no Microsoft Teams app or Teams-native approval channel for AP invoice workflows. The only documented path to connecting BILL with Teams runs through third-party middleware such as Workato, which surfaces exception notifications in Teams chat but does not deliver in-Teams approval actions, invoice image rendering, or line-level coding visibility, matching the anti-pattern of a notification-only bot that still redirects to the vendor portal for any action.

Limitations: BILL has no native Microsoft Teams app and no Adaptive Card-based approval mechanism for AP invoices; every approval action requires the approver to authenticate into BILL's own portal or mobile app, which directly breaks this buyer's Teams-native, no-separate-login requirement. For a D365 multi-entity organization whose finance team works primarily in Teams, this is a fundamental architectural mismatch, not a configuration gap.

Buyer requirement: Approval routing must be configurable to route each invoice line, or a split-coded invoice, to the owner of the specific dimension values coded on that line (e.g., the project manager for the project dimension, the department head for the department dimension), not just a fixed sequential chain applied at the invoice header level. This satisfies stage 5 of the pre-processing journey: the budget owner, not AP, must validate cost allocation, and that owner is determined by the dimension values on each line.

For a multi-entity SaaS company coding invoices across location, department, project, class, and custom Intacct dimensions, the buyer needs the approval engine to read those line-level dimension values and dynamically resolve the correct approver per line. BILL's documented approval policy model does not support this. According to BILL's own API platform documentation, approval policies are configured at the bill (header) level with conditions limited to invoice amount thresholds and minimum approver counts; a bill approval policy is a set of rules that controls which bills require approval, by whom, and when, with a representative example showing all bills above $1,000 routing to two pre-assigned approvers. The approver assignment mechanism is a fixed sequential array of named users or groups set at the bill object level, not at the line item level: the SetApprovers endpoint requires an objectId (the bill or vendor credit) and an array of user IDs, where the order of users in the array defines the sequence of approvals required. BILL's 'Smart Data Entry' feature, which is the closest thing to dynamic approver resolution, is vendor-pattern memory, not dimension-driven: when you set approvers to a bill for a vendor, the Smart Data feature remembers and automatically assigns the same approvers on the next bill for the same vendor. No mechanism exists in BILL to read a Project ID, Department ID, Class, or custom Intacct dimension coded on a specific line and fork routing to the owner of that dimension value. This means the system cannot satisfy stage 5 of the pre-processing journey (budget owner validation per cost allocation) when lines are split across multiple dimension owners, because the entire invoice routes to a single pre-configured approver chain regardless of what is coded at the line level.

Limitations: BILL's approval policy engine is header-level and amount-triggered, with no line-level dimension-to-approver mapping capability; a split-coded invoice with three different project managers on three lines cannot be routed to each respective project manager automatically. This is a structural gap in the product model, not a configuration limitation, and no workaround within BILL closes it for the buyer's described process.

Buyer requirement: Approval routing must be conditional on two independent variables simultaneously: the legal entity on the invoice (US parent or either UK subsidiary) and the invoice amount threshold, producing different approval chains for each entity-threshold combination. The routing engine must support mid-flow context-aware branching so that a UK invoice above a defined threshold follows a different chain than a US invoice at the same amount, without requiring separate workflow configurations for every permutation.

For this buyer: a Sage Intacct-connected, 3-entity services company needing approval chains that branch on both legal entity (US parent or either UK subsidiary) and amount threshold simultaneously, BILL's approval policy engine falls categorically short. BILL's documented approval policy mechanism is amount-only: policies require approvers for any bill or vendor credit based on the dollar amount, with no entity, subsidiary, or other invoice attribute available as a co-equal conditional input. The API developer documentation confirms the same architecture, showing rules and approvers set by amount range, for example all bills greater than or equal to $1,000, with no compound condition syntax. BILL's multi-entity approach further compounds the problem: each entity has its own separate workflow, and users must switch between entities and set up separate vendors, approval rules, and chart of accounts for each one. This is precisely the 'separate workflow configuration for every permutation' anti-pattern the buyer explicitly needs to avoid. There is no documented rule builder that accepts legal entity as a routing variable alongside amount within a single unified workflow engine.

Limitations: BILL's approval engine is architecturally constrained to amount-based policies within a single account context; entity-level branching requires fully separate BILL accounts with independent approval configurations, making a shared conditional routing matrix across the US parent and two UK subsidiaries structurally impossible without manual per-entity duplication and account switching.

Buyer requirement: The system must enforce a fixed two-tier sequential approval chain, manager review followed by CFO approval, configurable per vendor or per invoice amount threshold, with auto-escalation when an approver does not act within a defined time window and delegation capability when either approver is unavailable. This maps directly to the buyer's stated process and sits at the legitimacy and cost-allocation stages; approvers must see the full coded invoice (vendor, amount, GL account, line detail) inside the approval interface without needing to open QuickBooks Online separately.

For this 50-person SaaS startup, BILL's Approval Policies module delivers the core sequential two-tier chain with solid coverage at the legitimacy and cost-allocation stages of the pre-processing journey. Administrators configure amount-threshold policies (e.g., all bills above $X require two named approvers), and the order in which approvers are added to the policy is the enforced sequence: if multiple approvers are assigned to a bill, approver 1 must approve before approver 2 can. The API data model confirms this with an explicit `approverOrder` field (0, 1) per approver, and approval policies are created at the organization level, with configurable rules including payment amount threshold, mandatory approvers, and minimum number of approvers. Per-vendor routing is handled by Smart Data Entry: when approvers are set for a bill for a vendor, BILL's Smart Data feature remembers and automatically assigns the same approvers on the next bill for the same vendor. The approver interface is BILL-native and does not require a QBO login: the approver reviews the bill document received from the vendor and the transaction information recorded to the general ledger, confirming all information is accurate and the purchase is legitimate, and pending bill details include invoice number, vendor, due date, amount, and more inside BILL's Approvals screen. Enhanced approval policies extend routing criteria further: custom approval criteria can route by vendor, location, department, general ledger account, and more. However, two sub-requirements fall materially short. On escalation, BILL's documented mechanism is a manual nudge, not a timer-driven auto-reassignment: if an approver has not yet approved a bill or credit, a reminder email can be sent from the bill itself, prompting the approver that the bill is waiting for their review. There is no configurable inactivity window that automatically escalates or reassigns without AP staff intervention. On delegation, BILL's coverage mechanism is approval groups: approval groups are a designated group of approvers assigned to bills or policies, any approver in the group can approve the bill, and once one approver from the group has approved, the bill is routed to the next approver or approval group. This provides coverage-by-pool but does not constitute named-substitute out-of-office delegation where an individual designates a temporary replacement without admin involvement.

Limitations: Auto-escalation on timeout is not available as a system-enforced timer: BILL requires AP staff to manually send reminders, creating a human-dependent gap that can stall the manager-to-CFO sequential gate if no one is monitoring the queue. Formal out-of-office delegation to a named substitute requires admin-level approver reassignment rather than self-service delegation, introducing an audit-trail and operational friction risk for a startup where the CFO or manager may be frequently unavailable.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

This $120M services company needs routing logic that spans seven dimensions simultaneously: dollar threshold, department, GL account, vendor, entity, expense type, and project. BILL addresses this through its 'Enhanced Approval Policies' module (Settings > Approval Policies), which supports multi-step sequential approval chains where multiple policies can stack on a single bill and approvers are ordered across policies. The product page at bill.com/product/accounts-payable-controls confirms routing by vendor, location, department, and general ledger account as named routing criteria, and the developer API docs confirm amount threshold as a native rule key (BILL_AMOUNT) with sequential approver ordering. Where a bill matches multiple policies simultaneously, BILL merges all required approvers into a single ordered chain without duplicating the same approver twice. This covers pre-processing journey stages 1 through 2 (legitimacy and PO match coordination) plus the cost allocation confirmation step, but the documented routing dimensions stop short of the buyer's full list: expense type and project are not named as native policy conditions in any BILL source found, and the buyer's two Sage Intacct entities require either two separate BILL organizations or reliance on the Multi-Entity Approvals grid, which is designed for accountant-console cross-client use and does not natively route within a single BILL org by Intacct entity.

Limitations: Two of the seven required routing dimensions, expense type and project, are not documented as supported conditions in BILL's Enhanced Approval Policies engine, meaning those routing rules would need to be approximated through manual approver assignment or workarounds rather than policy-driven automation. The buyer's dual Sage Intacct entity structure adds a second constraint: BILL's standard Approval Policy engine operates at the organization level, and per-entity approval chains for a multi-entity Intacct setup are not natively supported within a single BILL account.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a $120M multi-location services company routing 1,800 invoices/month across 2 Sage Intacct entities, BILL's approval workflow engine operates at pre-payment authorization (stage 5 of the pre-processing journey) using two layers: a standard Approval Policy tier and an 'Enhanced Approval Policies' tier. The Enhanced tier is the relevant mechanism here: it routes transaction approvals automatically to designated approvers and approver groups with an expanded set of routing criteria, including vendor, location, department, and general ledger account. Multi-step sequential chains are supported: approval policies can be set based on dollar amount, and administrators can require a minimum number of approvers, specific approvers, or both. The ordering is strictly sequential: if multiple approvers are assigned to a bill, approver 1 must approve before approver 2 can. A Smart Data layer assists with vendor-level approver memory: when approvers are set for a bill for a vendor, the Smart Data feature remembers and automatically assigns those same approvers on the next bill for the same vendor. However, BILL's documented routing conditions for AP bills cover vendor, location, department, and GL account; the buyer's additional required dimensions of project, expense type, and Sage Intacct entity (as a discrete policy trigger within a single BILL organization) are not confirmed as native routing conditions in any BILL help center or API documentation found.

Limitations: Three of the buyer's seven required routing dimensions (project, expense type, and entity-level routing across 2 Sage Intacct entities) are not documented as native AP approval policy conditions in BILL's Enhanced Approval Policies engine. Additionally, BILL's approval architecture is fixed-sequential rather than context-aware mid-flow, meaning the chain cannot adapt dynamically based on mid-invoice attribute combinations across all 7 dimensions simultaneously, which creates rule-sprawl risk for a 3-person AP team managing 1,800 monthly invoices across 2 entities.

Buyer requirement: Approval routing must be configurable per entity so that each of the 8 real estate entities can enforce its own chain of approvers, spending thresholds, and GL-account-based escalations, all within a single AP workflow managed by the 4-person team. Stage 5 of the pre-processing journey (cost allocation sign-off) requires that budget owners see only the invoices and dimensional data belonging to their entity: role-based, entity-scoped visibility controls are required so one entity's approvers cannot view or act on another entity's payables.

For a portfolio of 8 real estate entities, BILL's multi-entity architecture operates through separate BILL company accounts, one per entity. Each account carries its own approval workflow, its own chart of accounts, and its own user roster, which enforces the entity-scoped data isolation the buyer requires at Stage 5: a budget owner assigned to Entity 3's BILL account cannot see invoices belonging to Entity 1 or Entity 7 because the account boundary is the access boundary. Within each account, BILL's Enhanced Approval Policies support routing by vendor, location, department, GL account, and spending thresholds, covering the threshold-based and GL-account-based escalation patterns the buyer needs. The 4-person AP team gains a consolidated action view through BILL's Multi-Entity Approvals (MEA) grid, which surfaces pending bills across all linked accounts in one screen and supports bulk or one-by-one approvals. The architectural ceiling is that this is 8 independently configured policy sets, not a single unified workflow engine with entity-aware routing rules; the buyer's requirement for entity-specific chains 'all within a single AP workflow' is met only at the consolidated action view layer, not at the policy configuration layer. Third-party analysis also notes that above 6 entities, BILL's multi-entity configuration 'grows more burdensome to maintain' as entity-specific coding rules, payment accounts, and vendor handling require manual configuration that a purpose-built multi-entity architecture handles automatically.

Limitations: Each of the 8 entities requires a separately maintained BILL account with its own approval policy configuration, meaning policy changes (new approvers, revised thresholds, updated GL escalation rules) must be replicated manually across all 8 accounts rather than governed from a single policy engine. The NetSuite integration (delivered as 'Intelligent Payment Automation' via a native SuiteApp) syncs per BILL account to a corresponding NetSuite subsidiary, adding configuration overhead for an 8-subsidiary NetSuite OneWorld setup and limiting the depth of NetSuite-native dimensions the buyer can leverage through the BILL layer.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a $120M multi-location services company operating across 2 Sage Intacct entities with a 3-person AP team, AppZen routes invoice approvals through its Autonomous AP module and Low-Code Workflow builder. The AP routing engine is documented as adapting to business rules and sending invoices to the right approver based on invoice amount, vendor, and department, with managers outside finance able to receive direct exception notifications. The Low-Code Workflow builder (AI Agent Studio) allows finance teams to build complex multi-step approval chains, including exception handling and risk-based routing, without coding. However, AppZen's own AP automation product page enumerates the routing dimensions it acts on as: invoice amount, vendor, and department. The buyer's requirement adds GL account, entity, expense type, and project as additional routing criteria. No documented source from AppZen's AP product pages or help center confirms that GL account, expense type, or project code are supported as discrete, configurable routing conditions within the AP approval workflow. Entity-level routing (across the buyer's 2 Sage Intacct entities) is referenced in marketing language about managing invoices across subsidiaries, but no mechanism document describes how entity drives approval chain selection. The Low-Code Workflow builder appears capable of encoding custom logic, but the specific conditions it exposes as routing triggers for AP invoices are not enumerated beyond amount, vendor, and department in any available source.

Limitations: AppZen documents routing by invoice amount, vendor, and department but does not enumerate GL account, expense type, project, or entity as named, configurable routing conditions in its AP approval workflow. Until AppZen confirms in product documentation that these additional dimensions are selectable routing triggers, a buyer with routing requirements across all seven criteria named should treat GL account, expense type, project, and entity routing as unverified and probe these specifically in a demo.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For a $120M multi-location services company requiring CFO or Controller electronic sign-off before any payment batch is released, AppZen does not provide this control at the payment execution stage. AppZen's documented scope covers invoice capture, AI-powered GL coding, PO matching, and invoice-level approval routing. Its own published documentation states that 'any further approvals and GL posting happen within your P2P and ERP systems,' explicitly placing payment-stage authorization outside AppZen's native perimeter. The platform's configurable Low-Code Workflow builder and Smart Routing can enforce role-based approval chains on individual invoices before they are posted, but no evidence exists of a native payment batch queue, a payment run hold/release control, or a mandatory designated-role gate (CFO or Controller) that blocks payment execution until electronic authorization is received. Payment batch release controls for the buyer's bi-weekly check runs and monthly ACH batches would need to be configured within Sage Intacct itself, not within AppZen.

Limitations: AppZen's architecture is an AI pre-processing layer that sits upstream of the ERP; it hands off approved, coded invoices to Sage Intacct and does not operate a payment module of its own. The buyer's critical requirement for a mandatory, role-gated payment batch approval before funds are released cannot be satisfied by AppZen and must be addressed through Sage Intacct's native payment approval controls or a dedicated payment automation layer.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

For this $120M services company requiring CFO or Controller electronic authorization before any payment batch is released, the structural gap is the boundary of AppZen's scope. AppZen's Autonomous AP processes invoices through a defined lifecycle: ingestion, validation, PO matching, audit, GL coding, and invoice-level approval routing. Once an invoice reaches the 'Processed' state, it is returned to the customer's ERP system for payment. AppZen's own blog states explicitly that 'any further approvals and GL posting would happen within your P2P and ERP systems,' and the Workday integration documentation confirms that 'once an invoice is processed, AppZen automatically syncs invoice data back to your financial system for final approvals (if needed) and payment.' There is no documented payment batch queue, payment hold gate, or CFO/Controller role-restricted authorization step within AppZen itself. The buyer's requirement for an electronic payment batch approval living inside the AP automation layer before funds are released is not a capability AppZen provides: that control would need to be configured inside Sage Intacct's own payment run workflow.

Limitations: AppZen's approval architecture is entirely invoice-level: it routes individual invoices to designated approvers during processing, but has no payment batch release layer where a named executive (CFO, Controller) must provide an electronic sign-off before a check run or ACH batch is submitted to the bank. This is a structural ceiling, not a configuration gap; the buyer's payment authorization control would need to be enforced in Sage Intacct, meaning AppZen cannot be the system of record for this specific internal control.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a $120M multi-location services company running 1,800 invoices per month across 2 Sage Intacct entities, AppZen's approval routing operates through its Autonomous AP layer and a low-code 'Mastermind' workflow builder. The AP automation page confirms the AI 'sends invoices to the right approver every time, based on the invoice amount, vendor, department, and its understanding of your business policy,' and the low-code workflows module supports building 'simple approvals to complex multi-approval processes' including 'automated invoice routing' without coding. However, the confirmed routing dimensions for AP invoices are invoice amount, vendor, and department: GL account, entity, expense type (as an AP invoice attribute), and project are not documented as explicit routing condition triggers in AppZen's AP workflow engine. A key signal from AppZen's own blog is that 'any further approvals and GL posting would happen within your P2P and ERP systems,' suggesting AppZen may hand off deeper dimension-based routing to the downstream ERP rather than resolving it natively. The Smart Workflow and multi-level approval chain capabilities are more fully documented in AppZen's T&E/expense audit context than in the AP invoice context.

Limitations: AppZen explicitly confirms only three of the buyer's seven required routing dimensions for AP invoices (amount, vendor, department); GL account, entity, expense type, and project are not documented as AP approval routing triggers, and AppZen's own documentation signals that ERP-side approval logic may be required to fill the gap. Additionally, Sage Intacct is not among AppZen's named ERP connectors (Oracle, SAP ECC, Workday, Coupa, NetSuite, Microsoft are listed), raising a further integration question that would need to be resolved before the full routing chain can function end to end.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a multi-location services company running 1,800 invoices per month across two Sage Intacct entities, Expensify's approval routing operates through its Advanced Approval mode configured at the Workspace level. The documented mechanism covers three of the seven routing dimensions the buyer specified. First, dollar threshold escalation: per-member rules let admins set 'If report total is over $X, then Approves To [person],' adding an extra approver level when amounts exceed the configured limit. Second, GL account and expense type routing: Expensify's Category Rules allow admins to assign a specific approver to each category (which maps to GL accounts imported from Sage Intacct), and any report containing expenses in that category is routed to the category approver before moving up the main chain. Third, tags can represent departments, projects, and other Intacct dimensions, and tag-level approvers are supported in the same way. What is not documented in Expensify's help center is vendor-based routing (routing an invoice differently based on which vendor sent it) or entity-based routing as a condition within a single workflow: because Expensify scopes approval workflows to individual Workspaces, the two Sage Intacct entities would require separate Workspaces, which separates configuration rather than enabling entity as a live routing variable. The bill-pay workflow for vendor invoices uses the same workspace-level routing engine as expense reports, with no documented additional routing logic specific to AP invoices.

Limitations: Vendor-based routing and true entity-based routing as dynamic workflow conditions within a single approval chain are not documented in Expensify's help center, meaning those two of the buyer's seven required dimensions are not addressed by the mechanism. The routing model is organized around submitter identity and category or tag overlays rather than a rules matrix that evaluates multiple invoice attributes simultaneously, which means compound logic such as 'if vendor = Subcontractor X AND amount > $50,000 then route to VP Operations' cannot be configured.

Buyer requirement: Approval routing must be configurable to route each invoice line, or a split-coded invoice, to the owner of the specific dimension values coded on that line (e.g., the project manager for the project dimension, the department head for the department dimension), not just a fixed sequential chain applied at the invoice header level. This satisfies stage 5 of the pre-processing journey: the budget owner, not AP, must validate cost allocation, and that owner is determined by the dimension values on each line.

For a multi-entity SaaS company on Sage Intacct with heavy dimensional reporting, Sage AP Automation (powered by Beanworks/Quadient) offers configurable approval channels that can route based on invoice-level attributes such as amount, vendor, GL account, department, and manager hierarchy. The Sage Intacct native approval engine supports routing to the 'transactions department manager' or 'transactions project manager,' meaning it can resolve the approver from the department or project dimension coded on the transaction. Third-party documentation notes that 'a multi-step approval can trigger if multiple departments or entities are involved in a single invoice' and gives the example of an IT invoice allocated to Marketing and Sales requiring each department manager to approve their portion. However, the documented routing triggers in Sage AP Automation operate at the invoice level, not the individual line level of a split-coded document. The product's own marketplace page describes 'configurable approval channels based on custom fields like invoice amount, vendor, and more,' and the Beanworks mechanism is described as 'customized approval channels' without explicit line-level dimension routing. Critically, no documentation found for Sage AP Automation itself (as distinct from Sage Intacct's native AP module) confirms that the system can fire a separate approval task to the project manager for line 1 and a different approval task to a different department head for line 2 of the same invoice, based on the dimension values on each line. This covers stage 5 of the pre-processing journey at the transaction or department level, but not with documented per-line, per-dimension-value routing precision. The glass ceiling here is that Sage AP Automation's approval architecture is channel-based and header-driven; line-level dimension-owner routing requires the buyer to configure workarounds or supplement with Sage Intacct's native Advanced Approvals add-on.

Limitations: Sage AP Automation's configurable approval channels are documented as routing by invoice-level attributes (amount, vendor, department, manager) rather than by the specific dimension values coded on individual lines of a split-coded invoice, which is the exact requirement. A SaaS company needing the project manager for line 1's project dimension and the department head for line 2's department dimension to receive separate, parallel approval tasks within a single invoice would need to validate this specific line-level mechanism directly with Sage, as no primary documentation confirms it.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For this multi-location services company processing 1,800 invoices per month across two Sage Intacct entities, Brex routes bill pay approvals through its Policy Engine. Admins configure a dedicated Bill Pay rule group within the Default policy section; using the Policy Engine, bills can be dynamically routed for approval based on attributes of the bill, specifically Amount and Vendor. The broader Policy Engine, which covers card expenses and reimbursements in addition to bill pay, gives admins the flexibility to create dynamic rules based on factors such as amount, expense type, role, merchant, and more. Multi-step sequential chains are supported: when more than a single individual needs to sign off, an approval chain routes the transaction through a string of individuals before it can be accepted. A vendor-specific routing example is explicitly documented: admins can create a rule where all AWS bills need to be reviewed by the Head of Engineering, while all other vendors follow the standard Bill Pay workflow, and the rule automatically routes those bills directly to the named reviewer. However, the bill pay approval routing conditions documented by Brex are limited to Amount and Vendor. There is no help center documentation confirming that GL account, department, entity, expense type, or project code can serve as independent routing conditions within a bill pay approval policy rule, which leaves five of the buyer's seven required routing dimensions without confirmed mechanism.

Limitations: The buyer's requirement spans seven routing dimensions (dollar threshold, department, GL account, vendor, entity, expense type, and project); Brex's documented bill pay approval routing covers only two of these natively (amount and vendor), meaning department-by-department approver chains, GL-account-triggered escalations, entity-specific routing, and project-based approval paths are not evidenced as configurable conditions in the bill pay policy rule builder. The broader Policy Engine adds expense type and role for card and reimbursement spend but does not extend those dimensions into the bill pay rule group per current documentation.

Buyer requirement: Configurable multi-level approval chains by dollar amount, department, category, vendor, and GL code

For a $250M technology company moving from ad-hoc Slack approvals to a structured P2P system, Esker's Purchasing module provides an automated approval workflow engine that routes purchase requisitions based on configurable predefined criteria. Esker's AP datasheet explicitly lists vendors, cost centers, G/L accounts, and approver rules as separately configurable workflow rule inputs, and the procurement product page confirms that 'the correct level of authorization is always applied to each request.' The P2P white paper documents that approvers can budget-check expenditures against cost center and GL account during approval, and the AP datasheet confirms that routing criteria include invoice total, vendor name, and exception type. However, no source found documents a compound rule builder that stacks dollar amount, department, category, vendor, AND GL code simultaneously into a single logical condition with AND/OR branching — the critical mechanism needed to route a marketing IT request over $50K from a specific vendor to a different approval chain than the same dollar amount coded to facilities. The customer testimonial referencing a 'two-point approval process' and the product's positioning around 'standardized approval workflow' suggest the engine may operate closer to sequential approval steps than a fully cross-dimensional policy matrix.

Limitations: Esker documents each approval routing dimension (vendor, GL/cost center, dollar amount, approver rules) as separate configurable inputs, but does not publicly document stacked AND/OR logic across all five buyer-required dimensions simultaneously; a complex rule such as 'department = Marketing AND category = Professional Services AND vendor = X AND amount > $50K AND GL = 6200 routes to Legal then CFO' may require professional services configuration rather than self-serve policy administration.

Buyer requirement: Configurable multi-step approval routing by: dollar threshold, department, GL account, vendor, entity, expense type, and project

For a $120M services company running 2 Sage Intacct entities, Airbase's Advanced Approvals module operates at the pre-processing journey's legitimacy and cost-allocation stages (stages 1 and 5), routing invoices through conditional, multi-step chains before any transaction posts to the ERP. The engine is built on a 'When... then...' policy architecture: admins construct Rules composed of one or more Conditions, then assign approvers or approval groups (sequential or any/all parallel) to each branch. Documented routing dimensions include dollar threshold, department, GL category, spend/expense type, and subsidiary/entity: as Airbase's approval workflows page states, rules can be created 'based on the employee's department, GL categories of the expense, the type of tool or service the employee is requesting, and more,' with auto-rerouting built in 'to next in line if one approver is not available.' The multi-subsidiary page further confirms flows 'that span departments, spend type, or GL categories' with entity-level isolation. Vendor-level routing is supported in the product (a third-party analysis confirms 'approval chains based on almost any data field from your ERP, including department, subsidiary, vendor, and custom fields'), but project-level routing as a native, standalone approval condition is not explicitly documented in any Airbase source found: the buyer's requirement to route by project sits in a gap between what Airbase documents and what it may support through custom fields or GL proxy, which cannot be confirmed without a direct product demonstration.

Limitations: Project-level routing as a first-class approval condition is not confirmed in Airbase's published documentation; the buyer may need to approximate it via GL account or a custom field workaround, which introduces maintenance overhead and may not survive ERP dimension changes cleanly. Additionally, Advanced Approvals is a higher-tier feature that is not included in Airbase's base tier, meaning this full routing capability requires a plan upgrade.

Buyer requirement: Approvers must be able to receive, review invoice details and coding, and take approval actions (approve, reject, request information, delegate) directly within Microsoft Teams, without being required to authenticate into a separate AP portal or web application. The Teams-native experience must surface the full invoice image, line-level coding, and any attached supporting documents so that approvers can make informed decisions without context-switching, addressing stage 5 approval routing in the buyer's primary collaboration environment.

This buyer runs Dynamics 365 Finance across three legal entities. Mekorma's product line is purpose-built for Dynamics 365 Business Central, Dynamics GP, and Acumatica; the vendor's own fact sheet states explicitly that it is 'an embedded accounts payable automation solution designed for Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica.' D365 Finance is a separate product with a different AP workflow model, and no Mekorma product covers it. Even setting aside the ERP mismatch, Mekorma's closest analog to an off-ERP approval experience is 'Mobile Workflows,' described as allowing approvers to 'review and take action from a mobile device or browser, without ever logging into the GP system.' That is a mobile browser app, not a Teams-native channel where approvers see an invoice image, line-level coding, and supporting documents as an Adaptive Card with embedded action buttons. No Mekorma documentation, help article, or product page references a Teams bot, Teams app, or Adaptive Card integration for invoice approvals at any stage of the pre-processing journey.

Limitations: Mekorma does not support D365 Finance at all, which is a threshold disqualifier before the Teams requirement is even reached. For the ERPs Mekorma does support (Business Central, GP), the approval experience is a mobile browser app; there is no documented Teams-native approval mechanism surfacing invoice images, line-level coding, or supporting documents within a Teams channel or chat.

Buyer requirement: The approval routing engine must support multi-level, configurable chains that can adapt based on legal entity, financial dimension values, invoice amount thresholds, and vendor attributes across the three legal entities, so that each entity's approval hierarchy is enforced independently within a shared workflow system. The engine must also support delegation and auto-escalation on timeout, since approvers who work primarily in Teams may be unavailable and the workflow must not stall at a single point.

The buyer runs Dynamics 365 Finance across three legal entities and needs approval routing logic tied to D365 financial dimensions, per-entity hierarchy enforcement, Teams-native actions, delegation, and auto-escalation. Mekorma has no product for this platform. The vendor's own positioning is explicit: its solutions are 'built directly inside Microsoft Dynamics 365 Business Central,' with continued support for Dynamics GP and Acumatica. Every workflow mechanism Mekorma documents, including threshold-based approval levels, vendor class security routing, out-of-office delegation via the Mekorma User Preferences window, entity-scoped visibility with Binary Stream MEM, and mobile approvals via PowerApprovals or Mobile Workflows, operates exclusively inside Dynamics GP or Business Central. None of these mechanisms connect to D365 Finance's data model, financial dimensions, or legal entity structure. The buyer's requirement therefore cannot be addressed by Mekorma on any level: there is no product to deploy, no integration to configure, and no workflow engine to route against D365 Finance attributes.

Limitations: The platform mismatch is total and non-remediable: Mekorma does not ship a product for Dynamics 365 Finance, so none of its approval routing capabilities, delegation features, or Teams-adjacent mobile approval tools are available to this buyer. This is not a feature gap that consulting or configuration can bridge; it is an absence of platform coverage.

Buyer requirement: Payment approval workflow: all payment batches require CFO or Controller electronic approval before release

This buyer runs on Sage Intacct. Mekorma's payment approval workflow is a well-documented, genuinely capable mechanism: within its supported ERPs, the Payment Hub enforces a hard separation between the Requestor (who builds batches) and the Approver (who must electronically authorize before any batch can print or release), with named role levels such as MEKORMA_APPROVER_LEVEL_1 and MEKORMA_APPROVER_LEVEL_2 that can be assigned to specific executives like a CFO or Controller, and threshold-based rules that require progressively higher-level sign-off on larger batches. However, the fact sheet states explicitly that Mekorma is built for Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica. No Sage Intacct integration exists in Mekorma's product line, a finding confirmed by zero results across multiple targeted searches of mekorma.com for any Sage Intacct connection. The payment approval workflow, and the entire Payment Hub, is inaccessible to this buyer without first replacing their ERP.

Limitations: Mekorma has no Sage Intacct integration; the buyer's ERP is outside Mekorma's supported platform set, making every Mekorma capability, including its payment batch approval controls, unavailable to this buyer without an ERP migration. This is a foundational compatibility failure, not a feature gap.