XRechnung öffnen und ZUGFeRD lesen: vom Beleg zur geprüften Rechnung

Sie erhalten eine Rechnung per E-Mail, klicken auf den Anhang und sehen eine Folge technischer Feldnamen. Bei einer XRechnung ist das zunächst kein Fehler. Sie enthält strukturierte Rechnungsdaten in XML. Eine Anwendung kann daraus eine übersichtliche Ansicht mit Lieferant, Rechnungsnummer, Positionen und Summen erzeugen. Das bloße Öffnen in einem Texteditor ist für die tägliche Rechnungsprüfung meist unpraktisch.

ZUGFeRD verbindet dagegen eine PDF-Darstellung mit eingebetteten XML-Rechnungsdaten. Ein gewöhnlicher PDF-Reader zeigt vor allem die sichtbare Seite. Daraus lässt sich noch nicht erkennen, ob der eingebettete Datensatz vollständig und fachlich stimmig ist. Auch nicht jede PDF ist automatisch eine ZUGFeRD-Rechnung. Klären Sie daher zuerst das tatsächliche Format, bevor Sie einen vermeintlichen Anzeigefehler melden.

Speichern Sie den empfangenen Anhang zunächst unverändert. Wählen Sie dann in Ihrer Rechnungsanwendung den Import oder die Anzeige strukturierter Rechnungen und öffnen Sie diese Datei. Wenn Sie nur Rohtext sehen, verwenden Sie vermutlich eine XML-Textansicht statt einer Rechnungsvisualisierung. Eine Umbenennung von .xml in .pdf ändert das Format nicht.

Für einzelne Dateien bietet die Finanzverwaltung den ELSTER-E-Rechnungsviewer an. Öffnen Sie die unten verlinkte Seite „E-Rechnung ansehen“ und wählen Sie Ihre Rechnungsdatei über das Auswahlfeld aus. Der Dienst stellt die Rechnung lesbar dar; die Finanzverwaltung bezeichnet ihn als unverbindlichen Service. Die Anzeige ist keine steuerliche Freigabe.

KoSIT stellt mit der XRechnung-Visualisierung technische Bausteine für eine HTML- oder PDF-Darstellung bereit. Das ist vor allem eine Referenz für Software und IT-Verantwortliche. Für den Büroalltag zählt, ob Ihre Anwendung die tatsächlich eingehende Syntax und Version unterstützt und alle benötigten Felder verständlich anzeigt.

Ein Viewer beantwortet: Was steht in der Datei? Ein Validator beantwortet: Entspricht der Datensatz den geprüften technischen Regeln? Dazu gehören beispielsweise vorgegebene Datenstrukturen, Pflichtfelder und rechnerische Beziehungen. Die KoSIT-Werkzeuge trennen den Validator von der XRechnung-Prüfkonfiguration. Eine beliebige XML-Prüfung ohne passende Regeln ist deshalb keine vollständige XRechnung-Prüfung.

Dokumentieren Sie bei einem Fehler die verwendete Konfiguration, die betroffene Datei und den Prüfbericht. Lesen Sie den einzelnen Hinweis: Fehlt eine Angabe, stimmen Summen nicht zusammen oder unterstützt die Anwendung das Format nicht? Fordern Sie gegebenenfalls eine korrigierte Rechnung beim Aussteller an. Verändern Sie nicht unbemerkt die empfangenen Daten, nur damit eine Prüfung grün wird.

Das BMF beschreibt die Validierung als sinnvolle Unterstützung; sie ist keine unmittelbare Voraussetzung für die steuerliche Anerkennung. Ein technischer Prüfstatus allein entscheidet also weder über den Vorsteuerabzug noch über die sachliche Berechtigung einer Zahlung.

Angenommen, die PDF-Ansicht zeigt 1.190 Euro, die übernommenen Daten ergeben aber einen anderen Zahlbetrag. Geben Sie die Rechnung dann nicht allein aufgrund der vertrauten PDF-Ansicht frei. Vergleichen Sie Positionen, Nachlässe, Steuerbeträge und bereits berücksichtigte Zahlungen. Halten Sie fest, ob ein Darstellungsproblem, eine falsche Übernahme oder ein Widerspruch in der gelieferten Datei vorliegt.

Die steuerlichen Pflichtangaben müssen bei einer E-Rechnung im strukturierten Teil enthalten sein. Ein Verweis auf eine ergänzende PDF ersetzt diese Angaben nicht pauschal. Bei widersprüchlichen Inhalten sollte der Aussteller eine nachvollziehbare Klärung oder Berichtigung liefern. Eine neue Rechnungsversion gehört mit ihrem Bezug zum ursprünglichen Eingang in den Vorgang.

Eine formal plausible Rechnung kann eine nicht bestellte Leistung, eine falsche Menge oder geänderte Bankdaten enthalten. Prüfen Sie deshalb Bestellung, Lieferung beziehungsweise Leistung, vereinbarten Preis und Zahlungsbedingungen. Vergleichen Sie kritische Änderungen mit bereits bestätigten Lieferantendaten. Klären Sie Unstimmigkeiten über einen bekannten Kontaktweg.

Für die Buchhaltung kommen weitere Entscheidungen hinzu: Welcher Zeitraum ist betroffen? Welches Konto passt? Liegt eine Teilzahlung oder ein bereits erfasster Beleg vor? Wer entscheidet einen unklaren Steuerfall? Eine kurze Prüfliste mit verantwortlicher Person und offenen Fragen verhindert, dass ein erfolgreiches Auslesen mit einer Buchungsfreigabe verwechselt wird. Die genaue Arbeitsteilung richtet sich nach Ihrem Unternehmen und der Vereinbarung mit der Steuerkanzlei.

Ein Ausdruck oder eine selbst erzeugte PDF-Ansicht ist hilfreich zum Lesen, ersetzt aber nicht die strukturierte Originaldatei. Bewahren Sie den empfangenen Beleg, ergänzende Unterlagen und die für Ihren Ablauf benötigten Prüfhinweise so auf, dass der Vorgang später nachvollziehbar bleibt. Unterschiedliche Fassungen sollten eindeutig zugeordnet werden können.

Prüfen Sie auch den späteren Export: Können Sie die Originaldatei wiederfinden und herunterladen? Bleibt ihr Bezug zur Buchung erhalten? Enthält die Übergabe alle mit der Kanzlei vereinbarten Unterlagen? Testen Sie das an einem abgeschlossenen Vorgang. Eine funktionierende Ansicht am Eingang ist nur ein Teil eines brauchbaren Rechnungsprozesses.

accuno liest eingehende XRechnungen in UBL- oder CII-Syntax sowie ZUGFeRD/Factur-X mit eingebettetem Rechnungs-XML strukturiert ein. Die übernommenen Werte stehen anschließend für die Prüfung und Weiterverarbeitung des Belegs zur Verfügung. Kontrollieren Sie insbesondere Geschäftspartner, Beträge, Steuerangaben und den vorgeschlagenen Buchungskontext anhand des Originals.

Strukturiertes Einlesen ist dabei nicht gleichbedeutend mit einem unabhängigen KoSIT-Validierungsnachweis. Wenn Ihr Prozess einen solchen Nachweis verlangt, gehört ein entsprechend dokumentierter Prüfschritt dazu. Starten Sie mit wenigen repräsentativen Eingangsrechnungen: einer normalen Lieferantenrechnung, einer Rechnung mit Nachlass und einer bewusst fehlerhaften Testdatei. Entscheidend ist, ob Ihr Team die Unterschiede erkennt und jeden Fall bis zur nachvollziehbaren Buchung oder Rückfrage bearbeiten kann.