No ERP does EDI alone: what users of fourteen ERPs say
Every ERP vendor's brochure says the product supports EDI. I wanted to know what that means in practice, so I read what the people who run these systems say in their own forums and community blogs: the SAP community, the Dynamics forums, the Epicor, Acumatica, IFS and Infor communities, the Odoo forum, and the one subreddit where EDI people talk to each other. About two hundred posts, fourteen ERPs. The short version is that no ERP does retail EDI on its own. Each one supplies a door, a way for documents to get in and out, and a translator, network or middleware does the EDI. The differences are in how good the door is and where the work that is left over has to be done.
ERP by ERP, in their users' words
SAP. The strongest in-product framework, and still the exception. IDocs are defended by its consultants for exactly the reasons retail EDI needs: asynchronous, bundled, reprocessed in bulk, monitored by business users in screens they already know. One well-known SAP integration writer argues that using APIs instead of IDocs for high-volume EDI is a design flaw, and a 2025 SAP note confirmed IDocs remain within clean-core rules. Even so, the SD consultants who write the detailed guides push partner quirks outward: unit-of-measure conversions and partner-role mapping belong on the network or middleware side, because provider rules are usually cheaper than development inside SAP. On the public cloud edition the IDoc framework is not available and EDI goes through SOAP business interfaces instead, which one consultant described as replacing a method used for many years.
Microsoft Dynamics 365. A moderator on the Finance and Operations forum put it in one line: the product provides an integration framework through data entities but does not support EDI out of the box. Another user: it is not an integration engine. The options are an add-on from an independent software vendor, which several users call expensive, or building the error handling and mapping in Logic Apps against the data entities, which presumes in-house skill. On Business Central the connectors are lighter and the processing runs in the network's cloud. The older NAV threads are the most candid about cost: an IT director with two hundred partners found embedded EDI customisation and testing ran well over the estimate, and concluded that embedded suits a few partners with light maps while outsourcing suits many partners with complex ones.
Oracle NetSuite. The practitioner forums are behind a wall, so the readable evidence is thinner, but the pattern is a managed network by default and strong opinions about which one. The measured onboarding times I quote elsewhere came from a NetSuite supplier. The one first-hand go-live story, from an apparel company, said the biggest challenges were not with NetSuite itself but with third-party integrations, particularly the EDI partners, some of which turned out not to exist yet.
Epicor. A long-time user explained to someone struggling with Amazon that Epicor's EDI output is just a dump of the report data definition, which a network must parse and translate. The vendor-direction document set is not available out of the box, and a supplier shipping to a large American hardware chain generates an SSCC-18 label for every pack regardless of customer and lets report routing decide what prints. A move to the web client changed the line endings in the ASN file and a customer rejected it for two months.
Acumatica, sold here as MYOB Acumatica. The accepted answer on the community is that native Acumatica does not have EDI functionality; use a marketplace add-on. The threads that follow are the real content: one sellable unit shipped in two boxes came through on the ASN as quantity two, and the fix was to model the boxes as components of a non-stock kit so the network could build the pack hierarchy. A connector logged itself out every thirty days for ten months before anyone explained why. EDI status lines count as ERP transactions against the licence tier.
Odoo. The built-in feature called EDI is electronic invoicing in European formats. Retailer EDI goes through a network or a custom module, and a forum question asking which transaction sets Odoo supports has over six thousand views and no answer.
IFS. Message classes and routing rules exist, but as a partner answered a customer who wanted one despatch-advice line per part instead of one per pallet, there is no transformer available for EDI, so it is a customisation. An inbound order was rejected on a blank date field until the network learned to omit it.
Infor. A healthcare customer found the maps written to one exchange's specification with no mapping tool to build others. A manufacturer on the automotive suite wrote a long post about orders that fail in the integration layer and vanish, proposing that the EDI team own mapping and customer service own cross-references, prices and minimum quantities.
JD Edwards. Inbound orders land in interface tables and a batch program creates them; it fails on incomplete item and address cross-references and unit mismatches. As one consultant put it, the program does not create orders, it exposes how well the system is configured. The outbound ASN's hierarchy is derived from packaging set-up, not configured. The X12 itself is always produced by a translator.
SYSPRO. Native EDI means fixed-format import and export programs, an XML document-flow manager and business objects. The import program rejects lines on sender code, cross-reference, unit, on-hold stock and duplicate order, parks every quantity in back order regardless of stock, and imports only when all lines are valid. SYSPRO's own guidance says to connect through business objects, which stay forward compatible, and warns that direct database connections tie a solution to a release. The translator is always a partner product.
Sage, Cin7, Unleashed, Katana, Fishbowl. All of them answer the question the same way: a third-party connector. Sage 50's integrators note it cannot produce an order response or hold packing information, so the connector synthesises them. Cin7 has native retailer connections in one edition and partner connectors in the other, and a trade article quotes a buyer who found out six months in that the edition they had bought could not trade with a large American retailer.
What this means when choosing or changing an ERP
The ERP decides where four things live: the item and location cross-references, the pick confirmation the ASN is built from, the packing data that gives the ASN its hierarchy, and the batch timing that stamps dates on documents. Almost every failure story above is one of those four in the wrong place or the wrong hands. It does not decide whether you need a translator; you do. So when I assess a system for retail trading I ask four questions. Where do the retailer's part numbers and location numbers live, and who maintains them. Can the ASN be generated from what was actually picked. Does the warehouse capture the pack level the retailer wants. And what runs overnight that could change a date. The answers tell me more than the brochure.