Microsoft Dynamics 365 Business Central and SFTP / Flat Files integration

What moves between them

Data moves in both directions. Outbound, ml-connector reads Business Central records such as purchase invoices, sales invoices, vendors, items, and general ledger entries, transforms each into the partner file format, and writes it to the outbound folder for pickup. Inbound, it polls the partner inbound folder, parses arriving files such as X12 810 invoices, X12 850 purchase orders, or CSV vendor and journal exports, and posts them into Business Central by creating draft documents or updating master records. Cadence is driven by polling: outbound runs on the BC side using lastModifiedDateTime delta filters, and inbound runs on a fixed SFTP poll interval. Posting in BC is explicit, so created invoices land as drafts until a flow calls the Microsoft.NAV.post bound action.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Business Central it requests an OAuth 2.0 client credentials token from Microsoft Entra ID using the tenant ID, client ID, and client secret, scopes it to the BC API, and targets the correct environment name in the URL. For the partner it opens an SSH session with the private key or password and verifies the pinned host key. Outbound flows map BC fields to the partner column or X12 segment layout, since file formats differ per partner and fixed-width files are positional by character, not by header. Inbound flows parse each file, map it back to BC entities, and create drafts that a flow then posts. Because SFTP cannot push and BC webhooks omit payload data, both sides are polled: BC reads use lastModifiedDateTime delta filters and follow @odata.nextLink pages, and SFTP reads list the inbound directory on a timer. Each processed file is renamed or moved to the processed folder and recorded by name and hash so a re-poll never imports it twice, and a stable jobId per file deduplicates at the queue level. The connector handles partial uploads by waiting for a sentinel file or comparing size across two polls, normalizes CRLF and encoding differences, and produces an X12 997 acknowledgment for inbound EDI. BC throttling returns HTTP 429, so writes back off and retry with jitter, and every record carries a full audit trail with error replay.

A real-world example

A mid-sized food distributor with roughly two hundred staff runs Microsoft Dynamics 365 Business Central for purchasing and finance, and sells to several grocery chains that accept orders and send invoices only as X12 EDI files over SFTP. Before the integration, a clerk downloaded each retailer purchase order file, re-keyed it into Business Central as a sales order, then exported the matching invoice and uploaded an X12 810 by hand for every shipment. The work was slow and a mistyped quantity or account meant a rejected invoice and a delayed payment. With Business Central and SFTP / Flat Files connected, inbound X12 850 purchase orders create BC sales orders automatically and outbound X12 810 invoices are generated and dropped in each retailer outbound folder on schedule, with a 997 acknowledgment returned for every file. The team stops re-keying and chargebacks for format errors drop.

What you can do

• •Read Business Central vendors, invoices, items, and journals and write them as CSV, fixed-width, or X12 files to the partner outbound folder.
• •Poll the partner inbound folder, parse arriving files, and post invoices, orders, journals, and master data into Business Central.
• •Bridge the Business Central OAuth 2.0 client credentials token to SSH key or password login on the SFTP server.
• •Map each partner file layout to Business Central OData entities, including positional fixed-width columns and X12 segments.
• •Rename processed files and track them by name and hash, and return X12 997 acknowledgments so nothing is imported twice.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and SFTP / Flat Files?

Both directions. Outbound, the connector reads Business Central records and writes them as files to the partner outbound folder. Inbound, it polls the partner inbound folder and posts the parsed files into Business Central as draft invoices, orders, or master data updates. The exact entities depend on which files a given trading partner exchanges.

How does the integration know when new files or new records are ready?

SFTP has no push mechanism, so the connector polls the inbound directory listing on a schedule, typically every five to sixty minutes. On the Business Central side it reads incrementally using an OData filter on lastModifiedDateTime and follows continuation links for large result sets. BC subscription webhooks exist but carry only change signals and expire every three days, so polling is the reliable path for file exchange.

What stops a file from being imported twice?

After a file is processed the connector renames or moves it to the processed folder and records its filename and a content hash in its own database. On the next poll any file already recorded is skipped, which matters because SFTP timestamps are unreliable across timezones. Each inbound file also enqueues under a stable job id, so a poll that fires twice before the first job finishes is a no-op.