E-Rechnung validieren: technische, semantische und fachliche Fehler finden

E-Rechnungsfehler: Was zuerst prüfen?

Das Protokoll organisiert die Bearbeitung; es validiert selbst keine XML-Datei. Ein grüner technischer Bericht ist noch keine sachliche, steuerliche oder zahlungsbezogene Freigabe.

E-Rechnung validieren: Kurzantwort und klare Abgrenzung

Validierung beantwortet mindestens vier Fragen: Kann die Datei technisch gelesen werden? Entspricht sie den semantischen Regeln? Erfüllt sie das konkrete Profil des Empfängers? Ist die Rechnung fachlich richtig? Ein Viewer beantwortet nur die Darstellungsfrage. Auch die Portalannahme ist kein vollständiges Qualitätsurteil, weil Portale oft nur einen Teil der Regeln prüfen.

E-Rechnung lesen erklärt Visualisierung und Feldverständnis. Dieser Owner behandelt die formale und fachliche Prüfkette. Er ersetzt nicht die vorgelagerte inhaltliche Eingangsrechnungsprüfung, sondern verbindet deren Ergebnis mit technischen E-Rechnungsregeln.

Entscheidungsmatrix für E-Rechnung validieren

Format erkennen

Dateiendung, Container und eingebettete Dokumente können irreführend sein. Für den Themenbereich E-Rechnung validieren folgt daraus eine klare Arbeitsentscheidung: Parser und Metadaten bestimmen tatsächliche Syntax, Profil und Version. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen MIME-Typ, XML-Wurzelelement, Profilkennung und PDF-Attachments. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

Fehler oder Warnung

Der Validator meldet unterschiedliche Schweregrade und Regelkennungen. Für den Themenbereich E-Rechnung validieren folgt daraus eine klare Arbeitsentscheidung: Blockierende Fehler stoppen; Warnungen erhalten eine fachliche Bewertung. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Originalmeldung, Regel-ID, Entscheidung und korrigierte Datei. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

Sender- oder Empfängerregel

Neben EN und Formatprofil bestehen portalspezifische Anforderungen. Für den Themenbereich E-Rechnung validieren folgt daraus eine klare Arbeitsentscheidung: Alle für den vereinbarten Kanal geltenden Regelmengen werden geprüft. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Empfängerdokumentation und erfolgreicher Testimport. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

Technisch gültig, fachlich falsch

Die Datei besteht Regeln, weicht aber von Auftrag oder Leistung ab. Für den Themenbereich E-Rechnung validieren folgt daraus eine klare Arbeitsentscheidung: Rechnung wird sachlich beanstandet und nicht allein wegen grünem Bericht freigegeben. Die Entscheidung wird nicht nur im fertigen Dokument sichtbar, sondern bereits am zugrunde liegenden Vorgang festgehalten. Als belastbarer Nachweis dienen Bestellung, Wareneingang, Vertrag und Prüfvermerk. So kann eine zweite Person später erkennen, welche Tatsachen geprüft wurden und weshalb genau dieses Ergebnis freigegeben wurde.

E-Rechnung validieren Schritt für Schritt umsetzen

1. Datei einfrierenBilde einen Hash und arbeite mit einer unveränderten Prüffassung.
2. Container untersuchenExtrahiere bei ZUGFeRD die XML und identifiziere bei XML das Wurzelformat.
3. Schema prüfenTeste XML-Wohlgeformtheit, Datentypen und zulässige Elemente.
4. Geschäftsregeln prüfenFühre EN-, CIUS-, Format- und aktuelle Codelistenregeln aus.
5. Inhalt abgleichenVergleiche Parteien, Leistung, Steuer, Referenzen, IBAN und Zahlbetrag mit Belegen.
6. Ergebnis klassifizierenOrdne Befund, Verantwortlichen, Korrekturweg und Frist zu.
7. Regression testenPrüfe nach Software- oder Regelupdate repräsentative Standard- und Sonderfälle erneut.

Datei einfrieren

Bilde einen Hash und arbeite mit einer unveränderten Prüffassung. Der Schritt ist abgeschlossen, sobald Bericht und später versendete Datei identisch zugeordnet sind. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung validieren ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Jede Korrektur erzeugt eine neue Fassung mit neuem Bericht. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Container untersuchen

Extrahiere bei ZUGFeRD die XML und identifiziere bei XML das Wurzelformat. Der Schritt ist abgeschlossen, sobald Syntax und Profil sicher erkannt wurden. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung validieren ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Unbekannte Attachments werden isoliert und nicht ungeprüft geöffnet. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Schema prüfen

Teste XML-Wohlgeformtheit, Datentypen und zulässige Elemente. Der Schritt ist abgeschlossen, sobald die Datei technisch parsebar ist. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung validieren ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Ein Schemaerfolg wird nicht als EN-Konformität ausgegeben. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Geschäftsregeln prüfen

Führe EN-, CIUS-, Format- und aktuelle Codelistenregeln aus. Der Schritt ist abgeschlossen, sobald Summen, Kardinalitäten, Codes und Abhängigkeiten regelkonform sind. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung validieren ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Validatorartefakte werden mit Version dokumentiert. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Inhalt abgleichen

Vergleiche Parteien, Leistung, Steuer, Referenzen, IBAN und Zahlbetrag mit Belegen. Der Schritt ist abgeschlossen, sobald fachliche und steuerliche Freigabe vorliegt. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung validieren ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Unbekannte Bankänderungen lösen Rückfrage über bekannten Kanal aus. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Ergebnis klassifizieren

Ordne Befund, Verantwortlichen, Korrekturweg und Frist zu. Der Schritt ist abgeschlossen, sobald jeder Fehler geschlossen oder bewusst abgelehnt ist. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung validieren ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Eine Warnung ohne Owner bleibt nicht dauerhaft offen. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Regression testen

Prüfe nach Software- oder Regelupdate repräsentative Standard- und Sonderfälle erneut. Der Schritt ist abgeschlossen, sobald keine bisher funktionierende Belegart unbemerkt scheitert. Das Ergebnis wird mit Datum und verantwortlicher Person am Vorgang dokumentiert. Für E-Rechnung validieren ist diese kleine Kontrolle wichtiger als eine bloße Statusmarkierung, weil sie Eingabe, Entscheidung und Beleg miteinander verbindet. Ein Rollback oder Hotfix ist vor Serienaussendung vorbereitet. In diesem Fall wird nicht improvisiert, sondern die Abweichung mit einer konkreten Rückfrage und einem nächsten Prüftermin weitergegeben.

Praxisbeispiele für E-Rechnung validieren

Gültige XML mit falscher IBAN

Alle EN-Regeln bestehen, die Zahlungsdaten wurden aber kurz vor Versand geändert. Die verantwortliche Person entscheidet deshalb: Das Team verifiziert die Änderung außerhalb der Rechnung beim bekannten Kontakt. Im Ergebnis wird ein möglicher Betrugsfall gestoppt, obwohl der Validator grün war. Das Beispiel zeigt, dass E-Rechnung validieren nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.

XRechnung mit veraltetem Code

Nach einem Codelisten-Update meldet der aktuelle Validator einen bisher erlaubten Wert. Die verantwortliche Person entscheidet deshalb: Der Exporter wird aktualisiert und Regressionstests decken alle Steuerfälle ab. Im Ergebnis entstehen neue Dateien mit aktuellem Code, während alte Belege unverändert archiviert bleiben. Das Beispiel zeigt, dass E-Rechnung validieren nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.

ZUGFeRD-Differenz

PDF zeigt 1.190 Euro, XML aufgrund eines Rundungsfehlers 1.189,99 Euro. Die verantwortliche Person entscheidet deshalb: Beide Repräsentationen werden aus korrigierter Berechnungslogik neu erzeugt. Im Ergebnis stimmen Sicht und Struktur überein und der alte Entwurf wird verworfen. Das Beispiel zeigt, dass E-Rechnung validieren nicht durch eine einzelne Checkbox erledigt ist. Erst das Zusammenspiel aus Ausgangsdaten, dokumentierter Prüfung und kontrolliertem Ergebnis macht den Vorgang für Empfänger, Team und spätere Prüfungen nachvollziehbar.

Typische Fehler bei E-Rechnung validieren

Online-Validator ohne Datenschutzprüfung

Rechnungsdaten können an einen unbekannten Dienst übertragen werden. Die fachliche Korrektur lautet: Vertraulichkeit, Auftragsverarbeitung und Betriebsmodell werden geprüft. Als dauerhafte Kontrolle wird sensible Testdaten oder lokal betriebene Validatoren verwendet. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung validieren erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Nur einen Validator nutzen

Werkzeuge können unterschiedliche Regelstände oder Profile laden. Die fachliche Korrektur lautet: Referenzregeln und Zielsystemtest werden kombiniert. Als dauerhafte Kontrolle wird Version und Prüfumfang im Bericht genannt. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung validieren erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Warnungen pauschal ignorieren

Eine Warnung kann beim konkreten Empfänger trotzdem zur Ablehnung führen. Die fachliche Korrektur lautet: Jede Warnklasse erhält eine dokumentierte Regel. Als dauerhafte Kontrolle wird wiederkehrende Warnungen im Qualitätsreport ausgewertet. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung validieren erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Fehler direkt in XML flicken

Manuelle Änderungen umgehen Quelldaten und können neue Inkonsistenzen erzeugen. Die fachliche Korrektur lautet: Ursache wird im Rechnungssystem korrigiert und neu exportiert. Als dauerhafte Kontrolle wird Dateihash den Bericht an die endgültige Fassung bindet. Dadurch wird der Fehler nicht nur in einem Einzelfall repariert. Der Ablauf rund um E-Rechnung validieren erhält eine Regel, die denselben Fehler bei der nächsten Rechnung, Datei oder Bestandsbewegung früh sichtbar macht.

Freigabe-Checkliste: E-Rechnung validieren

• Rechtsträger und Empfängerrolle eindeutig
• Rechnungs- und Leistungsdatum plausibel
• Bestell-, Vertrags- und Projektreferenzen vorhanden
• Steuerkategorie, Satz und Befreiungsgrund konsistent
• Summen auf Positions-, Steuer- und Dokumentebene stimmig
• Format, Profil und Syntax vom Empfänger akzeptiert
• aktuelle Validierungsartefakte verwendet
• Originaldatei, Prüfbericht und Versandnachweis verbunden

Die Checkliste wird nicht erst am Ende eines Monats abgearbeitet. Sie gehört an den einzelnen Vorgang, solange Rückfragen noch ohne aufwendige Rekonstruktion beantwortet werden können. Pflichtfelder verhindern einfache Lücken; fachliche Ausnahmen brauchen zusätzlich eine kurze Begründung. So bleibt E-Rechnung validieren auch dann kontrollierbar, wenn mehrere Personen Eingang, Prüfung, Freigabe und Versand übernehmen.

Ein Vier-Augen-Prinzip ist besonders bei neuen Geschäftsfällen, geänderten Stammdaten und rechtlich sensiblen Entscheidungen sinnvoll. Wiederkehrende Standardfälle können nach dokumentierter Freigabe stärker automatisiert werden. Die Automatisierung übernimmt jedoch nur die freigegebene Regel. Sie darf eine fehlende Information nicht still durch einen plausibel wirkenden Standardwert ersetzen.

Dokumentation, Verantwortlichkeit und regelmäßige Pflege

Für E-Rechnung validieren werden Eingangsdaten, Entscheidung, Ergebnis und Nachweis als zusammenhängender Vorgang geführt. Eine reine Dateiablage zeigt zwar das Endprodukt, aber nicht zwingend den Entscheidungsweg. Deshalb erhält jede Ausnahme einen Owner, einen Status und einen nächsten Schritt. Änderungen werden ergänzt oder versioniert; sie werden nicht durch stilles Überschreiben unsichtbar gemacht.

Die zugrunde liegende Arbeitsanweisung nennt außerdem ein Prüfdatum. Rechtliche Schwellen, technische Standards, externe Portale und interne Produktfunktionen können sich ändern. Bei der turnusmäßigen Kontrolle werden Primärquelle, tatsächlicher Prozess und veröffentlichte Aussage miteinander verglichen. Ändert sich nur eine Zahl, wird derselbe Intent-Owner aktualisiert; eine neue Jahres-URL ist dafür nicht erforderlich.

Die Erstellung erklären XRechnung erstellen und ZUGFeRD erstellen. Für die menschliche Darstellung folgt E-Rechnung lesen; Eingang und Zuständigkeit behandelt E-Rechnung empfangen.

E-Rechnung validieren und die Produktgrenzen von Invoify

Invoify erzeugt Ausgangsrechnungen als PDF, XRechnung und ZUGFeRD. Strukturierte Exporte werden mit Mustang beziehungsweise den einschlägigen KoSIT-Regeln validiert. Die Belegbox kann manuell hochgeladene XRechnung-XML und ZUGFeRD-Dateien technisch prüfen und ausgewählte Kernwerte ohne OCR oder Sprachmodell auslesen. Ein überwachter Lieferanten-Eingang, eine Peppol-Zustellung, eine automatische fachliche Buchung und eine Zahlungsfreigabe eingehender E-Rechnungen sind dagegen nicht als Produktfunktion belegt.

Eine Funktion wird in diesem Leitfaden nur dann als Invoify-Funktion bezeichnet, wenn sie in der aktuellen Produktdokumentation belegt ist. Steuerliche Würdigung, rechtliche Einzelfallprüfung und externe Behördenverfahren bleiben bei den verantwortlichen Personen beziehungsweise deren Beratung. Diese Trennung verhindert, dass ein formal erzeugter Beleg mit einer fachlich freigegebenen Entscheidung verwechselt wird.

Offizielle Quellen und Prüfstand

Maßgeblich sind § 14 UStG, die BMF-FAQ zur E-Rechnung mit Stand März 2026 und das aktualisierte BMF-Schreiben zur obligatorischen E-Rechnung. Technische Referenzen liefern KoSIT/XStandards Einkauf, FeRD zu ZUGFeRD und die EU-Kommission zu EN 16931. Stand der Prüfung: 5. August 2026. Technische Regelstände und neue Format-Releases werden spätestens im Januar 2027 erneut geprüft.

Validierung vor dem Übertragungsweg

Eine technisch gültige XML-Datei ist Voraussetzung, aber kein Versandnachweis. Wenn ein Empfänger Peppol verlangt, kommen Teilnehmeridentifikation, Access Point, Routing und Empfangsbestätigung als eigener Prozess hinzu.

E-Rechnung validieren: technisches Ergebnis und Rechnungsprüfung getrennt bewerten

Das Bundesfinanzministerium bezeichnet Validierung als sinnvoll, aber nicht als unmittelbare Voraussetzung für die steuerliche Anerkennung. Das aktualisierte BMF-Schreiben vom 15. Oktober 2025 ergänzt: Unter Beachtung kaufmännischer Sorgfalt kann sich ein Unternehmer auf das technische Ergebnis einer geeigneten Anwendung zu Format und Geschäftsregeln stützen; zum Nachweis bietet sich die Aufbewahrung des Berichts an. Ein falscher Steuersatz kann trotzdem unentdeckt bleiben.

KoSIT beschreibt für XRechnung eine technisch dreistufige Validierung aus Syntaxschema, EN-16931-Regeln und XRechnung-Regeln. Auf der offiziellen Seite XStandards Einkauf werden Validator, Konfiguration, Schematron, Testsuite und Visualisierung getrennt bereitgestellt. Ein Team dokumentiert deshalb nicht nur den Produktnamen eines Validators, sondern auch Konfiguration, Release und Syntax.

Beispiel für einen nachvollziehbaren Validierungsbericht

Ein Bericht muss sich auf exakt die Datei beziehen, die versendet, empfangen oder archiviert wird. Das folgende Beispiel ist ein redaktionelles Muster. Der SHA-256-Wert ist gekürzt dargestellt; im echten Nachweis wird der vollständige Hash gespeichert.

1. Prüffassung hashenHash vor dem ersten Validatorlauf bilden und Datei während der Prüfung nicht bearbeiten.
2. Regelstand erfassenSyntax, Profil, Validator und Konfigurationsrelease protokollieren.
3. Befunde schließenFehler in der Quelle korrigieren, neu exportieren und eine neue Dateifassung mit neuem Hash prüfen.
4. Warnungen entscheidenRegel-ID, Empfängerwirkung, verantwortliche Person und Entscheidung dokumentieren.
5. Fachprüfung verknüpfenAuftrag, Leistung, Steuerentscheidung und Zahlungsdaten außerhalb des Validators freigeben.
6. Finale Fassung bindenNur den Bericht der tatsächlich versendeten beziehungsweise empfangenen Datei als final kennzeichnen.

Welche E-Rechnungen Invoify validiert

Bei eigenen Ausgangsrechnungen erzeugt Invoify XRechnung beziehungsweise ZUGFeRD und validiert die produktseitig unterstützte Ausgabe vor dem Einfrieren. Formatfehler und Pflichtfeldlücken führen nicht zu einer pauschalen Rechtssicherheitszusage; die steuerliche und sachliche Freigabe bleibt beim Unternehmen.

Bei einem manuellen Upload in die Belegbox werden standalone XML-Dateien beziehungsweise das vollständige ZUGFeRD-PDF technisch geprüft. Erst nach erfolgreicher Prüfung wird der Beleg als strukturierte E-Rechnung markiert und werden ausgewählte Kernwerte ohne OCR oder Sprachmodell ausgelesen. Dieser Prüfpfad ist keine automatische Lieferantenbuchung, keine Vorsteuerentscheidung und keine Zahlungsfreigabe. Ein überwachtes Rechnungspostfach oder ein Peppol-Empfangskanal ist nicht enthalten. Quellen- und Produktcheck: 5. August 2026; nächste turnusmäßige Prüfung: Januar 2027.

BR-CO-10: Positionssumme mit einem Zahlenbeispiel prüfen

Die Regel BR-CO-10 vergleicht die Summe der Nettobeträge der Rechnungspositionen mit der dafür vorgesehenen Dokumentensumme BT-106. Jede Position liefert ihren Nettobetrag BT-131. Für zwei einfache Positionen mit 100,00 und 50,00 Euro ergibt sich 150,00 Euro. Stehen im Summenfeld 149,99 Euro, stimmt diese Summe nicht. Die Lösung ist nicht, eine willkürliche Rundungsposition hinzuzufügen: Prüfen Sie zuerst, wo der falsche Wert berechnet wurde, korrigieren Sie die Quelle und exportieren Sie erneut.

Dokumentnachlässe und Zuschläge sind nicht einfach zusätzliche Positionsnettobeträge. Sie wirken in weiteren Summenregeln. Deshalb darf der Gesamtzahlbetrag nicht ungeprüft als BT-106 übernommen werden. Die offizielle OpenPeppol-Regel BR-CO-10 dokumentiert den Zusammenhang und den UBL-Prüfausdruck. Das kleine Beispiel erklärt genau diese Regel; es ist keine vollständige validierte XRechnung oder ZUGFeRD-Datei.

Rundungsfehler: Nicht jeden Cent an derselben Stelle korrigieren

Bei mehreren Steuergruppen werden Nettobasis und Steuerbetrag je Gruppe geprüft. Ein Unterschied kann bereits aus der Positionsberechnung, einem Nachlass oder der Aggregation stammen. Lesen Sie deshalb die gemeldete Regel-ID und den betroffenen Pfad. Vergleichen Sie gespeicherte Dezimalwerte mit den tatsächlich exportierten Zahlen; ein auf zwei Nachkommastellen angezeigter Preis beweist nicht, dass die Quelle dieselben Werte verwendet. Eine Korrektur darf keine andere Summenregel beschädigen. Nach jeder Änderung wird die ganze finale Datei mit dem vorgesehenen Regelstand erneut geprüft.

BT-10: Käuferreferenz ist im B2B-Fall keine Pflicht zur Leitweg-ID

Bei XRechnung gehört eine Käuferreferenz in BT-10. Für einen Geschäftskunden kann das eine von ihm vereinbarte Zuordnung sein. Eine Leitweg-ID ist dafür im B2B-Bereich nicht erforderlich. Behörden verwenden sie im B2G-Kontext; fragen Sie dort Format, Portal und Referenz vor dem Export ab. Eine zufällige Zeichenfolge mag eine einfache Feldprüfung bestehen, löst aber nicht die Zuordnung beim Empfänger. Diese Abgrenzung erläutert die offizielle FAQ von XStandards Einkauf. Die konkrete Formatstruktur behandelt XRechnung erstellen.

1. Original behaltenDatei, Profil, Regelstand und vollständige Fehlermeldung sichern.
2. Quelle korrigierenDie Ursache im Rechnungsentwurf oder Export abstellen; eine fertige Datei nicht still austauschen.
3. Neu prüfenDen neuen Export vollständig validieren und mit dessen eigenem Bericht verbinden.
4. Inhalt freigebenAuftrag, Leistung, Steuerfall und Bankdaten weiterhin gesondert prüfen.

Invoify validiert unterstützte strukturierte Ausgangsexporte und technisch die manuell in die Belegbox hochgeladenen E-Rechnungen. Der Blog enthält keinen öffentlichen Datei-Upload-Validator. Technische Prüfung ersetzt keine sachliche Prüfung oder Zahlungsfreigabe. Für das Format mit eingebettetem XML führt ZUGFeRD-Rechnung erstellen weiter. Praxisbeispiele und die hier verlinkten Primärquellen geprüft am 2. Oktober 2026. Nächste Prüfung: April 2027; früher bei Rechts-, Format- oder Produktänderungen.