EDI Mapping Explained: From ERP Fields to X12 and EDIFACT Segments
A practical guide to how EDI mapping actually works — the concepts, common source formats, and a worked example translating SAP IDoc fields into an X12 850.
In this article
Every EDI implementation eventually comes down to the same question: how does this field in our internal system become that segment in the EDI file? That's mapping, and while EDI standards define the target structure precisely, they say nothing about your source data — so mapping is where most of the real engineering work lives.
1. What is EDI mapping?
Mapping is the specification of how each field in a source format corresponds to a segment/element in a target EDI format (or vice versa for inbound documents). A mapping spec typically includes the source field, target position, any transformation logic (formatting, unit conversion, code translation), and default/fallback behavior.
2. Common source formats
- SAP IDocs (ORDERS05, DESADV01, INVOIC02) — SAP's native document format
- Oracle e-Business Suite / Fusion flat files or open interfaces
- CSV/Excel exports from smaller ERPs or spreadsheets
- JSON/XML payloads from modern APIs and microservices
- Other EDI formats (X12-to-EDIFACT translation for multi-standard supply chains)
3. The mapping process
- Obtain the trading partner's EDI implementation guide (their specific rules on top of the base standard).
- Document every source field and its data type, format, and possible values.
- Build a field-by-field crosswalk: source field → target segment/element, with transformation rules.
- Implement the mapping in your translator or integration platform.
- Test with representative sample data, including edge cases (missing fields, unusual characters, maximum lengths).
- Run a full end-to-end test with the trading partner before go-live.
4. Worked example: SAP IDoc to X12 850
SAP represents a sales order line using the E1EDP01 IDoc segment. Below is how its key fields map onto the X12 850's PO1 loop.
EDI Mapping Visualizer
Pick a source and target format to see how fields translate.
Source · SAP
Target · X12
Business fields represented: Item / Material · Quantity · Unit Price · Delivery Date · Order Reference. Hover a row to trace it across formats.
5. Handling qualifiers and code lists
EDI standards rely heavily on qualifier codes — PO107 tells you whether PO108 is a vendor part number, buyer part number, or UPC. Your source system rarely stores this distinction explicitly, so mapping logic usually needs a small rules table: 'if the item master has a vendor part number populated, use qualifier VP; otherwise fall back to the internal SKU with qualifier BP.'
Document your qualifier decisions
Keep a living reference table of every qualifier choice made per trading partner. When a new team member picks up support six months later, this table is what prevents them from re-litigating decisions that were already agreed upon.
6. Testing your mapping
- Unit test individual field transformations (date formatting, unit-of-measure conversion) in isolation.
- Run full sample transactions through the translator and diff the output against the partner's implementation guide examples.
- Test boundary conditions: zero quantities, very long descriptions, special characters that could collide with EDI delimiters.
- Validate the output with the partner's own test/certification environment before going live.
7. Common pitfalls
| Pitfall | Why it happens | How to avoid it |
|---|---|---|
| Delimiter collision | A free-text field (like an item description) contains the EDI segment or element separator character | Escape or strip reserved delimiter characters during mapping |
| Silent truncation | Target element has a shorter max length than the source field | Validate field lengths at mapping time, not just at runtime failure |
| Hardcoded qualifiers | Mapping assumes only one qualifier will ever be used | Build qualifier selection as configurable logic, not a hardcoded constant |
Related transactions
Purchase Order
The X12 850 is the electronic purchase order a buyer sends to a supplier to request goods or services, replacing paper or PDF POs with a structured, machine-readable document.
Advance Ship Notice
The X12 856 (ASN) tells the buyer exactly what was shipped, how it was packed (pallet/case/item hierarchy), and when it will arrive — before the truck reaches the dock.
Purchase Order Message
UN/EDIFACT ORDERS is the international equivalent of the X12 850 — a structured purchase order used widely across Europe and global trade lanes.
Frequently asked questions
Not strictly, but purpose-built translators (IBM Sterling, Cleo, Boomi, MuleSoft) handle envelope construction, segment validation, and partner-specific rules that are painful to build from scratch.
Related articles
X12 850 Purchase Order: Complete EDI Guide
A complete, segment-by-segment walkthrough of the X12 850 Purchase Order — what it is, how it's structured, how to map it, and how to troubleshoot the errors that show up most often in production.
X12 856 Advance Ship Notice: The Complete EDI Guide
Everything you need to build, validate, and troubleshoot an X12 856 ASN — including the HL hierarchy that trips up almost every new implementation.
Have a follow-up question about this topic?
Ask EDI AI →