Stampli vs Medius vs BILL vs Mekorma vs AvidXchange for AP Automation

For a buyer running D365 Finance across three legal entities, Stampli connects via an in-house-built 'managed connector' that plugs directly into F&O's native tables without X++ customizations or middleware. Stampli's native connector mirrors F&O's exact configuration, including custom fields, dimensions, tax rules, and vendor setups, ensuring seamless data flow without modifying the ERP or requiring ongoing maintenance. On the dimensions front, Stampli carries over unlimited dimensions and enables AP to split charges across any combination of entities, projects, and cost centers before posting, preserving reporting integrity and eliminating post-entry adjustments in D365 F&O. More specifically, dimensions travel with every invoice and payment export, and AP can split charges across any combination of accounts, departments, projects, or other dimensions before posting; Stampli also mirrors any header- or line-level custom field that already exists in D365 F&O, automatically maps new ones, and filters out fields that should not post back. On tax configuration, Stampli imports every tax definition already created in D365 F&O, including multi-rate VAT/GST schedules, sales-tax codes, and item sales-tax groups, then applies the correct percentage on each invoice line automatically; PO invoices inherit these details automatically, and vendor-specific tax overrides continue to live in F&O, maintaining compliance without parallel tax tables or custom development. For multi-entity approval workflows, Stampli can be configured to align with existing approval hierarchies and workflows in D365 F&O, including multi-entity scenarios and delegation-of-authority rules, mapping approval routes and logic within Stampli's workflow engine. The connector is designed to survive Microsoft's continuous update cadence: Stampli's managed connector is designed to survive Microsoft's monthly 'One Version' updates without breaking; unlike X++ customizations or embedded services that require regression testing after each F&O release, the external integration approach ensures continuous operation through all Microsoft updates. Stampli covers pre-processing stages 1 through 5 (legitimacy, PO match, terms, receipt confirmation via 2/3-way matching, and cost allocation via dimension coding) before posting to D365, with the ERP remaining the unmodified system of record. The integration is listed on Stampli's integrations overview as supporting all native ERP functionality, unlimited entities, all invoice coding fields, and custom fields, with bi-directional sync of master lists including vendors, GLs, and entities. Stampli's integrations page lists support for all native ERP functionality, centralized and decentralized AP processes, all invoice coding fields, custom fields, and unlimited entities.

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. Financial dimensions governed within the D365 finance system flow into Medius coding, and for PO invoices, Medius applies predefined logic to handle invoice variations against those dimensions. Multi-legal-entity onboarding is supported: a step-by-step wizard handles new company setup, master data transfer, and posting flows per entity. However, the buyer's requirement that tax configuration be passed through to the ERP is not covered in the standard package: businesses requiring integration with D365FO and D365AX's Tax Engine must establish a separate agreement for implementation. This means the standard Medius Connect integration carries financial dimensions and legal entity structure at genuine depth, but the tax configuration passthrough the buyer named as a required field sits outside the base product and requires a separate commercial and implementation engagement. The integration operates at pre-processing stages 1 through 4 (legitimacy, PO match, terms, and receipt confirmation) and posts back to D365 as expense journals or vendor transactions, but the tax data model fidelity is gated behind a separate arrangement.

This buyer runs Dynamics 365 Finance across three legal entities and requires an AP automation layer that replicates D365 Finance's full data model: financial dimensions, legal entity structure, tax configuration, and custom segments. BILL's published integration documentation and help center articles confirm that its Microsoft Dynamics integration covers only Dynamics 365 Business Central and the legacy Dynamics GP. The official BILL integration page states that 'BILL Accounts Payable and BILL Accounts Receivable sync with Microsoft Dynamics 365 Business Central,' with no mention of D365 Finance (F&O) anywhere in BILL's documentation. D365 Finance is a structurally different product from Business Central: it carries a multi-legal-entity architecture, an unlimited financial dimension framework, F&O-specific tax engine configurations, and a data model that Business Central does not share. Even if a workaround import/export path were configured, BILL explicitly positions its platform for small and midsize businesses and the data structures it replicates match SMB-tier ERPs, not the D365 Finance enterprise data model. There is no mechanism, no connector, and no documented path through which BILL reaches any D365 Finance dimension, tax configuration, or legal entity structure.

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. The vendor's own primary positioning states the solution is 'built directly inside Microsoft Dynamics 365 Business Central,' and the product footer explicitly lists the supported platforms as 'Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica.' Dynamics 365 Finance (formerly Dynamics AX / F&O) is a separate Microsoft application built on the finance and operations apps architecture, with its own financial dimensions framework, legal entity model, tax engine, and extensibility layer; it shares a brand name with Business Central but is architecturally unrelated. No web search returned any evidence of a Mekorma connector, AppSource listing, or documented integration path to D365 Finance. The pre-processing journey question is therefore moot: Mekorma cannot receive invoices from, post coded invoices to, or synchronize payment results with the buyer's ERP.

This buyer runs D365 Finance across three legal entities and requires full data model depth: every financial dimension, tax configuration, legal entity structure, and custom segment replicated without truncation. AvidXchange's own Microsoft solutions page explicitly categorizes its D365 Finance (F&O) connection as file-based, not API-based: "We have API integrations with Business Central and GP, and file-based integrations with AX, NAV, F&O and SL." A file-based integration operates as a flat-file export/import bridge: AvidXchange exports a structured file from D365 Finance on a schedule, processes invoices in its own environment, then imports a coded transaction file back. This architecture sits at the lowest rung of ERP integration fidelity: it cannot dynamically query the D365 Finance dimension framework, cannot validate against entity-backed dimension values in real time, and cannot carry multi-legal-entity tax configurations or custom segment structures that D365 Finance manages at the data-model level. The API integration with automatic syncing is reserved for Business Central and GP only, meaning the full-fidelity integration path that would be needed for dimension and legal entity depth is not available for D365 Finance. AvidXchange's Microsoft-specific capability documentation is also GP-centric: "For users of Microsoft GP, our integration supports a touchless process with configurable 2- and 3-way PO matching that provides flexible approval workflows with enhanced internal controls", with no equivalent D365 Finance depth described. The glass ceiling here is structural: a file-based connector caps what the buyer can post to D365 Finance at whatever field set the flat file template defines, making financial dimension depth, tax group pass-through, and multi-entity legal isolation dependent on manual file configuration rather than live ERP data model replication.

For a three-legal-entity D365 Finance organization, Stampli's managed connector reads the buyer's live F&O configuration and surfaces every financial dimension (business unit, department, cost center, project, and any custom dimensions the buyer has defined) as validated, ERP-sourced lookup fields inside the Stampli coding UI, operating squarely at stage 5 of the pre-processing journey where cost allocation must be assigned before posting. Critically, this works at the line level, not just the header: line-level coding applies values to each distribution line, making it possible to split one invoice across multiple accounts, projects, cost centers, or legal entities. On the D365 Finance connector specifically, Stampli carries over unlimited dimensions and enables AP to split charges across any combination of entities, projects, and cost centers before posting, preserving reporting integrity and eliminating the need for post-entry adjustments in D365 F&O. The connector is bidirectional and self-updating: Stampli automatically mirrors the existing D365 F&O setup including all custom fields, financial dimensions, tax codes, and vendor configurations, and reads the F&O configuration in real time, adapting automatically when new fields or dimensions are added. Every custom field and financial dimension flows bidirectionally with no remapping required. Stampli AI then automates the coding itself: Stampli AI codes invoices line by line, applying GL accounts, departments, and custom dimensions learned from payment and accounting history. Reusable GL table templates and percentage-based allocation presets further accelerate multi-line dimension splits for recurring invoices, with AP able to split charges across any combination of entities, projects, and cost centers before posting.

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. The coding happens at the line level, not the header: accounting templates can be used to have invoices both coded and routed, and are managed from the Coding tab of the invoice, with cost distribution in percentage across coding lines enabling a single invoice to be split across multiple dimension combinations before any posting occurs. Dimension values are synchronized from D365 into Medius as master data: when the integration between D365 and Medius is set up, master data is automatically synchronized between the two systems, and Medius's restriction rules define dependencies and conditions in the dimensions tree to ensure consistency of coding configuration between Medius Spend Management and the ERP system, with settings in most cases imported directly from the ERP system. Each dimension column in the coding string carries a 'used by integration' flag that specifies whether the coding dimension should be transferred to the ERP system when booking an invoice, meaning dimension assignments made during AP pre-processing flow directly into the D365 posting payload without requiring post-posting corrections. The D365 F&O connector, which has passed the Microsoft AppSource validation process, handles this transfer as a managed cloud integration.

This buyer runs three D365 Finance legal entities and needs financial dimensions (business unit, department, cost center, project, and custom dimensions) encoded at the invoice line level during AP processing — stage 5 of the pre-processing journey — before posting. AvidXchange's own documentation confirms its integration with Dynamics 365 Finance and Operations (F&O) is file-based, not API-based: the vendor's product page explicitly states 'We have API integrations with Business Central and GP, and file-based integrations with AX, NAV, F&O and SL.' A file-based integration transmits data in batches using flat-file formats rather than a live, bidirectional API connection, which means the integration does not natively read or write to D365 Finance's financial dimension tables in real time. There is no evidence in AvidXchange's fact sheet, support documentation, or marketing materials that its F&O connector maps to D365's ledger dimension format at the invoice line level, surfaces custom dimension picklists to AP coders inside AvidXchange, or validates dimension combinations against D365 account structures before the file is imported. The practical consequence for this buyer is that cost allocation across three legal entities would either be keyed manually in a flat-file export or corrected post-import inside D365 — the opposite of the buyer's stated requirement — rather than being encoded and validated during AP processing through a live integration.

This buyer runs D365 Finance across three legal entities and needs invoice line-level financial dimension coding (business unit, department, cost center, project, custom dimensions) resolved during AP pre-processing before posting, which is stage 5 of the pre-processing journey. BILL's entire Microsoft Dynamics integration footprint is built for Dynamics 365 Business Central, a separate product with a different API surface than D365 Finance (F&O). Every Microsoft Dynamics help article on BILL's help center is titled 'Microsoft Dynamics 365 Business Central'; no documentation for a D365 Finance connector exists. BILL publicly stated it would focus Microsoft resources on Business Central after ending Dynamics GP support, and its general platform claims describe only 'sync with leading accounting software' without naming D365 Finance as a supported ERP. Without a D365 Finance connector, there is no mechanism to pull live dimension values from D365's financial dimension tables, surface them in a line-level coding UI during approval, validate against allowed-value combinations by legal entity, or write coded dimension splits back to the D365 F&O posting payload pre-posting.

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. The vendor's own positioning material states it is 'an embedded accounts payable automation solution designed for Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica,' and its invoice processing page confirms its embedded invoice solution covers only 'Microsoft D365 Business Central and Dynamics GP.' D365 Finance (the enterprise-tier ERP, formerly Dynamics AX/F&O) is a distinct product from Business Central (the SMB-tier ERP, formerly NAV); they share a Microsoft brand but differ in data architecture, financial dimension framework, and the integration surface that an AP tool must target. Because Mekorma has no integration layer for D365 Finance, the question of whether it maps financial dimensions at the line level in that ERP is not a feature evaluation: it is a platform compatibility disqualification.

For a buyer running three D365 Finance legal entities, Stampli addresses this requirement through a single-account multi-entity architecture rather than separate instances. Stampli allows adding and managing an unlimited number of companies or subsidiaries within a single account, enabling AP teams to manage invoice processing, approvals, and reporting across multiple legal entities from a single centralized platform. Data segregation is enforced at the permission layer: Stampli uses permission-based controls, ensuring that users only see invoices and data aligned with their specific permissions within the system. At the routing level, each invoice assigned to a company code is routed only to that company's coders, and the same logic applies to approvers: a company-specific code routes invoices only to that entity's approvers, with the specific approver varying by invoice type. Stampli's D365 Finance integration page confirms that Stampli can be configured to align with existing D365 F&O approval hierarchies, including multi-entity scenarios and delegation-of-authority rules, with a flexible workflow engine that maps approval routes and logic within Stampli's interface. For the coding interface specifically, Stampli carries over unlimited D365 dimensions and enables AP to split charges across any combination of entities, projects, and cost centers before posting, preserving reporting integrity and eliminating post-entry adjustments in D365 F&O. Each entity can have its own independently configured coding structure, approval workflow, and vendor list: each entity may have its own GL accounts, approval workflows, vendor data, and compliance requirements, all configurable per company's needs within the single account. The centralized administrator workspace with entity-level segregation is explicitly contrasted against multi-instance alternatives: other solutions typically require separate accounts or configurations for each legal entity, whereas Stampli positions itself as the only truly unified platform for complex, multi-entity corporate environments.

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) must be configured separately for each company: an approver or coder whose role is linked only to Entity A cannot view, search, or act on invoices belonging to Entity B or Entity C. The 'Roles, report and search access rights' help article confirms that the role form's search access rights control which invoices a role can search within the system, scoped to the selected company. On the entity-aware workflow side, Medius documents that each legal entity can maintain its own tax codes, currencies, and approval hierarchies within the centralized platform, directly matching the buyer's need for entity-level process separation without separate instances. The buyer's AP staff can code invoices to any of the three entities from one workspace, with the coding rights tab on each company-scoped role controlling which dimension values are accessible to each user per entity. This covers pre-processing journey stages 2 through 5 (PO match, terms verification routing, cost allocation coding, and approval): the permission boundary is enforced at the coding and approval stage before any invoice posts to D365.

For a buyer running three D365 Finance legal entities, AvidXchange offers a role-based permissions framework within AvidInvoice where users must be assigned roles that control access to specific product areas and functions; the platform's help center also surfaces an article titled 'Associating Users to Entities,' which indicates some form of user-to-entity scoping exists. At the multi-entity level, AvidXchange's documented architecture supports separate accounting structures, approval workflows, and reporting per entity within a single centralized platform, with payment execution managed centrally: this covers the centralized-workspace side of the buyer's requirement. However, no accessible documentation demonstrates enforced row-level data isolation at the invoice visibility layer, meaning there is no confirmed mechanism that hard-prevents Entity A's coders or approvers from viewing Entity B's invoices based on platform-enforced access control rather than user discipline or workflow routing. The permission model documented publicly is task-based and role-based within product modules, not legal-entity-scoped at the data row level with hard read boundaries between entities.

This buyer operates three D365 Finance legal entities and needs a single centralized AP workspace where coders and approvers are system-enforced to see only their permitted entity's invoices, with cross-entity visibility available only to designated AP administrators. BILL does offer a multi-entity capability, but its architecture is built as separate BILL accounts per entity navigated via a single-login switcher: with one secure login, users can access and manage the financials for all subsidiaries and switch between entity contexts without signing out. This is an entity-context-switching model, not a unified AP queue with row-level data isolation; a user operates within one entity account at a time, not across all three simultaneously from a single workspace. The permission model does not provide the depth this buyer needs: BILL's model uses six predefined roles (Administrator, Controller, Accountant, Approver, Clerk, and Payer), with no custom roles or granular permission editing outside these presets documented. Specifically, there is no field-level or object-level permission customization documented, which means entity-scoped invoice visibility restrictions cannot be configured within a shared AP workspace. A compounding gap is the ERP integration target: BILL's Dynamics 365 integration announcement covers Dynamics 365 Business Central and Microsoft Dynamics GP, not Dynamics 365 Finance, the enterprise product this buyer runs with legal entities, financial dimensions, and advanced tax configuration. There is no documented BILL integration with D365 Finance at all.

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. Second, even on the ERPs Mekorma does support, its multi-entity 'Shared Services' model relies on the Action Board filtering batches 'by the user's access level' so that 'users can only view and select batches from companies to which they have access' — access control that is delegated fully to the host ERP's native company-security model (BC permission sets or GP Task-Based Security), not an independent AP-layer RBAC mechanism. There is no standalone Mekorma permission layer that enforces per-entity invoice visibility and coding rights inside the AP workspace itself; entity segregation is inherited passively from the ERP session, not enforced by Mekorma. For the buyer's three-entity D365 Finance environment, neither condition required to support this requirement is met.

For a three-entity D365 Finance organization, Stampli's managed connector addresses stage 3 of the pre-processing journey (terms and tax verification) by importing the buyer's existing D365 F&O tax configuration directly into the AP coding interface. Specifically, Stampli reads sales tax codes, item sales-tax groups, and effective-dated VAT/GST rate schedules from the live F&O instance in real time rather than maintaining a parallel tax table, meaning there is no drift between the AP layer's tax universe and the ERP's. During invoice coding, PO-matched invoices inherit tax details automatically, while ad-hoc invoices present the F&O-sourced tax codes as selectable fields so an AP processor can verify assignment before approval. Vendor-specific tax overrides remain authoritative in F&O, and the connector writes the selected values back through bi-directional sync with no remapping step, satisfying the pass-through requirement that tax assignments survive the handoff intact.

This buyer runs D365 Finance across three legal entities and requires tax codes, tax groups, and item tax groups configured in their D365 instance to be available for selection during AP processing and written back to the D365 transaction record without manual re-entry. AvidXchange's official Microsoft integration page explicitly states: "We have API integrations with Business Central and GP, and file-based integrations with AX, NAV, F&O and SL", placing D365 Finance squarely in the file-based category. A file-based integration cannot pull live D365 tax tables (TaxTable, TaxItemGroup, TaxGroup entities) into the AvidInvoice coding UI as selectable dropdowns at processing time, nor can it write a verified tax code back to the D365 vendor invoice journal line before posting. Instead, the file handoff would trigger D365's own auto-determination logic on import, meaning tax assignment happens inside D365 after the AP processing stage, not during it, which breaks the stage 3 verification requirement that tax terms verified in the AP layer survive the handoff intact. AvidXchange's deeper API integrations exist only for Business Central and GP, which offer automatic syncing, not for the enterprise-tier D365 Finance instance this buyer operates.

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) option for PO-based invoices automatically populates coding dimensions and tax indicators directly from the purchase order, covering stage 2 and stage 3 of the pre-processing journey for matched invoices. For non-PO invoices, Medius supports per-line VAT code assignment during invoice coding, enabling tax verification before the invoice posts to D365. However, available documentation does not explicitly confirm that the posting payload to D365's vendor invoice journal carries the SALESTAXGROUP and ITEMSALESTAXGROUP fields as explicit mapped values rather than relying on D365's own auto-determination logic at the point of import: the gap between Medius writing a tax indicator into the AP workflow record and that value surviving as a committed field in the D365 VendInvoiceInfoLine entity is not fully documented in any source found.

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. Mekorma is explicitly scoped as "an embedded accounts payable automation solution designed for Microsoft Dynamics 365 Business Central, with continued support for Dynamics GP and Acumatica." Web search confirms no change to this scope: Mekorma describes itself as "a leader in Accounts Payable automation, serving businesses on Microsoft D365 Business Central, Dynamics GP, and Acumatica" with no mention of D365 Finance anywhere in vendor documentation or press releases. The Payment Hub v1.0, Mekorma's most recent product release, is explicitly described as "an end-to-end AP solution for Microsoft Dynamics 365 Business Central" only. Because no ERP connection to D365 Finance exists, there is no mechanism by which Mekorma could read D365 Finance tax tables, expose tax groups and item tax groups during invoice coding, or write selected tax values back to a D365 Finance vendor invoice journal record.

This buyer runs Microsoft Dynamics 365 Finance across three legal entities and requires that D365 tax codes, tax groups, and item tax groups be surfaced in the AP processing UI and written back to D365 transaction records intact. That capability depends entirely on a functioning D365 Finance connector. BILL's documented Microsoft Dynamics integration covers only Dynamics 365 Business Central and Dynamics GP: the BILL help center publishes a dedicated sync matrix, setup guide, payments guide, and error guide for Business Central, with no parallel documentation for D365 Finance (F&O) anywhere in its help center. BILL's own Microsoft Dynamics integrations marketing page and its Microsoft Marketplace listing both describe a 'two-way, API-based integration with Dynamics 365 Business Central,' with no mention of D365 Finance. Because the foundational D365 Finance connector does not exist in BILL's product, there is no mechanism by which D365 tax tables (TaxGroup, TaxItemGroup, sales tax codes) could be pulled into the BILL AP processing UI, pre-populated on invoice lines, or written back to the D365 vendor invoice journal record. Stage 3 tax terms verification in the pre-processing journey cannot be completed within BILL for this ERP.

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

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

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

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

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

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

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

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

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

For a buyer running three D365 Finance legal entities, AvidXchange offers the AvidXchange Supplier Hub: a free, self-service portal where enrolled vendors gain 24/7 visibility into invoice and payment statuses with granular states (Received, Pending Approval, Approved, Sent, Paid), configurable email notifications for status changes, and export tools for reconciliation. However, the Supplier Hub is explicitly not an invoice submission channel. AvidXchange's own documentation states directly: 'No, suppliers will continue to invoice their customers as they currently do' — meaning submission happens via email to a dedicated address or P.O. box, not through a structured portal intake form. Because invoice submission remains email-based, there is no mechanism for a vendor to select or confirm a legal entity at the point of submission; entity assignment is an internal AP function that happens after receipt, which is precisely the manual triage step this buyer needs to eliminate. The internal multi-entity blog content documenting company drop-down lists and entity-level permissions is addressed to AP staff within the buyer's AvidXchange instance, not to suppliers submitting invoices from outside.

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. On the payment status and query-resolution side, the Medius payments page confirms that 'suppliers get paid more quickly and efficiently with clear visibility into the payments process through the Medius supplier portal,' and the Supplier Conversations module uses agentic AI to 'respond automatically to supplier invoice and payment inquiries' without AP intervention. However, the mechanism for entity-level routing at invoice submission time is documented separately: the MediusGo support article describes per-company email addresses as the intake channel, where AP copies the email address for whichever company the invoice belongs to; this is an AP-managed routing step, not a supplier-facing entity selector inside the portal UI. No publicly available documentation from Medius confirms that the supplier portal presents a buyer-entity picker at the moment of invoice submission so that vendors can self-identify the target legal entity and trigger entity-specific workflows without AP triage.

For a buyer running three D365 Finance legal entities, BILL does offer a vendor network where suppliers can create accounts, submit invoices, and track payment status without emailing AP directly. BILL's own learning content confirms that vendors can 'submit invoices and track approval and payment status at their convenience' and that 'vendors can access all the critical information they need without having to reach out directly to your team.' However, the entity-routing requirement exposes a structural gap: BILL's multi-entity architecture creates a separate BILL company account per legal entity, and a vendor in the BILL Network connects to a specific company account. There is no documented unified portal with a legal-entity selector where a vendor can indicate which of the buyer's three entities an invoice is addressed to at submission time; the vendor must connect to and submit through each entity's separate BILL company, meaning entity identification is implicit in which company account the vendor accesses rather than being a structured field the vendor selects. This is the anti-pattern for this requirement: entity disambiguation still requires either the vendor to know which account to use, or AP to manually triage misdirected submissions. Compounding this, BILL does not document a native integration with Dynamics 365 Finance (the enterprise product); its published ERP integrations cover QuickBooks, Xero, NetSuite, Sage Intacct, and Dynamics 365 Business Central, not D365 Finance, which means the downstream routing from portal submission into entity-specific D365 Finance AP workflows lacks a documented connection path.

For a three-entity D365 Finance buyer, Stampli's Vendor Portal provides the self-service intake layer the buyer needs on several dimensions: vendors can directly upload invoices through the portal, initiate messages and respond to AP queries, and independently access invoice and payment status information. The compliance and onboarding layer is also present: vendors can securely submit documents and maintain their information through the vendor portal, helping ensure compliance before payments are issued. On the multi-entity side, Stampli's documented mechanism for entity assignment is primarily AP-side and AI-driven: invoices can automatically be assigned to specific companies based on invoice details, with configurable coding structures, approval workflows, and vendor lists tailored to each company. The AP Assignments engine can then route the classified invoice to entity-specific AP queues: AP Assignments allows organizations to automatically route invoices to the right users based on specific invoice characteristics such as business unit, region, office, department, vendor, or any other custom criteria. However, no documented mechanism exists showing a vendor-facing entity selector field presented at portal submission time, where the vendor explicitly confirms which of the buyer's three legal entities the invoice is addressed to before routing begins. The help center's vendor portal overview shows the portal scoped to a single customer name, and the multi-entity assignment language consistently describes system-side or AI-driven assignment rather than a supplier-initiated entity declaration at intake.

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. The only 'self-service portal' language on mekorma.com refers to Mekorma's own customer support and license-management portal for the buying organization, not a supplier-facing web interface. There is no documented portal module, supplier registration flow, entity-selector field, or payment-status inquiry surface anywhere in Mekorma's product line. Additionally, Mekorma's supported ERP platforms are Dynamics 365 Business Central, Dynamics GP, and Acumatica; Dynamics 365 Finance, the buyer's system of record, is not listed as a supported platform, which introduces a foundational compatibility gap before the portal question is even reached.

For a three-legal-entity D365 Finance organization requiring a complete, exportable audit trail across the full pre-processing journey, Stampli operates an invoice-centric communication hub where every stage of that journey is logged against a single invoice record. Stampli's audit trail captures all invoice activities including approvals, rejections, questions, answers, and field updates, with each entry recording names, dates, times, and field values both before and after edits. This is not a summary report: Stampli logs every coding change, message, approval, and decision tied to an invoice in a chronological record, with documented accountability for who decided, why it was split, and when it was approved. The log is explicitly immutable: the audit trail cannot be modified or deleted, ensuring data integrity for compliance and audit purposes. The trail covers the full pre-processing journey from receipt through coding and ERP posting, because every change, comment, approval, and document is preserved in a complete, immutable audit trail with role-based access controls and visibility. For the buyer's three legal entities specifically, Stampli manages invoice processing, approvals, and reporting across multiple legal entities from a single centralized platform, where each entity can have its own GL accounts, approval workflows, and compliance requirements, and users only see invoices aligned with their permissions, ensuring data security. Export is confirmed: search results can be exported to XLSX or CSV files, or downloaded as PDFs with complete audit trails, and results can be filtered by specific users involved in transactions. The critical gap for this buyer is interface-of-origin tagging. Stampli delivers approvals primarily through email notifications and its web/mobile interface, not a native Microsoft Teams app; no documentation confirms that the audit log records whether an approval action was taken from Teams, the web portal, or a mobile device, which is an explicit requirement. Additionally, while Stampli validates transactions before ERP posting, no source documents that a D365 journal or voucher reference number is written back into the Stampli audit record as a discrete, timestamped posting-confirmation event.

For a buyer running D365 Finance across three legal entities and requiring a granular, multi-layer audit record, AvidXchange's AvidInvoice module maintains a transaction-level audit trail that captures activity from invoice receipt through payment. User reviews describe the traceability as covering every action, review, and approval step from the moment an invoice is uploaded, with timestamped visibility across the full activity history. The platform allows users with appropriate access to run reports and export invoice data history in Excel, PDF, or HTML format. AvidXchange markets 'a full audit trail' as part of its compliance and spend management posture. The vendor describes tracking every action and invoice with a detailed audit trail for full historical accounting visibility. However, the buyer's requirement goes several layers deeper than what AvidXchange documents: there is no evidence that audit log entries are stamped with D365 financial dimension values at the record level (as opposed to the invoice header), no documentation of legal-entity-scoped audit partitioning that would allow the three entities' logs to be isolated and exported independently, no evidence of interface-of-action tagging distinguishing portal approvals from Teams adaptive card actions (and AvidXchange has no documented Teams integration at all), and no documentation of ERP posting confirmation callbacks that capture D365 journal or voucher references inside the audit record. Capterra's aggregated reviewer analysis specifically notes 'inconsistent audit records' as a recurring platform issue. A user review on SoftwareAdvice lists 'report export format limitations, inconsistent audit records' as primary drawbacks. Delegation and escalation events as discrete, named audit nodes — rather than implied by approval chain gaps — are also undocumented.

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's fraud and risk module additionally logs all risk flags 'across the AP lifecycle,' and Medius Payments adds 'audit-ready reporting' that 'ensures an audit trail for every payment.' Multi-entity scoping is addressed: Medius supports entity-aware rules whereby 'each legal entity can maintain its own tax codes, currencies, and approval hierarchies,' and each invoice 'is posted back to the correct ERP with full accounting details, approvals, and audit logs intact.' The buyer's specific ask that records be 'tied to the specific legal entity and financial dimensions on each transaction' aligns with Medius's multi-entity architecture, and the platform's dimension-based coding is synchronized with D365 financial dimensions via its packaged connector. However, two material gaps exist for this buyer. First, no documentation confirms that the audit log explicitly captures the interface channel from which an approval was made (Teams adaptive card versus the Medius portal), which the buyer requires. Second, export granularity for audit records across all three legal entities in a single exportable artifact is documented only at the level of scheduled report exports from the analytics/ETL layer and invoice-level Excel exports from gadgets; there is no documented mechanism confirming a single unified, cross-entity, field-level audit log export purpose-built for external auditors, as opposed to ad-hoc report assembly.

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. Within its supported platforms, Mekorma does document a 'Mekorma Audit Log report' for payment-stage events: when using Mekorma secure approval workflow, posted payments are tracked in the Mekorma Audit Log report, which details who approved and printed each batch, and lists delegates for all payments they approve. That log is confined to payment batch approvals and delegation events at the payment stage. There is no evidence of audit capture for the pre-posting pre-processing stages the buyer requires: OCR extraction events, financial dimension coding changes, tax code assignment, Teams-interface-of-action tagging, or ERP posting confirmation callbacks scoped to individual legal entities and their financial dimensions. Mekorma's enhanced audit log capabilities offer an export-to-Excel function for upgrade history and give visibility into who approved outgoing payments, but this mechanism addresses check-run payment approval tracking, not the structured compliance audit record across the full AP lifecycle the buyer has defined.

This buyer runs Microsoft Dynamics 365 Finance across three legal entities and needs an audit trail tied to D365 Finance financial dimensions, legal entity context, tax codes, Teams-based approvals, and ERP posting confirmation. BILL does maintain a timestamped, unalterable audit trail covering AP activity: approvals, payments, review notes, and remittance details per transaction. However, the foundational integration problem renders this capability irrelevant for the buyer's context: BILL's Microsoft Dynamics integration is scoped exclusively to Dynamics 365 Business Central and Dynamics GP, two mid-market products. There is no documented integration with Dynamics 365 Finance (the enterprise F&O platform), which is what this buyer runs. As a result, the audit trail records that BILL generates cannot be tied to D365 Finance financial dimensions, legal entity structure, or ERP posting events, because BILL never connects to that ERP in the first place. The audit trail records who approved a bill and captures payments, but it operates within BILL's own data model: it does not carry D365 Finance dimensions (department, cost center, project, business unit, or custom segments), does not reflect legal-entity-level isolation across three F&O entities, and has no mechanism to log ERP posting confirmation back from D365 Finance. The approval interface gap compounds this: there is no Teams integration, so the buyer's requirement to capture which interface (Teams vs. portal) an approver used is also unaddressed.