Every X12 file your trading partners exchange with you can be read and generated inside your own ERP. That is how we build EDI. The mapping lives in the ERP’s own code, and the files are parsed and produced with the EdiFabric .NET library.
What changes from partner to partner is only how the file travels. Some retailers accept files directly. Others require their own network, such as SPS Commerce, CommerceHub or Radial. In both cases the ERP builds and reads the files itself. Where a network is involved, it validates the files and delivers them. It does not translate them.
Two ways to run EDI
Most companies arrive at EDI through a translation provider, often called EDI middleware, and for good reason. A trading partner requires EDI, there is no time to build anything, and a provider can get the connection live quickly. That is a sound decision under the constraints it was made in.
The question worth revisiting is what happens afterwards, once EDI is no longer a project but part of how the business runs. At that point the trade-offs look different.
How a translation provider setup works
The usual middleware arrangement has three parts. A connection carries files between you and the partner, often through a value-added network or a secure file transfer. A mapping layer translates between the partner’s transaction sets and a format your systems can read. Then an integration drops the translated data into your ERP, commonly as a flat file or a staging table.
The mapping lives in the provider’s tool. You configure it, or they configure it for you, and the translation happens outside your own systems. Commercially, these arrangements are often structured around a per-document fee model, so cost scales with transaction volume rather than with complexity.
That architecture has real strengths. Onboarding a new partner is a configuration exercise rather than a development one, the provider keeps up with connectivity requirements, and you do not need EDI knowledge in house.
What changes when the mapping is yours
Moving the mapping into your own codebase changes three things in particular.
Ownership of the business rules. EDI mapping is rarely only format translation. Deciding which SKU a partner’s item number refers to, how a substitution is represented, what happens when a quantity cannot be fulfilled: these are business rules, and they get encoded in the mapping. When the mapping sits outside your systems, those rules live outside them too, in a tool with its own conventions and its own change process.
Visibility into rejections. This is the difference people notice first. Diagnosing a rejected transaction means comparing the document against the order record and against what physically shipped. When the mapping and the order both live in your ERP, that is a query. When the document was assembled elsewhere, you are reconstructing what was sent from what you think was sent, or raising a ticket with a provider.
Storing the raw file alongside the parsed result matters more than it sounds. A dispute over what was sent becomes a lookup rather than an argument, and a missing acknowledgment becomes a quick check rather than a day of investigation.
Cost shape. A per-document fee model means the cost of EDI tracks volume. Mapping in your own codebase moves the cost to development time, which is front-loaded and does not grow with the number of transactions. Which of those is cheaper depends entirely on your volume and your development capacity, and it is worth doing the arithmetic for your own numbers rather than assuming either answer.
Direct partners and network partners
Building the mapping into the ERP does not mean every partner connects directly. It means the ERP owns the documents, whatever route they take.
On the ERP we built for a US consumer electronics brand, Amazon Vendor Central (Wholesale and Direct Fulfillment) and Adorama connect directly over SFTP. Best Buy, Costco, QVC, Staples and other retailers connect through SPS Commerce, CommerceHub or Radial, because those retailers require their network. The ERP uploads its own files to the network’s FTP and reads the files the network delivers. The network validates and delivers them, and the mapping stays in the ERP.
A few partners do not use EDI at all. They exchange spreadsheet order and ship files over FTP instead, and the ERP handles those automatically too. Across more than a dozen retail trading partners, the documents are built and read in one place.
What it looks like built in
Built inside the ERP, an inbound 850 is parsed with EdiFabric directly into the order tables, validated against your own item and pricing data, with the original file retained. An outbound 856 should describe what the warehouse actually did, not a re-entry of the order, and the 810 should bill for what actually shipped.
There is no second system holding its own copy of the mapping. That is the structural argument for building it in: most recurring EDI problems come from a gap between what the order record says and what the document says, and removing the intermediate copy removes the gap.
This is the approach we take with EDI integration services. For a US consumer electronics brand, the EDI work sits in the same system as the orders, inventory and shipments it describes, with other channels integrated over APIs where the partner uses them rather than EDI.
When a translation provider is still the right answer
Building this in is not the right call for everyone, and it is worth being clear about when it is not.
If you have no in-house development capability and no plans to acquire any, mapping in your own codebase is a dependency you cannot support. EDI requirements change, partners update their implementation guides, and someone has to respond to that. A provider is the better choice if the alternative is code nobody can maintain.
If you need a partner live quickly, a middleware provider wins on speed. Onboarding through configuration is faster than onboarding through development, particularly for a first partner where there is no existing pattern to follow.
If your documents are simple and your volume is low, the economics may never justify the build. A handful of straightforward partners at modest volume is exactly the case a translation provider handles well.
And if your ERP is a packaged product you cannot extend, the question changes shape entirely: the work becomes ERP integration around the edges of that system rather than development inside it.
Moving one partner at a time
Where it does make sense, the way to do it is incrementally, and the reason is risk rather than effort.
Pick one partner to move first, ideally one with straightforward documents and enough volume to exercise the path properly. Build the mapping for that partner inside the ERP, then run it alongside the existing route, comparing what each produces for the same orders before anything is switched over. Only when the new path matches does the old one stop carrying that partner.
That gives you a working pattern and a real cost estimate before the second partner starts, and a mapping problem affects one relationship instead of all of them. Partners with the most intricate requirements should go last, once the pattern is established and the only new problem in front of you is their implementation guide.
Transport and mapping can also move separately. Keeping existing connectivity, including a retailer’s required network, while the document mapping moves in house is a smaller change than replacing both at once, and it is often the sensible first step.
If you are paying per document for mappings you would rather own, or losing time to rejections you cannot diagnose from your own data, that is usually the signal to look at this. We build EDI inside the ERP as part of custom ERP development work. See EDI integration services for how the work is structured, or get in touch with your partner list and current volumes.
Common questions
Do we have to move every partner at once?
No, and it is better not to. Partners move one at a time, with the new path running against the old one until it is proven, so a mapping problem affects one relationship rather than all of them.
Do we still need SPS Commerce or CommerceHub?
Only where the retailer requires its network. The ERP still builds and reads every file. The network validates the files and delivers them, but it does not translate them.
What happens to our existing partner connections?
The connectivity and the mapping are separate concerns. Transport can stay as it is while the document mapping moves, which keeps the change smaller than replacing both at once.
Is in-house EDI only worth it above a certain partner count?
Partner count matters less than how much the documents interact with your own business rules. A few partners with complex requirements can justify it; many partners with simple requirements often do not.