XRechnung Validator (structure check)

When the invoice bounces back before the money comes in

You delivered. The event went off, the catering landed, the work is done. You send your invoice to a public authority, a municipal office, or another public-sector client. And then the thing that happens far more often with e-invoices than people expect: the invoice is rejected automatically. No human ever looked at it. A system checked it, declared it invalid, and stopped processing. A missing mandatory field, a wrong routing ID, a tax code that doesn't match the standard – and intake grinds to a halt.

The result isn't a friendly phone call. It's a standstill. The invoice counts as never received, the payment clock never starts, and you're left clarifying by email or phone what actually went wrong. With the thin margins typical of catering and event work, delayed payment isn't a cosmetic annoyance – it's a cash-flow problem.

That's exactly where an XRechnung validator comes in: you upload your finished XML invoice, the tool checks it against the EN 16931 standard – before you send it to the recipient. You see the errors while you can still fix them, instead of reconstructing them from a rejection notice.

What the XRechnung actually is

The XRechnung is a purely structured XML format for electronic invoices. That's the decisive difference from whatever you may have been sending until now.

• A PDF is a picture of an invoice. A human can read it; software has to interpret it laboriously or extract it via OCR.
• An XRechnung is machine-readable. Every value – invoice number, net amount, tax rate, recipient – sits in a clearly defined data field. A system can read it in, validate it, and process it further without any interpretation.

The XRechnung follows the European standard EN 16931. This standard defines which fields an electronic invoice must contain and how they're structured. So a correct XRechnung isn't just a file that happens to open – it's a file that matches a precise, EU-wide data model.

In practice, this means an XRechnung is not "a prettier PDF" but a data structure with rules. And rules can be broken – which is precisely why validation exists.

Who needs the XRechnung – and from when

It pays to keep two worlds clearly apart here: invoices to the public sector, and invoices between businesses.

B2G – invoices to public-sector clients

If you invoice public-sector clients – authorities, government offices, public institutions – the electronic invoice has been mandatory nationwide since 2020. This is the area that often hits caterers and event providers first: catering for a municipal event, the buffet for a public office's celebration, event support for a public body.

In this B2G area (business-to-government), a PDF invoice generally won't cut it anymore. A structured format like the XRechnung is expected.

B2B – invoices between businesses

In the B2B area (business-to-business), the rollout is staggered:

• Receiving and processing: Domestic companies have been required since 1 January 2025 to be able to receive and process e-invoices. This applies regardless of whether you yourself already issue electronically – if your business partner sends you an e-invoice, you must be able to accept and process it.
• Issuing: The obligation to issue is staggered, with transition periods running until the end of 2026/2027, depending on the prior-year turnover of the issuing company.

The takeaway: the ability to receive e-invoices is already the present in B2B. The obligation to create them yourself is coming for many businesses over the next few years – sooner or later, depending on turnover. So it's not a question of whether you'll deal with this, but when.

Note: this text is not a substitute for legal or tax advice. Which deadline applies specifically to your business is something to clarify with your tax advisor.

What the validator checks

An XRechnung validator does one thing thoroughly: it checks your uploaded XML invoice against the standard. Three levels of checking matter here:

1. Mandatory fields. Are all fields required by EN 16931 present and filled in? An invoice without an invoice number, without correct recipient details, or without tax information is incomplete – and gets rejected.
2. XML structure and schema. Is the file technically well-formed? Are the XML elements correct, properly nested, and does the document match the expected schema? A single misplaced element can render the whole file unusable.
3. EN 16931 business rules. Are the substantive rules satisfied? This isn't just "field present" – it's logic: do tax amounts match tax rates, are the totals consistent, do the details together form a valid document?

The validator thus gives you a clear yes/no with a reason, before the recipient runs the same check – except that on the recipient's side, a "no" means rejection, while on yours it's a fixable hint.

XRechnung vs. ZUGFeRD

With e-invoicing you'll inevitably run into a second name: ZUGFeRD. The two aren't rivals in a "good vs. bad" sense – they're two formats for different preferences, and both satisfy the same standard.

• XRechnung: purely XML. A pure data structure, designed exclusively for machines. No human-readable image built in.
• ZUGFeRD: a hybrid format – a PDF with embedded XML. You see a normal, human-readable PDF, and inside the file the structured XML data set is included as well.

The common denominator: both satisfy EN 16931. In terms of content they follow the same data model. The difference is the packaging – XRechnung is the "bare" data structure, while ZUGFeRD layers a readable PDF on top.

In practice this means: if a recipient explicitly requires an XRechnung, a PDF-with-XML won't automatically help if the other side expects the pure XML format. Which format your client accepts is worth asking up front, when in doubt – it spares you a rejection after the fact.

Common errors that lead to rejection

Most rejected e-invoices fail not on exotic edge cases but on a handful of recurring errors.

• Missing or wrong routing ID (Leitweg-ID). The Leitweg-ID addresses the public-sector recipient and is therefore a core component in the B2G area. If it's missing or incorrect, the receiving system doesn't know where the invoice should go – and rejects it. Important: the Leitweg-ID is a B2G matter. In a pure B2B invoice, no one expects a Leitweg-ID.
• Wrong or mismatched tax codes. When the tax rate, tax category, and stated amount don't line up, the business rules trip. A classic stumbling block is a tax code that doesn't match the tax logic actually applied.
• Incomplete mandatory fields. A missing invoice number, missing invoice date, missing or incomplete recipient or sender details – gaps in the mandatory fields are a frequent reason for rejection.
• Structural errors in the XML. Incorrectly nested elements, missing mandatory nodes, or a document that violates the schema. Such errors often arise from manually tinkering with the XML or from a faulty export out of a tool.
• Inconsistent totals. When line items, subtotals, and the grand total don't add up cleanly, that's a violation of the business rules – not just a blemish.

The point about all these errors: they're detectable in advance. That's exactly what validation is for.

Archiving and the original

A widespread misconception: "I print the invoice or save a PDF, then I've archived it." With the e-invoice, that misses the core point.

The original you have to retain is the XML file itself. Not a PDF created after the fact, not a printout, but the structured data set you sent or received. Invoices are retained in a GoBD-compliant way, and the retention periods follow the German Fiscal Code (Abgabenordnung, AO).

In practice this means:

• Keep the original XML file, not just a reading view of it.
• Make sure the file is stored unchanged and in a traceable way (that's the GoBD idea).
• Don't rely on a PDF export "being enough too" – the original is and remains the XML.

Here too: how exactly you have to archive and which periods apply to you is a question for your tax advisor. This text offers orientation, not binding legal information.

The limits of the validator

So you place the tool correctly – a validator is a format check, not a do-everything. It's fair to be clear about what it does not do:

• It checks your XML invoice against the standard – it is not an archive. It does not store your invoices in a GoBD-compliant way; you still have to take care of that yourself.
• It checks format, structure, and business rules – it does not judge on the merits whether your service was billed correctly. Whether the price is right, whether you charged the correct item, whether the quantities fit – that remains your responsibility.
• It is not legal or tax advice. A passed format check tells you the file conforms to the standard – not that your invoice is flawless in every fiscal or legal respect.

These limits aren't a shortcoming; they're the whole idea. A tool that does exactly one job cleanly is more reliable than one that promises everything.

Practical tips

A few habits that will save you rejections:

• Validate before sending, not after. It's the simplest rule and the most effective. A pre-checked invoice goes through; an unchecked one is a gamble.
• Clarify the format up front. Ask your client whether an XRechnung or ZUGFeRD is expected – and in B2G, which Leitweg-ID you should use.
• Treat the Leitweg-ID as a B2G mandatory detail. In B2B you don't need it; in B2G it's the address key. Don't mix up the two worlds.
• Watch your tax codes. Tax rate, tax category, and amounts have to match. This is one of the most common stumbling blocks.
• Keep the XML original. Not the printout, not the exported PDF – the original file.
• Make validation a routine. If every outgoing e-invoice runs through the check once, you catch errors systematically instead of repairing them one by one.

In the end, the e-invoice is a data topic. When the data is right, the rest almost takes care of itself – and that's exactly where validating before sending helps.

If you're already planning, costing, and invoicing your events and catering in one piece of software, it makes sense to set up invoicing cleanly right there – Univents brings event planning and invoicing together in one place.