What Is EDI Mapping? A Freight Example

What Is EDI Mapping?

EDI mapping is the specification that ties a field in your internal system, an ERP, TMS or WMS, to a specific segment and data element inside a standard EDI transaction set. EDI mapping is the process of defining how data fields from one business system or file format translate into another format for electronic data interchange. It's a blueprint, not the conversion itself. Think of it as the rulebook that says "our TMS field called origin_location_code becomes the N4 segment's city and state qualifiers in an X12 204." Nothing gets converted yet. That happens later, in translation.

EDI Mapping vs EDI Translation: The Distinction People Mix Up

Mapping defines where each piece of data belongs. Translation is the software process that actually executes that rule and produces the file. While mapping determines where data belongs, the EDI translation process converts that mapped data into standardized EDI formats used in document exchange. Mapping defines how internal data aligns with the fields required by EDI standards, while translation converts that mapped data into standardized EDI formats that trading partners can process.

Every major EDI vendor glossary, from SEEBURGER to Cleo to Orderful, ends up drawing this same line, because the confusion is common enough to warrant its own FAQ entry on nearly every one of their sites. Mapping is bilateral by nature. EDI mapping software allows EDI platforms to create EDI maps bidirectionally, originating from an ERP, or originating from a trading partner, so IDoc to EDI mapping is the reverse of EDI mapping to IDoc. This is known as bilateral EDI mapping, as it works in both directions.

Why Mapping Has to Exist at All

No two trading partners store the same business fact the same way. Your ERP might hold a "carrier" as a free-text field; a load tender needs it as a SCAC code in a specific segment position. The EDI mapping process defines the translation rules to convert internal data formats (e.g., CSV, SAP IDoc, XML, etc.) into standardized EDI formats (e.g., ANSI X12, EDIFACT, etc.), ensuring accurate and seamless data flow. Add a second trading partner running EDIFACT instead of X12, or a European carrier expecting DDMMYY dates instead of CCYYMMDD, and you can see why a map isn't a one-time build. It's a living document tied to whatever standard, version and code list each partner insists on.

Worked Example: Mapping an EDI 204 Load Tender

Say a shipper's TMS holds a load as internal fields: origin location, pickup window, equipment type, SCAC code, and a shipper reference number. Before that load can be tendered to a carrier, a map decides which EDI 204 segment carries each value. Common segments in the EDI 204 Motor Carrier Load Tender include the ST Transaction Set Header, B2 Shipment Identification, B2A Transaction Purpose, L11 Reference Numbers, G62 Date/Time, N1/N3/N4 Party Identification, S5 Stop-off Details, N7 Equipment Information, and SE Transaction Trailer, which closes the transaction.

Structurally, a 204 opens with the B2 beginning segment carrying the shipment reference, carrier SCAC, and method of payment, followed by a B2A that states the tender's purpose. Header-level L11 reference segments carry identifiers such as the bill of lading and PRO number, and G62 segments carry shipment dates. N1 loops name the parties: the shipper (SH), the carrier (CA), and optionally a bill-to (BT). Each physical stop, pickup or delivery, becomes its own S5 loop with a reason code and its own dates and references.

Those segment codes and qualifier positions aren't guesswork. They come straight from published 204 implementation guides used across carrier networks. A real 204 payload runs something like B2**TRCR**IS1075661**PP~ B2A*01*LT~ N1*SH*Rite Aid-Woodland, CA (DC #81)*93*50086~ S5*1*CL~ L11*R1024266*BM*BOL~ L11*FLATBED*EQ*Equipment Type~ G62*37*20200429*I*0700~ On the carrier side, their own map reverses the process, pulling those same segments back into fields their dispatch system recognizes, and typically fires back an EDI 990 response. Standardized status indicators allow transportation systems to interpret shipment instructions consistently while enabling automated responses such as EDI 990 Response to Load Tender.

Where Mapping Breaks in Practice

Most 204 rejections trace back to a qualifier problem, not a missing field. If your map sends a bill of lading number under the wrong L11 qualifier, say CR (carrier reference) instead of BM (bill of lading), the carrier's translator either drops the value or files it against the wrong reference type entirely, and you get a 997 or 999 rejection with no obvious cause until someone opens the raw segment. Date qualifier mismatches on G62 (requested pickup vs must-arrive-by) cause the same kind of silent failure, because both are syntactically valid, just semantically wrong.

Shippers with more than a handful of carriers usually stop building one map per partner and move to a canonical, or indirect, mapping layer instead. Indirect or canonical mapping uses an abstraction layer between partner formats and internal systems. A partner mapping converts the EDI message into the abstraction-layer format, and a company-specific mapping converts the abstraction-layer format into the in-house format consumed by the receiver's ERP system. This approach can scale better because it supports one process, two process maps, and any number of partner mappings. That's the difference between rebuilding a map every time you onboard carrier number 40 versus adding one more partner-side mapping to an existing canonical model.

Who Actually Builds and Maintains These Maps

Three routes are common. An in-house EDI analyst owns the spreadsheet-and-code process directly, which works until partner volume outpaces headcount. A managed EDI or VAN provider (SPS Commerce, TrueCommerce, Cleo, IBM Sterling) builds and maintains maps as a service, bundled with translation and connectivity. Or the mapping work sits inside a transport-specific connectivity layer, where platforms like Cargoson, MercuryGate, or Descartes maintain pre-built carrier maps so shippers aren't rebuilding a 204 map from scratch for every new carrier relationship, a route worth evaluating directly if freight tenders and responses are your main EDI volume rather than purchase orders and invoices.

FAQ

Is EDI mapping the same as an EDI translator? No. The map is the specification; the translator is the software that reads the map and performs the conversion.

How long does building a map for a new carrier take? It depends on how close the new partner's guide is to one you already support, and whether you're on direct or canonical mapping. Canonical setups add a single partner-side map rather than rebuilding the whole chain.

Can EDI mapping handle JSON or API payloads too? Yes. Modern EDI platforms support EDI formats such as X12, EDIFACT, and TRADACOMS, alongside non-EDI formats such as XML, flat files, spreadsheets, and databases, and API payloads such as JSON, so teams converting EDI to JSON, JSON to EDI, EDI to XML, or XML to EDI reduce brittle one-off maps.

What happens when a mapping error causes a rejection? Usually a 997 or 999 comes back citing a segment or element error. Check the qualifier first, not the value, since most rejections are a right-value-wrong-qualifier problem rather than missing data.

Do I still need mapping expertise if I use a managed EDI or VAN provider? You need less of it day to day, but someone on your side still has to validate that the provider's map matches what your ERP or TMS actually expects, especially after a version upgrade.