Supply Chain & InventoryFree worksheetPDF, Excel, Word export

EDI X12 Field Mapping Specification Worksheet

A mapping specification is the contract between the EDI team, the ERP team and the partner. This worksheet gives you a structured way to document each X12 segment and element, the ERP field behind it, the rule and the usage, and then export it to Excel.

Download:
SeqSegmentElementElement descriptionERP source / target fieldRuleUsageMax lengthDefault / notes
Mapped elements
6
Longest element (chars)
80

Add one row per element you map. Keep one worksheet per transaction set and direction, and per partner when rules differ. Record the partner guide version and revision date in the file name. Lookups and defaults documented here should match the cross-reference tables loaded in the ERP.

Turn mapping specs into tested maps

Optional: we can review your specs and show how maps and test cases could be generated from them.

Optional. The tool and every export work without this. No spam.

How to use the worksheet

Work through the partner's implementation guide segment by segment. For inbound documents such as the 850, the ERP field is the target where the value will be stored. For outbound documents such as the 855, 856 and 810, the ERP field is the source. Choose a rule type for each row: direct copy, constant, lookup against a cross-reference, format change, concatenation of fields, or a conditional rule. Mark the usage as mandatory, optional or conditional exactly as the guide states.

  • One worksheet per transaction set and direction
  • Capture qualifier values for N1, REF and DTM loops
  • Record max length so truncation rules are explicit
  • Put every default and exception in the notes column

Why a written spec matters

Maps built from memory or a chat message tend to fail in edge cases: units of measure, ship-to codes, decimals, date formats and optional segments. A written spec lets the partner review your interpretation before testing, gives developers a clear build target, and gives support staff a reference when a document fails. It also makes it easier to reuse a map for the next partner by copying the worksheet and changing only the differences.

Common mistakes

Do not skip segments that look optional: partners often require them in practice. Do not leave lookup behavior undefined, for example what happens when a ship-to code has no cross-reference. Decide whether the document is rejected, held for review or sent with a default. Be explicit about quantities and prices: X12 uses explicit decimals in most quantity and price elements but implied decimals in monetary totals such as TDS01, and mixing these up causes valuation errors in both directions.

Frequently Asked Questions

What should an EDI mapping specification include?

It should list every segment and element used, the ERP source or target field, the transformation rule, usage (mandatory, optional, conditional), length and data type, code values, defaults, and the handling of errors and missing data. It should also state the partner guide version.

Should I make one spec per partner?

Create a base spec per transaction set and copy it per partner, recording only the differences. Partners often differ in qualifiers, required segments and codes, so a copy per partner avoids hidden assumptions while keeping reuse high.

How do I handle unit of measure differences?

Use a cross-reference table between the partner's UoM codes and your ERP units, and include conversion factors when pack sizes differ. Define what happens when no entry exists, ideally holding the document for review rather than guessing.

Can I use this for EDIFACT?

Yes. Use the segment and element columns for EDIFACT segments and data element numbers, such as BGM and 1004, and record composite and component positions in the description. The structure of rules, usage and defaults applies equally.

If you maintain many partner-specific maps, we can help generate and test them from a structured spec like this one against your ERP.