# The network that already uses GS1 party identity: Peppol, EAS 0088, and the invoice rail > transactions.dev · by visibility.cloud — 2026-07-31 > Written for the supply-chain ISV / traceability-vendor engineering org — the standards-and-compliance PM asked whether "e-invoicing readiness" and "traceability" are one roadmap item or two. One thesis: **Peppol participant addressing supports the GLN as a first-class endpoint scheme — ISO 6523 code 0088 — and its documents carry GTINs at line level, which makes Peppol the richest GS1-identifier rail in the business-document landscape, and the way `inv` coverage arrives on the event record without negotiating bilateral EDI.** If your customers are asking about e-invoicing compliance and your roadmap is asking about transaction context on traceability events, this page's claim is that those are one workstream wearing two department names — and the spec citations below are why. ## Four corners, two paragraphs Peppol is a four-corner document network: a sender (corner one) hands a document to their Access Point provider (corner two), which looks up the receiver's Access Point (corner three) through the network's addressing layer and delivers over AS4 to the receiver (corner four). Nobody negotiates bilateral connections; joining the network once reaches everyone on it. Governance sits with OpenPeppol; the document specifications are public at [docs.peppol.eu](https://docs.peppol.eu/). The payloads are UBL profiles — which is why [the previous post's one-to-one mapping](/blog/ubl-already-speaks-cbv/) matters here. BIS Billing 3.0 carries the Invoice; BIS Ordering carries the Order; and the Peppol Despatch Advice transaction (T16, on the 3.x line, May-2025 release current) is a UBL DespatchAdvice — the same document the compile already turns into a `desadv` reference and a validated event skeleton. ## EAS 0088: party identity that survives the network hop Every Peppol participant is addressed by a scheme-qualified identifier, and the schemes are the ISO 6523 registry — Peppol's Electronic Address Scheme (EAS) code list, published at docs.peppol.eu, includes **0088: the GS1 Global Location Number**. A supplier addressed as `0088:0614141000005` on the network envelope is the *same party* the event record names as `urn:epc:id:pgln:0614141.000005` on `sourceList` — one identifier system from the network's routing layer to the record's §7.4 party fields, no crosswalk table, no fuzzy vendor-name matching. At line level, the standard item identification slot carries GTINs (ISO 6523 scheme 0160), joining invoice lines to the same trade items the events observe. No other document rail in [the connector landscape](/blog/eancom-is-the-bigger-rail/) hands over GS1 identity this completely — the EDI dialects carry it in their content; Peppol carries it on the envelope itself. (The identifiers' own grammar is the family's barcode layer: [GLN anatomy at barcoding.dev](https://barcoding.dev/schemes/gln/).) ## The compile: BIS document in, CBV reference out A BIS Billing 3.0 invoice, reduced to the elements the record needs: ```xml INV901447 2026-08-05 4500123 0614141000005 0345678000007 192 00614141123452 ``` compiles to the `inv` reference on the movement it bills — landing beside the `po` and `desadv` references on the shipping event's `bizTransactionList`, with the endpoint GLNs preserved end to end as party EPC URIs on the §7.4 source and destination fields. Same scope law as every invoice lane: [identity on the record, money in AP](/blog/invoic-to-inv/). Same validation gate as every compile on this site: the emitted events validate against the pinned official EPCIS 2.0 schema — superset where the document carries more, conformant always. What that buys strategically: `inv` coverage is the reference type bilateral EDI delivers most unevenly, because invoice flows are exactly where smaller counterparties never onboarded — the same gap that leaves [commerce platforms with no invoice object at all](/blog/ecommerce-has-no-invoice-object/). Peppol inverts it: the long tail is being pushed onto the network by law, ViDA carrying the EU mandate forward and adoption compounding well beyond it (Japan, Australia and New Zealand, Singapore, Malaysia). The paperwork dimension of the record fills in from a rail your counterparties are joining for reasons that have nothing to do with you — regulatory gravity doing the onboarding work that VAN sales teams spent three decades failing to finish. ## The honest gate Becoming a Peppol Access Point is a certification, not a signup: OpenPeppol membership, a transport infrastructure agreement with a Peppol Authority, AS4 conformance testing, network PKI certificates, and an increasingly expected ISO 27001 posture — weeks to months of calendar time and annual obligations. That is why nearly every participant, including this layer, integrates *via* an existing certified Access Point provider: corner two is a commodity you rent, and the differentiated work — the compile from BIS documents to conformant event context — happens on your side of it. That integration path is stated here exactly as it is built, because a network post that hides its own on-ramp behind vague "connectivity" language is the genre this site exists to replace. For the PM holding both questions from the top of this page: one roadmap item. The network your regulators are pushing you toward already routes by the party identifier your traceability events already carry — and the compiler that joins them is [the same one](/blog/biztransaction-is-a-core-field/) that handles every other dialect of the same fourteen-word vocabulary. If both questions are on your desk this quarter, [answer the first one at the door](/get-access/) — the onboarding flow asks which document sets are actually on your wire and whose partner guides constrain them. --- Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt