XRechnung-Validator (Struktur-Check)

XRechnung-/UBL-/CII-XML auf well-formed und EN16931-Pflichtfelder prüfen.

Ergebnis & Vorlagen per Mail (optional)

Schick dir das Ergebnis als Mail, dazu unseren Event-Spickzettel — und teste Univents 7 Tage kostenlos.

Kein Spam. Jederzeit abmeldbar. Datenschutz

Wenn die Rechnung zurückkommt, bevor das Geld fließt

Du hast geliefert, das Event lief, die Leistung steht. Du stellst die Rechnung an eine Behörde, ein städtisches Amt oder einen anderen öffentlichen Auftraggeber. Und dann passiert das, was bei E-Rechnungen häufiger vorkommt, als man denkt: Die Rechnung wird automatisch abgewiesen. Kein Mensch hat sie angesehen, ein System hat sie geprüft und für ungültig erklärt. Ein fehlendes Pflichtfeld, eine falsch gesetzte Leitweg-ID, ein Steuerschlüssel, der nicht zur Norm passt – und die Eingangsverarbeitung stoppt.

Das Ergebnis ist kein freundlicher Anruf, sondern Stillstand. Die Rechnung gilt als nicht eingegangen, die Zahlungsfrist beginnt nicht zu laufen, und du klärst per Mail oder Telefon, was eigentlich schiefgelaufen ist. Bei knappen Margen im Catering- und Eventgeschäft ist verzögerter Zahlungseingang kein kosmetisches Problem, sondern ein Liquiditätsproblem.

Genau hier setzt ein XRechnung-Validator an: Du lädst deine fertige XML-Rechnung hoch, das Tool prüft sie gegen den Standard EN 16931 – bevor du sie an den Empfänger schickst. Du siehst Fehler, solange du sie noch korrigieren kannst, statt sie aus einer Ablehnungsmeldung zu rekonstruieren.

Was die XRechnung eigentlich ist

Die XRechnung ist ein rein strukturiertes XML-Format für elektronische Rechnungen. Das ist der entscheidende Unterschied zu allem, was du vielleicht bisher verschickt hast.

  • Ein PDF ist ein Bild einer Rechnung. Ein Mensch kann es lesen, eine Software muss es mühsam interpretieren oder per OCR auslesen.
  • Eine XRechnung ist maschinenlesbar. Jeder Wert – Rechnungsnummer, Nettobetrag, Steuersatz, Empfänger – steht in einem klar definierten Datenfeld. Ein System kann sie ohne Interpretation einlesen, prüfen und weiterverarbeiten.

Die XRechnung folgt der europäischen Norm EN 16931. Diese Norm legt fest, welche Felder eine elektronische Rechnung enthalten muss und wie sie strukturiert sind. Damit ist eine korrekte XRechnung nicht nur eine Datei, die zufällig öffnet, sondern eine Datei, die einem präzisen, EU-weit abgestimmten Datenmodell entspricht.

Für dich heißt das in der Praxis: Eine XRechnung ist nicht "ein hübscheres PDF", sondern eine Datenstruktur mit Regeln. Und Regeln kann man verletzen – deshalb braucht es eine Prüfung.

Wer die XRechnung braucht – und ab wann

Hier lohnt sich eine saubere Trennung zwischen zwei Welten: Rechnungen an die öffentliche Hand und Rechnungen zwischen Unternehmen.

B2G – Rechnungen an öffentliche Auftraggeber

Wenn du an öffentliche Auftraggeber fakturierst – also Behörden, Ämter, öffentliche Einrichtungen –, ist die elektronische Rechnung bundesweit seit 2020 Pflicht. Das ist der Bereich, der Caterer und Eventdienstleister oft als Erstes trifft: das Catering für eine städtische Veranstaltung, das Buffet für eine Behördenfeier, die Eventbetreuung eines öffentlichen Trägers.

In diesem B2G-Bereich (Business-to-Government) reicht eine PDF-Rechnung in der Regel nicht mehr. Erwartet wird ein strukturiertes Format wie die XRechnung.

B2B – Rechnungen zwischen Unternehmen

Im B2B-Bereich (Geschäft zwischen Unternehmen) wird es gestaffelt eingeführt:

  • Empfangen und verarbeiten: Inländische Unternehmen müssen seit dem 1. Januar 2025 in der Lage sein, E-Rechnungen zu empfangen und zu verarbeiten. Das gilt unabhängig davon, ob du selbst schon elektronisch ausstellst – wenn dein Geschäftspartner dir eine E-Rechnung schickt, musst du sie annehmen und verarbeiten können.
  • Ausstellen: Die Ausstellungspflicht ist gestaffelt mit Übergangsfristen bis Ende 2026/2027, abhängig vom Vorjahresumsatz des ausstellenden Unternehmens.

Was du daraus mitnimmst: Die Fähigkeit, E-Rechnungen zu empfangen, ist im B2B bereits Gegenwart. Die Pflicht, sie selbst zu erzeugen, kommt für viele Betriebe in den kommenden Jahren – früher oder später, je nach Umsatz. Es ist also keine Frage, ob du dich damit beschäftigst, sondern wann.

Hinweis: Dieser Text ersetzt keine Rechts- oder Steuerberatung. Welche Frist konkret für deinen Betrieb gilt, klärst du mit deiner Steuerberatung.

Was der Validator prüft

Ein XRechnung-Validator macht genau eine Sache gründlich: Er prüft deine hochgeladene XML-Rechnung gegen den Standard. Drei Prüfebenen sind dabei relevant:

  1. Pflichtfelder. Sind alle nach EN 16931 erforderlichen Felder vorhanden und befüllt? Eine Rechnung ohne Rechnungsnummer, ohne korrekte Empfängerangabe oder ohne Steuerinformationen ist unvollständig – und wird abgelehnt.
  2. XML-Struktur und Schema. Ist die Datei technisch korrekt aufgebaut? Stimmen die XML-Elemente, sind sie richtig verschachtelt, entspricht das Dokument dem erwarteten Schema? Ein einziges falsch platziertes Element kann die ganze Datei unbrauchbar machen.
  3. EN-16931-Geschäftsregeln. Sind die fachlichen Regeln eingehalten? Hier geht es nicht nur um "Feld vorhanden", sondern um Logik: Passen Steuerbeträge zu Steuersätzen, sind Summen konsistent, ergeben die Angaben zusammen ein gültiges Dokument?

Der Validator gibt dir damit ein klares Ja/Nein mit Begründung, bevor der Empfänger dieselbe Prüfung durchführt – nur dass beim Empfänger ein "Nein" eine Ablehnung bedeutet, bei dir ein behebbarer Hinweis.

XRechnung vs. ZUGFeRD

Du wirst bei E-Rechnungen zwangsläufig auf einen zweiten Namen stoßen: ZUGFeRD. Beide sind keine Konkurrenten im Sinne von "gut gegen schlecht", sondern zwei Formate für unterschiedliche Vorlieben – und beide erfüllen dieselbe Norm.

  • XRechnung: rein XML. Eine reine Datenstruktur, ausschließlich für Maschinen gedacht. Kein menschenlesbares Bild eingebaut.
  • ZUGFeRD: ein hybrides Format – ein PDF mit eingebettetem XML. Du siehst ein normales, menschenlesbares PDF und in der Datei steckt zusätzlich der strukturierte XML-Datensatz.

Der gemeinsame Nenner: Beide erfüllen die EN 16931. Inhaltlich folgen sie demselben Datenmodell. Der Unterschied liegt in der Verpackung – XRechnung ist die "nackte" Datenstruktur, ZUGFeRD legt ein lesbares PDF darüber.

Für die Praxis heißt das: Verlangt ein Empfänger explizit eine XRechnung, hilft dir ein PDF-mit-XML nicht automatisch weiter, wenn das Gegenüber das reine XML-Format erwartet. Welches Format dein Auftraggeber akzeptiert, fragst du im Zweifel vorher ab – das erspart dir die Ablehnung im Nachhinein.

Typische Fehler, die zur Ablehnung führen

Die meisten abgelehnten E-Rechnungen scheitern nicht an exotischen Sonderfällen, sondern an einer Handvoll wiederkehrender Fehler.

  • Fehlende oder falsche Leitweg-ID. Die Leitweg-ID adressiert den öffentlichen Empfänger und ist damit ein zentraler Bestandteil im B2G-Bereich. Fehlt sie oder ist sie fehlerhaft, weiß das Empfangssystem nicht, an welche Stelle die Rechnung gehen soll – und weist sie ab. Wichtig: Die Leitweg-ID ist eine B2G-Sache. In einer reinen B2B-Rechnung erwartet niemand eine Leitweg-ID.
  • Falsche oder unpassende Steuerschlüssel. Wenn Steuersatz, Steuerkategorie und ausgewiesener Betrag nicht zueinander passen, schlagen die Geschäftsregeln an. Ein klassischer Stolperstein ist ein Steuerschlüssel, der nicht zur tatsächlich angewandten Steuerlogik passt.
  • Unvollständige Pflichtfelder. Fehlende Rechnungsnummer, fehlendes Rechnungsdatum, fehlende oder unvollständige Empfänger- bzw. Absenderangaben – Lücken in den Pflichtfeldern sind ein häufiger Ablehnungsgrund.
  • Strukturfehler im XML. Falsch verschachtelte Elemente, fehlende Pflicht-Knoten oder ein Dokument, das das Schema verletzt. Solche Fehler entstehen oft beim manuellen Basteln an der XML oder bei fehlerhaftem Export aus einem Tool.
  • Inkonsistente Summen. Wenn Einzelpositionen, Zwischensummen und Gesamtbetrag nicht sauber zusammenpassen, ist das ein Verstoß gegen die Geschäftsregeln – nicht nur ein Schönheitsfehler.

Der Punkt bei all diesen Fehlern: Sie sind vorab erkennbar. Genau dafür ist die Validierung da.

Archivierung und das Original

Ein verbreitetes Missverständnis: "Ich drucke die Rechnung aus oder speichere ein PDF, dann habe ich sie archiviert." Bei der E-Rechnung ist das nicht der Kern der Sache.

Das aufzubewahrende Original ist die XML-Datei selbst. Nicht ein nachträglich erzeugtes PDF, nicht ein Ausdruck, sondern der strukturierte Datensatz, den du verschickt oder empfangen hast. Die Aufbewahrung von Rechnungen erfolgt GoBD-konform, und die Aufbewahrungsfristen richten sich nach der Abgabenordnung (AO).

Praktisch bedeutet das:

  • Bewahre die originale XML-Datei auf, nicht nur eine Lese-Ansicht davon.
  • Achte darauf, dass die Datei unverändert und nachvollziehbar abgelegt ist (das ist der GoBD-Gedanke).
  • Verlasse dich nicht darauf, dass ein PDF-Export "auch reicht" – das Original ist und bleibt das XML.

Auch hier gilt: Wie du konkret archivieren musst und welche Fristen für dich gelten, ist eine Frage an deine Steuerberatung. Dieser Text liefert Orientierung, keine verbindliche Rechtsauskunft.

Die Grenzen des Validators

Damit du das Tool richtig einordnest – ein Validator ist ein Format-Check, kein Alleskönner. Es ist fair, klar zu sagen, was er nicht tut:

  • Er prüft deine XML-Rechnung gegen die Norm – er ist kein Archiv. Er bewahrt deine Rechnungen nicht GoBD-konform auf; dafür musst du weiterhin selbst sorgen.
  • Er prüft Format, Struktur und Geschäftsregeln – er beurteilt nicht inhaltlich, ob deine Leistung korrekt abgerechnet wurde. Ob der Preis stimmt, ob du den richtigen Posten in Rechnung gestellt hast, ob die Mengen passen – das bleibt deine Verantwortung.
  • Er ist keine Rechts- oder Steuerberatung. Ein bestandener Format-Check sagt aus, dass die Datei der Norm entspricht – nicht, dass deine Rechnung steuerlich oder rechtlich in jeder Hinsicht einwandfrei ist.

Diese Grenzen sind kein Mangel, sondern der Sinn der Sache: Ein Werkzeug, das genau eine Aufgabe sauber erledigt, ist zuverlässiger als eines, das alles verspricht.

Praktische Tipps

Ein paar Gewohnheiten, die dir Ablehnungen ersparen:

  • Validiere vor dem Versand, nicht danach. Das ist die einfachste Regel und die wirkungsvollste. Eine vorab geprüfte Rechnung kommt durch; eine ungeprüfte ist ein Glücksspiel.
  • Kläre das Format vorab. Frag deinen Auftraggeber, ob XRechnung oder ZUGFeRD erwartet wird – und im B2G, welche Leitweg-ID du verwenden sollst.
  • Behandle die Leitweg-ID als B2G-Pflichtangabe. Im B2B brauchst du sie nicht; im B2G ist sie der Adressschlüssel. Verwechsle die beiden Welten nicht.
  • Achte auf saubere Steuerschlüssel. Steuersatz, Steuerkategorie und Beträge müssen zusammenpassen. Das ist einer der häufigsten Stolpersteine.
  • Bewahre das XML-Original auf. Nicht den Ausdruck, nicht das exportierte PDF – die originale Datei.
  • Mach die Validierung zur Routine. Wenn jede ausgehende E-Rechnung einmal durch den Check läuft, fängst du Fehler systematisch ab, statt sie einzeln zu reparieren.

E-Rechnung ist am Ende ein Datenthema. Wenn die Daten stimmen, läuft der Rest fast von selbst – und genau dabei hilft eine Validierung vor dem Versand.

Wenn du Events und Catering ohnehin in einer Software planst, kalkulierst und abrechnest, ist es naheliegend, die Rechnungsstellung gleich dort sauber aufzusetzen – Univents bündelt Eventplanung und Fakturierung an einem Ort.

Schluss mit Eventplanung in Excel

Univents bündelt Angebote, Personal, Küche und Finanzen für dein Event an einem Ort. Kostenlos starten, in Minuten loslegen.

Univents jetzt starten

Häufige Fragen

Was ist eine XRechnung und wer braucht sie?
Ein strukturiertes XML-Rechnungsformat nach EN 16931. Für Rechnungen an öffentliche Auftraggeber in Deutschland Pflicht; seit 2025 müssen Unternehmen E-Rechnungen zudem empfangen können.
Was prüft der Validator?
Ob deine Datei dem XRechnung-/EN-16931-Schema entspricht: Pflichtfelder, Formatregeln und Struktur. Du siehst Fehler, bevor die Rechnung an die Behörde geht.
Werden meine Rechnungsdaten gespeichert?
Die Prüfung dient dem schnellen Format-Check. Für die rechtssichere Archivierung nutzt du dein Rechnungssystem, nicht den Validator.