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

Data Mesh applied to EDI

Move beyond the centralised EDI hub that becomes a bottleneck monolith — and give business domains ownership of their EDI flows.

Problem

A monolithic EDI hub that processes all orders, all shipments, all invoices, all payments and all logistic statuses of an organisation ends up concentrating in one integration team the functional knowledge of every business domain. That team becomes the bottleneck of every functional change: new partner, new message, new regulatory rule. The hub ages, accumulates debt, becomes fragile.

Forces

  • Each business domain knows its flows best. The Orders domain knows the Walmart ORDERS variants, PEPPOL acknowledgements, customer validation rules. The Payments domain knows PAYMUL/BANSTA, SEPA, SWIFT.
  • The organisation already has business silos (Procurement, Logistics, Finance, HR). The mesh embraces existing structure rather than fighting it.
  • A domain must evolve independently. HR must integrate JOBAPP/JINFDE without coordinating with Logistics.
  • But compliance remains transverse. Fiscal proof, GDPR, cybersecurity are platform concerns, not domain concerns.

Solution

Apply Dehghani's four Data Mesh principles to the EDI landscape:

  1. Domain ownership — each business domain (Orders, Shipments, Billing, Payments, HR) owns its EDI flows: it drives mappings, validations, partner SLAs.
  2. Data as a product — each domain publishes its events as a product with a versioned schema, documentation and SLA. edi.events.orders.v3 is a product, not a side effect.
  3. Self-service platform — a central platform provides transverse building blocks (AS2/AS4/SFTP connectors, validator, observability, fiscal archive) that domains consume.
  4. Federated computational governance — a transverse council defines standards (idempotency, schema, security, partner onboarding) that all domains must respect.

EDI implementation

In practice: the Orders domain owns its EDIFACT ORDERS / X12 850 / UBL Order pipeline, publishes an orders.v1 product consumable by other domains (Inventory, Picking). The Billing domain owns INVOIC and publishes an invoices.v2 product. The central platform provides Sterling B2B, a schema registry, a Datadog observability stack, an immutable S3 archive for fiscal proof. The transverse governance imposes idempotency (stable UNB CTRL), correlation identifier (TraceId), standardised log format. Each domain has its own internal integration team; no domain depends functionally on another to ship a change.

Anti-patterns

  • Mesh without platform. Five domains each reinventing AS2 produce five different incidents for the same partner.
  • Platform without governance. Without a transverse standard, two domains end up modelling the same partner differently — end-to-end traceability becomes impossible.
  • Domain ownership without data product. Domains own their flows but expose them to no one — the result is a silo, the opposite of mesh.
  • Mesh imposed top-down. Without buy-in from business teams, the mesh becomes a new acronym dressing the same monolith.
  • Canonical Model — each product publishes its canonical schema.
  • Event Sourcing — technical foundation for publishing event-based products.
  • Message Broker — the neutral infrastructure on which domains publish.

Sources