# What is in an EDI implementation guide, and how do you check it? An EDI implementation guide describes which messages your partner expects, in which format, with which mandatory information and over which transmission method. It is also called a Message Implementation Guide (MIG) or EDI specification. Reading it carefully before the project starts avoids most queries and test loops. The checklist below helps you make sure nothing is overlooked. ## What an implementation guide is Standards such as EDIFACT are very broad. A purchase order (ORDERS) has hundreds of possible data items, most of which no single company needs. Industry associations therefore narrow the standard down into subsets. EANCOM, for example, is GS1's subset for retail; GS1 describes it as a subset of UN/EDIFACT that contains only the elements needed. Your partner's implementation guide goes one step further. It specifies which segments it actually reads in-house, which codes it expects and how it reports errors. Two retailers that both send EANCOM orders can differ considerably in the details. That is why your partner's guide always applies, not the general standard. More on the standard itself is under [EDIFACT explained](https://edi-service.eu/en/knowledge/edifact/). A typical implementation guide contains: - an overview of the message types and the process, often as a diagram - a segment directory for each message with its status (mandatory, conditional, dependent) - the permitted qualifiers and codes for each segment - sample messages - details of identifiers, transmission method, testing and contacts ## 20-point checklist for your EDI implementation guide Go through the guide with this list and note the page where the answer is for each point. Collect whatever you cannot find and ask the partner all at once. 1. Message types: which messages go in which direction? For example, purchase order (ORDERS) inbound, despatch advice (DESADV) and invoice (INVOIC) outbound. The page on [message types](https://edi-service.eu/en/knowledge/edi-message-types/) gives an overview. 2. Standard and version: EDIFACT, EANCOM, VDA, a Global format as recommended by the VDA, or a proprietary XML? For EDIFACT, also the directory, such as D.96A or D.01B. 3. Subset and guide version: which subset applies, and which version of the guide do you have? Guides are revised; work with the current version. 4. Syntax and character set: which syntax identifier is in the header (for example UNOC), which separators, and is a UNA segment intended? 5. Mandatory segments: mark all segments and data elements with mandatory status. If one is missing, the partner's system will often reject the message. 6. Dependent information: some details are only mandatory under certain conditions, such as a batch number only for certain items. Note the condition. 7. Qualifiers and code lists: which codes does the partner expect, for example for date types, party roles or units of measure? Only use the values listed in the guide. 8. Party identifiers: you and the partner are identified by numbers, often a GLN, Odette ID or supplier number. Details under [GLN and other identifiers](https://edi-service.eu/en/knowledge/gln-edi-identifiers/). 9. Item numbers: does the partner work with the GTIN, its own material number or your item number? Often two of these are required at the same time. 10. Transmission method: AS2, OFTP2, SFTP or a network? See [Transmission methods](https://edi-service.eu/en/knowledge/edi-communication-protocols/). 11. Connection details and certificates: AS2 ID, Odette ID, addresses, ports, encryption, signing, exchange and validity of certificates. 12. Acknowledgements of receipt: are technical receipts expected, such as the MDN with AS2 or the EERP with OFTP2? 13. Syntax check (CONTRL): does the partner require a CONTRL message? It confirms or rejects an interchange at syntax level. It is requested via a field in the UNB header. 14. Application error report (APERAK): does the partner send APERAK when processing errors occur, and do you have to send any yourself? APERAK reports errors from the application, not from transmission. 15. Number ranges: how must document numbers, references and the control reference in the message header be structured? May they repeat? 16. Links between messages: which reference links the despatch advice and invoice to the purchase order, such as the order number and line number? 17. Labels and SSCC: must every pallet or package carry an SSCC, and must the label match the despatch advice? GS1 describes the SSCC as a globally unique number for logistic units. 18. Master data: delivery locations, unloading points, item mappings and prices often have to be agreed in advance. 19. Test procedure and deadlines: how many test rounds, with which test data, via which test environment? By when should production be running? 20. Contacts and incidents: who is responsible on the business side and on the technical side, and what is the procedure for outages or faulty messages? ## A short example This is what the start of a purchase order in EANCOM format looks like, sent by a retailer to its supplier. The GLNs are fictitious example numbers: ``` UNB+UNOC:3+9520000000028:14+9520000000011:14+261016:0930+00042++++1' UNH+1+ORDERS:D:96A:UN:EAN008' NAD+BY+9520000000028::9' NAD+SU+9520000000011::9' ``` The UNB header contains the sender, recipient, date, time and a control reference. The `1` at the end of the UNB segment requests an acknowledgement. In the NAD segments, the qualifiers `BY` (buyer) and `SU` (supplier) assign each GLN to a role. These are exactly the details the implementation guide sets out. ## Typical pitfalls - Outdated version. The partner has revised the guide, but you are working with an older PDF. - Example instead of rule. Sample messages show one case, not all of them. Something missing from the example can still be mandatory. - Mixed-up numbers. Your own item number ends up in the field for the customer's number, or vice versa. - Units of measure. Your ERP system counts in cartons, the partner orders in pieces. Without conversion, quantities and prices will not match. - Forgotten receipts. Transmission works, but the partner is waiting for a CONTRL or APERAK and treats its absence as an error. - Label and despatch advice do not match. The SSCC on the pallet does not match the one in the DESADV, and goods receipt grinds to a halt. - Test data from production. Real orders in testing may trigger real transactions at the partner. Clarify which environment and which identifiers apply for testing. ## How edi-service.eu helps with the implementation guide During onboarding with edi-service.eu, you upload exactly this implementation guide, along with the cover letter and sample files. An AI reads the message types, standard and version, identifiers, transmission method and test procedure from it and shows you the result for confirmation. You only correct what is wrong; open points are recorded as queries instead of being guessed. What the fixed price covers is explained in the [FAQ](https://edi-service.eu/en/faq/). If you have an implementation guide and want to know whether it is a good fit for us, you can [send an enquiry](https://edi-service.eu/en/enquiry/). ## Frequently asked questions ### What is an EDI implementation guide? An EDI implementation guide is your partner's technical specification for electronic data interchange. It sets out message types, format, mandatory information, codes, identifiers and transmission method. Other names are Message Implementation Guide (MIG), EDI guideline or EDI specification. ### Where do I get my customer's EDI implementation guide? Ask your purchasing or EDI contact at the customer for it. Large companies often provide it in a supplier portal or send it with the request to connect via EDI. Also ask for sample files and the test identifiers. ### What is the difference between CONTRL and APERAK? CONTRL confirms or rejects a received interchange at syntax level. APERAK reports whether the recipient's application was able to process the message and names business errors. Which of the two your partner uses is stated in the implementation guide. ### How long does it take to implement an implementation guide? That depends on the scope, the format and the partner's test procedure. Trade articles put a connection to a major customer as a traditional project at three to four months. The test cycle with the partner often takes up most of that time. More on effort and costs is under [How much does EDI cost?](https://edi-service.eu/en/knowledge/edi-costs/). ## Sources - GS1: “GS1 EANCOM”, (retrieved 16 October 2026) - GS1: “EANCOM 2002 S4, CONTRL, Introduction”, (retrieved 16 October 2026) - GS1: “EANCOM 2002 S4, APERAK, Introduction”, (retrieved 16 October 2026) - GS1: “EANCOM 2002 S4, Part I, section 4”, (retrieved 16 October 2026) - GS1: “Serial Shipping Container Code (SSCC)”, (retrieved 16 October 2026) - GS1: “Global Location Number (GLN)”, (retrieved 16 October 2026) - dasistweb: “B2B EDI Integration”, (retrieved 16 October 2026)