D365 F&O Batch Vendor Invoice Import via DMF

Dynamics 365 Finance & Operations imports vendor invoices in batch through the Data Management Framework (DMF), using a paired Vendor invoice header entity and Vendor invoice line entity that link by invoice number. Before that import can run cleanly, the batch needs a destination — one of three F&O artifacts, each with its own posting behaviour and its own downstream consequences for approval and matching.

The three destinations are the vendor invoice journal (lightweight, journal-style entries useful for cleanup batches and historical migrations), the vendor invoice register plus invoice approval journal (the classic two-step capture-then-approve flow with separate posting), and pending vendor invoices (the destination that puts the imported invoice into the standard vendor invoice workflow and exposes it to automatic PO and product receipt matching). Each of these has its own header/line entity pair in DMF, and the destination decision drives both the entity selection and the shape of the import file.

That single decision — destination first, entities and file shape second — is what separates a d365 f&o batch vendor invoice import that posts cleanly from one that stalls in staging or lands invoices in the wrong place. Pick the wrong destination and a migration of already-approved historical invoices triggers approval workflows that should never have fired; pick the right one and the same file flows through to the right approver and the right matching policy with no manual intervention.

This article is the DMF batch path specifically. It takes a structured file — commonly from an upstream extraction step, a migration source, or a third-party capture service — runs it through DMF data entities into the destination artifact you chose, and hands the result off to the workflow and matching layers configured on your environment.

Choosing the destination: vendor invoice journal, register, or pending invoices

The three destination artifacts solve different problems, and the right choice depends entirely on what AP wants to happen after the invoice lands.

Vendor invoice journal is the lightweight option — journal-style entry, direct posting, no separate approval workflow. Once the journal posts, the invoice transaction posts with it. This is the right destination for cleanup batches and for migrations of historical invoices that were already approved in the legacy system, where re-running them through F&O's workflow would be both pointless and noisy. It is also the right destination for adjusting entries and corrections that AP wants to land as journal entries rather than as workflow-tracked vendor invoices. The trade-off is that nothing about this path engages F&O's matching policies or the standard vendor invoice workflow; if you need either, this is the wrong destination.

Vendor invoice register plus invoice approval journal is the two-step capture-then-approve flow. The register stage captures the invoice and posts a credit to the vendor account against a holding account — recognising the liability the moment the invoice arrives, even before expense coding or approval has happened. Some time later (typically days or weeks, depending on the organization's close cadence), the invoice approval journal picks up the registered invoice, debits the expense account or the PO accrual, clears the holding account, and posts the invoice into its final state. This fits organizations where AP wants liability recognition on receipt of the invoice but the expense coding and approval work belongs to a different person, often working on a different timeline. A d365 f&o vendor invoice register batch lands in this two-step flow when AP needs the liability visible immediately but the rest of the invoice can wait for the approver. The closest parallel on the Dynamics SMB side is Business Central's invoice registration journal as the SMB counterpart to F&O batch intake, which fills a comparable role for BC organizations.

Pending vendor invoices is the destination that wires the imported invoice into the standard vendor invoice workflow and into automatic PO and product receipt matching. Once a row lands here, the invoice behaves the same as one captured interactively through the vendor invoice center or surfaced through Intelligent OCR — the workflow triggers, matching policies evaluate against the PO and receipt references on the invoice, and approval routing resolves against the invoice's amount, dimensions, and vendor. An f&o pending vendor invoices import is the right choice when the batch needs to follow the same governance path as in-flow invoices: it is the natural destination for invoices coming from an external capture service, an extraction pipeline upstream of F&O, or any source where the batch is operational rather than migratory.

The downstream consequences of these three choices diverge sharply. The vendor invoice journal posts on its own and never touches the vendor invoice workflow or matching policies. The register-plus-approval-journal flow splits the posting in two and uses the invoice approval journal as its approval gate, separate from the standard vendor invoice workflow. Pending vendor invoices is the only destination of the three that triggers the standard vendor invoice workflow and exposes the invoice to automatic matching, and it is the only one where the imported invoice shows up in the vendor invoice workspace alongside invoices captured through the other intake paths.

The decision mistakes are predictable. The most common is dumping migration data — old, already-approved invoices being brought across from a legacy system — into pending vendor invoices, which then triggers the vendor invoice workflow on every historical record and floods approvers with thousands of items that should have skipped the workflow entirely. The opposite mistake is importing live operational invoices into the vendor invoice journal because it is the simplest path, only to discover later that the matching policies the organization relies on were never applied and that there is no workflow audit trail on any of these invoices. The destination has to match the use case; choosing it for convenience rather than for fit is where most multi-week clean-up projects start.

The DMF data entity model for vendor invoices

The DMF data entity model for vendor invoices is built on a header-and-line pair: a Vendor invoice header entity and a Vendor invoice line entity, joined by invoice number as the parent-child key. Both entities have to be mapped together in the same DMF data project, with the import order honouring the parent-child relationship so the header row lands before any of its line rows. A DMF data project that includes only the header entity will import invoice headers with no lines attached; a project that includes both but runs the line entity first will fail every line row at validation, because the matching header does not yet exist in staging.

Each destination artifact has its own header/line entity pair behind it, and the entity you map has to correspond to the destination you chose in the previous section. The vendor invoice journal sits behind its own journal header and journal line entities. Pending vendor invoices sits behind a pending vendor invoice header and a pending vendor invoice line entity. The vendor invoice register has its own register entity for the registration step, with the invoice approval journal handled through a separate journal-side entity. This is the detail that catches teams who treat the entities as interchangeable: a journal-side entity will not land data in pending vendor invoices, and a pending-side entity will not produce journal entries. The entity choice is part of the destination choice, not a separate decision to make later.

The parent-child key relationship is where most entity-level failures originate. Invoice number is the join — the line row's invoice number has to match the header row's invoice number exactly, including character case, leading and trailing whitespace, and any prefix or suffix the source system applied. A line row with "INV-00123 " (trailing space) referencing a header row with "INV-00123" does not join; the line orphans in staging and never attaches to its header. This pattern often survives all the way through a source system unnoticed because the source's own display layer trims whitespace before showing values to users, masking the data-quality issue right up until the moment DMF refuses to join the rows.

Optional fields on these entities go beyond shaping the data — they change behaviour downstream. Posting profile selection on the header determines which ledger accounts the invoice posts against and can override the vendor's default profile. Financial dimension defaults can be supplied per row to drive cost-centre or project assignment. Sales tax fields on the line, including tax codes and item sales tax groups, control how tax calculates against the destination legal entity's tax setup. Document attachment fields, mapped through the document attachment entity in the same project, attach PDFs or images of the source invoice to the imported record so the document is available alongside the data in F&O. None of these are required for the import to physically run, but each can change what the invoice looks like once it is posted.

Architecturally this is one place where Dynamics 365 Finance & Operations and Business Central diverge sharply. BC does not use this entity model at all — BC's import path runs through Configuration Packages or the Purchase Invoice Import add-on, with field-mapping happening against a CSV or Excel template rather than against parent-child data entities. Teams with experience importing invoices into Dynamics 365 Business Central via Configuration Packages and CSV sometimes assume the F&O path is a similar field-mapping exercise; it is not. F&O's DMF model is staging-table-based with explicit entity validation, and the BC mental model does not transfer to it.

Shaping the import file so DMF accepts it

Once the destination and entity choice are settled, the work shifts to the import file. F&O takes Excel, CSV, and several other DMF-supported formats; what matters is not the file type but the field-level shape against the entities you mapped.

The header entity requires, at minimum: an invoice number that acts as the parent key, a vendor account that exists in the target legal entity (not just somewhere in the tenant), an invoice date, due date or terms of payment, currency code, the legal entity itself, and a posting profile that controls how the invoice posts to the ledger. Each of these has to be valid against the destination company's setup, not against any company in the environment — a vendor master that is set up only in USMF will not satisfy a row scoped to DEMF, even when the vendor name and contact details are notionally the same.

The line entity requires invoice number (the foreign key matching the header row), line number, item or procurement category, quantity and unit, unit price or line amount, and any financial dimensions the legal entity marks as mandatory on vendor invoice postings. The line entity is where most of the substantive data lives, and where most of the validation effort lands.

Several optional fields change posting behaviour rather than just shaping the data. Sales tax codes and item sales tax groups resolve against the destination legal entity's tax setup — a tax code defined in one company will not resolve in another, and there is no tenant-wide tax code list to fall back on. Charges and miscellaneous charges on the header or line attach freight, customs, and similar amounts to the invoice in the way F&O expects them. Document date versus posting date matters when the organization runs period control or accrues across period boundaries. Payment reference fields populate the data the bank file generation step needs later. A matching policy override on the line lets you explicitly bypass or enforce specific PO matching where the default policy for the procurement category is not what this batch needs.

Tax code mapping deserves its own attention because it fails so reliably. Tax codes have to exist in the destination legal entity and resolve cleanly against that legal entity's tax setup. The same code name in two different companies can refer to different rates or different reporting structures, and a code that resolves in one will not necessarily resolve in another. Pre-validate every tax code against the destination company's tax setup before submitting the import, ideally by querying the destination company's tax code table from a small validation step in whatever produces the source file.

Legal-entity scoping runs through every other validation. Each row's legal entity, expressed as the DataAreaId, determines which company's setup the row validates against — vendor account, tax codes, financial dimensions, posting profile, exchange rates, the lot. Cross-company batches need each row scoped explicitly to its destination company; relying on a default scope at the DMF job level only works when every row in the file belongs to the same company.

Currency handling adds another failure surface. An exchange rate for the invoice currency on the invoice date has to exist in the destination legal entity's currency exchange rate setup; otherwise the import fails on rate resolution before the invoice is ever posted. Triangulation currencies — where the invoice currency differs from both the company's accounting currency and the reporting currency — compound this, because rates have to be present for each leg of the conversion. Loading currency rates is a separate maintenance task that has to be in place before the import runs, not something the DMF job will handle for you.

Document attachments come in through their own data entity. The document attachment entity sits in the same DMF data project as the header and line, linked by document key to the header, and PDFs or images of the source invoice attach as records on that entity. When the project runs, the attachment lands alongside the invoice in F&O, visible to anyone reviewing the imported record. This is also where the source document for the invoice becomes available to approvers in the workflow.

Clearing the staging table: why imports halt and how to fix them

DMF stages every imported row in an entity-specific staging table before posting anything to the target. Validation happens at the staging step, and the import halts there when validation fails. The actual vendor invoice header, pending vendor invoice, or invoice register record — the target table — is never touched until staging passes for that row. This is the safety net: a half-validated batch leaves staging rows behind but leaves the target tables in their pre-import state.

The error patterns that show up in staging are predictable enough to enumerate, and each has a specific cause and a specific fix. These are the d365 f&o vendor invoice staging table errors most teams see week after week.

• Vendor not found in the target legal entity. The vendor account on the row exists somewhere in the tenant — usually in another legal entity that was the source for setting it up — but not in the legal entity the row is scoped to. F&O does not automatically share vendor masters across companies; each company maintains its own vendor table unless the organization explicitly configures shared vendor master data. Fix: confirm the vendor is set up in the destination legal entity (and create it if not), or re-scope the row to a company where the vendor does exist.
• Tax code mismatch. The tax code or item sales tax group on the row does not exist in the destination legal entity's tax setup, or it exists but does not resolve cleanly against the tax group on the vendor or item. The same code name in different companies can mean different things, and F&O validates against the destination company's setup specifically. Fix: validate the source file's tax codes against the destination legal entity's tax code table before submitting, or update the source mapping to use codes that exist in the destination.
• Currency exchange rate missing. No exchange rate is defined for the invoice currency on the invoice date in the destination legal entity's currency exchange rate setup. This happens most often for back-dated invoices where the historical rate was never loaded, or for currencies the company has only recently started transacting in. Fix: load the missing rate (or rates, for triangulation cases) into the exchange rate setup, then re-run the affected rows.
• Header-line key break. Line rows reference an invoice number that has no matching header row in the same batch. Almost always a data-quality issue at the source: trailing whitespace on the line invoice number, character-case differences, or a header row that was filtered out by an export step while its lines survived. Fix: re-export the source so header and line rows share exact invoice numbers, with no leading or trailing whitespace and consistent case.
• Mandatory dimension missing. The legal entity requires a financial dimension on vendor invoice postings — cost centre, department, project, or similar — and the source row does not supply a value for it. F&O will not default a mandatory dimension; the row fails validation. Fix: add the dimension value to the source file, or reconfigure the legal entity's dimension setup if the requirement was set up in error.
• Posting profile mismatch. The posting profile name on the row does not exist in the destination legal entity, or has been renamed. Fix: align the profile name on the source row with what is configured on the destination.

The cleanup pattern for a failed staging batch matters as much as the diagnosis. Deleting staging rows for a failed run is generally safe — nothing has been posted to the target table, so removing staging rows for the failed portion does not leave orphaned records in the actual vendor invoice tables. The case to be careful about is partial success, where some of the batch posted and some failed. In that situation, the staging rows for the failed portion are the audit trail of which rows landed where; do not delete them until the posted portion has been verified against the target tables and you know exactly what state the data is in.

Re-running corrected rows beats re-importing the whole batch. DMF does not deduplicate imports, so re-running a full file after a partial success creates duplicate invoices in the target — invoice number alone does not protect you, because the second import will land as a new invoice rather than rejecting on the existing one. The discipline is: fix the source file for the failed rows specifically, import just those rows, leave the posted rows alone.

There is a deeper pattern worth naming when the same staging errors recur batch after batch. When whitespace on invoice numbers, inconsistent tax code naming, missing financial dimensions, or vendor-not-found errors show up across every weekly load, the problem is not in F&O at all — it is in the upstream extraction or capture step that is producing inconsistent data. Fixing it in the staging table over and over is the most expensive way to handle it. The cheaper fix is upstream: making the extraction step produce clean, normalized, DMF-ready data the first time, every time.

Workflow approval and PO matching on DMF-imported invoices

Once an invoice lands cleanly in its target table, the next question is whether the vendor invoice workflow triggers and whether matching runs — and the answer depends entirely on which destination the import targeted.

Invoices landed in pending vendor invoices trigger the standard vendor invoice workflow automatically, the same as invoices created interactively through the vendor invoice center. From the workflow engine's perspective there is no difference between a pending vendor invoice that was typed by an AP clerk and one that arrived through a DMF batch. The workflow triggers, the routing rules evaluate, and the invoice moves to the first approver. Invoices landed in the vendor invoice journal bypass the standard workflow entirely — the journal posts on its own approval step (the user who posts the journal is the implicit approver), and no vendor invoice workflow ever runs against the invoice. Invoices landed in the vendor invoice register flow next to the invoice approval journal, which is the approval gate for the register-and-approve path; this is a separate journal-side flow rather than the standard vendor invoice workflow, and the routing rules and approver setup are configured independently.

Approver routing on a DMF-imported pending vendor invoice resolves the same way as on a natively captured invoice — by the fields on the invoice itself. Amount, legal entity, financial dimensions, vendor, and project (where applicable) are what the workflow evaluates. If the import file supplies dimensions and amounts that drive conditional approval rules, those rules fire the same way they would for a manually entered invoice. If those fields are missing or wrong, the routing falls through to whatever default the workflow is configured with — sometimes a catch-all approver, sometimes an outright failure that parks the invoice in an unassigned state requiring manual intervention. The operational consequence is unambiguous: routing-driving fields are not optional on the import file, and getting them right at import time is what makes the workflow behave correctly without intervention later.

Conditional approvals on amount thresholds and dimensions work the same way. The workflow does not know the invoice came from DMF; it evaluates against the data on the invoice. An imported invoice for $250,000 routes to the higher-tier approver just as an in-product capture for the same amount would. An imported invoice missing the cost-centre dimension routes (or fails) according to whatever the workflow says about missing dimensions, with no special-case handling because the source was a batch. The implication for the import file is unambiguous: the fields that drive routing are part of the import contract, not nice-to-haves.

Audit trail differences are subtle but real. F&O records the source of an invoice in workflow history and document references, and the originating user for an imported invoice is the user account that submitted the DMF job, not whoever produced the source file. The capture method — vendor invoice center, Intelligent OCR, or DMF batch — is recorded on the invoice and is visible to auditors looking at the trail. Organizations with strict provenance requirements sometimes route DMF imports through a dedicated service account so the trail is unambiguous, rather than letting the submitting administrator's account become the recorded originator across thousands of historical invoices.

PO and product receipt matching on imported invoices follows the same logic. Matching policies are configured per procurement category, item, or vendor, and they evaluate against the PO number and receipt references on the line entity. When the import file populates the PO number and the relevant receipt reference on each line, matching runs automatically against the configured policy — two-way (PO to invoice), three-way (PO to receipt to invoice), or charges-based variants. When the PO and receipt are not populated, matching does not fire, and the invoice posts as a non-PO invoice. That is rarely what AP actually wants for an operational batch; non-PO posting bypasses the accrual the receipt created, and the open PO line stays open with no matching invoice against it.

What needs to be set on the import file to enable matching is straightforward but easy to miss: PO number on each line where the line maps to a PO, product receipt reference where three-way matching applies, and line-to-PO-line linkage where matching is at the line level (some matching policies match header-to-PO; others match line-by-line, and the import file's linkage has to match the policy). The matching policy override exists for the case where a specific imported invoice should explicitly bypass the configured policy — useful when historical invoices are being brought across that pre-date the current matching setup.

The contrast with the vendor invoice center and Intelligent OCR paths is in when matching happens. Those paths capture invoices interactively, with PO and receipt suggestions surfaced at the point of capture, and the AP user resolves matching exceptions inline before the invoice ever enters the workflow. A clerk capturing a vendor invoice in the vendor invoice center will see immediately if the PO has no matching receipt, or if the amount is outside tolerance, and can resolve it before submitting. A DMF-imported invoice arrives with whatever matching state the import file specified — if the PO is wrong or the receipt reference is missing, the issue surfaces later in the workflow or in the matching exception queue, rather than at point of capture. The choice between paths is partly a choice about where in the process the exception-handling work happens.

Multi-legal-entity batches

Many F&O environments run with several legal entities — operating companies, regional subsidiaries, shared services centres — and any AP batch of meaningful size will touch more than one. There are two viable patterns for handling this, and the right one depends on how the source data arrives and how independent the failure modes need to be. An f&o multi-legal-entity vendor invoice import sits in one of these two shapes.

Pattern A: one DMF job per legal entity. Each job is scoped to a single company, and the source file is split or filtered per company before the job runs. Operationally this is the simpler pattern — each job's failures only affect one company's staging table, re-runs do not require any row-level re-scoping, and a failure in one company does not block any of the others. It fits naturally when the source data is already segmented by company, which is often the case when the upstream extraction step is configured to produce one file per receiving legal entity, or when separate AP teams own each company's batch.

Pattern B: a single file with per-row legal-entity scoping. Every row carries an explicit DataAreaId, and a single DMF job runs against an execution context that can write to multiple legal entities. This reduces orchestration overhead and fits well when the source data arrives as a single batch — typically because the extraction or routing step upstream determines each invoice's receiving company from the bill-to address, a vendor-to-entity map, or a PO lookup. The requirement is twofold: the DMF job has to run in a cross-company-capable context, and every row's setup (vendor account, tax codes, posting profile, mandatory dimensions) has to be valid in the legal entity it is scoped to. The single-file pattern fails fast when one company's setup is incomplete, because the rows for that company will hit the same vendor-not-found or tax-code-mismatch errors covered earlier — just mixed in among rows for companies where the import is succeeding.

Vendor mapping across companies is the recurring complication. A vendor doing business with multiple group companies will typically have a different vendor account ID in each company unless the organization has explicitly configured shared vendor master data. The vendor name "Acme Corp" can map to vendor account V-1042 in one company and ACME001 in another, and the import file has to use the right account ID for the destination company on every row. Relying on vendor name to do the mapping at import time is not an option — DMF validates against vendor account, not against name.

Inter-company posting is the other complication. When an invoice received in one legal entity needs to be posted across to another — a common pattern when a shared services centre handles AP on behalf of operating companies, or when a parent company pays a vendor and rebills the subsidiary — F&O's inter-company accounting setup governs how the cross-entity entries generate. The inter-company trading relationships, posting profiles, and dimension defaults all have to be configured in advance. DMF imports do not bypass the inter-company setup; they trigger it the same way an interactively entered invoice would. The cross-postings happen automatically when the setup is in place, and they fail when it is not.

Cross-company allocations and charges — rebill arrangements, shared-cost allocations, inter-company management fees that need to land on multiple companies — usually do not survive a naive single-import approach. The two workable options are modelling them in the source data with explicit cross-company lines (where the source extraction step is sophisticated enough to know about allocations and to break them out by receiving company), or running separate jobs per company and relying on F&O's inter-company functionality to generate the cross-postings after the fact. Which is right depends on whether the allocation logic lives in the source system or in F&O itself.

---

When to extract upstream vs use F&O's native invoice automation

DMF batch import is one of three viable intake paths for vendor invoices in F&O, and it is not always the right one. F&O ships with its own native intake — the Intelligent OCR capability inside the invoice capture solution, and the vendor invoice center for interactive entry — and that path is well-suited to a specific set of conditions: invoice volumes that are moderate rather than overwhelming, a document mix that is reasonably uniform, and an AP team that wants point-of-capture control over matching exceptions and dimension assignment. When those conditions hold, the native path keeps the entire workflow inside F&O, with no external dependencies and no separate audit trail to reconcile.

The DMF batch path is the right choice when the conditions are different: invoices arrive in batches rather than one at a time, the source data is already structured (or will be, after an upstream extraction step), and the organization wants explicit control over field-level transforms, multi-entity coding, and data quality before any of it touches F&O. The two paths are complements, not substitutes; many F&O environments run both — Intelligent OCR for in-flow invoices that arrive by email or upload, DMF batch for periodic loads from external systems, migration runs, or third-party capture services.

Where upstream extraction belongs in this picture is specifically when the source documents are unstructured and varied — PDFs, scans, vendor portal exports, the mixed stack that real AP teams actually receive. Producing a clean, structured, line-level dataset shaped to the F&O Vendor invoice header and Vendor invoice line entities before DMF runs converts a heterogeneous problem (every invoice looks different) into a uniform one (every batch lands the same way). The staging-table error patterns covered earlier — vendor not found, tax code mismatch, header-line key break, mandatory dimension missing — become rare rather than routine, because the upstream step is enforcing data quality at the entity boundary instead of leaving it for DMF to discover and reject.

The decision factors come into focus when you compare the paths against the work they have to do:

• Volume and variety. High volume with high document variety pushes hard toward upstream extraction; the same prompt or extraction logic processes the whole stack and produces the same DMF-ready output every time. Moderate volume with uniform documents fits native intake, where Intelligent OCR's defaults are well-matched to the input.
• Multi-entity coding control. When each invoice's legal entity, dimensions, and tax coding are determined by upstream logic — a routing service, a vendor-to-entity map, an invoice-to-PO lookup — upstream extraction can supply those fields deterministically before DMF runs. Intelligent OCR uses its own defaults and learned mappings, which suit some organizations and not others.
• Audit trail. Native intake keeps the audit trail inside F&O end to end; upstream extraction adds an external step with its own logging that needs to reconcile against the F&O trail. Some organizations strongly prefer the single-system trail; others explicitly want the external step for control reasons (a separate party producing the extraction record, a different system enforcing the data-quality contract).
• Field-level transforms. When invoices need normalizing or enriching before they hit F&O — date format standardization, tax-code re-mapping from supplier conventions to internal codes, vendor name resolution against the master list, currency conversion at a specific rate — upstream extraction is the natural place to do it. F&O's native intake assumes the data is already in the shape it expects.

This is where Invoice Data Extraction enters as the upstream step for the DMF path. The product converts a mixed batch of invoice PDFs, scans, and portal exports into a structured spreadsheet — natural-language prompt in, structured Excel, CSV, or JSON out. Batches scale to 6,000 mixed-format files per job and single PDFs up to 5,000 pages, which is the kind of throughput an enterprise AP batch actually needs; the prompt-based extraction is what makes the output consistent across thousands of documents, with the same column structure and field-level rules applied to every invoice regardless of supplier format. A prompt configured to produce the F&O header and line shape — invoice number, vendor account, legal entity, currency, line item, quantity, unit price, line amount, financial dimensions where the organization makes them mandatory — turns the upstream extraction into the entity boundary that DMF then consumes cleanly. That is the practical role: extract vendor invoice PDFs into a DMF-ready dataset once, on a stable prompt, so the staging table stops being the place where data-quality problems are discovered.

For readers whose answer is to stay on F&O's native intake, the complementary coverage is Dynamics 365 Finance's native Intelligent OCR and vendor invoice center workflow, which goes into the native automation path in depth. For BC organizations that landed here on the wrong product, the parallel native intake on the BC side is Business Central Payables Agent for native PDF invoice intake, which fills a similar role to F&O's Intelligent OCR for AP teams on the SMB platform.

The strategic point underneath all of this is that the intake quality determines the ceiling on what AP automation can achieve. The Hackett Group's 2025 Digital World Class Matrix for accounts payable found that top accounts payable platforms deliver 60% touchless, straight-through invoice processing and 3.5X higher AP productivity than peers, with 59% faster cycle times. Those numbers compound from clean upstream data — invoices that arrive at the workflow already coded correctly, matched against the right PO, scoped to the right legal entity. Whether that data quality comes from F&O's native intake doing its job well or from an upstream extraction step producing DMF-ready output, it is the lever — not a footnote.