The Peppol network is by its own definition about fast, efficient and borderless trade. To truly enable that, Peppol has to handle the identification of business partners for domestic and global transactions alike in all kind of jurisdictions and combinations of them. That is the job of Peppol party identifiers (Peppol IDs). When you implement Peppol, the type of IDs can impact the effort related to e.g. master data management. This blogs aims at helping you framing that.

Similarly to paper transactions, Peppol identifiers identify both the sender and the receiver and are present in envelops and messages. This makes four Peppol IDs per transactions.

Illustration: Peppol’s use of ID reflects that of paper documents.

All available Peppol ID types are listed in the Peppol documentation at https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/. At the time of writing, the list holds more 70 different identifiers. For countries most involved with Peppol and supported by SAP Document Compliance, the below table summarizes what identifiers are most relevant. In annex 1 a further table helps with the correspondence to party ID types in the master data of backend systems. GLN can be used in every country.

Table: Typical Peppol IDs per jurisdiction (bold = most commonly used IDs).

The Germano-Austrian exception

In most countries, sender’s and receiver’s IDs used in the envelop and within the document are the same. But as you might already have spotted in the above table, Germany and Austria decided to use Peppol IDs to identify their public sector access points, creating the need to maintain further IDs for final routing. There are some process-historical and legal reasons to that approach[1]. That said, it creates additional work at suppliers. It might be progressively addressed e.g. with a wider adoption of purchase orders in the public sector (Peppol’s order reference), a change process likely to span over years.

Currently in Austria, final recipients of the public sector are determined from Peppol’s order reference in UBL. In backend systems, this order reference is maintained directly in the Sales Order. The Peppol participant ID of the central government platform does not have to be maintained[2].

In Germany, final recipients of the public sector are determined from Peppol’s buyer reference in UBL (Leitweg ID #2 in below figure).

### Update February 2021: In Germany, the federal government platforms ZRE and OZG-RE are now using single Leitweg IDs per recipient. Other platforms still do not. For how to implement this, see the specific blog How to maintain Leitweg-ID for Peppol Exchange Service. ### 

Illustration: two German Leitweg IDs, one identifying the receiving platform (#1) and one the final recipient (#2).

Why and when to use global identifiers such as GLN (EAN) numbers for identifying your organization?

In the below figure, for simplification, VAT IDs are used as an illustration for any locally relevant participant IDs. Similarly, GLNs represent any ID that can be chosen more flexibly[3].

Illustration: backend structure and selection Peppol ID types

Let’s look at these four cases.

• (I) If your organization has one local Peppol participant ID per company code, local IDs are an easy choice.
• (II) If your organization shares one local ID across multiple company codes, the back routing of inbound messages and statuses to individual company codes is not possible. More flexible Peppol participant IDs such as GLNs solve that issue.
• (III) If company codes are split across backends, it’s the same issue. Actually, you cannot even assign a same ID to different backend systems in Master Data Management of the service. Again, more flexible Peppol participant IDs such as GLNs solve the issue.
• (IV) Inversely, if your organization has multiple participants for one company code, a single participant ID (e.g. a GLN or one of the two VAT IDs) does the job.

That’s it for now.

Note that the use of envelop-level IDs to route messages has some importance for testing. For details, see the blog Peppol – Attention points for testing. For more information on SAP Document Compliance go to the related Community page.

This blog consolidates the input of development and product management colleagues at Globalization Services: Gabor Nagy, Claudia Lampl (AT), Linda Garcia (BE), Chanchana Bhiboolnakrin (SG), Erik Toernqvist (NO, SE), Rikus Voerman (NL), Francois Vigneron (DE). Feel free to reach out and comment.

Annex 1: IDs and master data.

For more details, Backend-specific documentation e.g. for S/4HANA, S/4HANA Cloud and ECC is available from Supported Countries/Regions by Product. SAP S/HANA Cloud documentation is found directly under [Country] > General Functions, e.g. for Norway > General Functions.

Table: Types of Peppol participant IDs and Party ID types in ERP master data.

[1] See blog on Germany’s LeitwegID.

[2] Public and private customers are differentiated on the Party ID Type (AT:GOV vs AT:VAT).

[3] In the Peppol documentation, Global Location Numbers (GLN) are referred to with their older name of EAN location numbers. GLNs can be acquired from local GS1 organizations, see https://www.gs1.org/.