Invoicing & funding
XRechnung to the Straßenbauamt: Leitweg-ID, attachments and the most common mistakes
Why XRechnungen to authorities fail: structure and check digits of the Leitweg-ID, mandatory fields, and what the portal rejects on its own.
Why an XRechnung to an authority fails differently from a normal invoice
An invoice to a private customer is read by a person. An XRechnung to a public client first runs through a portal that checks it by machine. If it fails there, no case handler ever sees it – and you find out immediately at best, or weeks later through the payment that never arrives.
The good news: the grounds for rejection are manageable and they repeat. The most common ones lie not in the invoice content but in the addressing.
The Leitweg-ID: structure and check digits
The Leitweg-ID addresses the invoice within the administration. It consists of three parts, separated by hyphens:
| Part | Length | Content |
|---|---|---|
| Coarse addressing | 2 – 12 digits | federal government often 991, municipalities the official municipality key |
| Fine addressing | optional, up to 30 characters | alphanumeric, internal routing at the recipient |
| Check digits | 2 digits | calculated by Modulo 97-10 |
The check digits follow the same procedure as an IBAN. That is the practical reason a transposed digit in the Leitweg-ID is reliably caught: it changes the checksum, and the portal rejects the invoice before a human sets eyes on it.
In the XRechnung the Leitweg-ID sits in field BT-10 (BuyerReference). With public clients it
is a mandatory field – an otherwise faultless invoice without a Leitweg-ID is not delivered.
Practical tip: Check the Leitweg-ID when you set the client up, not when you send the first invoice. Otherwise a typo in the master data repeats itself every month.
The most common grounds for rejection
| Cause | How you notice | Remedy |
|---|---|---|
| Leitweg-ID wrong or missing | portal rejects immediately | verify the check digits, request the ID from the authority |
| Wrong format supplied | the authority wants XRechnung, you send a PDF | settle the client’s requirement beforehand |
| Mandatory field empty | validation error with a cryptic number | have it checked against the EN 16931 rules |
| No reference to the job | the case handler queries it | supply the call-off or order number |
| Supporting documents missing | payment is delayed | attach the take-off sheets |
What stands out: only one of these points concerns the invoice itself. The rest is addressing, format and evidence.
Attachments: the underestimated part
Many authorities expect the take-off sheets as an attachment to the invoice. Technically that is provided for in the XRechnung – embedded attachments are part of the standard.
In practice the attachment decides how quickly the check happens. When the case handler sees the billed quantity and the signed Zettel side by side, the check is a comparison. If the evidence is missing, it becomes a query – and queries cost weeks.
XRechnung or ZUGFeRD?
Both satisfy EN 16931. The difference is in the form:
| XRechnung | ZUGFeRD | |
|---|---|---|
| Structure | pure XML file | PDF with embedded XML |
| Human-readable | no | yes, as a PDF |
| Typical with | public clients | B2B |
For a Straßenbauamt, XRechnung applies as a rule. What is decisive, though, is always the specific client’s requirement – ask about it before you issue the first invoice.
Version status: 3.0.2 today, 4.0 in sight
What currently applies is XRechnung 3.0.2 (as of August 2026). Version 4.0 implements the revised EN 16931-1:2026 and has been announced for mid to late 2026; a transition period is provided for 3.0.2. There will probably not be a single cut-off date by which everything must have changed over.
For your planning that means: the change is a matter for your software vendor, not a project in your firm. Ask the vendor how they handle it – that is a fair question to put to anyone.
How to check an invoice before sending it
There are public validation tools that check an XRechnung against the EN 16931 rules. The drawback: the error messages are written for specialists and give rule numbers instead of plain language.
The check is worthwhile all the same, especially for the first invoice to a new client. At Levora every build runs through KoSIT’s test tools for EN 16931, and the ZUGFeRD variant additionally through veraPDF for PDF/A-3B – if a check fails, there is no new version.
Deadlines: from when you must send
All domestic businesses have had to be able to receive since 01.01.2025. Sending depends on the previous year’s turnover:
| Previous-year turnover | Obligation to send from |
|---|---|
| over €800,000 | 01.01.2027 |
| up to €800,000 | 01.01.2028 (paper and PDF remain permitted until 31.12.2027) |
These deadlines concern the B2B area. Towards public clients, separate and earlier rules apply – for federal authorities the XRechnung has been mandatory since 27.11.2020, and states and municipalities have their own deadlines and their own portals.
Source: BMF – e-invoicing FAQ
What this means concretely for a civil engineering firm is in the article The 2027 e-invoicing duty for civil engineering firms .
Frequently asked
Where do we get the Leitweg-ID? From the client. It is usually stated in the order confirmation or in the procurement portal; if in doubt, ask the case handler. Do not guess – a wrong ID is caught by the check digits.
Do we need expensive software for this? No. Inexpensive invoicing programs and the federal portal can produce an XRechnung too. The effort lies in the chain before it – in the take-off and in assigning it to the item.
What if the authority wants a PDF anyway? Then supply what is asked for. The client’s requirement takes precedence over your own habit.
The Leitweg-ID by example
Take a fictitious Leitweg-ID in the form you will encounter:
04011000-12345-06
│ │ └── Check digits (2 places, Modulo 97-10)
│ └──────── Fine addressing (optional, here: department)
└───────────────── Coarse addressing (here: official municipality key)
Three things can be read off it:
The coarse addressing identifies the authority. For municipalities that is the official
municipality key, for the federal government often 991. You get this sequence from the client –
do not piece it together from another invoice.
The fine addressing is optional and usually filled in anyway. It routes the invoice internally to the right department. If it is missing, the invoice may end up in the central intake and take longer.
The check digits are your protection against typos. They are calculated by Modulo 97-10 from the preceding places – the same procedure as for an IBAN. A transposed pair of digits changes the result and is detected.
In practice that means: if you retype a Leitweg-ID and make a typo, the portal notices. If you use a wrong but internally valid ID – say, that of another authority – nobody notices, and the invoice lands with the wrong recipient.
What happens when an invoice is rejected
The sequence differs from what you know from a paper invoice:
| Stage | Who checks | Feedback |
|---|---|---|
| Delivery | portal, automatic | immediately, technical message |
| Formal check | portal / validation | usually within minutes, rule numbers |
| Content check | case handler | days to weeks, by mail or phone |
| Substantive check | the authority’s site management | can trigger queries about the take-off |
The first two stages are automated and report back quickly. The catch is that a formally faultless invoice with a missing call-off reference passes both stages and only sticks with the case handler – there without an error message, simply without being processed.
Hence the practical rule: check everything that can be checked by machine before sending. Avoid everything else through clean assignment from the outset.
How to settle the sending route
There is no single route to an authority. In practice you will meet three:
- Portal upload. You upload the XML file in the state’s invoice portal. Widespread, works, costs a few clicks per invoice.
- Email to an intake address. Some clients accept the XRechnung as an attachment. Convenient, but not permitted everywhere.
- Peppol. A European network for exchanging invoices. The cleanest route for firms with many invoices to different bodies; for a firm with three clients, effort without benefit.
Ask on the first job which route is expected, and record it in the client’s master data – together with the Leitweg-ID. Those five minutes save you the search on every subsequent invoice.
Attachments technically: what can be sent along
Attachments are provided for in the XRechnung, and the options are wider than many use:
| Type | Typical content | Note |
|---|---|---|
| Embedded file | take-off sheet as a PDF, photos | increases the file size noticeably |
| Reference to a document | link to a portal | only sensible with permanent availability |
| Additional text entry | explanation of an item | for short notes, not for evidence |
The embedded file is the normal case for evidence. Watch the size: some portals reject invoices above a certain file size. Take-off sheets as a compressed PDF rather than a series of photos keep the invoice manageable.
Payment terms and early-payment discount in practice
One point that works differently with public clients than in B2B: payment terms are as a rule set by contract, and an early-payment discount is unusual. Anyone who states one anyway should know that it is mostly not taken.
More relevant is when the period starts to run at all: as a rule with the receipt of an invoice that is fit for checking. That is exactly why a missing attachment is more expensive than it looks – it delays not only the check but possibly the start of the period.
Practical consequence: better to issue a complete invoice a week later than an incomplete one at once.
Where the German language actually gets in the way
The invoice data is figures and codes; language causes no trouble there. It causes trouble in two places.
First, the tender documents: the Leitweg-ID, the format requirement and the sending route are stated there, in German. Reading them once and recording them in the client’s master data beats reading them again every month.
Second, the rejection reason: the portal’s message arrives in German and technical, often just a rule number. That is why the table on this page carries the field numbers – even if you cannot read the message, you can match the number.
In summary
XRechnungen to authorities rarely fail on the invoice content and almost always on the addressing. Anyone who keeps the Leitweg-ID clean in their master data, settles the format requirement in advance and encloses the evidence has ruled out the three most common causes.
How Levora produces the invoice from the approved items is on the page about XRechnung and ZUGFeRD .
Walk through a rejected invoice
Bring an invoice that has already come back once. Where it jams shows up fastest on that.
Request a demo