EDI concepts
EDI software: what it does, layer by layer
EDI software does four jobs in a row: it moves files to and from a trading partner, translates between X12 and structured data, maps each element to a field per partner, and writes the result into your order system. The first two follow published standards and are the same everywhere. The last two are specific to your partners and your systems, and they are where products and projects differ.
Updated
The four layers of EDI software
Every EDI setup, from a web portal to an add-on inside an ERP, does the same four jobs. They are worth separating, because each is bought, built and billed differently.
| Layer | What it does | Defined by | Changes when |
|---|---|---|---|
| 1. Transport | Moves the file: AS2, SFTP or a mailbox on a value-added network | RFC 4130 for AS2, the partner's connection rules | A partner changes its endpoint or certificate |
| 2. Translation | Parses and writes X12, checks counts and control numbers, produces the 997 | The X12 standard, per version | A partner moves to another version, for example 4010 to 5010 |
| 3. Mapping | Places each element in one of your fields, with the codes one partner accepts | That partner's implementation guide, per document | A partner revises its guide, or you add a partner or a document |
| 4. ERP side | Creates the order, reads shipments, cartons and invoices | Your order system and its API or files | Your system, its fields or your process change |
On the transport layer AS2 is the protocol written for business documents. RFC 4130 describes it as the exchange of structured business data over HTTP, with the payload signed and encrypted and a receipt, the MDN, returned to the sender. A signed MDN is the proof that the partner received exactly that file. SFTP has no receipt of that kind. Walmart, which accepts both for drop-ship vendors, prescribes a file name for SFTP: WMI_856SH_ followed by the vendor ID, the date, the time and a six-digit random number. More under AS2 and EDI VAN.
What translation software covers and where mapping starts
A translator turns one line of X12 into structured data and back. Take the first line of the sample order on our EDI 850 page:
PO1*1*24*EA*12.50**UP*614141104826*VP*10482~
The translator knows that this is a PO1 segment, that * separates elements and that the fifth element is empty. It does not know what your system calls the value in the ninth element. The map does:
{
"po_number": "4500018236",
"lines": [
{ "line": 1, "sku": "10482", "upc": "614141104826",
"quantity": 24, "unit": "EA", "unit_price": 12.50 }
]
}
The map decided that the value after VP is your SKU, that UP is stored as the UPC, and that EA is a unit your system sells in. For another partner the line carries the buyer's own item code after qualifier PI, and the unit is cases.
The reason the map is separate from the translator is the size of the standard. The PO1 segment has 25 elements; the line above uses 8 of them. X12 version 5010 defines 26 status codes for a line in an 855, and one retailer's published guide accepts 5. The standard is the superset. Each partner's guide is a subset, and no two partners pick the same one. Translation is solved once per version. Mapping is done once per partner and per document, and again when a guide changes.
The same split shows in validation. The translator checks syntax and returns the 997. Whether the codes fit the partner's guide is a property of the map, and whether the content matches the shipment needs data from the order system. The three levels are explained under EDI compliance.
What the software's limits look like in practice
The limits a buyer meets first are metering limits: the unit a product counts decides what a busy month does to the bill. Four units are in use.
| Unit | What is counted | What to check |
|---|---|---|
| Document | Each transaction set sent or received | Whether a 997 counts, and whether both directions count |
| Kilocharacter | Every 1,000 characters, including delimiters and the padded envelope | The ISA segment alone is 106 characters |
| Trading partner | Each partner connection | Whether a partner is an ISA sender and receiver pair, a GS ID or a retailer |
| Interconnect | A document that crosses from your network to the partner's network | Each side pays its own network for the same document |
A worked sum for the kilocharacter. The single-carton 856 on our EDI 856 page has 19 segments, and with its envelope the interchange is 482 characters: 0.482 kilocharacters. Ship 40 cartons with two items each and the same notice has 122 HL levels and 331 segments. That is 5,350 characters, 5.35 kilocharacters. Metered per document the two notices count the same. Metered per kilocharacter the second counts 11 times the first.
The partner unit works the other way. One provider definition counts every unique pair of ISA sender ID and receiver ID as a partner, whatever the GS IDs inside. A retailer that trades under one ISA ID is one partner. A retailer with a separate ISA ID for each of 8 divisions is 8.
Many products have a web portal as their entry tier: forms in a browser and no layer 4 at all. Its limit is the typing. That route is worked out under EDI capable.
What your ERP does natively
ERP vendors document where their product stops, and for retail X12 the boundary sits in the same place each time: the ERP holds the records, and a separate layer produces the documents.
| System | What is native | Where the vendor draws the line |
|---|---|---|
| NetSuite | A WMS rule "Generate EDI 856 outbound ASNs?", an "ASN Required?" box on the customer, staging records for shipped orders | The data "is then read by the NetSuite EDI partner, who converts the data into an EDI document" |
| Business Central | The E-Documents framework: Peppol BIS 3, XRechnung, ZUGFeRD, OIOUBL, Factura-E | E-invoicing formats. The 850, 856 and 810 of retail X12 are not among the documented formats |
| SAP S/4HANA | The IDoc interface with its own status codes and process library | SAP's documentation assigns the conversion from IDoc to X12 or EDIFACT to an external EDI subsystem |
A store platform sits in the same position. Shopify has orders, fulfillments and an Admin API, and no X12 translator. See NetSuite EDI integration, Business Central EDI integration and Shopify EDI integration for each boundary in detail.
So for most suppliers "EDI software" means layers 1 to 3 from outside the ERP, plus a layer 4 that someone has to build to the ERP's API. Who sells which combination is set out under EDI provider.
What this means for your integration
We build layers 3 and 4 to your systems and your partners' guides, and run all four as one EDI integration: hosted, monitored and changed by us when a partner revises a guide or your ERP changes a field. It comes at a fixed build price and a monthly fee.
In practice that means the 850 arrives as a sales order with your own item numbers and units, and the 855, 856 and 810 are assembled from your order, pack and invoice records. Each outbound document is validated before it is sent and matched to its 997 afterwards, and a document that fails is held and shown in the dashboard with the reason. Tell us which partners and which ERP.
Frequently asked questions
What is EDI software?
Software that exchanges business documents such as purchase orders, ship notices and invoices with trading partners in a standard format, in North America mostly X12. It covers up to four layers: transport, translation, mapping and the connection to the ERP. A product that is sold as EDI software can cover one of them or all four, so the layer list is the first thing to check.
What is the difference between an EDI translator and EDI mapping?
A translator parses and writes the X12 syntax: envelopes, segments, counts and the 997. Mapping decides which element goes to which of your fields for one partner and one document, and which codes that partner accepts. The translator is the same for every partner. A map exists per partner and per document. See EDI mapping.
Does my ERP have EDI software built in?
Usually the ERP holds the records and leaves the X12 to another layer. Oracle's NetSuite documentation says its staging records are "read by the NetSuite EDI partner, who converts the data into an EDI document". Microsoft documents e-invoicing formats such as Peppol BIS 3 for Business Central. SAP assigns the conversion to X12 or EDIFACT to an external EDI subsystem.
What is a kilocharacter in EDI billing?
A kilocharacter is 1,000 characters of EDI data, counted with every delimiter and padding space. The single-carton 856 on our EDI 856 page is 482 characters with its envelope, 0.482 kilocharacters. The same notice for 40 cartons is 5,350 characters, 5.35 kilocharacters.
Which EDI software is best?
Transport and translation follow published standards, X12 and RFC 4130 for AS2, so products differ little there. They differ on two points: who builds and maintains the map for each partner and document, and how orders, shipments and invoices get in and out of your order system. Compare offers on those two layers and on the unit that is metered.
Do I need EDI software if I use a web portal?
No. The portal is the software for the first three layers, operated by hand: you read the order in a form and type the replies. The fourth layer is you, keying the order into your own system. The numbers for that route are under EDI capable.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase