The implementation guide: where EDI's recurring cost lives

About this document. It describes the open SDC4 specification maintained by the Semantic Data Charter. SDCStudio, by Axius SDC, Inc., is one commercial implementation of that specification. Nothing here depends on the implementation.

Summary

ASC X12 defines the structure of a transaction set: which segments, in which order, with which elements. It does not define what most of those elements mean in a given relationship. That is left to each trading partner's implementation guide, a document of a hundred pages or more that says what a reference qualifier means to this retailer, which identification system a party carries, and which of the standard's date qualifiers is the one that will be enforced.

The consequence is that a supplier does not maintain one map for the 850 Purchase Order. It maintains one per partner, and each map has to be renegotiated when either side changes anything. The cost of EDI is not moving the bytes. Moving bytes has been close to free for twenty years. The cost is agreement about meaning, paid per partner, per change, forever. This page shows where that agreement lives, segment by segment, so the reader can recognize the pattern in their own guides. Business Data Exchange shows what changes when the meaning is bound to the record instead.

What an implementation guide is

The X12 standard is a grammar. An implementation guide is a trading partner's reading of it: which segments the partner requires, which it forbids, which qualifier values it accepts, and what it will do with each. Guides are published as PDFs, run from fifty to several hundred pages for a single transaction set, and are revised on the partner's schedule, not the supplier's. The supplier's EDI team reads the guide, builds or adjusts a map, tests it with the partner, and repeats the exercise for the next partner and again at the next revision.

None of this is a defect in X12. The standard was designed in the late 1970s to carry any business document between any two parties, so it had to leave the meaning of most elements open. The guides are where that openness is closed, one relationship at a time. The pattern below is the same in retail, manufacturing and healthcare.

One segment, many meanings: REF

The REF segment carries a reference identifier with a qualifier that says what kind of reference it is:

REF*qualifier*identifier~

The standard lists several hundred qualifier values. A guide selects a few and states what each means in that relationship. Three guides for the same transaction set can read like this (illustrative, drawn from the shape of published guides rather than quoted from any one):

Nothing in the file says which reading applies. The supplier's map has to know which partner sent it and branch on that, and every branch is a line of agreement that someone wrote down after reading a PDF and will have to revisit when the PDF changes.

The same role, three identification systems: N1

The N1 loop identifies a party, with the role in the first element and the identification system in the third:

N1*role*name*id-system*id~
N3*street~
N4*city*state*postal*country~

The roles come from the standard's own list. The identification system is where the guides diverge. One partner identifies a ship-to location by an assigned number of its own (92), another by a DUNS number (1), a third by a code carried in the name field with no identification system at all. The party is the same shape every time, a name and an address, and the supplier maintains three ways of saying which one it is.

Product identification

The PO1 segment carries the line item and, in pairs of elements, the product identifiers:

PO1*line*quantity*unit*price*basis*id-qualifier*id~

The qualifier says which identification system the value belongs to: the buyer's part number, a UPC, a GTIN-14, the vendor's part number, or a system the two parties defined between themselves. Each partner requires its own, sometimes two. A supplier selling to five retailers keeps a cross-reference table, one row per product, one column per retailer, and the table is the only place the identities are reconciled. When a retailer changes its identification requirement, the column changes. When a product is re-listed, the row changes. The table is never finished.

Dates

The DTM segment carries a date with a qualifier from the standard's list, which distinguishes, among dozens of meanings, a requested ship date from a ship-not-before date, a do-not-deliver-after date and a requested delivery date.

The definitions in the standard are clear. The guides are where they blur: one partner takes the requested ship date and enforces it as the delivery date, another requires a delivery window from two other qualifiers, a third requires the ship date alone. The supplier's warehouse has to know, per partner, which date the penalty is computed against. The date in the file does not say.

Measurements, and the mutually defined escape hatch

The MEA segment carries a measurement with two qualifiers, one for what is being measured and one for the property:

MEA*PD*HT*36*IN~    a product height
MEA*PK*HT*40*IN~    a package height

Whether a guide asks for the product, the inner pack or the case, and whether inches means the carton or the pallet, is again the guide's to say. And where the standard's lists do not cover what a partner wants to say, the standard provides ZZ, mutually defined, which means exactly what the two parties agreed it means and nothing to anyone else:

REF*ZZ*SEASONAL-SUMMER~
REF*ZZ*PROMO-BOGO50~
REF*ZZ*Y~

Every ZZ is a private agreement carried in a public format, and it is invisible to a third party, an auditor or a new system until someone finds the paragraph that defined it.

What it costs, with what can be sourced

We do not publish industry-wide totals for this, because the ones in circulation do not survive checking. Three figures do, and they say enough.

• A mandated version step costs 25 to 50 percent of the original implementation, and testing is 60 to 65 percent of that. This is the regulatory impact analysis for the HIPAA 5010 transition (HHS/CMS, 74 FR 3296, January 2009, analysis by Gartner under contract to CMS), which put the industry's cost of one version change of the healthcare X12 transaction sets at $7.2 billion to $14.2 billion over ten years. The dominant line is testing: proving that two parties still agree.
• The next version costs more than the last. HHS's 2022 proposal for the next pharmacy standard recorded industry's own assessment that the conversion would take two to four times the effort of the previous one (Federal Register, 9 November 2022). Each migration is mapped onto the workarounds the last one left.
• A retailer's on-time-in-full penalty is a penalty for meaning. Walmart's OTIF program, in force since September 2020, fines 3 percent of cost of goods for shipments outside a 98 percent threshold, and a shipment that arrived on time can fail it because the advance ship notice did not conform. The supplier put the right goods on the right truck; the data describing them was wrong by the partner's reading.

The per-partner onboarding fees and per-document penalties quoted around the industry come from vendor and consultancy pages rather than disinterested publishers, so they are not repeated here. They are also not needed. The three figures above are the shape of the cost: it recurs, it grows with each partner and each version, and it is paid to keep two parties agreeing about meaning the file does not carry.

What to conclude

The structure of an 850 is not the problem; it has been stable for decades and every translator on the market parses it. The problem is that the meaning of its elements is external to the file, held in documents that each partner writes and revises, so agreement has to be rebuilt by hand at every boundary and every change. Any approach that keeps the meaning outside the data, whether a new syntax, an API or a smarter mapping tool, inherits the same recurring cost.

The Semantic Data Charter's answer is to bind the meaning to the record: every value is an instance of a published component with a permanent identifier, a definition and a link to the vocabulary that defines it, so the document does not need a guide to be read, and whatever format a partner mandates becomes a projection of the record. The business documents themselves come from open standards, the OASIS Universal Business Language and GS1's identifiers, composed on the published component libraries. Business Data Exchange is the next page. If the argument seems wrong, the objections page is where the disagreements live.