Medius vs Mekorma

Requirement evaluated: 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. …

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. …

Requirement evaluated: 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. …

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. …

Requirement evaluated: Spend analytics: top vendors, spend by GL category, month-over-month trending

For a $120M multi-location services company running two Sage Intacct entities, Medius addresses this requirement through Medius Analytics, a dedicated reporting module with out-of-the-box dashboards that are automatically available upon deployment. The module delivers a real-time spend analysis view covering cashflow, costs, and forecasts through pre-defined reports, dashboards, and KPIs, with drill-down capability to the individual supplier level for vendor performance monitoring. …

Limitations: Documentation confirms the named dashboards and the supplier- and dimension-level filtering mechanism, but the exact out-of-the-box layout of a 'top vendors' ranked list or an explicit MoM trend chart is not shown in public help articles; buyers should request a live demo of the Cashflow and Overview dashboards to conf …

Requirement evaluated: Spend analytics: top vendors, spend by GL category, month-over-month trending

For a $120M services company running Sage Intacct, Mekorma cannot deliver this requirement for two independent reasons. First, Mekorma is built exclusively for Microsoft Dynamics 365 Business Central, Dynamics GP, and Acumatica: its documentation and product pages make no reference to Sage Intacct as a supported ERP, and Mekorma does not appear in the Sage Intacct Marketplace. The product cannot be deployed in this buyer's environment. Second, even on its native platforms, Mekorma has no documented spend analytics capability of the kind requested. …

Limitations: Mekorma does not integrate with Sage Intacct, making it incompatible with this buyer's ERP environment entirely. On its native platforms, Mekorma offers no documented mechanism for spend analytics by GL category, top-vendor ranking, or month-over-month trending; any such reporting would have to be sourced from the unde …

Requirement evaluated: The system must provide a self-service vendor portal where suppliers can submit invoices directly, check payment status, and respond to queries from AP, reducing inbound email volume and giving AP a single structured intake channel. For the buyer's three-entity structure, the portal must allow vendors to indicate or confirm which legal entity the invoice is addressed to at submission time, so that entity-level routing can begin without manual AP triage.

For this buyer's three-entity D365 Finance environment, Medius provides a dedicated Supplier Portal described as a 'single point-of-entry for suppliers to view, register, record and update their details in a cloud-based location.' During supplier registration, the portal requires suppliers to configure their own legal entities before they can begin invoicing customers, establishing the supplier-side identity. …

Limitations: The core gap for this buyer is the absence of documented evidence that the Medius Supplier Portal surfaces a buyer-entity selection field at invoice submission time: the intake mechanism Medius documents is per-company email routing (an AP-managed step), meaning AP staff must still triage or pre-sort submissions by ent …

Requirement evaluated: The system must provide a self-service vendor portal where suppliers can submit invoices directly, check payment status, and respond to queries from AP, reducing inbound email volume and giving AP a single structured intake channel. For the buyer's three-entity structure, the portal must allow vendors to indicate or confirm which legal entity the invoice is addressed to at submission time, so that entity-level routing can begin without manual AP triage.

The buyer runs three legal entities on Dynamics 365 Finance and needs a self-service supplier portal where vendors submit invoices directly, check payment status, and select the target legal entity at intake so entity-level routing begins without AP triage. Mekorma does not offer this capability. Its invoice intake mechanism is an email-based channel: vendors email invoices to a dedicated AP inbox, Microsoft AI Builder extracts header-level data (invoice number, date, amount, due date), and a Power Automate flow pushes records into the ERP for AP staff review — a workflow documented on the Dynamics GP Invoice Capture feature page and confirmed across multiple help-center builds. …

Limitations: Mekorma has no supplier-facing portal for invoice submission, payment status, or entity routing at any tier of its product line, and its documented ERP coverage does not include Dynamics 365 Finance, making this requirement entirely unaddressed by Mekorma regardless of configuration or add-on selection.

Requirement evaluated: The AP automation layer must integrate with Dynamics 365 Finance at full data model depth, replicating every financial dimension, legal entity structure, tax configuration, and custom segment that D365 Finance supports across all three legal entities, with no field-level truncation or mapping loss. This is the buyer's stated top-priority criterion; any gap here limits how much of the D365 Finance investment is actually usable through the AP layer.

This buyer runs D365 Finance across three legal entities and needs full data model depth including financial dimensions, legal entity isolation, and tax configuration passthrough. Medius delivers its D365 F&O integration through a packaged connector called Medius Connect, deployed via Microsoft Lifecycle Services (LCS) as a deployable package with an OAuth2-authenticated Medius Integration Client. The package transfers master data (such as suppliers, accounts, and financial dimensions) from D365 to Medius, and transfers approved invoice data from Medius back to D365 for automated posting. …

Limitations: The D365 Tax Engine integration is explicitly a non-standard add-on requiring a separate implementation agreement, which is a material gap for a buyer who listed tax configuration passthrough as a top-priority criterion alongside dimensions and legal entity structure. …

Requirement evaluated: The AP automation layer must integrate with Dynamics 365 Finance at full data model depth, replicating every financial dimension, legal entity structure, tax configuration, and custom segment that D365 Finance supports across all three legal entities, with no field-level truncation or mapping loss. This is the buyer's stated top-priority criterion; any gap here limits how much of the D365 Finance investment is actually usable through the AP layer.

This buyer runs Dynamics 365 Finance across three legal entities and needs an AP automation layer that integrates at full data model depth: financial dimensions, legal entity structure, tax configuration, and custom segments. Mekorma cannot deliver this because it does not integrate with Dynamics 365 Finance at all. Every product Mekorma ships is scoped to a different set of ERP platforms. …

Limitations: Mekorma has no integration with Dynamics 365 Finance; this is a complete platform mismatch, not a depth or fidelity gap. Deploying Mekorma would require the buyer to replace D365 Finance with Business Central, which is a full ERP migration, not an AP automation project.

Requirement evaluated: The system must capture and pass D365 Finance financial dimensions (business unit, department, cost center, project, and any custom dimensions configured in the buyer's D365 instance) at the invoice line level, not just the header, so that cost allocation across the three legal entities is encoded during AP processing rather than corrected post-posting. This addresses stage 5 of the pre-processing journey, where budget owners and cost centers must be identified before the invoice reaches the ERP.

For a three-legal-entity D365 Finance environment, Medius addresses stage 5 of the pre-processing journey through its 'Coding String' framework, a configurable dimension schema maintained per company in the Medius administration tool. Each company's coding string defines the composition of the account and other coding dimensions that together form a coding row, where each dimension's object designation maps it to the corresponding dimension in the financial system. …

Limitations: The restriction rules engine that enforces valid dimension combinations requires configuration effort per legal entity: one documented real-world scenario shows customers needing to manually update a dependent dimension (DIM4) when another (DIM3) …

Requirement evaluated: The system must capture and pass D365 Finance financial dimensions (business unit, department, cost center, project, and any custom dimensions configured in the buyer's D365 instance) at the invoice line level, not just the header, so that cost allocation across the three legal entities is encoded during AP processing rather than corrected post-posting. This addresses stage 5 of the pre-processing journey, where budget owners and cost centers must be identified before the invoice reaches the ERP.

This buyer runs D365 Finance across three legal entities and needs line-level financial dimension mapping (business unit, department, cost center, project, and custom dimensions) resolved during AP pre-processing, before the invoice posts. That is stage 5 of the pre-processing journey. Mekorma cannot address this requirement because it does not run on D365 Finance. …

Limitations: Mekorma has no documented D365 Finance compatibility; deploying it would require the buyer to first replace their ERP with Business Central or Dynamics GP, which is outside the scope of an AP automation evaluation. There is no workaround or add-on that bridges this gap within the Mekorma product family.

Requirement evaluated: Learning capability: accuracy should improve over time on our specific vendor invoice formats

For a 1,800-invoice-per-month services company starting from zero automation, Medius addresses this requirement through two complementary mechanisms in its invoice capture stage (pre-processing stage 1: legitimacy and initial data extraction). First, Medius Capture uses a proprietary multi-stage AI pipeline combining Siamese CNNs for document classification and Markov models for line-item extraction, trained on a global corpus of 2.4 billion+ invoice field data points including 393 million real-world human corrections across its customer base. Second, and directly relevant to per-vendor format improvement, SmartFlow (a proprietary CNN) …

Limitations: The precise boundary between global cross-customer model retraining and this buyer's tenant-specific model is not fully disclosed in public documentation; accuracy improvement on genuinely novel or low-volume vendor formats depends on correction volume from this buyer's own invoice corpus, and very infrequent suppliers …

Requirement evaluated: Learning capability: accuracy should improve over time on our specific vendor invoice formats

For a $120M services company running Sage Intacct, this requirement cannot be met by Mekorma. Mekorma's Invoice Capture product is built exclusively for Microsoft Dynamics GP, using Microsoft Power Platform and AI Builder to receive invoices by email, extract data, and push records into Dynamics GP. For Business Central users, Mekorma redirects to a partnership with SignUp Software. There is no Mekorma invoice capture product for Sage Intacct, meaning the prerequisite mechanism for any learning capability simply does not exist for this buyer's environment. …

Limitations: Mekorma's Invoice Capture is a Dynamics GP-only product with no documented Sage Intacct integration, making it unavailable to this buyer entirely. The AI learning model it relies on (Microsoft AI Builder) …

Requirement evaluated: Integration setup assistance included in implementation; not a separate SOW or additional cost

For a $120M services company on two Sage Intacct entities, Medius does offer a Sage Intacct connector, but it is structured differently from their native managed connectors for Microsoft Dynamics, SAP, Oracle, and NetSuite. Medius's own ERP integrations page documents that the Sage Intacct connection is a 'pre-packaged integration with Sage X3 and Intacct in partnership with Acuity Solutions' — a third-party firm — rather than a connector built, maintained, and deployed entirely by Medius. …

Limitations: Because the Sage Intacct integration is delivered through a third-party partner (Acuity Solutions) rather than as a natively managed Medius connector, the buyer faces a real risk that integration configuration, entity mapping, and go-live setup for their two Sage Intacct entities will be scoped and billed separately by …

Requirement evaluated: Integration setup assistance included in implementation; not a separate SOW or additional cost

Your company runs Sage Intacct across 2 entities, and the integration setup requirement is predicated on Mekorma connecting to that ERP. Mekorma does not offer a Sage Intacct integration. Every Mekorma product, including the Payment Hub, Remote Payment Services, and its invoice capture tools, is built exclusively for Microsoft Dynamics GP, Microsoft Dynamics 365 Business Central, and Acumatica. The vendor's own user guide library lists supported platforms as 'Microsoft D365 Business Central, GP and Acumatica Cloud ERP' with no mention of Sage Intacct anywhere in their documentation or product catalog. …

Limitations: Mekorma is a Microsoft Dynamics-native vendor; adopting it would require your organization to migrate off Sage Intacct, which is a foundational ERP change, not an AP automation decision. This disqualifies Mekorma for any buyer whose ERP of record is Sage Intacct.

Requirement evaluated: The system must maintain a complete, timestamped audit trail covering every action in the pre-processing journey: invoice receipt, OCR extraction, dimension coding, tax code assignment, approval decisions (including who approved, from which interface, Teams or portal), delegation events, escalations, and ERP posting confirmation, with records tied to the specific legal entity and financial dimensions on each transaction. This audit record must be exportable and must satisfy both internal controls and external audit requirements across all three legal entities without manual log reconstruction.

For a D365 Finance organization operating three legal entities, Medius provides a documented audit trail mechanism that logs every approval, edit, comment, and action within the platform. Third-party implementation guidance confirms that 'every approval, edit and comment are registered and stored in Medius' and constitutes 'a complete audit trail of who did what and when.' Medius's own documentation states that 'approvals should be logged automatically within a structured audit trail, including timestamps, decision history, and handoffs,' and a dedicated blog confirms that 'auditors can quickly access timestamped records of every action, from submission to approval to payment.' The platform' …

Limitations: No documentation confirms that the audit log records the specific interface channel (Teams versus portal) through which an approval was submitted, which is a named buyer requirement. …

Requirement evaluated: The system must maintain a complete, timestamped audit trail covering every action in the pre-processing journey: invoice receipt, OCR extraction, dimension coding, tax code assignment, approval decisions (including who approved, from which interface, Teams or portal), delegation events, escalations, and ERP posting confirmation, with records tied to the specific legal entity and financial dimensions on each transaction. This audit record must be exportable and must satisfy both internal controls and external audit requirements across all three legal entities without manual log reconstruction.

This buyer runs Dynamics 365 Finance across three legal entities and requires a complete, exportable, entity-scoped audit trail covering the full pre-processing journey. The foundational barrier is platform compatibility: Mekorma is an embedded AP automation solution designed for Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica. Dynamics 365 Finance (the enterprise F&O product the buyer operates) is not a supported platform. …

Limitations: Mekorma is not available for Dynamics 365 Finance; the platform incompatibility alone eliminates it from consideration before any audit trail capability question can be evaluated. …

Requirement evaluated: The system must support multi-legal-entity coding and data isolation across the buyer's three legal entities, enabling AP staff to code invoices to any of the three entities with entity-level permission controls that prevent one entity's approvers or coders from viewing or acting on another entity's invoices. This is an intra-system segregation requirement, not a multi-instance requirement: all three entities must be manageable from a single centralized AP workspace while maintaining strict per-entity data boundaries.

For a buyer running three D365 Finance legal entities from a single AP workspace, Medius delivers the required intra-system segregation through its company-scoped role and permission architecture. The platform operates as a single installation covering all entities simultaneously, but every permission is configured at the company (legal entity) level rather than at the installation level. Specifically, roles are linked to the legal entities they are authorized for, and all permission settings (approval rights, coding rights, report and search access, and special approval rules) …

Limitations: The help documentation reviewed is from the MediusGo portal, and the granularity of search-visibility isolation (whether a user with no role linked to Entity B sees zero invoices for that entity, or sees them in read-only form) should be confirmed in implementation with Medius's team. …

Requirement evaluated: The system must support multi-legal-entity coding and data isolation across the buyer's three legal entities, enabling AP staff to code invoices to any of the three entities with entity-level permission controls that prevent one entity's approvers or coders from viewing or acting on another entity's invoices. This is an intra-system segregation requirement, not a multi-instance requirement: all three entities must be manageable from a single centralized AP workspace while maintaining strict per-entity data boundaries.

This buyer runs Dynamics 365 Finance across three legal entities and needs enforced, per-entity invoice coding and access control inside a single centralized AP workspace. Mekorma cannot address this requirement for two compounding reasons. First, and most fundamentally, Mekorma is purpose-built for Dynamics 365 Business Central, Dynamics GP, and Acumatica; the vendor's own footer, fact sheet, and product announcements confirm this scope explicitly, and there is no documented Mekorma product for D365 Finance. The buyer's ERP is outside Mekorma's supported platform set entirely. …

Limitations: Mekorma has no product for Dynamics 365 Finance; its entire solution set targets Business Central, Dynamics GP, and Acumatica. Even setting aside the ERP mismatch, Mekorma's multi-entity isolation mechanism is ERP-session-delegated access control, not an independent AP-platform RBAC layer, which means it cannot deliver …

Requirement evaluated: The system must support tax configuration pass-through to D365 Finance, meaning that tax codes, tax groups, and item tax groups configured in the buyer's D365 instance are available for selection or auto-assignment during AP processing, and are written back to the D365 transaction record without manual re-entry or override. This covers stage 3 of the pre-processing journey, ensuring that tax terms verified during AP processing survive the handoff to the ERP intact.

For a three-legal-entity D365 Finance organization, Medius handles tax field pass-through through two documented mechanisms. First, its pre-packaged D365 F&O connector (delivered as a D365 extension with no source-code modification) stores both D365 VAT indicators at the company or vendor level inside Medius; when an invoice enters the workflow, both VAT fields are pre-populated automatically, addressing the common gap where D365 itself only allows one VAT indicator to be pre-set on the vendor master. Second, the 'SaC' (Same as Cost) …

Limitations: The critical unconfirmed gap is write-back fidelity for item tax groups specifically: if Medius's posting connector leaves tax group fields null or passes only the header-level sales tax group, D365 will apply its own auto-determination rules at posting time, which could override the tax assignment verified during AP p …

Requirement evaluated: The system must support tax configuration pass-through to D365 Finance, meaning that tax codes, tax groups, and item tax groups configured in the buyer's D365 instance are available for selection or auto-assignment during AP processing, and are written back to the D365 transaction record without manual re-entry or override. This covers stage 3 of the pre-processing journey, ensuring that tax terms verified during AP processing survive the handoff to the ERP intact.

This buyer runs Dynamics 365 Finance across three legal entities, a platform where tax codes, tax groups, and item tax groups are configured at the legal-entity level and must survive the handoff from AP processing to the posted vendor invoice record intact (stage 3 of the pre-processing journey). Mekorma cannot fulfill this requirement because it does not connect to Dynamics 365 Finance at all. …

Limitations: The limitation is not a feature gap within D365 Finance; it is an absent ERP connection. Mekorma's entire embedded architecture operates within Business Central's AL extension model, which is incompatible with the X++ and OData-based extension model of D365 Finance. …

Requirement evaluated: Two-way matching for service POs where no goods receipt applies

For a multi-location services company with subcontractor, facilities, and professional-services POs, Medius operates at pre-processing stages 2 and 5 (PO match and cost allocation) and explicitly supports 2-way matching as a configurable match type for service-based purchases. The Medius glossary directly answers the buyer's scenario: 'Can invoice matching be tailored for service-based purchases without a goods receipt? Yes. …

Limitations: The product definition documentation confirming the 2-way matching policy is drawn from MediusFlow/D365 integration specs dated 2017-2018; configuration options for the current Sage Intacct connector should be verified with Medius directly to confirm that the 2-way match policy is available and configurable at the PO-t …

Requirement evaluated: Exception dashboard showing all unmatched/flagged items with aging and priority indicators

This buyer operates two Sage Intacct entities, but Mekorma is documented exclusively as an embedded solution for Microsoft Dynamics 365 Business Central, Dynamics GP, and Acumatica. No Sage Intacct integration exists in any Mekorma product documentation, help center, or web search result, so the product cannot be deployed in this buyer's environment at all. Setting aside the ERP compatibility gap: Mekorma's central interface, the Action Board, is a payment batch processing and approvals hub, not an exception triage dashboard. …

Limitations: Mekorma cannot be deployed in this buyer's Sage Intacct environment: the product is architecturally scoped to Dynamics BC, Dynamics GP, and Acumatica only. Even on a compatible ERP, Mekorma offers no documented exception dashboard with aging timers or priority scoring for unmatched or flagged invoices; exception visibi …

Requirement evaluated: Virtual card program with rebate revenue; we want to shift 30%+ of spend to virtual card

For a US-based multi-location services company aiming to convert 30%+ of AP spend to virtual card, Medius delivers this through Medius Payments (their own payment module, priced separately from the core AP automation product). Once invoices are approved in the AP workflow, Medius Payments routes each payment to the optimal method: virtual card, ACH, wire, or check. For virtual card transactions, Medius issues a unique, single-use card number tied to a specific invoice and dollar amount; after the supplier processes it, the card self-destructs, closing the payment loop back to the ERP. …

Limitations: Virtual cards through Medius Payments are available for US-based businesses only, which is not a blocker for this buyer but would be relevant if international supplier payments were added later. …

Requirement evaluated: Automatic remittance advice sent to vendors upon payment

This buyer runs Sage Intacct across 2 entities. Mekorma is built exclusively for Microsoft Dynamics 365 Business Central, Dynamics GP, and Acumatica; it has no product, module, or certified integration for Sage Intacct. Within its supported ERP platforms, Mekorma does offer automated EFT remittance delivery: the system generates a PDF remittance and emails it to the vendor's address on file at the time of payment processing, and its Remote Payment Services (RPS) module sends remittance emails automatically for ACH and virtual card payments. However, none of this mechanism is accessible to a Sage Intacct environment. …

Limitations: Mekorma is not deployable on Sage Intacct at any price or tier; the platform incompatibility is absolute. For remittance automation on Sage Intacct, the buyer should evaluate solutions certified in the Sage Intacct Marketplace, where Sage Intacct itself provides native vendor payment notification functionality as a sta …

Requirement evaluated: Data encryption at rest and in transit

For a $120M multi-location services company handling invoice data, vendor credentials, and payment information across two Sage Intacct entities, Medius provides encryption controls at both the storage and transmission layers. On the storage side, Medius explicitly documents AES-256 encryption across its infrastructure, which is hosted in Microsoft Azure data centers with customer data separated into unique SQL databases per customer. On the transmission side, Medius's Trust Center confirms that Transport Layer Security (TLS) …

Limitations: Medius's publicly accessible Trust Center pages confirm AES-256 and TLS but do not enumerate the specific TLS version floor (1.2 vs. 1.3) in free-text form; buyers with contractual requirements for a minimum TLS version should request the full SOC 2 Type 2 report and Qualys detail from trust.medius.com to confirm. …

Requirement evaluated: Complete audit trail: every action timestamped with user ID, viewable by invoice or by user

Your company runs Sage Intacct across two ERP entities, and Mekorma is purpose-built exclusively for Microsoft Dynamics 365 Business Central, Dynamics GP, and Acumatica. There is no Mekorma integration with Sage Intacct, which means the product cannot be deployed in your environment at any price or configuration. Within the Microsoft Dynamics environments it does support, Mekorma provides an Audit Log Report (accessible at Mekorma Area Page > Inquiry > System > Audit Log) that records posted check and EFT batch details including the approvers and authorizers of each batch, filterable by Checkbook ID, Batch ID, or Posting Date, with drill-down to batch-level detail. …

Limitations: Mekorma has no Sage Intacct integration and cannot be implemented in your environment; this alone makes the capability unavailable to you. For buyers on compatible Microsoft Dynamics platforms, the audit trail covers posted payment batches only, lacks a per-user activity view, and does not capture pre-payment invoice l …