Skip to Content
Technical Articles

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

As we made the case earlier, Peppol is the best option to automate your billing to public German customers from November 2020. 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. For a given German public entity, invoice senders actually need to maintain two LeitwegIDs. This is disappointing news for suppliers used to the simplicity of Peppol in other contexts, but once you know about, at least, you can organize for. On a second look, KoSIT probably had no choice but that one. 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 cannot 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 tinest organizational parts of the German social state? I would not, at least, not  under short notice. The standard might evolve and further iterations provide a better answer.

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).

For business to government transactions, this is how the two LeitwegIDs come into play:

  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: Leitweg ID used as a Peppol ID.

For users of SAP Document Compliance, the PDF documentation attached to note 2690949 describes how to maintain technical LeitwegIDs (e.g. in the S/4HANA documentation, 1.4.7 Maintaining Leitweg-ID for Business Partners) and business LeitwegIDs (1.8.2 Maintaining Leitweg ID in Billing Documents)[4].

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 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

[3] See

[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 Venkata Sudhakar Pagidi, Felipe Velloso Alves, Gabor Nagy and Eleonora Vidal.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.