Skip to main content
Integrations

UBL Order files, and what they mean for Peppol

UBL (Universal Business Language, OASIS 2.1) is the XML document standard behind most European e-procurement. ProcuLink parses inbound UBL 2.1 Order documents and emits UBL 2.1 Order documents, so a buyer running UBL and a supplier that needs something else can still trade.

Peppol BIS Order 3 is a profile on top of UBL 2.1 — the same document, with extra business rules the Peppol network enforces and two identifier elements that declare which profile a document follows. ProcuLink emits UBL 2.1, not Peppol. Read what this does not cover before you commit to a Peppol counterparty: ProcuLink is not a Peppol conformance tool.

When to use this

Reach for UBL when:

  • Your buyers or public-sector customers send purchase orders as UBL 2.1 XML.
  • A supplier asks you to deliver an XML order document and names UBL.
  • You operate in a European market where UBL is the expected document format.

If neither side has named UBL, you probably don't need it — pick the format the supplier actually requires on the delivery tab.

Inbound: parsing a UBL Order

ProcuLink ingests the UBL 2.1 Order document into the canonical order model — the mandatory ID and IssueDate, the buyer and supplier parties, and each OrderLine / LineItem with its item identification, quantity, unit, and price. The document is recognised by its root element and namespace:

<Order xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-2"
       xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
       xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:ID>PO-10432</cbc:ID>
  <cbc:IssueDate>2026-07-04</cbc:IssueDate>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:OrderLine>
    <cac:LineItem>
      <cbc:ID>1</cbc:ID>
      <cbc:Quantity unitCode="EA">12</cbc:Quantity>
      <cac:Item>
        <cbc:Description>Steel bracket, 40mm</cbc:Description>
      </cac:Item>
    </cac:LineItem>
  </cac:OrderLine>
</Order>

Every parsed field can surface its exact UBL element path in the app — open the standards popover on any mapping field, or browse the full matrix at /library/standards. Because Peppol BIS Order 3 constrains UBL rather than replacing it, those element paths are the Peppol paths too.

UBL Invoice also parses on the inbound side, so you can bring UBL invoices in as well as orders. UBL invoice output is not offered.

Outbound: emitting a UBL 2.1 Order

On a supplier's Delivery tab, choose UBL 2.1 as the output format and sending auto-transforms the reviewed order into a UBL 2.1 Order document.

What comes out is a plain OASIS UBL 2.1 Order: cbc:UBLVersionID 2.1, the mandatory cbc:ID, cbc:IssueDate and cbc:DocumentCurrencyCode, a buyer party and a supplier party, a delivery block when the order carries ship-to data, and one cac:OrderLine per line. It declares no profile — see what this does not cover.

The emitted document is validated against the OASIS UBL 2.1 Order schema itself — the published XSD, vendored into ProcuLink unmodified — which checks element order, cardinality and datatypes. That is a grammar check on the file, and it is worth more than a presence check because UBL content models are ordered sequences: a document with every mandatory element present but two of them transposed still fails it. It is not a statement that your supplier, or the Peppol network, will accept the order.

What this does not cover

ProcuLink emits UBL. It does not certify Peppol BIS Order 3 conformance — and we would rather tell you here than have you find out at an access point. Today, specifically:

  • No BIS business-rule validation runs. There is no Schematron and no EN 16931 / UBL-CR rule engine in the product. Nothing checks an emitted order against the BIS 3 rule set.
  • No profile is declared in the document. The emitted order carries neither cbc:CustomizationID nor cbc:ProfileID. Both are optional in UBL 2.1, so omitting them is still valid UBL — but those two elements are what would declare the file a Peppol BIS Order-only 3.0 document, and writing them would assert a conformance to your counterparty's software that nothing here checks. They were removed for that reason.
  • So the file is not routable on the Peppol network as it stands. Peppol composes a document type identifier as <syntax specific id>##<customization id>::<version>, which makes the customization ID part of the key an access point looks up to find what the receiver is registered to accept. An order without one gives the network nothing to route on. Your access point supplies the profile the receiver expects, and the document is completed to it before it enters the network — so treat this output as the input to that step, not as a file you can hand straight to Peppol.
  • Party electronic addresses are incomplete. cbc:EndpointID — the address a receiver routes on — is emitted for the supplier only when that supplier's stored EDI code is provably a GS1 GLN: 13 digits with a valid check digit, tagged scheme 0088. A VAT or registration number is left out rather than tagged with a guessed scheme, because its EAS code depends on the issuing country and nothing stored beside the number records which country that was. The buyer party carries no cbc:EndpointID at all. BIS 3 requires one for both parties, so on this point the emitted document does not meet the profile.
  • The supplier party name is whatever ProcuLink holds for that supplier. It resolves to the stored supplier name, falling back to the supplier's internal identifier only when no name is recorded anywhere. Check the supplier record before sending to a counterparty that matches on registered name.
  • No emitted order has been accepted by a live Peppol access point. We have not run that test, so we do not claim the result.
  • AS4 transport into the Peppol network is not ours. ProcuLink produces a document; getting it onto the network runs through an access-point partner, arranged with you.

If your counterparty requires certified Peppol BIS Order 3, treat ProcuLink's UBL output as the input to your access point's validator, not as a finished Peppol document — and talk to us at support@proculink.eu first, so we can be straight about what will and will not work before you commit to it.

Common problems

  • Namespace not recognised — the file must be a UBL 2.1 Order in the Order-2 namespace shown above. A wrapped or profile-only variant may need a mapping review.
  • Peppol validation errors downstream — expected rather than surprising; see what this does not cover. Run the emitted file through your access point's validator and treat its output as the list of gaps to close with us.
  • "Delivered" is not "accepted" — a successful send means the endpoint answered, not that the supplier or network accepted the order's contents.

Need help? Email support@proculink.eu or see the standards catalog.