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.

Envelope Wrapper

The root EDI pattern: it is not the payload that travels — it is the envelope carrying it.

Problem

A raw business message (ORDERS, INVOIC) carries neither sender / receiver identity, nor routing, timestamping, nor required acknowledgements. How to make it traceable and auditable without modifying the payload?

Forces

  • The payload must be free to evolve (D.96A → D.01B) without breaking routing.
  • Intermediate middlewares must route without parsing the payload.
  • The envelope must carry standard-enough fields for auditability (control reference, syntax version, hash).
  • Envelope parsing cost must stay minimal.

Solution

Wrap the payload in a standardized structure that carries (1) sender/receiver identification (GLN, DUNS, EIN), (2) routing and syntax version, (3) optional signature/hash, (4) control (control reference), (5) arithmetic trailer (segment count). In EDIFACT: UNA/UNB/UNH...UNT/UNZ; in X12: ISA/GS/ST...SE/GE/IEA; in UBL: SBDH (Standard Business Document Header); in cXML: the DTD wrapper with `<Request>` / `<Response>`.

EDI implementation

Envelope Wrapper is imposed by the EDI standards' grammar itself. The golden rule: NEVER generate an `ORDERS` payload without its UNB/UNH envelope; a generic middleware will silently reject it. Validators like ediverse.io's EDIFACT validator check both payload syntax AND envelope ↔ payload coherence (UNH02 must match the ST segment and directory used).

Anti-patterns

  • Naked payload for "simplicity" — the first middleware encountered rejects it.
  • Envelope with in-house partner identifiers (`SAP-001`) instead of standards (GLN/DUNS) — partner interop impossible.
  • Control reference mismatch between envelope and payload — acknowledgement cannot be paired.
  • Custom wrapper — loss of standard auditability.

Sources