EDI mapping: what a translator does and where the mapping starts

What is EDI mapping?

EDI mapping is the rule set between a trading partner's document and your own records. For every element the partner sends, the map says which field it fills, how the value is converted and what happens when it fits nowhere. For every document you send back, it says which record each element comes from.

The work exists because the standard and your system describe the same order in different terms. The partner's 850 says PO1*1*2*CA*150.00**UK*10614141104823. Your ERP wants SKU 10482, 24 eaches, 12.50 each. Nothing in the X12 syntax connects the two; the map does.

What an EDI translator does, and where mapping starts

An EDI translator is finished software. Given a 004010 file it will tell you that an 850 has 16 segments, that SE01 says 16 and that the group control number in GE02 matches GS06. It will produce the 997 that says so. What it hands over is still the partner's data: a quantity of 2, a unit CA, a 14-digit number with qualifier UK.

Mapping starts there, and it has two halves. Toward the partner it follows the guide. Toward your system it follows your item master, your units, your customer and address records. Both halves change over time, and neither is covered by the standard.

Why every partner needs its own map

The standard is a superset. Each partner's guide is a subset, and no two are the same.

• The PO1 segment of the 850 has 25 elements. PO106 to PO125 are ten pairs of a qualifier and a product ID, and a partner fills whichever it likes.
• The LIN segment allows fifteen product IDs, in LIN02 to LIN31.
• The ACK01 element of the 855 has 26 codes in version 5010. Chewy's guide uses 5 of them.
• ISA05, the qualifier of the sender ID, has 38 codes in 004010.
• The list of transaction sets on x12.org holds more than 300. A retail supplier handles a handful.

The same order line from three published guides:

Partner A   PO1*1*24*EA*12.50**UP*614141104826*VP*10482~
Partner B   PO1*1*2*CA*150.00**UK*10614141104823*PI*88231~
Partner C   PO1*1*24*EA*12.50*QE*BP*3335027*UP*0614141104826*VP*10482~

Partner A follows the pattern of D&H's 850 guide: a UPC and the vendor part number on one line. Partner B follows Kroger's: cases, a GTIN-14 with qualifier UK and the purchaser's item code in PI. Partner C follows Walmart's drop-ship guide: a price basis in PO105, Walmart's own item number in BP, and a UPC written with 13 digits. The string 0614141104826 does not match 614141104826 in an item master unless the map strips or pads it.

The differences continue in every document.

A map built for one column fails in the other two. The partner pages show the detail: EDI with Walmart and EDI with Kroger.

A worked example: one order line into the ERP

Partner B orders the item from our document pages in cases.

The arithmetic the map carries out:

• Quantity: PO102 is 2 and PO103 is CA. The pack size of this item is 12, so 2 times 12 is 24 eaches.
• Price: PO104 is 150.00 per case. 150.00 divided by 12 is 12.50 per each. The line value stays 300.00 either way: 2 times 150.00, or 24 times 12.50.
• Item: 10614141104823 is the GTIN-14 of the case. It is not the UPC 614141104826 of the single item with digits added; the leading 1 marks the packaging level and the check digit differs, 3 instead of 6. The SKU comes from a cross-reference table.
• Location: N104 holds 0007, the partner's code for a distribution center. The address comes from a location table.
• Line number: PO101 is stored unchanged, because the 855, 856 and 810 have to return it.

Without the unit rule, 2 cases are booked as 2 eaches and the order ships 22 units short. Without the price rule, a line of 2 at 150.00 is compared with a price list entry of 12.50 and flagged, or a line of 24 at 150.00 is invoiced. The classes behind these rules are worked out in units of measure and SKU, UPC and GTIN.

The mapping classes that cause errors

Each class is a general field mapping problem in X12 form. The EDI part adds one thing: the partner validates each document against its guide and rejects what does not fit.

Outbound: mapping back what the partner sent

Outbound maps start from your records and have to reproduce the partner's references. The acknowledgment returns the PO number in BAK03 and the line numbers of the 850. The 856 returns the PO number in PRF01, identifies items the way the partner did, and adds what only your warehouse knows: cartons, SSCCs, tracking numbers. The 810 returns the PO number in BIG04 and bills in the partner's unit.

That makes the inbound map a dependency of the outbound ones. If the 850 was converted from 2 cases to 24 eaches, the 856 for Kroger reports cases at pack level and eaches at item level, and the invoice has to bill 2 at 150.00, not 24 at 12.50. The conversion has to be stored with the order line, not recomputed from an item master that may have changed since.

Maps change

A map is tested once with the partner, with ISA15 set to T, and then lives for years. During that time three things move.

The partner revises its guide. Chewy's 855 guide lists the removal of two ACK01 codes in its change history for 2020. Kroger's 850 map carries a modification date of 17 March 2025 and its 810 map one of 4 April 2025.

Your own data changes. A new item needs a row in the cross-reference table for every partner that orders it; a changed pack size changes two conversions. The partner adds stores, and each new code in N104 needs an address before the first order for it arrives.

And the tables are state that someone has to own. An item missing from the cross-reference stops an otherwise valid 850, and it is found only when the order arrives.

What this means for your integration

The translator is the solved part of an EDI project. The maps and their tables are the part that decides whether orders import and ship notices are accepted, and they are specific to your partners and your systems.

We build them as part of an EDI integration: one map per partner and document against its guide, conversions stored with each order line, lookup tables kept per partner, and a dry run in which inbound orders are mapped and shown without being written to the ERP. An order that fails a lookup waits in a queue with the reason in the dashboard, and is processed when the missing row is added. When a partner changes its guide, we adjust the map. Tell us which partners and documents you have.