Stampli vs BILL vs Sage AP vs Medius vs Quadient AP for AP Automation

For a multi-entity SaaS company on Sage Intacct with line-level dimension coding across location, department, project, class, and custom dimensions, Medius Capture addresses this requirement at Stage 1 of the pre-processing journey with dedicated line-item extraction that goes well beyond header capture. The module uses OCR, AI, and ML to extract discrete, addressable line rows from every invoice format (PDF, paper, XML, EDI), and its product page explicitly commits to 'accurately capturing information from invoice headers and line-items then automatically matching them against single or multiple POs and receivables' — the product page for healthcare and retail both state that 'Medius Invoice Capture can digitize any invoice format and all line items from suppliers.' The MediusGo customer portal's dedicated 'Line items' help article documents that the system visually highlights each recognized line in the capture interface, with the ability to add, edit, or delete individual rows before the invoice is sent to workflow, providing a human-in-the-loop correction layer when OCR confidence is low. Downstream of extraction, the coding string administration layer (documented in the Medius success portal) allows each company to configure a multi-dimension coding string per invoice line, with each dimension individually flagged for ERP transfer ('Used by integration: This specifies whether the coding dimension should be transferred to the ERP system or not when booking an invoice'); Medius's own engineering blog on coding suggestions confirms the system operates on multi-line 'Coding Tables' containing 'Coding Lines' each carrying multiple 'Accounting Dimensions,' with a standard measurement variant of '12 coding dimensions + 2 tax codes + first approver' per line — comfortably above the buyer's five-plus named dimensions.

For a multi-entity SaaS company on Sage Intacct applying five-plus dimensions at the line level, Stampli's capture mechanism works as follows: when an invoice arrives, Billy the Bot applies OCR plus NLP to extract discrete line rows including descriptions, unit prices, quantities, taxes, and amounts from both paper scans and digital PDFs, not just header fields. Billy uses OCR to digitize invoice data including line item descriptions, then NLP to understand and extract fields like product descriptions, unit prices, and quantities at the line level. Those extracted rows become addressable records against which Billy then applies per-line coding: Stampli AI codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from the buyer's payment and accounting history. For recurring vendors, GL table templates allow users to create or apply pre-defined templates that auto-populate multiple line items in an invoice, making line-item coding a swift, automated process. Billy learns from corrections across invoices over time, improving suggestion accuracy: Stampli Cognitive AI reached the same conclusions as human operators 97% of the time, and Stampli expects that result to approach 100% as it gathers additional data. On the Sage Intacct integration specifically, the line-level architecture is preserved end to end: live PO receipts, work orders, and one-invoice-to-many-PO scenarios reconcile down to the line level, with line-level enhancements including subtotal codes, transaction-specific subtotal lines, and GL-table item workarounds preserving full detail. Custom fields and Smart Rules are also honored: Stampli honors Intacct's Smart Rules by triggering them during export as if a user were entering the bill directly in Intacct, auto-populates project defaults, and creates dual documents to preserve every user-defined field. This places Stampli squarely at Stage 1 of the pre-processing journey (invoice capture and structured extraction) with a direct handoff into Stage 5 (cost allocation coding), before routing to the appropriate dimension owner for approval.

For a multi-entity SaaS company on Sage Intacct that codes every invoice across five or more dimensions at the line level, Quadient AP's capture architecture is a two-tier system: a header-only default and a separately enabled line-item mode. The default processing path is SmartCapture, which the official help center documentation confirms is 'header-only' by default, coding fields such as vendor, invoice date, currency, and totals, but producing a single invoice record rather than a discrete row array. Line-item extraction is a distinct sub-feature called 'Line Item Capture,' documented as part of the SmartCapture initiative but requiring a separate enablement request to a Customer Success Manager. Once enabled, the system splits 'each line out based on the invoice image,' producing addressable line rows with fields including descriptions and unit costs, and Quadient's own blog confirms this captures 'line item information, such as descriptions and unit costs.' The vendor markets the combined capability as eliminating 83% of data entry through 'automatic header and line item data capture,' with a claimed 99% accuracy rate, though that accuracy claim is specifically anchored to header data capture with human verification in the loop.

For a multi-entity SaaS company needing discrete, addressable line rows as the pre-condition for per-line dimensional coding across location, department, project, class, and custom dimensions, BILL's capture mechanism presents a material ceiling. BILL's Intelligent Virtual Assistant (IVA) is the product feature that handles invoice ingestion: invoices arrive via a dedicated inbox email address or upload, and IVA applies ML to begin the bill creation process automatically. However, the documented output of IVA is primarily header-level: a BILL press release describing IVA's capabilities confirms it 'automatically processes and codes the invoices in the system with vendor name, invoice number, amount and due date' — the named fields are all header fields, with no reference to structured line-row extraction. A practitioner review on the Sage community forum corroborates this, noting that BILL 'seemed lacking in the ability to handle invoices with line item detail.' BILL does support multiple bill lines within its data model, and an AP clerk can manually add or correct lines after IVA creates the draft bill, but the automated extraction step does not reliably disaggregate invoice tables into discrete, per-line rows the way the buyer's cost allocation model requires. This means the buyer's current pain point — keying dimensions by hand because the tool only auto-codes header fields — is not materially resolved by BILL's IVA layer. The pre-processing journey stage covered is Stage 1 (legitimacy/ingestion) and partial Stage 5 (cost allocation), but only at the header level; the line-level structure that makes per-line dimension assignment possible must still be assembled manually.

For a multi-entity SaaS company on Intacct that codes every invoice across location, department, project, class, and custom dimensions at the line level, Sage AP Automation's native AI (the 'Automated Bill Entry' / Sage AI capability built into Sage Intacct) does perform true line-item extraction: Sage AI correctly identifies the vendor, amount, dates, and line items, and the 2026 R1 release added AI-powered data extraction and line-level PO matching as native capabilities. The mechanism is: an invoice is uploaded or emailed to a dedicated inbox, Sage AI automatically extracts details and creates a pre-populated draft for approval, with the AI model learning from every invoice and adapting to account-level patterns over time. This places the product at Stage 1 of the pre-processing journey (legitimacy and basic capture) and partially at Stage 2 (PO matching at the line level). However, the critical ceiling for this buyer is that line extraction produces structural line rows (quantity, amount, description) but does not auto-propose the full Intacct dimension set per line from OCR inference. Sage Intacct's dimensions feature lets you tag transactions with custom values such as department, location, and project, and for AP automation you can set rules that apply dimension values automatically based on vendor or expense type, but this is a rules engine, not AI inference from extracted line content. Third-party commentary consistently identifies per-line dimension coding as the gap that external AP tools fill beyond what native Sage AI provides: an even more powerful approach is using AI-based coding predictions, where modern AP automation tools learn from historical data and suggest or auto-apply GL codes and dimensions to each invoice line, a capability positioned as additive to, not included in, Intacct's native feature set.

For a multi-entity SaaS company on Sage Intacct with heavy dimensional reporting, Stampli operates squarely at pre-processing stages 1 through 5: invoice legitimacy, PO matching, and crucially the coding and cost-allocation stages where your team currently keys dimensions by hand. The core mechanism is Stampli AI (Billy the Bot), which codes invoices line by line: Stampli AI codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from your payment and accounting history. The Intacct integration is a bidirectional API connector, not a file-based flat sync: Stampli embeds itself natively with Intacct and keeps data flowing in both directions with minimal lag, resulting in lists, status flags, custom fields, and business rules that behave exactly as if they were working inside Sage Intacct itself. The full dimension set, including user-defined dimensions, travels both directions: Vendors, GLs, entities, projects, retainage, custom dimensions, and other custom fields are explicitly listed as syncing from Intacct to Stampli. At the ERP fidelity level, Stampli mirrors your chart of accounts, dimensions, entities, and approval logic at the field level, with every transaction validated before posting with real-time, bi-directional sync so your ERP remains the single source of truth with zero reconciliation gaps. For Intacct Smart Rules and project-level defaults, Stampli honors Intacct's Smart Rules by triggering them during export, just as if a user were entering the bill directly in Intacct; when project defaults are configured, Stampli automatically populates those fields upon export; and for custom fields, Stampli creates dual documents (invoice and paid bill) to preserve every user-defined field. Line-level split coding across all these dimensions is handled via GL table templates and AI-suggested allocations: Stampli's GL table templates allow users to create or apply pre-defined templates that auto-populate multiple line items in an invoice, automatically filling in GL or item account lines when a template is applied, making line-item coding a swift, automated process. Billy the Bot also proactively surfaces templates: Billy learns from recent invoices, and, when it spots a pattern, will automatically suggest table templates for approval.

This buyer codes every invoice across location, department, project, class, and multiple custom dimensions at the line level — and needs the AP automation engine to auto-populate that full set without leaving any named dimension to manual keying. Sage AP Automation (the native AP Automation agent embedded in Sage Intacct) operates squarely in stage 1 and 2 of the pre-processing journey: it ingests invoices by email or upload, uses AI/ML to extract line items and create a draft bill, and applies learned coding predictions before routing for approval. The Sage Intacct AP Automation FAQ, published on the official help center, answers the dimension-coverage question directly: "What dimensions and GL account tagging does the AI/ML support? AI-driven GL account coding and location, department, and project dimensions are available for everyone. For all other fields, you can manually add this information to the draft bill before you post it." The AI/ML documentation corroborates this scope, confirming the engine is designed to "code dimension details, such as the GL account, location, and department." Class and every user-defined custom dimension fall outside the auto-coding boundary and must be keyed manually on each draft. The FAQ also explicitly states: "AP Automation does not currently populate allocations. You can still upload bills with automation and then add the allocations for each line." The model does learn from corrections: each time a draft transaction is reviewed and corrected, the information is sent back to the Sage Network to update the ML model, helping AP Automation deliver more accurate vendor matches and properly code line-item dimensions — but that learning curve applies only within the dimensions the engine is designed to predict (GL account, location, department, project). The glass ceiling here is the AI coding engine itself: Intacct's data model supports the full dimension set including class and user-defined dimensions, but the AP Automation agent does not predict them.

For a multi-entity SaaS company that codes every invoice across location, department, project, class, and custom dimensions in Sage Intacct, Medius operates at coding stage (pre-processing step 5: cost allocation) through its configurable 'coding string' architecture. Internally, MediusGo supports an open-ended set of custom coding dimensions at the line level, and each dimension carries a per-field flag ('Used by integration') that controls whether that dimension value is transferred to the ERP at posting time. However, the Sage Intacct connector is not a first-party Medius product: Medius has a pre-packaged integration with Sage X3 and Intacct in partnership with Acuity Solutions. The internal coding architecture is flexible, as the MediusGo coding string documentation shows administrators can create new dimensions and configure each one as 'Used by integration' to control what transfers to the ERP, specifying whether the coding dimension should be transferred to the ERP system or not when booking an invoice. Automatic coding suggestions can be applied to imported invoices and are configurable by vendor, reference, or both, including coding proposals that the system automatically applies to imported invoices, created based on reference, vendor, reference and vendor, or one proposal per company. The binding question, however, is whether the Acuity-built Intacct connector carries all five buyer-named standard dimensions plus each active user-defined dimension (UDD) at the line level to Intacct's AP bill detail object, and no public documentation from Medius or Acuity enumerates this field-by-field.

For a multi-entity SaaS company running heavy dimensional reporting in Sage Intacct, Quadient AP connects to Intacct via API and uses its SmartSync engine to pull ERP list data into the platform, making dimension values (GL accounts, vendors, and ERP list items) available as selectable coding fields. At the line level, Quadient AP offers two coding mechanisms: Auto-Capture, which the help center explicitly documents as capturing header fields only (vendor, date, and amount), and Smart Code, which the help center describes as allowing users to 'quickly code invoice line item details for a specific vendor' by replicating the coding pattern from the last approved invoice for that same vendor. Smart Code is a per-user, vendor-keyed template suggestion, not an AI model that reads invoice content and derives dimension values. There is no documented evidence that Quadient AP auto-codes the full Intacct dimension set (location, department, project, class, or user-defined dimensions) at the line level from invoice data; the auto-coding ceiling is header fields, and dimension coding at the line level is primarily a human-assisted or template-driven process.

For a multi-entity SaaS company coding every Intacct invoice across location, department, project, class, and custom dimensions at the line level, BILL's Invoice Coding Agent operates during pre-processing stage 1 (legitimacy and coding prediction) and addresses cost allocation (stage 5) partially. The agent analyzes up to five recent bills per vendor and the uploaded document to generate line-item coding predictions; per BILL's product updates page, it produces predictions for 'amounts, descriptions, and six specific coding fields,' which from documented behavior correspond to GL account, department, class, location, project/job, and one additional standard field. Standard Intacct dimensions, specifically department, location, class, and project, do sync bidirectionally: BILL's own support documentation confirms that bill edits including 'Classifications (Accounts/Departments/Locations/Dimension)' attempt to sync to Intacct on every cycle. The Intacct integration marketing page further claims 'Sync your User Defined Dimensions across bills and transactions,' suggesting custom dimension values can pass through the sync layer when manually entered. However, the AI coding agent's documented prediction scope is bounded at those six named standard fields; no BILL documentation confirms the agent auto-predicts or auto-populates every active user-defined custom dimension configured in a buyer's Intacct instance. The glass ceiling here is clear: BILL can carry manually-entered custom dimension values to Intacct through the sync, but the auto-coding engine itself does not demonstrably extend to the full open-ended set of custom dimensions this buyer requires.

For a multi-entity SaaS company on Sage Intacct with heavy dimensional coding, Stampli's Billy AI operates at stage 1 (invoice coding) of the pre-processing journey and explicitly covers the full Intacct dimension set. Billy codes invoices using the complete GL structure including accounts, departments, projects, classes, and custom dimensions, drawing from historical patterns, and applies per-organization coding logic through pattern recognition to eliminate repetitive work. The learning mechanism is a continuous feedback loop: unlike other providers requiring manual workflow mapping, Billy automatically discovers coding workflows by analyzing trends and patterns in the first days of usage. Each correction the AP team makes to Billy's suggestion becomes a training event: Billy applies contextual reasoning to unfamiliar scenarios, and once a correction is provided, it incorporates that feedback into its permanent knowledge base, applying the learning consistently across all similar future situations. For recurring vendor-to-dimension patterns specifically, Billy learns from recent invoices and, when it spots a pattern, automatically suggests GL table templates for approval; Billy auto-generates suggested templates based on recent invoices, performing this work on AP's behalf. The base model is also trained on a large cross-tenant corpus: trained on $150B+ in annual spend across 70+ ERPs, its intelligence evaluates every transaction. However, Stampli does not publicly document the technical boundary between the global model and the per-customer learning layer, nor does it publish a measured accuracy lift curve at the dimension level. The buyer's requirement asks vendors to describe the training scope (per-customer vs. shared) and provide a staged accuracy metric; neither is disclosed in any available source.

For a multi-entity SaaS company coding across location, department, project, class, and custom dimensions in Intacct, Medius's primary learning engine is SmartFlow: a proprietary CNN that reaches 95%+ coding precision after just two invoices, trained on your historical actions and enriched by 2.4 billion+ invoice field data points across Medius's global customer base. This is a documented hybrid architecture: the base model is per-customer (the buyer's own confirmed coding events are the primary training signal), with a global cross-tenant dataset providing the foundation. Learning occurs when a user clicks 'Send to workflow' in Capture Verify; that is when the AI and ML engines kick in, before the invoice hits the workflow. The dimension scope covered by SmartFlow is explicitly documented: Medius uses both micro and macro KPIs to describe coding suggestions in practice, including accuracy, precision, and recall, as well as Coding Rate, most often computed in the variant of '15 segments,' meaning 12 coding dimensions plus 2 tax codes plus first approver. The model handles multi-line coding tables, not just header fields: the number of values possible for different dimensions is company/tenant-dependent and evolves over time, and the number of dimensions in use varies between tenants from 2 to 12, and may even differ among coding lines within a single invoice. The underlying AI pipeline is described in technical detail: Medius's AI is a multi-stage proprietary pipeline, Siamese CNNs for document classification, tree-based ensembles for confidence scoring, proprietary Markov models for line-item extraction, and CNN-based SmartFlow coding, trained on 2.4 billion+ invoice field data points accumulated over more than 10 years of production. For about eight years, Medius has been using machine learning and neural networks to enhance invoice processing, with ML technology using pattern recognition to capture invoices, code them correctly, and route them for processing, all based on patterns specific to that company. Critically for the Copilot LLM layer, customer data never leaves the intended region and is never used to train OpenAI or any third-party AI model; customer data is submitted as temporary prompt context, processed in a stateless manner, and not retained or learned from by the LLM.

For a multi-entity SaaS company on Sage Intacct coding invoices across location, department, project, class, and custom dimensions, BILL's learning model presents a material ceiling. BILL's IVA (Intelligent Virtual Assistant) and its newer agentic coding layer do incorporate per-organization transaction history: the agent creates predictions by analyzing two primary sources: historical patterns, reviewing up to five of the most recent bills for a specific vendor to identify the organization's unique coding habits, and document analysis, pulling data directly from newly uploaded bill documents to compare predictions with current billing details. However, the model's base layer is a shared cross-tenant corpus: the platform is built on ten years of experience managing business payments and hundreds of millions of bills and invoices to train the AI. The training improvement mechanism is centralized annotation rather than per-customer supervised retraining: the solution combines high-error user documentation with normal user documentation fed into the model, and this approach improved IVA's field-extraction accuracy by 5%. Critically, the agent provides line-item coding predictions for amounts, descriptions, and six specific coding fields, with GL account, department, class, and location noted as examples of fields where correct coding is often complex. The vendor's own Sage Intacct integration page confirms AI-enabled invoice coding and duplicate invoice detection but does not enumerate custom dimensions or confirm parity with the full Intacct dimension set. An independent evaluation of BILL against Sage Intacct use cases directly states that the platform requires manual location coding and does not support splitting invoices by location, and line-item coding and special parsing for atypical documents are not available. Separately, a practitioner critique notes that for many teams, BILL captures header data only: vendor, invoice number, date, and total, with the rest of the work still on the AP user. No published accuracy lift curve by dimension type or per-customer model isolation documentation exists in any BILL source.

This multi-entity SaaS company codes every invoice across location, department, project, class, and multiple custom dimensions. Sage AP Automation's ML engine operates as a hybrid: a shared cross-tenant base model trained on what Sage describes as 'millions of bills submitted to many companies' via the Sage Network, layered with a per-customer feedback loop where each correction an AP user makes to a draft bill is transmitted back to the Sage Network within 24 hours and used to update the model for that specific tenant. ML relies on collective activity on the Sage Network to learn how to read bills efficiently; rather than learning only from the hundreds or thousands of bills submitted to one company, it has the opportunity to learn from millions of bills, with all privacy and safety laws applied. In addition to collective activity, ML also learns from changes and corrections unique to each company: each time a draft transaction is reviewed and corrections are posted, this information is sent back to the Sage Network to update the model, helping AP Automation deliver more accurate vendor matches and properly code line-item dimensions. ML also looks for consistent changes to avoid learning from one-off corrections; when the same correction is made multiple times, ML adds it to the model and applies it to future transactions, meaning some corrections may need to be made several times before AI applies them automatically. However, the official AP Automation FAQ draws an explicit ceiling on which dimensions the AI/ML actually covers: AI-driven GL account coding and location, department, and project dimensions are available for everyone; for all other fields, the user must manually add information to the draft bill before posting. Class and user-defined custom dimensions are explicitly excluded from AI coding coverage and must be keyed manually on every draft. No published accuracy lift curve or numeric benchmark appears in Sage's documentation; the only quantitative signal is a qualitative note that most customers see a dramatic improvement in vendor matching after a month of regular use.

For a multi-entity Sage Intacct SaaS company that codes invoices across five or more dimensions and needs the system to learn and improve those coding patterns over time, Quadient AP's mechanism is the 'GL Smart Coding' feature. The official product page describes it as the ability to 'code invoices with one click, based on what was entered previously for similar invoices,' and a verified user review on Capterra confirms the operational behavior: 'it takes the most recently approved invoice's expense coding and applies it to the same vendor with a simple tap of the button.' This is a recency-based lookup: the system surfaces the last approved coding for a given vendor and proposes it as a one-click default. What is absent from all documentation and help center sources found is any evidence of a statistical ML model that improves suggestion confidence over time, publishes an accuracy lift curve, or distinguishes between per-customer and shared-tenant model training. The mechanism sits at the rules-based end of the coding intelligence spectrum, not the ML-assisted or customer-specific learning end the buyer requires.

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.

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.

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.

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.

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.

For a multi-entity SaaS company on Sage Intacct coding invoices across five or more dimensions, Medius maintains a dedicated Invoice Log embedded in every invoice window that records who made changes, when, and what was changed in the coding lines, currency, and amounts across the full pre-processing journey from capture through payment. The Invoice Log section records information about who has made changes to the invoice, when, and what has been changed in the coding lines, currency, amount, etc. Critically, this log is structurally separated from the live coding data: all coding rows are deleted when restarting an invoice, while the processing history and invoice log are retained, confirming the log persists independently of edits to the underlying coding. Every approval action is also stamped into this history: the invoice history is stamped that the invoice was routed for additional approval due to Four Eyes Principle, and a Medius implementation partner confirms that every approval, edit and comment are registered and stored in Medius, providing a complete audit trail of who did what and when for audit review. At the payment stage, Medius captures approvals electronically to ensure an end-to-end record of everything related to payment activity, and audit-ready reporting ensures an audit trail for every payment. The primary tier reinforces this: every invoice is automatically archived, ensuring accuracy, traceability, and audit confidence at any time, and all risk is automatically flagged, mitigated and logged across the AP lifecycle.

For a multi-entity Intacct customer coding invoices across location, department, project, class, and custom dimensions, Stampli's audit trail operates across the entire pre-processing journey: from initial AI extraction through manual overrides, approval routing, and final ERP posting. The core mechanism is a per-invoice activity log, surfaced inside Stampli's communication hub, that captures every action in a single chronological view. Critically for this buyer's dimension-coding workflow, the audit trail records field values both before and after edits, giving complete visibility into any changes made, and the log covers all invoice activities including approvals, rejections, questions, answers, field updates, and email details. On the immutability requirement, Stampli is explicit: the audit trail cannot be modified or deleted, ensuring data integrity for compliance and audit purposes, and every action is documented with a complete, immutable audit trail ready for inspection. Approver identity and timing are fully logged: Stampli maintains a comprehensive, timestamped audit trail of all actions within the approval workflow, logging who took what action, when they took it, and any comments they provided, and this includes initial submissions, approvals, rejections, questions, reassignments, and any modifications to the request itself. For cost allocation decisions specifically, which is central to this buyer's multi-dimension workflow, Stampli logs every coding change, message, approval, and decision tied to an invoice in a chronological record, so every allocation carries documented accountability: who decided, why it was split that way, and when it was approved, transforming allocation from an undocumented adjustment into a transparent, auditable business decision. On exportability, search results can be exported to XLSX or CSV files, or invoices downloaded directly as PDFs complete with all record details and audit trails. The trail covers the full pre-processing journey inside Stampli, stages 1 through 5 (legitimacy, PO match, terms, receipt confirmation, and cost allocation), before any data is posted to Intacct.

For a multi-entity SaaS company on Sage Intacct coding invoices across location, department, project, class, and custom dimensions, Quadient AP maintains a per-document Audit Log covering the full pre-processing journey inside the platform. The mechanism has three reinforcing layers. First, Quadient AP keeps a comprehensive log of the changes made to invoices, purchase orders, and payments, known as the Audit Log; this generates an Audit Log PDF report retrievable on demand from within each invoice record. Second, the platform enforces a structural coding lock: once an invoice is submitted for approval, the coding cannot be changed, and a comment must be left explaining why the invoice is being reset before any recoding is permitted, creating a mandatory reason record for every post-submission edit. Third, approval identity is captured at each step: your approval is recorded on the invoice and can be viewed by clicking the thumb icon; if there are multiple approvers, the invoice stays in pending approval status with your approval recorded, showing who is remaining to approve. The NextGen UI extends exportable detail further: PDF reports provide a summary of transactions and a copy of the invoice image by default, with the option to include line item details, approval history, and any purchase order or backup images. The critical gap for this buyer is that the available documentation describes the Audit Log as a log of all changes to a transaction without confirming that before/after field values for individual line-level dimension edits (e.g., project changed from X to Y) are explicitly captured as discrete log entries with prior and new values. Additionally, the audit log for the Invoice and PO modules can be accessed by System Administrators only, which restricts read-only audit access for external reviewers or non-admin finance roles.

For a multi-entity SaaS company on Sage Intacct that needs an immutable, line-level audit trail covering every dimension-coding change, approval action, and edit made between extraction and ERP posting, BILL offers a timestamped audit trail feature documented on its security page. BILL explicitly states it will 'automatically keep a record of all AP activity with a timestamped audit trail that cannot be altered, including original bills, review notes, approvals, payments, and remittance details for each transaction,' with documentation accessible for internal, vendor, and auditor inquiries. The Bill Approval Audit report is exportable as CSV and surfaces approval-level fields: bill ID, created date, invoice number, vendor name, amount, bill status, last approver identity, last approved date, next approver, approvals requested, and approvals completed. The trail records user actions with timestamps and transaction details including changes made. However, the documented audit trail fields operate at the bill/header level for approval sequencing. There is no evidence in BILL's help center or product documentation that the trail captures field-by-field changes to individual line-level dimension values (location, department, project, class, or custom Intacct dimensions) as discrete before/after records across the pre-processing journey. The Bill Approval Audit report's published field set contains no dimension-change history columns, and BILL's Intacct-facing documentation does not describe line-level dimension edit logging in the pre-processing layer. This means the trail covers approval identity and timing (stages 1 and 2 of the pre-processing journey) but does not demonstrably cover the per-line, per-dimension coding change history this buyer's audit requirement demands.

For a multi-entity SaaS company on Sage Intacct coding invoices across location, department, project, class, and custom dimensions, Sage AP Automation (native to Intacct) does maintain an audit trail that covers approval actions and bill-level changes. The official Intacct AP product page confirms 'centralized, electronic access to bills, approvals, payment status, posting details, and audit trails,' and the Sage blog confirms 'automatic audit trails are provided... user activities are logged, providing an audit trail for accountability.' The Intacct developer API documents an AUDITHISTORY object and field-level ACTIVITYLOG that records who changed what, with timestamps, on AP bill objects (apbill), and corrections to line-item dimension coding during the draft stage are fed back to the ML system, confirming the system is aware of line-level edits. However, the material gap for this buyer is that the documented audit trail mechanism covers post-draft actions inside Intacct itself. The pre-processing journey (stages 1 through 4: legitimacy, PO match, terms verification, receipt confirmation) largely occurs upstream of posting, and no Sage-native documentation reviewed specifies that dimension coding edits made between initial AI extraction and final posting are recorded in a separately exportable, non-editable audit log with before/after field values at the line level. The developer docs note that the ACTIVITYLOG only works on custom objects, and the AUDITHISTORY object covers standard objects but the export and immutability guarantees are not explicitly documented for the AP draft-to-post pre-processing window.

This buyer codes every invoice across location, department, project, class, and multiple custom dimensions at the line level, and needs those values to post to Intacct as discrete dimension fields with no collapsing. Stampli's Intacct connector, validated as a Sage Marketplace 'Recommended Solution,' is documented to support the full native Intacct dimension framework: the Sage Intacct integration page explicitly lists 'Fields, Custom Fields, Dimensions e.g., Project, Dept, Allocation, etc.' as synced fields, and states the connector 'embeds itself natively with Intacct and keeps data flowing in both directions with minimal lag, resulting in lists, status flags, custom fields, and business rules that behave exactly as if they were working inside Sage Intacct itself' (stampli.com/erp/sage-intacct). GL segmentation is also explicitly covered: 'GL segmentation and inter-company lines — Exports respect every segment,' and user-defined fields are preserved via 'Dual-document export preserves every custom field on both the invoice and the paid bill record.' The AI layer (Billy the Bot) codes at the line level across GL accounts, departments, and custom dimensions learned from the organization's own payment and coding history, directly addressing the buyer's current pain of hand-keying dimensions. Dimension validity is enforced pre-export through many-to-many dynamic filtering, so only valid field combinations (entity, location, vendor, etc.) appear during coding, preventing bad data from reaching Intacct. The connector also honors Intacct Smart Rules and auto-populates project-level defaults on export, preserving downstream reporting fidelity. The buyer's requirement for no memo-field workarounds and discrete field posting is substantiated by the 'GL segmentation exports respect every segment' language and the Marketplace listing's assertion of 'full support for the FULL range of native functionality in Sage Intacct.' Stampli does note that third-party ERP add-ons may require additional development, so any custom dimensions built via third-party Platform Services extensions (rather than native Intacct UDDs) should be confirmed with Stampli during scoping.

For a multi-entity SaaS company on Intacct with heavy dimensional reporting, Quadient AP connects to Sage Intacct via an XML-based Web Services user: a Web Services User is a special type of user that logs in using the Intacct web API and issues commands using XML. On the inbound side, SmartSync will sync all list items from Sage Intacct into Beanworks, making dimension value lists (departments, projects, classes, locations) available for manual coding. The Coding Fields menu allows certain coding specifics for invoices and purchase orders; you can enable required fields that must be coded before an item can be submitted for approval. However, the documented auto-coding ceiling is header-level only: Auto-Capture reviews an invoice image and codes certain fields such as Vendor, Date, and Amount, with no documented extension to line-level dimension fields such as location, department, project, class, or custom UDDs. No public documentation confirms that the connector carries Intacct user-defined dimensions (UDDs) as discrete fields in the AP bill writeback payload, nor does any published source address field collapsing or UDD coverage scope in the XML transaction record.

For a multi-entity SaaS company with heavy dimensional reporting on Sage Intacct, Sage AP Automation is the ERP's own native built-in module, not a third-party connector. This eliminates the integration fidelity concern entirely: because bills are created and posted as native Intacct AP transaction records, there is no connector, no field collapsing, and no memo-field workaround possible. The module operates at pre-processing stages 1 and 2 (legitimacy and PO matching), and partially at stage 5 (dimension coding). The AI/ML engine, operating via the Sage Network, explicitly codes GL account, location, and department at the line-item level by learning from corrections fed back each time a draft bill is reviewed and posted. The AI extracts details such as names, dates, addresses, and line items, and codes dimension details such as the GL account, location, and department. Each time a reviewer posts corrections to a draft transaction, that information is sent back to the Sage Network to update the ML model, helping AP Automation deliver more accurate vendor matches and properly code line-item dimensions. However, the official help documentation explicitly enumerates only GL account, location, and department as AI-predicted dimension fields; project, class, and custom dimensions are not explicitly documented as AI-coded fields in the primary help articles. The documentation also confirms that AI/ML does not predict Account labels, and that these must be selected manually during bill review. Line-item detail mode is also not the default: by default, Intacct summarizes the AP bill total on a single line when creating draft bills from emailed transactions, and the administrator must change the default to create bills with multiple line items that match the original supplier document.

For a multi-entity SaaS company on Sage Intacct with location, department, project, class, and active custom dimensions coded at the line level, the critical issue is how Medius's Intacct connector is architected. Medius's own ERP integrations page discloses that its Sage Intacct integration is a pre-packaged solution delivered in partnership with Acuity Solutions, a UK-based Sage business partner, rather than a first-party, natively maintained Medius connector. Medius's internal platform does carry a general 'coding dimensions' concept within its accounting template framework, where dimension values are determined at the accounting line level by the company context, but no public technical documentation from Medius or Acuity Solutions confirms that this partner connector uses Intacct's XML API dimension framework to post discrete user-defined dimension (UDD) fields at the line level on AP bill records. The absence of a first-party connector means field-fidelity guarantees, upgrade continuity, and custom-dimension coverage depend on a third-party implementation layer that publishes no auditable field mapping specification for buyer review.

This buyer codes every AP transaction across location, department, project, class, and several active custom dimensions at the line level in Sage Intacct, and needs a writeback connector that carries all of those as discrete dimension fields on the APBILL record. BILL connects to Intacct via the Intacct XML API Web Services framework (using a dedicated Web Services user and Sender ID), which is the correct API pathway for dimension-aware AP posting. BILL's Intacct integration page states it will 'sync your User Defined Dimensions across bills and transactions to preserve your unique Sage Intacct setup,' and a 2021 press release confirmed custom dimension support went live in early 2022. However, BILL's own setup documentation for the Intacct connector explicitly instructs administrators to 'ensure that all dimensions are unchecked' on the GL account configuration because 'required dimensions may cause sync failure.' For a buyer who enforces mandatory dimension tagging in Intacct (the typical configuration for heavy dimensional reporting), this means BILL requires the buyer to weaken their Intacct dimension enforcement rules to prevent sync errors: a direct trade-off between AP automation and the integrity of the ERP's dimensional controls. The connector operates at the pre-processing stage (invoice intake, AI coding, and approval routing) and posts the resulting approved bill to Intacct, but the documented sync failure risk on required dimensions means the full five-dimension plus custom-segment fidelity this buyer requires is not reliably delivered end to end.

For a multi-entity SaaS company on Sage Intacct, Stampli operates as a single unified platform that mirrors Intacct's full entity hierarchy: Stampli mirrors Intacct's multi-entity hierarchy exactly in one unified platform, supporting both traditional parent-child entities and modern single-entity with multi-location setups, automatically importing and enforcing the same entity-level user restrictions configured in Intacct, delivering both consolidated oversight and entity-specific control without trade-offs. AP staff do not switch between separate system instances per entity. Whether running classic parent-child entities, a single-entity with multi-locations, or inter-company transfers without MEM, Stampli mirrors the workflow exactly, with entity-level permissions traveling automatically from Intacct so finance admins configure access once. At the line-coding stage, GL segmentation and inter-company lines are preserved: exports respect every segment. When an invoice spans multiple entities, Stampli supports the ERP's features for managing intercompany transactions and multi-entity allocations natively. On export, Stampli honors Intacct's Smart Rules by triggering them during export, just as if a user were entering the bill directly in Intacct, and automatically populates project defaults configured in Intacct upon export: this means Intacct's own automatic due-to or due-from inter-entity journal entries fire at post time without any manual workaround. Intercompany coding in the AP workflow identifies the correct entity so the ERP can create the proper due-to and due-from entries, which is especially important in shared-service finance models where AP receives invoices centrally but allocates spend across subsidiaries, business units, or regional entities.

For a multi-entity SaaS company on Sage Intacct, Sage AP Automation is the native AP layer inside Intacct itself, which means there is no integration gap between the AP pre-processing workflow and the ERP's multi-entity engine. The mechanism is Intacct's top-level shared environment: an AP clerk logs in once at the top level and can process bills across all entities without switching instances. As documented by Sage's own product page, the system allows teams to 'process bills and payments for all business entities from multiple bank accounts, all within Sage Intacct.' At the line level, entity tagging is native: a single AP bill can tag multiple entities on individual lines, and the system automatically posts expenses to the correct subsidiary ledgers and generates balancing intercompany Due To/Due From journal entries simultaneously, with no manual reconciliation step. This covers pre-processing stages 1 through 2 (legitimacy and PO matching via the AI AP Automation agent) and posts directly to the correct entity ledger at stage 5 (cost allocation), with entity dimension carried at the line level alongside the buyer's other Intacct dimensions. Because Sage AP Automation lives inside Intacct natively, it uses Intacct's full data model including all standard and custom dimensions, and posts to the exact entity and subsidiary ledger structure the buyer has already configured, with no field-loss or remapping at handoff.

For a multi-entity SaaS company on Sage Intacct, Medius's connection to Intacct is not a first-party native integration: it is a pre-packaged connector delivered in partnership with Acuity Solutions, a UK-based Sage business partner. Medius has a pre-packaged integration with Sage X3 and Intacct in partnership with Acuity Solutions. This partner-mediated architecture means the depth of multi-entity support depends on what Acuity's connector exposes, not on Medius's core platform capabilities. Medius's own integration data model uses generic dimension slots (DIMENSION1 through DIMENSION12) and includes a companyId field described as an "ExternalSystemId to corresponding entity," which carries the ExternalSystemId to a corresponding entity, providing entity-level awareness at the data layer. However, neither Medius's marketing pages, help center documentation, nor the Acuity partner page document whether this entity field maps to Intacct's multi-entity shared services model, whether intercompany Due To/From entries are generated within the AP workflow, or whether AP staff can process invoices across entities from a single Medius interface without switching system contexts. Medius's own hero integration list names SAP, Oracle, Microsoft Dynamics, NetSuite, and Infor as its primary 100+ ERP connections; Medius connects to 100+ ERPs out of the box including SAP, Oracle, Microsoft Dynamics, NetSuite, and Infor, with Intacct sitting in the partner tier, not the first-party tier.

For a multi-entity SaaS company on Sage Intacct, BILL offers two connection modes documented in its official setup guides: root-level sync and entity-level sync. Under root-level sync, Bill.com syncs to the top level in Sage Intacct, shares list objects (Vendors, Chart of Accounts, Departments, Locations, Items) across all entities via 2-way sync, and requires that a Location be entered on each bill to route it to the correct entity. This provides a single Bill.com instance view, but entity routing depends entirely on the AP coder manually selecting the correct Location field. Under entity-level sync, Bill.com syncs to the entity level, carrying list objects with 2-way sync, which can be created at root level and shared down to entities or created at the entity level; however, bills and payments will ONLY sync to that one entity, and bills cannot be coded to any entity other than the one the account syncs to. This means entity-level sync requires a separate Bill.com account per Intacct entity, forcing AP staff to switch between separate system instances. There is no evidence in BILL's documentation of native intercompany transaction (IET) handling within the AP workflow itself: Intacct's own AP multi-entity guidelines confirm that a bill created at the entity level cannot be paid with a bank account from a different entity, and the entities do not have access to each other, so inter-entity transactions will fail unless structured correctly. BILL's integration does not generate or manage the IET entries in the AP pre-processing workflow; any due-to/from entries result from how Intacct natively handles root-level location-coded bills after sync, not from BILL orchestrating intercompany logic.

For a multi-entity SaaS company on Sage Intacct, Quadient AP maps each Intacct entity to a distinct 'Legal Entity' inside its platform. The Sage Intacct connection guide on the help center shows that setup requires entering the specific Intacct Entity ID per connection, and syncing is performed per-entity via a Legal Entity dropdown in SmartSync, confirming entity-level posting rather than a single top-level post. Sage Intacct supports exchange rate types at both the top level and entity level, and Quadient AP's exchange rate feature is explicitly applicable to both top-level and entity-level integrations, confirming the integration recognises Intacct's shared services architecture natively. AP staff work in a single Quadient AP interface across all entities: users can move from one entity to another in the same screen while keeping the same approval rules, reports, and controls, eliminating the need to switch between separate system instances. The platform consolidates payables for multiple entities and stores all workflow data in the cloud, meaning all AP processes are accessible through a single platform. However, the documented intercompany transfer mechanism, which includes explicit 'Originator Company' and 'Destination' coding fields and a dedicated intercompany workflow, is documented only for Sage 300, not for Sage Intacct. No equivalent Intacct-specific intercompany transfer article or workflow was found in the help center, leaving the in-workflow handling of intercompany AP transactions against Intacct's IET (inter-entity transaction) model unconfirmed.

For a multi-entity SaaS company coding every invoice across location, department, project, class, and custom Intacct dimensions, Quadient AP supports the line-level split step of this requirement but stops short of the independent per-segment routing step. On the split side, AP staff select any invoice line and invoke a 'Split By' menu that distributes the amount across as many rows as needed by percentage or equal parts, with each resulting row coded independently across all line-level fields. Quadient AP allows splitting invoice line items by either percentage or equal parts, with as many percentages as needed as long as they total 100%. Org Units are subsections under a Legal Entity that mirror department structure; an Org Unit is assigned to each line of a transaction and can be used to limit a user's accessibility or visibility in the system. For routing, Quadient AP uses Approval Channels: Approval Channels are built using a variety of criteria including dollar amounts, ERP lists, and Org Units, and a background process determines which channels a transaction matches when submitted for approval. The critical architectural limitation is that Approval Channels evaluate and route the entire invoice object, not individual split segments. An invoice with a 40%/60% split coded to two different Org Units will pass through every channel whose Org Unit criteria it satisfies sequentially, but all approvers see and act on the full invoice, not an isolated slice. There is no documented mechanism for dispatching split segment A to dimension owner A and split segment B to dimension owner B as simultaneous, independent approval tasks scoped to each owner's portion. Additionally, the documented routing criteria are dollar amounts, Org Units, and ERP lists; when submitting an invoice for approval, the 'No Approval Channels match line items' error fires when there is no active Approval Channel matching the invoice coding, confirming routing is line-aware but still whole-invoice in its approval dispatch. Routing on project, class, or custom Intacct dimensions as independent channel triggers is not documented.

For a multi-entity SaaS company on Sage Intacct coding every invoice across location, department, project, class, and custom dimensions, Stampli handles the allocation and coding half of this requirement with strong depth. The GL table templates feature lets AP staff or Stampli AI (Billy) distribute a single invoice across multiple accounting lines, each carrying its own amount and full dimension combination drawn from Intacct's native field set. Split coding distributes one invoice across multiple accounting lines, and each line receives its own amount and coding values, allowing allocation across different accounts, departments, projects, or entities. Billy learns from recent invoices and automatically suggests GL table templates; when a template is applied, it automatically fills in GL or item account lines and calculates line amounts based on the percentage defined on the template. The Sage Intacct connector preserves the full dimension set through to posting: Stampli embeds itself natively with Intacct and keeps data flowing in both directions with minimal lag, and Stampli triggers Intacct Smart Rules and auto-populates project-level defaults on export. For custom fields, Stampli creates dual documents to preserve every user-defined field. On the approval side, Stampli supports invoice-level dynamic routing driven by dimension values: dynamic routing, on-the-fly approver additions, vendor defaults, and a robust validation engine keep invoices moving while blocking bad data before it touches Intacct. Stampli's predefined approval workflows automatically assign invoices to the appropriate approvers based on predefined criteria, and approvers can be assigned based on up to 5 invoice fields including vendor, company, amount, department, and custom fields. Stampli logs every coding change, message, approval, and decision tied to an invoice in a chronological record, and every allocation carries documented accountability: who decided, why it was split that way, and when it was approved. The critical gap for this buyer is the second half of the requirement: automated independent routing of each split segment to the dimension owner who owns only that slice. Stampli routes the invoice as a whole unit based on its attribute values; it does not natively fire separate, parallelized approval sub-chains per coded split segment where each dimension owner sees and approves only their portion. The procurement module documents that reviewers can approve or reject individual line items within a single request, but this is within the procurement request flow and does not translate to a documented per-split-segment approval sub-chain on the AP invoice side. On-the-fly approver additions are available but require manual action, not automated per-segment dimension-owner resolution.

This multi-entity SaaS company needs to split a single invoice line across multiple combinations of location, department, project, class, and custom dimensions, then route each split segment to the owner of that dimension slice for approval. Sage AP Automation (the native Sage Intacct AP module with Sage AI) handles two of those three components but not the third in a documented, integrated way. On capture and line-item coding: Sage AI extracts vendor, amount, dates, and line items from uploaded or emailed invoices and creates pre-populated drafts, and the underlying Intacct platform supports Transaction Allocations, which can split a single AP bill line across multiple dimension combinations using percentage or fixed-amount rules at the time of entry. On approval routing: Intacct's native approval workflow engine supports multi-level routing based on amount thresholds, department, and location, and one practitioner source confirms that a bill allocated to multiple departments can trigger approval steps requiring sign-off from each department's manager. However, no official Sage documentation or product page found in search describes a mechanism inside Sage AP Automation where each split segment of a single invoice line is independently queued to its specific dimension owner (project owner, location owner, class owner) as a separate routable slice. The approval architecture documented is invoice-level or department-level routing, not split-segment-level routing keyed to each unique dimension combination within a line. The glass ceiling here is architectural: Sage AP Automation is an ERP-native module, and its workflow engine routes at the bill or bill-line level, not at the sub-line allocation segment level.

This buyer codes every invoice across five-plus Intacct dimensions at the line level and needs each split segment routed to its dimension owner for independent approval. Medius directly addresses the split-coding side of this requirement: its Accounting Templates module supports both percentage-based and fixed-amount distribution across multiple coding lines on a single invoice, allowing a single invoice amount to be spread across any number of dimension combinations. The per-line approval routing mechanism is also documented: the Medius workflow assigns coding lines to specific approvers, and each approver sees and acts only on the lines assigned to them, with the system checking approval rights against the specific coding values on each line. One Columbus Global implementation guide explicitly names this capability: 'Apply different approval flows for each invoice line so that you can distribute the invoice to multiple approvers simultaneously and only present the specific cost they are responsible for.' Approval hierarchies can then escalate based on the amount totaled across the lines assigned to each approver. Where this falls short for this specific buyer is the Sage Intacct custom-dimension layer: Medius documents that restriction rules and dimension dependencies are 'imported directly from the ERP system,' and the Sage Intacct ERP page confirms integration exists, but no Medius-published documentation was found that explicitly confirms the Intacct connector maps every custom user-defined dimension (beyond the eight Intacct built-ins) into Medius's coding grid at line level. That gap is material for a buyer with 'several custom dimensions' beyond location, department, project, and class.

For a multi-entity SaaS company needing line-level cost allocation splits across five Intacct dimensions with per-segment approval routing, BILL covers the first half of the requirement but not the second. On the coding side, BILL's AP bill entry screen includes a split option that allows AP staff to divide a single line amount across different GL accounts and departments; the 2018 BILL AP Setup Reference Guide documents: 'if you need to split the amounts between different accounts or departments, select the split option.' BILL's Intacct integration does sync custom dimensions (a dedicated help article 'Sage Intacct sync: custom dimensions' exists), and BILL's enhanced approval policies can route a bill by vendor, location, department, and GL account at the invoice level. However, the approval architecture is bill-level and sequential: approver 1 must approve before approver 2 can, and routing criteria operate on the full invoice, not on individual split segments. There is no documented mechanism in BILL for independently routing each split segment to the owner of that specific dimension combination (e.g., routing the Project A / Location West slice to its project manager while simultaneously routing the Project B / Department Finance slice to the finance controller). Third-party analysis corroborates this ceiling, noting BILL's approvals 'often center on simple dollar thresholds and basic routing' and that the system cannot route by specific GL codes or locations to department heads on a per-line basis without manual workarounds outside the tool.