Leitweg-ID: structure, origin, and where it sits in an XRechnung

What the Leitweg-ID does

Public administration is not a single recipient but a network of federal, state and municipal bodies with their own back-office systems. An invoice arriving there has to be routed to exactly one of them — automatically, without anyone reading the postal address.

That switch is what the Leitweg-ID is. It does not answer "who is meant" but "where in the government network does this document belong".

Which is also why it cannot be derived. Address and authority name describe the organisation; the Leitweg-ID describes a delivery point inside it — and only the authority knows that mapping.

The structure

The Leitweg-ID has up to three parts, separated by hyphens:

1991-12345-67
2│    │     └── check digits (2)
3│    └──────── fine address (optional)
4└───────────── coarse address

• Coarse address — names the superordinate area: the federation, a particular state, or a municipality.
• Fine address — optional, names the body within that area. Where it is absent, the ID addresses the area as a whole.
• Check digits — two digits, computed from the rest.

The check digits are why a typo usually surfaces immediately: a transposed digit changes the checksum, and the format check fires before the invoice is passed on at all.

🔵 That is the good news. The bad news: an ID that is formally correct but belongs to the wrong body passes every check — and the invoice disappears quietly somewhere nobody is expecting it.

Where it sits in the document

The Leitweg-ID travels in BT-10, the buyer reference. In a UBL XRechnung that looks like this:

1<cbc:BuyerReference>991-12345-67</cbc:BuyerReference>

And in CII:

1<ram:BuyerReference>991-12345-67</ram:BuyerReference>

BT-10 is an ordinary field of the European standard. What is new is not the field but the German ruling on what belongs in it: for invoices to public administration, BT-10 is mandatory and carries the Leitweg-ID.

In the API

In our data model it sits in the country-specific block, because that is exactly what it is — a German particularity on a European field:

1{
2  "countrySpecific": {
3    "countryCode": "DE",
4    "leitwegId": "991-12345-67"
5  }
6}

Mapping it onto BT-10 is the generator's job. So you do not need to know whether the target format is CII or UBL — only which Leitweg-ID applies.

The three mistakes that actually happen

1. The ID goes in the wrong field. A widespread assumption is that there is a dedicated Leitweg field. There is not. Writing the ID into a free-text field, the payment reference or the order number produces a formally valid invoice that cannot be delivered.

2. The ID is last year's. Administrative structures change, and Leitweg-IDs change with them. An ID that worked on the last invoice is not a guarantee for the next. For recurring invoices it pays to reconcile the ID against the order rather than carrying it forward from the master record.

3. Leitweg-ID and order number get mixed. If an authority additionally asks for an order number, that number does not also belong in BT-10. Writing both into one field — separated by a slash or a comma — makes delivery impossible, because the switch evaluates the whole field content.

Check before you send

Whether a Leitweg-ID is formally valid can be established without any access to the authority: the check digits reveal typos, and the structure reveals whether the separators are right. Whether it is the correct one is something only the customer can confirm.

The distinction is worth saying out loud: a validator confirms that the invoice is technically deliverable. It does not confirm that it arrives at the right recipient.