What does D.96A mean? Understanding EDIFACT versions
An EDI specification will show you a line like ORDERS D.96A UN EAN008. Those four parts say which dictionary the file should be read against. The wrong version means a file that is valid but misunderstood.
What do the four parts say?
The information sits in the second data element of the UNH segment:
UNH+ME000001+ORDERS:D:96A:UN:EAN008'
| Part | Value | Meaning |
|---|---|---|
| Message type | ORDERS | This is a purchase order |
| Version | D | The draft directory family |
| Release | 96A | Release A of 1996 |
| Agency | UN | The United Nations (UN/CEFACT) |
| Association code | EAN008 | An industry subset — here GS1/EAN |
The first three identify the standard; the last identifies whose subset you are using.
Why is it still 1996?
D.96A is the most widely used EDIFACT release. Newer ones exist — D.01B, D.07A and later — but the retail world largely stayed on 96A.
The reason is economics, not inertia. Upgrading a release affects every supplier of a chain at once. Where the gain is limited, nobody wants to move thousands of trading partners to a new version. The cost of changing a working standard outweighs the benefit of the new fields.
So "we are on an old release" is rarely a defect in EDI; more often it is a deliberate choice.
The part that really decides: the association code
The most commonly overlooked part of the line is the last one. Codes such as EAN008, EAN009 or ETEB01 say which industry subset of the standard applies.
The subset determines:
- Which segments are used — not every segment in the standard is
- Which fields are mandatory
- Which values the code lists are restricted to
So ORDERS D.96A can look different at two different partners. The standard is the same; the subset is not. Writing an integration from the version alone, without the specification, is the single most repeated mistake in this work.
How does a version mismatch show up?
Usually the file is not rejected — it is misread. The symptoms:
- A field you expected arrives empty, because in your release it sits elsewhere
- A code list value is not recognised, because it was added in a later release
- Segment order does not match the specification, because grouping rules can
change between releases
Looking at the UNH line of the incoming file answers most of these at a glance.
Which version should you use?
That is not your decision. Whatever your trading partner says. The party sending the order sets the version; you follow it.
If two partners want different versions, you need two mappings. This is normal; most EDI integrations carry per-partner configuration.
What to do in practice
1. Note the four parts on the UNH line of the incoming file 2. Compare them with the values in the specification, the association code above all 3. If they differ, ask your partner before writing any code
To see which version a file uses, opening it in a viewer is enough; UNH is usually the second line.