ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Format Indicator

A message that does not say who it is makes coexistence of multiple versions impossible. The Format Indicator pattern asks the message to self-declare its format and version on the first line.

Problem

An EDI hub continuously receives messages from partners that have not all adopted the same release: Walmart still runs X12 004010, Costco has moved to 005010, one European chain sends EDIFACT D.96A while another runs D.24A. How does the hub know which parser to use without aggregating a per-partner directory? And what happens when a partner silently changes release between two sends?

Forces

  • Release coexistence. No EDI standard replaces its versions overnight: 4010, 5010 and 6020 coexist in the same DMZ for years.
  • Unilateral changes. A partner can migrate version without warning as soon as its systems support it; the hub must follow, not break.
  • Silent failure. Without a format indicator, a 4010 parser reads a 5010 "approximately" — new segments are ignored or crash silently. The worst EDI bugs.
  • Context-free inspection. An operator opening an archived file must know what format it is, without reading the bilateral agreement.

Solution

EIP §180 (Hohpe & Woolf, 2003) prescribes: each message carries, in a very early region of the payload, an explicit format and version indicator. The receiver reads this indicator first, picks the right parser, and only then consumes the rest of the payload. The pattern is so fundamental that it is encoded in every serious EDI standard.

EDIFACT — UNH S009

The UNH (Message Header) segment opens with a composite S009 — Message Identifier carrying: message type (ORDERS), version (D), release (96A), controlling agency (UN), and an optional association assigned code (EAN008 for EANCOM, etc.). This is the canonical EDIFACT format indicator — four fields saying exactly which segment dictionary to use.

edifact orders-d96a.edi 
UNB+UNOC:3+SENDER:14+RECEIVER:14+260514:1545+ORD202605140001'
UNH+1+ORDERS:D:96A:UN:EAN008'
... ORDERS segments ...
UNT+12+1'
UNZ+1+ORD202605140001'

X12 — GS08 and ISA12

In X12 two indicators coexist. ISA12 (Interchange Control Version Number) declares the envelope syntax version (00401, 00501) — the ISA / IEA grammar itself. GS08 (Version / Release / Industry Identifier Code) declares the transaction-sets version inside the group (004010, 005010X222A1 for HIPAA 837). A single interchange can in theory contain groups in different versions.

x12 x12-version-indicators.x12 
ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID    *260514*1545*U*00401*900042001*0*P*>~
GS*PO*SENDERID*RECEIVERID*20260514*1545*42*X*004010~
ST*850*0001~
...
SE*42*0001~
GE*1*42~
IEA*1*900042001~

Reading: ISA12 = 00401 says "envelope syntax 4010". GS08 = 004010 says "transaction sets 4010". A HIPAA payload would carry 005010X222A1 which also encodes the industry sub-profile.

UBL / cXML — namespace and version

On the XML side, the format indicator is carried by the XML namespace plus an explicit version attribute. A UBL invoice declares its namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 with UBLVersionID and CustomizationID (for example urn:cen.eu:en16931:2017 for PEPPOL BIS 3.0). cXML declares its version in the version attribute of the root element.

xml cxml-1.2.069.xml 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd">
<cXML xmlns:xml="http://www.w3.org/XML/1998/namespace"
      payloadID="20260514@partner-a"
      timestamp="2026-05-14T15:45:00-05:00"
      version="1.2.069">
  ...
</cXML>

AS2 / AS4 — Content-Type and Service

On transport, AS2 (RFC 4130) uses the MIME Content-Type to indicate the application format: application/EDI-X12, application/EDIFACT, application/xml. AS4 (OASIS ebMS3) goes further with eb:Service and eb:Action encoding a business-service identifier (busdox:noprocess in PEPPOL) — a fine-grained format indicator, read by the AS4 router before payload inspection.

Anti-patterns

  • Implicit format per channel. "Everything that lands on /edi/inbound/x12 is X12 4010." False the moment a partner migrates: the hub crashes silently or ignores new segments.
  • Content sniffing. Detecting X12 vs EDIFACT by looking at the first bytes works for the standard but not for the version. A sniffer cannot distinguish 4010 from 5010 — declarative format indicators are more reliable.
  • Ignoring the format indicator. Every standard carries one. Ignoring it to save three lines of code amounts to reinventing the pattern on top, with less robustness.
  • Content-Type / payload mismatch. An AS2 application/EDI-X12 message containing JSON is a silent sender-side bug; the receiver must validate the coherence and alert on mismatch.
  • Normalizer — consumes the Format Indicator to pick the appropriate Translator.
  • Message Translator — converts between formats identified by the indicators.
  • Content-Based Router — can route on the format indicator, not just on payload content.
  • Message History — should keep format indicators per stage for audit.

Sources