EDI mapping explained: what it is, how it works and who should own the maps

A new retail customer sends a technical guide at set-up. It sets out what each message must contain, down to the codes it will accept. Your ERP holds the same facts under its own field names. Something has to connect the two, document by document, for every customer you trade with.

What is EDI mapping?

Transalis puts it this way: "Mapping is the process of locating data in your business systems, connecting the relationships between fields, and translating them into the file format your trading partners require."

A map is one set of those rules, for one document type and one partner's specification. An order coming in needs a map. So does the invoice going back out.

The rules work at the level of the message's building blocks. The Transalis standards guide describes them this way: "A document includes elements (such as an item number, cost or buyer location). Groups of elements are segments (for example, a full buyer address)." GS1 sums up the syntax behind EANCOM in the same terms: "The UN/EDIFACT syntax rules set the rules for structuring data into segments, segments into messages, and messages into an interchange." For the standards themselves, read EDI standards explained.

What does an EDI map connect?

A map has two sides: your system and your partner's standard.

Your side is whatever holds the data. With Transalis, it usually takes one of these forms.

• Pre-built connector. The Transalis integrations network page says "Transalis OpenEDI™ plugs into your system through a pre-built connector", whether that system is an ERP, accounting or ecommerce platform.
• API. In its Dynamics 365 guide, Transalis offers API connectivity "with JSON, UBL or XML message examples supplied" as one connection option. The route into your ERP is agreed when the connection is scoped.
• File drop. Messages are "stored in a secure file destination that Transalis hosts for you", then imported into your chosen application.
• Browser portal. Transalis Web EDI needs "No ERP integration and no software to install". With no ERP link, your team has nothing to map.

The partner's side is its EDI standard and its own rules for using it. As the same standards guide notes, "Many UK suppliers need to support more than one standard at once, because each retailer they trade with may ask for a different format."

Why does every trading partner need its own map?

Because a standard leaves room for choice, and every partner makes its own choices.

EANCOM is GS1's subset of UN/EDIFACT, and it keeps only the message elements business applications need. Sectors and partners then narrow it further. GS1 Australia describes the result: Message Implementation Guidelines (MIGs) set out industry-agreed business rules and ways of working between trading partners.

The difference sits in the detail. EANCOM marks each conditional field as required, advised, dependent, optional or not used. Advised and optional fields leave room for choice, so two partners can use the same message in different ways. Each retailer's Message Implementation Guide sets out the detail of every message, and one partner's guide can require a field that another's leaves out. A map built for the first can then fail the second's validation.

You learn the rules at set-up. Ocado's supplier manual says the detailed technical content of its ASN is set out in a Message Implementation Guide sent to suppliers during EDI set-up. Tesco works the same way: it does not publish its EDI specification publicly, and sets out the message detail in a Message Implementation Guide during onboarding.

Same message type. Different map.

What does a mapped purchase order look like?

GS1's EANCOM ORDERS manual includes a worked purchase order, sent by a buyer to a supplier. For a supplier, it is an incoming order: each row below moves a value out of a segment and into your system. Laid out as a map, a few of its lines look like this.

This is GS1's illustration from 2002. It is not a live order.

The buyer and supplier are identified by Global Location Number rather than company name, and so is each delivery location. When the order arrives, the map has to match each GLN to the right customer account and delivery address in your ERP.

The manual also sets rules for whoever sends the order: "If Global Trade Item Numbers are available it is mandatory to use GTIN within the LIN segment." Where your products have GTINs, a retailer's order names each product by its GTIN, and your map has to turn that into your own product code. That only works if each product's GTIN is held against it in your ERP.

EDI mapping vs translation: what is the difference?

Many guides use the two words as if they meant the same thing. The Transalis guide to managed EDI providers lists them as separate tasks: translating between formats, and mapping each partner's specification.

The map is the set of rules for one partner: which field goes where, and in what form. Translation is running the conversion between formats or standards, such as TRADACOMS, EANCOM, EDIFACT and X12. On the Transalis network, "Transalis translates between them automatically."

The difference matters when you add partners. Transalis translates each partner's format on its side, so your ERP sees one structure whoever the partner is. The partner-specific mapping rules stay out of your ERP.

How is an EDI map built and tested before go-live?

The Transalis Dynamics 365 guide puts the job in one line: "Every new trading partner means another specification to read, map and test." The steps follow that sentence.

1. Read the guideline. Start from the partner's own Message Implementation Guide.
2. Locate each field. Find where each required value lives in your system, and write the rule that moves it into the right segment.
3. Test with real documents. The same guide's advice is: "Run real documents end to end before anything goes live." A new connection runs in parallel to your live system, so live orders keep flowing while the map is proven.
4. Check the syntax responses. On EANCOM links, GS1 notes that a CONTRL message may be used to indicate when an interchange has been rejected due to syntax errors. Ask each partner how it reports rejected messages, and see a clean result in test before go-live.
5. Switch on. Move the partner to live only when its documents pass its own validation.

Testing takes the time it needs. TRIP, a drinks brand with twelve trading partners, had two partners onboarded within four weeks, with extended user acceptance testing before launch. Where the partner is already on the network, onboarding means switching on a route and testing it, not building a new link from scratch. At Space NK, the first trading partner was onboarded within a single week.

For the full onboarding sequence with a retailer, read the EDI requirements for retail suppliers.

What happens when a retailer changes its rules?

A map is never finished. Retailers revise validation rules, and each change needs a mapping update, a test and a deployment.

That work needs an owner. If you maintain EDI in-house, someone has to notice the change, re-map the data and test it in time. If the change is missed, messages start failing validation.

In one documented case, a UK poultry producer built its retailer EDI in-house. The retailer made a routine change to its validation rules, and the custom build did not absorb it. Its advance shipping notices stopped registering, and compliance chargebacks passed £35,000 in two weeks. The full account is in when in-house EDI breaks. For what an ASN carries and when it is due, see how and when to send an ASN.

Who should own your EDI maps?

The maps sit with one of three owners.

• In-house. On-premise EDI runs on your own servers and needs an in-house team to map, test and maintain it. The trade-offs are covered in cloud-based EDI.
• Software or a hosted tool. Your team, or a consultant, builds each map. You own the rule changes too.
• Managed service. The provider builds and maintains the maps. That includes updating the mapping when a retailer changes its rules.

The right answer depends on who will be there when a retailer's guideline changes. For a fuller comparison, read the guide to choosing a managed EDI provider.

Questions to ask a provider about mapping

Mapping fees, and a fee every time a map needs updating, are easy to miss in a quote. Ask these before you sign.

1. Who builds each new partner map, and who tests it?
2. Who updates a map when a retailer changes its rules, and how fast?
3. Is there a charge every time a partner map needs updating?
4. Is the partner already connected, or does the link start from scratch?
5. Are new maps tested in parallel to the live system before switch-on?
6. If we change provider later, who recreates and validates our maps?

Ask for the total cost of ownership in writing, including partner connection, mapping, change-request and support charges. The aim is a cost you can predict through every rule change.

How Transalis handles mapping for you

Transalis is a managed outcomes provider for B2B integration, EDI and eInvoicing. The managed service handles mapping, testing and go-live, so your team stays focused on operations.

Retailer rules are part of that. Transalis handles the document types and formats major retailers ask for, and the managed service maps to each retailer's spec. When a partner changes a requirement, absorbing it is Transalis's job. Connect once and reach Argos, AS Watson, Superdrug and 15,000+ more across 50+ countries.

Map your network with the team, your retailer's guideline in hand, or see the managed service on the EDI page.