File-Based Integration in Dynamics 365 Finance and Operations

Introduction

Files get filed under "legacy" far too quickly. In Dynamics 365 Finance and Operations (also known as Dynamics 365 Finance & Supply Chain Management) estates, file exchange remains one of the most common integration shapes, and usually the least invested in.

Banks send statements as files. 3PLs return shipment confirmations as flat text. EDI partners exchange ANSI X12 or EDIFACT documents through SFTP or AS2 gateways. Vendor portals push CSVs of price updates. Internal upstream systems drop XML extracts to SharePoint or Azure Storage on a schedule.

If you treat all of these as "the legacy stuff" and route them through whatever the last consultant set up, you slowly accumulate one of the most expensive forms of integration debt: silent, fragile, ERP-owned, but not actually owned by anyone.

This article is a practical guide to file-based integration in D365 F&O. It covers the formats, the storage layers, the recurring patterns, and the operational model that keeps file integrations from becoming a long-term tax on the ERP team.

Why file-based integration matters more than people think

Most D365 F&O landscapes have three things in common:

1. A meaningful share of the volume (often the majority) is asynchronous and document-shaped.
2. The business systems on the other side often require files (banks, EDI partners, government portals, 3PLs, customs brokers, payroll providers, regulated reporting).
3. Files are the lingua franca of ERP-to-non-ERP integration. They cross firewalls, vendors, and decades.

Treating file exchange as an afterthought puts the most operationally critical flows on the weakest foundation.

The formats you actually meet in D365 F&O

The real-world list is shorter than the brochure list. In practical Dynamics 365 Finance and Operations deployments, you mostly deal with:

• EDI: ANSI X12 (US) and EDIFACT (Europe), often wrapped in AS2, SFTP, or VAN delivery
• CSV: vendor price files, item updates, customer master loads
• Delimited / fixed-width text: bank statements, payroll exports, regulatory feeds
• XML: system-to-system master data, document exchange with mature partners
• JSON: increasingly common from modern SaaS counterparts (often arriving wrapped over HTTPS rather than as a file)
• Data entity packages: D365's native bundling format used by the Data Management Framework

Any serious D365 F&O file-integration design needs an explicit answer for each of these formats; otherwise you will end up writing one-off transformation code per partner.

The storage layers that matter

D365 F&O file integrations terminate against a small set of well-understood storage destinations:

• FTP / SFTP: still the dominant protocol for EDI, banking, and vendor exchange
• Azure Blob Storage: natural choice when both ends are Microsoft-cloud-native
• SharePoint: common when finance, controlling, or operations teams curate the files manually
• Local network shares: diminishing but not gone, especially in manufacturing and retail; these sit outside the configured storage-connection model and usually end up migrated to SFTP or Azure Storage

For D365-centric workloads, the strongest pattern is to make the FTP, SFTP, Azure Storage, and SharePoint connections first-class, configurable, and reusable rather than hard-coded into individual integration projects. A storage connection should be defined once and reused across every data port that points at it.

That is what an embedded integration layer like Outbridge does: storage connections, processors (simple text, delimited, fixed-width, XML, CSV, data entity, EDI, API request), data ports, and port groups are configuration, not code.

In concrete terms: Outbridge installs as a model inside Dynamics 365 Finance and Operations. Integrations are configured in F&O, executed in the D365 batch framework, and logged in F&O — run history and payloads stay in the ERP your team already operates. The only external piece is an optional Web Relay for webhook ingress.

Recurring imports and exports — the workhorse pattern

Most file-based D365 integrations are recurring.

A typical estate runs dozens of these:

• Hourly: 3PL shipment confirmations, e-commerce order drops
• Daily: bank statements, vendor master refreshes, regulatory feeds
• Weekly: payroll exports, intercompany journal exchanges
• Monthly: customer master cleanses, supplier rebate calculations

Microsoft's native answer is recurring integrations in the Data Management Framework. It works, but it is opinionated: schedule-driven, package-shaped, with logs that live in the data management workspace.

What it does not give you, out of the box, is:

• a single place to monitor every recurring file flow across legal entities
• hierarchical port groups so a parent file can fan out to dependent child processes
• correlation IDs that follow a file from pickup to D365 record
• payload snapshots (configurable retention) for audit
• routing rules that pick up a file from SFTP, route it to the right legal entity, and trigger the right import

Those are the gaps an embedded integration operating layer is designed to close.

Asynchronous document processing — the harder pattern

A subset of file-based integrations have outgrown the word "file": a purchase order with header, lines, charges, and references is a document. So is an invoice, and so is a shipment with multiple packages and serial numbers.

These are typically modeled in D365 F&O as composite entities (a parent entity with one or more child entities), and they are firmly in the asynchronous, batch family.

Two pitfalls to avoid:

1. Do not flatten composite documents into single OData calls. OData is not designed for header/line transactional posting at scale. You will fight throttling and lose the document semantics.
2. Do not treat document exchange as just "another CSV import." Validation, sequencing, and partial-success behavior are different for documents than for flat lists.

The right architecture is asynchronous, document-aware, with sequenced processing and visible state. In Outbridge that is the job of composite data entities: a header-line document arrives as a file or an entity package, a composite-entity processor maps the parent and its children together, and processing runs asynchronously in the D365 batch framework, with sequencing and run state visible in the ERP, where the people who can fix data issues already work. The Web Relay stays in its webhook lane here: when a partner announces a new document with a lightweight notification, Outbridge pulls the full document from the source system and routes it into the same composite-entity processing. Where retry is needed, it is configured at the port-group level.

EDI in D365 F&O — a special case

Dynamics 365 EDI integration deserves its own paragraph because it is one of the highest-stakes file flows in any D365 F&O estate.

The realities:

• EDI partners do not negotiate. If your trading partner expects ANSI X12 850 over AS2 with a specific envelope, that is what you will deliver.
• Most EDI failures are silent until somebody downstream calls about a missing shipment.
• The transformation between EDI and D365 entities is rarely 1:1. There is mapping, validation, and partner-specific quirks.
• EDI volume is often spiky: a quiet Tuesday and a 5,000-document Friday afternoon.

A good D365 EDI integration architecture treats EDI as a first-class processor (not as "we'll write a parser"), uses asynchronous handling so a partner spike does not block user-facing transactions, keeps logs in D365 for the operations team to triage, and does not need a separate iPaaS license to do basic EDI ingestion.

What good looks like — checklist

If you are evaluating or improving file-based integration in D365 F&O, the bar is:

• Storage connections are defined once and reused (FTP, SFTP, Azure Storage, SharePoint)
• Processors handle the formats your partners use (EDI, XML, CSV, delimited, fixed-width, data entity, API request) without bespoke code per partner
• Data ports and port groups support hierarchy and dependencies so parent/child sequencing stays configuration rather than custom logic
• Webhook entry exists for the cases where a partner pushes notifications instead of dropping files
• Logs live in D365 under Modules > Outbridge > Inquiries and reports: the Run history view (per-run with Run status, Port ID/group, Correlation ID, Trigger, Snapshot tab, and API request bodies as downloadable attachments) and the Execution log view (chronological with Severity, Stage, Snapshot), so the ERP team can triage without leaving the system
• Authentication and IP/domain whitelisting are configurable at the relay level
• The whole thing is asynchronous by default so a partner spike does not block user-facing postings

When file-based integration is not the right answer

This pattern is not universal, though. Avoid file-based integration as the default when:

• the workload requires real-time confirmation back to the calling user (use OData or custom services)
• the external system owns orchestration and just needs synchronous calls into D365
• the data shape is a single record per call and latency matters
• regulatory or contractual rules forbid intermediate file storage

One clarification: asynchronous does not mean silent. An Outbridge port can send a callback notification with the processing outcome once a document has been handled, so the counterparty still learns what happened to its file. The boundary above is only about a caller that blocks and waits for an in-session answer.

Use the right tool for the workload, rather than the tool you happen to have a license for. If you are weighing file-based patterns against native D365 tooling, iPaaS, or custom X++ for a given flow, the D365 F&O integration architecture decision framework walks through that choice.

Making file-based integration a first-class discipline

File-based integration is not glamorous, but it carries an outsized share of the value in Dynamics 365 Finance and Operations estates.

The teams that handle it well do three things:

1. Treat file integration as deliberate architecture rather than legacy plumbing.
2. Standardize storage, processors, ports, and logging, so each new partner is configuration, not a project.
3. Keep execution and troubleshooting close to ERP, where the people who can fix data already are.

Book a 30-minute Integration Architecture Review — free, vendor-neutral. Bring your recurring file flows; we will map each by partner, format, schedule, and ownership, and tell you where it belongs, including a clear "no" where Outbridge is not the answer.

Related reading

• D365 F&O Integration Architecture: Native, Embedded, iPaaS, or Custom?
• D365 F&O Integration Patterns: Synchronous vs Asynchronous (coming soon)
• D365 OData vs DMF: When to Use Each Integration Pattern (coming soon)
• How to Reduce Integration Cost in D365 F&O Without Rebuilding Everything (coming soon)