LeitwegID – All you wanted to know about the identification of public organizations for electronic invoicing in Germany

[francois_vigneron]

=== Update January 2021 ===

This blog, while updated, details much of the history on Leitweg IDs. For information on how to implement with SAP Document Compliance, cloud edition, please go to:

• The latest PDF documentation attached to note 2690949 (s-user required). The introduction from page 7 details all use cases depending on the setup of your public customers and on of their Peppol access points.


• In complement, d.cotelea's blog How to maintain Leitweg-ID for Peppol Exchange Service for the Cloud Edition of SAP Document Complia... is more helpful to consulting teams.  

==========================

As we made the case earlier, Peppol is the best option to automate your billing to public German customers. Understanding the LeitwegID in the context of Peppol will set your projects on rails for success. 

Translated, the LeitwegID means more or less the Guiding Way Identification. The LeitwegID is guiding documents to their final recipient within government organizations. It is a mandatory content of XRechnung invoices and specified by KoSIT in a 10-page document[1]. The LeitwegID applies to public entities only[2].

As Germany is a federal state, the LeitwegID is taking up the challenge to fit all possible government organizations and still being agreed by 16 individual German states and the federal state (the so called 16+1). KoSIT, the organization in charge of standardization of public IT, is calling the LeitwegID a unified systematic approach to addressing and, if applicable, to forwarding electronic invoices.

A unified systematic approach can be opposed to a unique approach on the one hand and to not having an approach at all on the other.

• A unique approach has been chosen by some countries like Denmark. There, the GS1 Global Location Number (GLN) is defined as the sole way to identified public services for electronic invoicing. It means that all public and private organizations get their IDs assigned from a single organization, GS1. GS1 is taking care that IDs are valid, unique and searchable in a directory - simple.


• No approach would have meant that every public buyer could have defined on their own how invoices are addressed to them: VAT-ID, GLN, DUNS, local fiscal IDs, e-mails, etc. Suppliers then have no clue whether Buyer B1 is doing it the same way as Buyer B2, and B3: a permanent source of errors and conflict for teams responsible of billing, accounts payable and cash collection - complex.


• Finally there are middle ways. A unified but non-systematic approach could be the one chosen by Austria. While Austria does have a unique central platform and does require a reference from all suppliers, this reference, the so-called order reference, can be an organization ID, a purchase order number, a buyer group, an additional internal reference or a combination of them[3].

The German unified systematic approach means that, at least, suppliers know what they can ask their public buyers for: a LeitwegID that follows a unique but flexible structure.

Stupid question: There is just one LeitwegID per invoice recipient, right? Wrong but changing to "right".

• At the beginning of 2020, for a given German public entity, invoice senders actually need to maintain two LeitwegIDs. This was disappointing news for suppliers used to the simplicity of Peppol in other contexts, but once you knew about, at least, you could organize for. On a second look, KoSIT probably had no choice but that one in the beginning. The LeitwegID is not necessarily an organization (or suborganization) ID, it can, like in Austria, also be a project number or an order number. At least KoSIT could not exclude that. You would argue that there are tags in the Peppol and XRechnung structures to catch such content in a proper manner – which I agree with. But would you take up to get an agreement from 16+1 states for an approach that has implications in tens of thousands of backend applications up to the tiniest organizational parts of the German social state? I would not have, at least, not  under short notice.


• During the course of 2020, the platforms in charge of receiving invoices for government agencies realized that they actually do not comply with Peppol recommendations and make it complex for suppliers by requesting two LeitwegIDs. ZRE and OZG-RE moved first and new Peppol platforms in other Germany states are expected to either support one LeitwegID from the start or work through ZRE or OZG-RE. To my best knowledge, currently our customers are only using double Leitweg IDs with Bremen.

Before we look further at the LeitwegID, let's be reminded that for B2B, even in Germany, VAT-IDs are maintained as a unique ID the regular Peppol way. The mapping between backend masterdata and the Peppol message looks like in the below simplified illustration.

Illustration: Typical use of Peppol ID (e.g. B2B with VAT IDs for the invoice sender and receiver).

At the beginning of 2020, for business to government transactions, we implemented LeitwegIDs like this:

1. A technical LeitwegID is maintained at business partner level (or at company code level for buyers). This ID is identifying the buyer’s platform e.g. the central invoicing entry platform of the federal state (ZRE). It will be typically derived from the legal jurisdiction of the invoice recipient: entities subordinated to the federal state will use the ZRE platform along with some other states such as Saxonia. Entities in other states will prescribe their own local platforms and Peppol entry points such as the ones for Schleswig-Holstein and Rhineland-Palatinate.


2. A business LeitwegID is maintained as a buyer reference within each invoice document by the Seller. This ID will be provided by the buyer with each new contract or order.

The illustration for a private supplier of a German public entity then looks like this.

Illustration: LeitwegID used as a Peppol ID.

Now, as of January 2021, the situation is more complex as we have to take into consideration, the different cases:

• Invoice recipient has one or multiple end/business LeitwegIDs


• Peppol access point of the invoice recipient supports end-recipient LeitwegIDs or only platform LeitwegIDs.

That makes four different cases that are covered in detail in the latest PDF documentation attached to note 2690949 (s-user required). See the introduction from page 7 that details the four cases. Note that the help portal documentation will get updated later due to own documentation cycles.

That's it on the LeitwegID. You are warned and informed about the unified systematic approach that guides your invoices to their final recipients. For other Peppol identifiers, check Peppol IDs in the context of SAP Document Compliance. For further context including on the standard solution offered by SAP, see the blog series All you wanted to know about the electronic invoice in Germany (also in German). For more information on SAP Document Compliance go to the related Community page. For detail on Peppol testing, see Peppol – Attention points for testing.

 

[1] See https://www.xoev.de/xrechnung-16828#LID and latest version (Leitweg-ID, Format-Spezifikation Version 2.0.1, Fassung vom 20.12.2019).

[2] Private buyers in countries with value added tax (including Germany) typically opt for VAT-IDs as preferred ID in the Peppol network, but many other IDs are available in the Peppol network. See full list at https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/.

[3] See https://www.erechnung.gv.at/erb?p=einvoice_info_fedgov_orderref.

[4] The regular product documentation will be updated based on a different cycle. It can be found here: SAP S/4HANA, SAP S/4HANA Cloud, SAP ERP.

This blog has been written with the help of venkatjs.01, Felipe Velloso Alves, ga.nagy and eleonora.vidal.