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:

PartLengthContent
Coarse addressing2 – 12 digitsfederal government often 991, municipalities the official municipality key
Fine addressingoptional, up to 30 charactersalphanumeric, internal routing at the recipient
Check digits2 digitscalculated 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

CauseHow you noticeRemedy
Leitweg-ID wrong or missingportal rejects immediatelyverify the check digits, request the ID from the authority
Wrong format suppliedthe authority wants XRechnung, you send a PDFsettle the client’s requirement beforehand
Mandatory field emptyvalidation error with a cryptic numberhave it checked against the EN 16931 rules
No reference to the jobthe case handler queries itsupply the call-off or order number
Supporting documents missingpayment is delayedattach 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:

XRechnungZUGFeRD
Structurepure XML filePDF with embedded XML
Human-readablenoyes, as a PDF
Typical withpublic clientsB2B

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 turnoverObligation to send from
over €800,00001.01.2027
up to €800,00001.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:

StageWho checksFeedback
Deliveryportal, automaticimmediately, technical message
Formal checkportal / validationusually within minutes, rule numbers
Content checkcase handlerdays to weeks, by mail or phone
Substantive checkthe authority’s site managementcan 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:

  1. Portal upload. You upload the XML file in the state’s invoice portal. Widespread, works, costs a few clicks per invoice.
  2. Email to an intake address. Some clients accept the XRechnung as an attachment. Convenient, but not permitted everywhere.
  3. 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:

TypeTypical contentNote
Embedded filetake-off sheet as a PDF, photosincreases the file size noticeably
Reference to a documentlink to a portalonly sensible with permanent availability
Additional text entryexplanation of an itemfor 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 .