PEPPOL SBDH Validator

Client-side validator for the SBDH (Standard Business Document Header) envelope. Checks sender / receiver ICDs, document type, PEPPOL BIS 3.0 process ID, RFC 3339 timestamps, payload presence — without sending a byte to a server.

How it works

SBDH (Standard Business Document Header) is the XML envelope normalised by ISO/IEC 9735, profiled by UN/CEFACT and refined by GS1 XML 3.0 to wrap a business document (UBL Invoice, UBL CreditNote, EDIFACT INVOIC…) for transport. On the OpenPEPPOL network, every document handed off between Access Points over AS4 is packed inside a <StandardBusinessDocument> carrying:

• The ISO 6523 sender and receiver identifiers (e.g. 0192:991825827).
• The exact payload nature (Standard URI, TypeVersion, local Type).
• An instance GUID (InstanceIdentifier) for traceability.
• The PEPPOL DOCUMENTID and PROCESSID BusinessScope.

Validator pipeline:

1. XML parsing (DOMParser in browser, fast-xml-parser fallback).
2. Lookup of the StandardBusinessDocument root.
3. Extraction of each header block (Sender, Receiver, DocumentIdentification, BusinessScope).
4. Application of the rules below.

Rules checked

• Root element: StandardBusinessDocument (any prefix). The canonical namespace is http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader — a different namespace raises a warning, not an error.
• HeaderVersion: must be exactly 1.0 (SBDH 1.3 still uses the 1.0 header tag). Any other value, or absence, raises a blocking error.
• Sender / Receiver: at least one of each, with a non-empty <Identifier>. The ICD scheme (the prefix before :) is checked against the ISO 6523 list below — an unknown ICD raises a warning.
• DocumentIdentification: the five fields Standard, TypeVersion, InstanceIdentifier, Type, CreationDateAndTime are mandatory. CreationDateAndTime must be RFC 3339 (YYYY-MM-DDThh:mm:ssZ or with explicit offset).
• BusinessScope: PEPPOL requires two <Scope> entries — one of type DOCUMENTID, one of type PROCESSID. A missing entry raises a warning. InstanceIdentifier values shaped as urn:peppol:bis:… are checked against the bundled list.
• Loopback: when Sender and Receiver carry the exact same value, a warning is emitted (most often unintentional in integration).
• Payload presence: a business element must follow the <StandardBusinessDocumentHeader>; a body-less StandardBusinessDocument raises a warning.

Supported ISO 6523 ICD schemes

The list below covers the ICDs actively used on the OpenPEPPOL network. The full OASIS registry contains ~250 codes — we bundle the 68 most-used ones for recognition and labelling.

PEPPOL BIS 3.0 identifiers recognised

The validator recognises the common PEPPOL BIS 3.0 identifiers and attaches a label:

• urn:peppol:bis:billing:3.0:invoice — Invoice.
• urn:peppol:bis:billing:3.0:creditnote — CreditNote.
• urn:peppol:bis:ordering:3.0:order — Order.
• urn:peppol:bis:ordering:3.0:orderresponse — OrderResponse.
• urn:peppol:bis:despatch:3.0:despatchadvice — DespatchAdvice.
• urn:peppol:bis:catalogue:3.0:catalogue — Catalogue.
• urn:peppol:bis:mlr:3.0:mlr — Message Level Response.

Process IDs:

• urn:peppol:bis:billing:3.0 — Billing 3.0 process.
• urn:peppol:bis:ordering:3.0 — Ordering 3.0 process.
• urn:peppol:bis:despatch:3.0 — Despatch 3.0 process.

Limits

• No full XSD validation of the envelope — only the rules above. The official StandardBusinessDocumentHeader.xsd is strict on a few secondary cardinalities we do not cover.
• No validation of the wrapped payload. If the body is a UBL Invoice, run it through UBL 2.1 Validator or PEPPOL Validator downstream.
• No signature or TLS chain verification — the envelope is examined in cleartext, outside the AS4 transport layer.

Privacy

Related documentation

• UBL / PEPPOL — overview of the OpenPEPPOL network.
• PEPPOL BIS Billing 3.0 — reference specification for invoices on PEPPOL.
• PEPPOL Code Lists — the up-to-date list of document type and process IDs.
• UN/CEFACT SBDH 1.3 — the official XSD and implementation guide.