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

Exception flow and escalation matrix

When something goes wrong — and something always does — you need to know who to call, within what delay, and how to close the loop.

Problem

An EDI integration produces, in operations, several incident categories:

  • The message fails syntactic validation.
  • The partner returns a CONTRL/997 rejection.
  • The partner returns a negative ORDRSP/855.
  • No ACK arrives within the contractual SLA.
  • A send sits in DLQ after exhausting retries.
  • A partner certificate expires in 30 days.
  • Volume received from a partner is abnormally low (statistical anomaly).

Without an explicit matrix, each incident is handled by oral convention or by habit, and ends up in the inbox of an EDI operator who wakes up on Monday with 400 errors and no prioritisation. The business impact is heavy: unsent invoices, lost orders, late payments.

Forces

  • Asymmetric consequences. A 997 syntax rejection on a catalogue message does not hit the same impact as a missing MDN on a B2G invoice — one wants a weekly ticket, the other wants an immediate alert.
  • Multiple stakeholders. Depending on the incident, escalation targets EDI ops, security (certs), procurement or sales (orders), finance (invoices), or the partner directly.
  • SLA diversity. A strategic partner has tighter thresholds than a long-tail partner. The matrix must parameterise per partner.
  • Cost of false alerts. Too many alerts are ignored. A coherent filter, calibrated thresholds, and self-closing mechanisms when the incident resolves on its own are required.

Solution: classify then escalate

Hohpe & Woolf's Invalid Message Channel (2003) sets the base: dedicate a separate queue to invalid messages, with a human at the end. The exception flow pattern extends this in EDI:

  1. Classify each incident by axis (technical vs business), severity (warning, error, critical), and origin (internal, partner).
  2. Bind each class to a recipient and an escalation delay: EDI ops (1h), partner manager (4h), business (24h), management (48h).
  3. Define closing actions: manual retry, sender-side fix, partner escalation, documented abandonment.
  4. Measure MTTR (Mean Time To Resolution) per class, to calibrate over time.

Escalation matrix

Incident Severity First recipient Escalation delay Expected action
IN syntax validation — failed Error Partner sender 2h business Sender-side fix, resend under new reference
CONTRL/997 received — action 7 (rejection) Error EDI ops 2h business Root-cause analysis, mapping or partner fix
ORDRSP/855 received — full business rejection Error Procurement 4h business Business call: resend or abandon the order
ORDRSP/855 received — partial rejection Warning Procurement 8h business Business validation of delta accepted vs sent
MDN/Receipt missing within partner SLA Warning → Error if 2× SLA EDI ops then partner manager SLA + 30 min Check partner state, retry, escalate if KO
Send in DLQ — max-attempts reached Critical EDI ops + partner manager 1h Manual triage, replay or documented abandonment
Partner certificate — expires in 30 days Warning Security 5 business days Request new certificate from partner
Partner certificate — expires in 7 days Error Security + EDI ops 24h Urgent escalation, plan the rollover
Received volume — ‑50% over 7 rolling days Warning Partner manager 24h Verify: partner outage, end of season, commercial loss?
Partner circuit breaker — Open > 30 min Critical EDI ops + partner Immediate Diagnosis, customer comms if required

SLA and per-partner thresholds

The matrix above is a generic default. In practice each partner has a profile:

  • Walmart expects a 997 within 1 hour on every 856 ASN and imposes penalties on late 997s. The threshold must tighten on this flow.
  • Automotive OEM on OFTP2, DELJIT files are critical — a missing EERP impacts a JIT line. Alert threshold is in minutes, not hours.
  • PEPPOL eDelivery, the Access Point must acknowledge within 5 minutes by network rule. Beyond that, AS4 reception awareness triggers retries.

The matrix × partner profile coupling lives in a config file (YAML or a DB table) parameterising thresholds, recipients and delays — versioned and auditable like code.

Operations console — the other half of the pattern

The matrix is worthless without an operations UI. A good EDI console offers:

  • Sorted view by severity and escalation delay. Criticals on top, Warnings below.
  • Drill-down on a send. See the three ACK levels (cf. the Acknowledgements pattern), retry history, payload content (with access control).
  • One-click actions. Replay, mark abandoned with reason, manually escalate to a different recipient.
  • Persistent annotations. Each incident carries an audit-logged comment thread — who did what when, for audits.
  • Export to ticketing. A Critical must generate a Jira/ServiceNow ticket without copy-paste.

Anti-patterns

  • A single "Error" class. Everything is Error, no one can prioritise. Eventually everything is ignored.
  • Email to edi-ops@…. A shared mailbox with no structure. No SLA, no tracking, no review.
  • No automatic closure. A partner that recovers does not trigger closure of open alerts — operators chase already-resolved incidents.
  • No per-partner thresholds. The generic threshold hides real incidents on critical flows and creates noise on secondary ones.
  • Alert = escalation. Conflating an ops alert with a management escalation. An ops alert is a queue signal, not a major incident — the matrix must distinguish.
  • Acknowledgements — the source of "missing ACK" and "negative ACK" incidents.
  • Retry & backoff — the DLQ is the main entry point of the exception flow.
  • Idempotency — a manual replay from the console needs the same key.
  • Canonical model — canonical invalidation is one of the incident types to classify.

Sources