Ariba vs Ottimate vs Mekorma for AP Automation

This $120M services company running two Sage Intacct entities needs four discrete dollar-threshold tiers (under $2,500 to manager, $2,500-$10K to director, $10K-$50K to VP, over $50K to CFO) enforced automatically at invoice submission. SAP Ariba addresses this through its Approval Process editor within SAP Ariba Buying and Invoicing, where administrators build condition-based approval flows using 'if/then' rule blocks. The Approval Flows guide explicitly documents that amount-based conditional routing is a native pattern: any request submitted 'might be subject to approval; for example, purchases under $50.00 might not require any approval, purchases' above a threshold route to designated approvers in a sequential approval chain. At the user-settings level, if the 'Manager > Authorized Approver > Processor' routing option is selected, spending limits are set per approver on the Users page; the invoice travels first to the employee's manager, and if that manager lacks sufficient approval authority, the system prompts selection of an authorized approver from a list of users with a sufficient limit. Beyond this, the Approval Process editor supports serial approval chains where each approver appears in an approver node in the diagram, with 'Active' status meaning the approver has received notification but not yet acted, and active approvers must approve before the invoice moves to the next in the approval chain. Auto-escalation on timeout is also documented: if an approver does not approve before the expiration interval elapses, the system forwards the invoice to the next approver; when enabled, the system begins timing the approver and automatically reassigns the invoice to the approver's manager if the interval elapses. The supporting fact sheet confirms that Ariba's design allows administrators to 'connect supplier systems, orchestrate approval workflows, and build custom extensions with low-code tools', and Joule agents can 'automatically plan and execute multi-step workflows connecting departments, speeding up decisions, and streamlining processes.' This requirement sits at pre-processing stage 1 (legitimacy and authorization), covering the automated routing step before ERP posting.

For a $120M multi-location services company whose DOA policy spans four distinct dollar bands (under $2,500 to Manager, $2,500-$10K to Director, $10K-$50K to VP, over $50K to CFO), Ottimate addresses this requirement through its named 'Threshold Approval' capability combined with customizable multi-level approval chains. Ottimate's Threshold Approval type requires additional approval for payment amounts above a certain threshold, typically from upper-level management. Beyond a single threshold, Ottimate offers fully customizable approval workflows that automatically route invoices to the correct approvers; for example, a rule can be created that invoices above a certain dollar amount route to the controller or CFO, and those conditional approval policies can be created based on any piece of invoice data, including vendor and dollar amount. Multi-level sequential chains are also explicitly supported: Ottimate confirms the ability to set up multi-level approvals where invoices pass through the department head, general manager, and then accounting for better awareness and budget control. Within the pre-processing journey, this capability sits at stage 1 (legitimacy and authorization) and stage 5 (cost allocation sign-off by the budget owner), routing each invoice to the appropriate organizational authority before it is posted to Sage Intacct. Ottimate's workflow engine creates automated workflows to route invoices and payments through custom approval policies, enabling individually tailored approvals for invoices and payments and visibility into bottlenecks.

This buyer runs 2 Sage Intacct entities and needs dollar-threshold routing across a four-tier hierarchy (Manager under $2,500, Director $2,500-$10K, VP $10K-$50K, CFO over $50K). Mekorma does document a well-developed threshold-based approval mechanism: administrators configure 'Threshold IDs' in the Threshold Maintenance window, define From/To dollar ranges for each tier, and assign a named Approver Level role (MEKORMA_APROVER_LEVEL_1, LEVEL_2, etc.) to each range; users assigned to a given role can only approve transactions within their designated band and are blocked from approving above it. Mekorma's own blog confirms this pattern with a concrete example: 'your Accounting Manager is required to approve any outgoing payment between $500 and $20K, and payments over $20K need approvals by two VPs.' The mechanism is architecturally capable of replicating the buyer's four tiers. However, Mekorma is built exclusively for Microsoft Dynamics 365 Business Central, Dynamics GP, and Acumatica; it has no integration with or support for Sage Intacct, and does not appear in the Sage Intacct Marketplace. The approval threshold mechanism operates entirely inside the Dynamics/Acumatica data layer and cannot be connected to this buyer's ERP environment.

For this buyer's 45% non-PO invoice volume (utilities, professional services, subscriptions, insurance), Ottimate operates at pre-processing stage 5: cost allocation and GL assignment before any invoice is exported to Sage Intacct. The mechanism runs in two layers. First, Ottimate checks existing vendor and line-item mapping rules; if a rule exists, the GL is applied automatically with no human touch. Second, when no rule matches an unmapped line item, the AI suggestion engine fires: as documented in the official help article 'GL Suggestions Powered By Ottimate AI,' "AI reduces manual effort by recommending the most likely GL code for unmapped items based on your past activity" and "Ottimate will suggest a GL account if it cannot auto-map a line item using your existing rules." The AP reviewer can then accept or reject the suggestion directly on the line item; Ottimate always checks existing rules first, applies them automatically if found, and AI only steps in to suggest a GL code when no rule is found. Accepted suggestions feed a learning loop: when an AP reviewer accepts an AI suggestion, "Ottimate learns from your decision and can create a rule so future line items like this are mapped automatically." This means the system graduates from probabilistic suggestions to deterministic rules as transaction history accumulates, directly satisfying the buyer's requirement for coding driven by vendor history. The platform also explicitly distinguishes non-PO from PO invoices in its coding logic: "Ottimate now recognizes the difference between invoices with and without a purchase order (PO), so the GL account is only required for non-PO invoices which saves time and keeps data accurate." At the line-item level, "if you GL code a line item once, you will never have to GL code the item again" as Ottimate remembers line-item coding rules and automates this going forward. Bulk acceptance is available for high-volume invoices: Ottimate lets users accept all AI-predicted GL suggestions on an invoice in one go, instead of approving each suggested GL code individually, via a single click. The Sage Intacct integration is a documented selling point; the platform is designed so users "set up your workflow and mappings once" and "Ottimate learns your processes and takes over from there so you never have to manually code another GL item twice."

For a $120M services company running Sage Intacct as its ERP, SAP Ariba's GL coding capability for non-PO invoices is architecturally blocked before it can be evaluated on its merits. SAP Ariba Invoicing does offer a documented ML-based mechanism for non-PO GL coding: embedded AI and ML capabilities learn from invoice history and assign relevant accounting on non-PO invoices, minimizing manual account assignment with automated non-PO invoice processing. The SAP Ariba Central Invoice Management module deepens this further: its machine learning for data recommendations provides intelligent line-item recommendations for missing G/L accounts, cost centers, and WBS elements in draft invoices, trained on the company's historical invoice data to learn patterns and make accurate predictions. However, the platform's own FAQ draws a hard line on ERP compatibility: the solution is currently compatible with SAP S/4HANA Cloud Public Edition, SAP S/4HANA Cloud Private Edition, SAP S/4HANA (2022 support pack 1 or later), and SAP ERP Central Component (enhancement package 8 or later), with compatibility with third-party ERP systems to be added in future releases. Sage Intacct is a third-party ERP. The ML coding capability is real and well-documented, but it operates only within the SAP ERP ecosystem; it is not available to this buyer without replacing their ERP.

This buyer runs Sage Intacct across 2 entities, but Mekorma is architecturally incompatible with that ERP: Mekorma is an embedded accounts payable automation solution designed for Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica — Sage Intacct is not a supported platform, and no Mekorma listing appears in the Sage Intacct Marketplace. Setting aside the ERP incompatibility, even on its native Dynamics GP platform, Mekorma's Invoice Capture module does not deliver intelligent GL coding suggestions. Mekorma uses a subset of Microsoft AI Builder data and brings the following into Dynamics GP: Invoice Number, Invoice Date, Amount, and Due Date — GL account assignment is not extracted or suggested by the AI layer. Instead, once those technologies have played their part, the AP Specialist takes over and validates the extracted data and GL Distributions, meaning coding falls back entirely to manual review by the AP clerk, supported only by whatever static vendor default account the underlying ERP carries. No mechanism exists for learning from vendor history, parsing invoice description fields, or generating context-aware GL suggestions for non-PO invoices. This places Mekorma at the earliest point on the GL coding automation spectrum: rules-based static defaults at best, with no ML assist or description-driven coding at any tier of its product.

For a 3-person AP team processing 1,800 invoices/month across 2 Sage Intacct entities, SAP Ariba delivers role-based access control through two layered mechanisms. First, named system groups (such as Invoice Administrator, Payment Administrator, and Invoice Agent) grant hard-coded functional permissions per module, and administrators assign users to these groups to control what actions (create, approve, manage) they can perform in the invoicing workflow. Permissions are managed via a group-to-child inheritance model, where custom organizational roles inherit hard-coded functional access from predefined system groups. Second, Ariba's Purchasing Unit (also called Procurement Unit) feature provides entity-level data scoping: a purchasing unit is an SAP Ariba concept that lets you separate spend activities by entities such as departments, business units, purchasing organizations, cost centers, and divisions. When the visibility control feature is enabled, the system can restrict the search results, report output, and manage operations (such as Manage Contracts or Manage Invoice Reconciliations) displayed to users based on specific purchasing units. For the deepest entity isolation in multi-ERP environments, Ariba supports integrating multiple sites so that enterprise-wide data can be shared throughout the organization while site-specific and transactional data remains separate, with each site associated with a separate ERP system. Segregation of duties is also configurable: SoD is configured by designing roles that prevent conflicting actions, balancing native Ariba reporting with external GRC tools to meet audit requirements. However, this capability operates at the pre-processing journey's access-control layer (prior to Step 1) rather than at any approval or matching stage.

For a 3-person AP team processing invoices across 2 Sage Intacct entities and 6 office locations, Ottimate's access model operates on an internal location construct rather than Sage Intacct entity boundaries. Administrators assign each user a role (with configurable read, write, approve, and export permission sets) and scope that user to a single location, multiple locations, or all locations; the help center confirms that 'Ottimate allows selective permissions for every user in a specific location' and that users can be assigned 'a single location, multiple locations, or all locations.' Data visibility is genuinely enforced at the location level: Ottimate's own Copilot FAQ confirms 'Can I see invoices from locations I don't have access to? No,' meaning location restrictions gate invoice data, not just routing. Approval access is similarly enforced: 'Only users having access to the selected locations can approve invoices.' The Sage Intacct integration page confirms Ottimate 'supports mapping across customized dimensions and metadata fields configured within Sage Intacct entities,' but no documentation confirms that Ottimate's internal location concept maps one-to-one to Sage Intacct entity records such that invoices belonging to Entity 1 are categorically invisible to users assigned only to Entity 2. This distinction matters because the buyer's 2 entities represent separate books of record in Intacct, and enforcing that boundary requires the AP layer to gate access at the entity dimension, not merely the office-location dimension.

This buyer runs 2 Sage Intacct entities and needs RBAC enforced at the entity level within that environment. Mekorma's security architecture is built entirely on top of Microsoft Dynamics GP and Dynamics 365 Business Central: its Task-Based Security model 'integrates with Dynamics GP security, allowing you to assign users tasks and roles in accordance with the AP work they perform,' and entity-level restrictions in multi-company scenarios are inherited from GP's own company database assignments. For Business Central, Mekorma relies on that platform's native permission sets. Mekorma has no documented integration with Sage Intacct; the vendor's own fact sheet and documentation consistently describe it as 'an embedded accounts payable automation solution designed for Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica.' Because Mekorma cannot connect to Sage Intacct at all, evaluating its RBAC or entity-level access capabilities against this buyer's requirement is moot: the product is not deployable in this buyer's environment.

This buyer runs two Sage Intacct entities and needs a bidirectional vendor master that keeps supplier records (names, addresses, payment terms, banking details, tax IDs) in sync in both directions without manual re-entry. SAP Ariba does have a documented bidirectional vendor master sync capability through its Supplier Lifecycle and Performance (SLP) module combined with the SAP Cloud Integration Gateway (CIG): it replicates Vendor Master Data as Business Partners between Ariba SLP and the connected ERP in both directions using MDG-based web services. However, every native integration pathway explicitly targets SAP ERP and SAP S/4HANA on-premise only. SAP's own course documentation states that the Managed Gateway and Unified Vendor Model support 'SAP ERP, SAP S/4HANA (on-premise), or SAP Master Data Governance' as the ERP-side target, and several integration toolkit methods are documented as explicitly not supporting export of data from SAP Ariba Supplier Management solutions back to a non-SAP ERP system. Connecting Ariba's supplier master to Sage Intacct bidirectionally would require a third-party middleware layer (such as Commercient or a custom iPaaS configuration), which is not bundled with Ariba and introduces a separate implementation project, a separate data mapping exercise, and an additional point of failure that is not governed by Ariba's standard support model.

For a $120M services company running two Sage Intacct entities, Ottimate's native Sage Intacct connector is positioned as a bidirectional integration: Ottimate keeps invoices, corporate cards, and vendor payments up-to-date in both directions. The connection is built on a flexible API platform that integrates across all major Sage Intacct modules including AP, AR, GL, Purchasing, Inventory, and more. The AP Automation Guide confirms that for Sage Intacct, Ottimate maps invoices and details into Sage Intacct in real time and links transactions back to original source invoices. However, the documented "both directions" language covers invoices, cards, and payments; no indexed help center documentation confirms the specific mechanism by which vendor records created or modified in Ottimate during invoice processing are written back to Sage Intacct as the system of record, nor does any available source document how that sync behaves across the buyer's two distinct Sage Intacct entities (top-level shared vendor propagation vs. entity-level isolation).

This buyer runs two Sage Intacct entities and needs a centralized vendor master that synchronizes bidirectionally between the AP automation layer and both ERP entities. Mekorma cannot fulfill this requirement because it has no Sage Intacct integration of any kind. Every Mekorma product, including the Payment Hub, Vendor Validation, and Shared Services Multi-Entity, is built natively inside Microsoft Dynamics 365 Business Central, with separate support for Dynamics GP and Acumatica. The only vendor master synchronization mechanism documented in Mekorma's user guides applies exclusively to Dynamics GP: a scheduled daily sync between the Dynamics GP vendor master and Mekorma's Enhanced Electronic Payments system. No Sage Intacct connector, API integration, or marketplace listing for Mekorma was found in any source, making bidirectional vendor master sync with Sage Intacct structurally impossible without a full ERP migration away from Sage Intacct.