EDI Integration by ERP Platform, Custom Build, or Legacy System

Your ERP Shapes How EDI Should Work

EDI itself, the 850s, 810s, 856s moving between you and your trading partners, is fairly standardized. What isn’t standardized is how your ERP creates, stores, and expects that data back. A purchase order acknowledgment that maps cleanly into NetSuite’s SuiteScript layer won’t touch SAP’s IDoc structure the same way, and a TMS built for load tendering has almost nothing in common with a general-ledger-driven system like Dynamics 365.

That’s usually where EDI implementations stall, not because EDI is hard, but because the provider doesn’t actually understand the ERP on the other end. The second place implementations stall is trading partner testing itself; see how EDI testing and certification actually works for what that process typically involves. Below is how we approach integration across the systems we see most often in mid-market manufacturing, distribution, and logistics. If you are running something built in-house, or a system whose vendor moved on years ago, that is covered further down.

Enterprise & Mid-Market ERPs

SAP (S/4HANA & ECC)

SAP’s IDoc framework is both a strength and a bottleneck: it gives EDI providers a structured, well-documented interface, but IDoc segments don’t map 1:1 to X12 or EDIFACT documents without real mapping work. We build and maintain the IDoc-to-EDI translation layer so purchase orders, ASNs, and invoices flow in and out without manual re-keying, and we handle the segment-level quirks that trip up templated integrations. See our full guide to SAP EDI integration →

SAP Business One

SBO’s smaller footprint means fewer built-in integration hooks than full SAP, so EDI connections typically run through its API layer or a middleware bridge rather than native IDocs. We’ve built these connections for growing manufacturers and distributors who’ve outgrown spreadsheet-and-email order processing but aren’t running full S/4HANA.

JD Edwards (World & EnterpriseOne)

JD Edwards environments range from older World installations to modern EnterpriseOne deployments, and the integration approach differs meaningfully between them. We work with both, mapping EDI documents to JDE’s table structures (like F4211 for sales order detail) so data lands where your team already expects to find it. See our full guide to JD Edwards EDI integration →

Infor (CloudSuite, CSI, LN, M3)

Infor’s product line is really several distinct platforms under one name, each with its own data model and integration tooling (ION for some, direct API/database access for others). We scope the integration to the specific Infor product in play rather than treating “Infor” as one generic connector. See our full guide to Infor EDI integration →

NetSuite

NetSuite’s SuiteScript and REST/SOAP APIs make it one of the more straightforward ERPs to integrate with cleanly, which is part of why it’s become common among growing distributors. We connect EDI documents directly into NetSuite’s native sales order, item fulfillment, and invoice records instead of routing through a bolt-on flat-file process. See our full guide to NetSuite EDI integration →

Acumatica

Acumatica’s contract-based REST API, Generic Inquiries, and Import and Export Scenarios give several viable routes in and out, so the technical surface is rarely the constraint. The two things that shape an Acumatica project are the customizations a deployment carries and the implementation partner who owns them. Worth noting that a good share of Acumatica integration work is not ANSI X12 at all, but industry flat-file standards moving over FTP. See our full guide to Acumatica EDI integration →

Odoo

Odoo’s modular, open structure means the right integration path depends heavily on which modules a company actually uses (Sales, Inventory, Accounting, or a customized build). We work through Odoo’s XML-RPC/JSON-RPC APIs to keep the connection maintainable as modules are added or changed. See our full guide to Odoo EDI integration →

Microsoft Dynamics 365

Dynamics 365 (Business Central and Finance & Operations both) exposes solid API and OData endpoints, but the two products differ enough that we treat them separately when scoping a connection. We map EDI transactions to the correct entities in each so order-to-cash data stays synchronized without duplicate manual entry. See our full guide to Dynamics 365 EDI integration →

ECi M1

M1 is common among smaller manufacturers who need EDI capability without an enterprise-scale system. We connect it through its available data access layer, focusing on keeping the setup lean so it doesn’t outgrow the system it’s serving.

Guardian

Guardian’s install base tends to be more specialized, so we scope these integrations closely to how a given implementation stores order and shipment data, rather than assuming a one-size approach.

Transportation & Logistics Platforms

Trucking and 3PL operations run on transportation management systems (TMS), not traditional ERPs, and their EDI needs center on load tendering, status updates, and invoicing document sets like the 204, 990, 214, and 210 rather than standard purchase-order-to-invoice flows. See our Logistics & 3PL page for more on how that world differs from manufacturing EDI.

McLeod

McLeod is a long-standing standard in trucking dispatch and accounting, with a mature but sometimes rigid data structure. We’ve built EDI connections into McLeod environments handling the full load lifecycle from tender through invoicing. See our full guide to McLeod EDI integration →

Turvo

Turvo’s modern, API-first architecture makes it more flexible to integrate with than legacy TMS platforms, which is part of why more 3PLs are migrating to it. We connect EDI load tenders and status updates directly through Turvo’s API rather than a batch file workaround. See our full guide to Turvo EDI integration →

Rose Rocket

Rose Rocket is another cloud-native TMS gaining ground with growing carriers and brokers. As with Turvo, its API-first design supports real-time EDI status and tender flows instead of the overnight-batch pattern older TMS integrations relied on. See our full guide to Rose Rocket EDI integration →

Custom, Homegrown, and Legacy Systems

Plenty of mid-market manufacturers and distributors are not running any of the platforms above. They are running something a developer built in the 1990s and has maintained ever since, or a heavily modified version of a product whose vendor stopped supporting it years ago. The system works. Replacing it is a multi-year project with no obvious payback, so it stays.

This is usually where the EDI conversation ends. Templated integrations are built against a supported platform list, and a homegrown system is not on it. The provider offers a portal instead, which means somebody re-keys orders by hand, which is the outcome EDI was supposed to prevent.

The question is data access, not platform support

Whether we can integrate with a system has very little to do with whether we have heard of it. It comes down to how data gets in and out:

• Direct database access. If we can read and write the tables, we can work with it. This is the most common path for older systems and usually the most reliable.
• Staging tables. Where writing to production tables is unwise or restricted, we write to a staging layer the system already reads, or build one. Your developers keep control of what happens after that.
• Flat file exchange. Many older systems already produce and consume fixed-width or delimited files on a schedule. That interface is often more stable than anything newer bolted onto the same system.
• API, where one exists. Less common in older environments, though some homegrown systems have accumulated web services over the years.

Most custom integrations end up using more than one of these.

IBM i, AS/400, and RPG environments

A significant number of the metals companies we work with run on IBM i. These environments are stable, fast, and routinely misunderstood by integration vendors who have never touched one.

We are not learning this on your project. Foundational built and ran its own platform on IBM i in RPG and CL for more than two decades. We read the source, work with DB2 physical and logical files, and understand why a program behaves the way it does instead of guessing from the outside.

What actually makes custom integrations harder

Not the technology. Two things:

Documentation. The person who wrote the system may have retired. Field names may mean something that made sense in 1997. We work through that by reading the code and validating against live data rather than trusting a spec nobody updated.

Change control. A commercial ERP publishes release notes. A homegrown system changes when somebody changes it. We build the integration to fail loudly rather than silently when a field moves, and we stay in contact with whoever maintains it.

If you are running something that is not on any provider’s supported list, talk to us about what it actually takes to connect it.