# UBL vs X12 vs EDIFACT: How the Three Standards Map onto Each Other
> An EDI 850 is an EDIFACT ORDERS is a UBL Order. The same business documents exist in all three standards under different names. A field-by-field mapping for teams who already run X12 and are being asked about Europe.
X12, EDIFACT, and UBL describe the same business documents under different
names. An X12 850 purchase order is an EDIFACT ORDERS message and a UBL Order.
X12 dominates North America, EDIFACT dominates Europe and Asia, and UBL is the
syntax behind Peppol and most EN 16931 e-invoicing mandates.
If you already run X12, you know more about European e-invoicing than you think.
The business documents are the same. What changes is the syntax, the naming, and
the assumptions about how a document travels.
## The mapping
| Business document | X12 | EDIFACT | UBL 2.1 |
| --- | --- | --- | --- |
| Purchase order | [850](/guides/edi/850-purchase-order) | ORDERS | Order |
| PO acknowledgment | [855](/guides/edi/855-purchase-order-acknowledgment) | ORDRSP | Order Response |
| PO change | [860](/guides/edi/860-purchase-order-change) | ORDCHG | Order Change |
| Ship notice | [856](/guides/edi/856-ship-notice) | DESADV | Despatch Advice |
| Invoice | [810](/guides/edi/810-invoice) | INVOIC | Invoice |
| Price and sales catalog | [832](/guides/edi/832-price-sales-catalog) | PRICAT | Catalogue |
| Inventory report | [846](/guides/edi/846-inventory-inquiry) | INVRPT | (no direct equivalent) |
| Planning schedule | [830](/guides/edi/830-planning-schedule) | DELFOR | (no direct equivalent) |
| Technical acknowledgment | [997](/guides/edi/997-functional-acknowledgment) | CONTRL | Message Level Response |
The three families cover the same order-to-cash cycle. Where they diverge is at
the edges: X12 has richer retail-specific documents, EDIFACT has stronger
logistics and customs coverage, and UBL carries procurement documents that the
other two never needed because procurement was not the problem they were built
for.
## The structural difference that matters
X12 and EDIFACT are both **positional and flat**. A segment is a line, elements
are separated by a delimiter, and meaning comes from position.
```
BEG*00*SA*4500012345**20260812
```
That is an X12 850 header. `4500012345` means "purchase order number" because it
is in the third element of a `BEG` segment, not because anything in the file
says so.
EDIFACT does the same thing with different punctuation and a header that can
redefine the delimiters:
```
BGM+220+4500012345+9'
```
UBL is **nested and named XML**:
```xml
4500012345
```
This is why an X12 mapping tool does not port to UBL. Positional element
addressing has no meaning in a namespaced tree. If you have a declarative X12
mapping layer, it is not reusable for UBL, and trying to force it produces a
worse tool for both.
What does port is everything either side of the syntax: your customer master,
product matching, unit-of-measure normalisation, and pack-size logic. Those are
the expensive parts, and they are format-independent.
## Units of measure, where the three actually converge
UBL uses UN/ECE Recommendation 20 codes in the `unitCode` attribute. EDIFACT
uses the same code list. X12 uses Element 355, which overlaps heavily but not
completely.
So `EA` is each in all three. `CS` is case in X12; UBL and EDIFACT prefer `CT`
for carton. If you already maintain a UOM translation table for X12 trading
partners, that table is most of what you need for UBL, with the Rec 20 subset
filtered out.
This matters more than it sounds. Getting a case quantity wrong by a factor of
twelve is the single most expensive class of order error, and it does not
announce itself.
## Transport assumptions differ more than the formats
- **X12** typically moves over AS2, SFTP, or a VAN. The relationship is
bilateral and set up per partner.
- **EDIFACT** moves the same way in practice, over AS2 or SFTP, often through a
VAN.
- **UBL under Peppol** moves over AS4 in a four-corner model with a public
participant directory. You connect once and reach anyone, without per-partner
onboarding.
That last point is the real innovation and it is worth understanding properly.
In X12, adding a trading partner is a project: spec review, mapping, testing,
certification. Under Peppol it is a directory lookup. That is why governments
chose it for universal invoicing mandates, since it makes compliance reachable
without every small business hiring an EDI consultant.
But note that UBL does not require Peppol. Germany mandates EN 16931 and no
transport whatsoever, so a UBL or CII invoice attached to an email is
compliant there. See
[what each country actually mandates](/guides/e-invoicing/peppol-vs-e-invoicing-mandates).
## EDIFACT is not going away, but it is not growing
If you trade with European retailers or logistics providers, EDIFACT is what
they run, and the e-invoicing mandates do not change that. The mandates cover
invoices. ORDERS, DESADV, and DELFOR keep flowing exactly as before.
What is changing is the invoice leg specifically, and only in mandated
countries. A German supplier may well keep receiving ORDERS over AS2 while its
INVOIC leg moves to ZUGFeRD over email, because those are two different
obligations with two different drivers.
## The practical read for an X12 team
1. Your document knowledge transfers directly. An 850 is an ORDERS is a UBL
Order.
2. Your mapping tooling does not transfer to UBL. Budget a separate emitter.
3. Your master data, matching logic, and UOM tables do transfer, and they are
the expensive part.
4. Check what your ERP already emits before buying anything. See
[does your ERP support Peppol](/guides/e-invoicing/does-your-erp-support-peppol).
## Sources
- [Peppol BIS specifications](https://docs.peppol.eu/poacc/upgrade-3/), OpenPeppol
- [UN/CEFACT Recommendation 20, units of measure](https://unece.org/trade/uncefact/cl-recommendations), UNECE
## Related reading
- [European e-invoicing mandate timeline](/e-invoicing)
- [EDI document types](/edi-document-types), the full X12 reference
- [Peppol ordering profiles](/guides/e-invoicing/peppol-order-documents)
- [EDI Inspector](/edi-inspector), free in-browser EDI file reader