FW-XML-001: XML korrigieren, das der Parser nicht lesen will

FW-XML-001 ist eine eigene Diagnose von Ironfang. Sie ist keine Regel aus EN 16931 oder Peppol BIS Billing, und andere Validatoren melden sie nicht unter dieser Kennung.

Die kurze Antwort

FW-XML-001 ist eine eigene Kennung von uns. Sie ist nicht Teil von EN 16931 oder Peppol, und Sie finden sie nicht in deren Regellisten. Sie bedeutet, dass der XML-Prüfschritt das Dokument abgelehnt hat, bevor irgendeine Rechnungsregel betrachtet wurde: Der Text ist kein wohlgeformtes XML, er liegt in einer Kodierung vor, die wir nicht akzeptieren, oder er enthält ein Konstrukt, das wir aus Sicherheitsgründen blockieren.

Die Prüfschritte XSD, EN 16931 und Peppol werden alle als übersprungen gemeldet, sodass das Ergebnis noch nichts über den Inhalt der Rechnung aussagt. Korrigieren Sie die Datei, sodass sie sich parsen lässt, prüfen Sie dann erneut und rechnen Sie damit, dass die eigentlichen Befunde erscheinen.

Was die Regel prüft

Wohlgeformtheit. Abgeschnittene Dokumente, nicht geschlossene oder falsch verschachtelte Tags, ein einzelnes & oder < im Text, Steuerzeichen, ein zweites Wurzelelement, Text nach der Wurzel und Eingaben, die gar kein XML sind, wurden im Versuch jeweils abgelehnt. Für diese Fälle nennt der Befund Zeile und Spalte, an denen der Parser anhielt.

Die XML-Deklaration muss, falls vorhanden, ganz am Anfang der Datei stehen. Eine Leerzeile oder anderer Text davor wird abgelehnt. Ein Dokument ganz ohne Deklaration wird akzeptiert.

Kodierung. UTF-8 wird mit oder ohne Byte-Order-Mark akzeptiert. UTF-16 wird nur mit Byte-Order-Mark und einer dazu passenden Deklaration akzeptiert. Alles andere wird abgelehnt, auch ein deklariertes ISO-8859-1, windows-1252 oder US-ASCII, selbst wenn die Bytes reines ASCII sind, sowie Bytes, die für die deklarierte Kodierung ungültig sind.

Verbotene Konstrukte. Jeder DOCTYPE wird abgelehnt, mit oder ohne Entitätsdeklarationen. Ebenso jede Entitätsreferenz außer den fünf vordefinierten, weshalb HTML-Namen wie   fehlschlagen. Jedes Element in einem XInclude-Namensraum wird abgelehnt, wo immer es steht; dieser Befund trägt keine Ortsangabe.

Nicht abgelehnt werden: numerische Zeichenreferenzen wie  , & und die anderen vordefinierten Entitäten, CDATA-Abschnitte, Kommentare und Verarbeitungsanweisungen.

Wie es in einer Integration dazu kommt

Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:

• Das XML wird durch String-Verkettung oder eine Textvorlage zusammengesetzt, und ein Name wie Smith & Sons gelangt unmaskiert hinein.
• Die Datei wurde abgeschnitten, durch einen fehlgeschlagenen Upload, ein vorgelagertes Größenlimit oder einen nicht geleerten Stream.
• Der Exporter schreibt eine veraltete Ein-Byte-Kodierung oder deklariert UTF-8, schreibt aber Bytes in einer anderen Kodierung.
• Das XML wird vor dem Senden base64-kodiert oder in eine JSON-Hülle verpackt, sodass im XML-Body kein XML ankommt.
• Ein Protokollierungs- oder Vorlagenschritt setzt eine Leerzeile oder eine Bytefolge vor die XML-Deklaration.
• Das erzeugende Werkzeug fügt einen DOCTYPE hinzu, oder der Text enthält HTML-Entitäten, die aus einem Webformular kopiert wurden.

So korrigieren Sie das Dokument

1. Gehen Sie zu Zeile und Spalte aus dem Befund und sehen Sie sich an, was dort steht. Bei einer abgeschnittenen Datei ist das das Ende des Dokuments.
2. Erzeugen Sie das XML mit einer XML-Bibliothek statt durch das Zusammenfügen von Strings, damit Text maskiert und Tags für Sie ausgeglichen werden.
3. Schreiben Sie die Datei als UTF-8 und deklarieren Sie sie als UTF-8, oder lassen Sie die Deklaration weg. Stellen Sie sicher, dass nichts vor der Deklaration steht.
4. Senden Sie die XML-Bytes selbst, als rohen Request-Body oder als Teil document einer Multipart-Anfrage: nicht base64, nicht in JSON.
5. Entfernen Sie jeden DOCTYPE, Entitätsdeklarationen und XInclude-Elemente. Ersetzen Sie benannte HTML-Entitäten durch das Zeichen selbst oder eine numerische Referenz.
6. Prüfen Sie erneut. Die übersprungenen Prüfschritte laufen nun, und das Dokument kann Regeln melden, die es vorher nicht erreichen konnte.

Korrigierte Rechnung prüfen

Vorher und nachher

Dies sind Ausschnitte, keine vollständigen Dokumente. Die vollständigen synthetischen Dokumente, aus denen sie stammen, sind unten verlinkt.

Illustration, keine herunterladbare Testdatei: ein Dokument, das mitten in einem schließenden Tag abbricht

<cac:Price>
  <cbc:PriceAmount currencyID="EUR">500</cbc:PriceAmount>
</c

Illustration: dasselbe Dokument vollständig, mit jedem Element bis zur Wurzel geschlossen

<cac:Price>
  <cbc:PriceAmount currencyID="EUR">500</cbc:PriceAmount>
</cac:Price>
<!-- the enclosing cac:InvoiceLine and the Invoice root are then closed in turn -->

Die fehlerhafte Eingabe endet mitten in einem schließenden Tag, sodass der Parser das Dateiende mit noch offenen Elementen erreicht. Das Dokument meldet nur FW-XML-001, im XML-Prüfschritt; die Prüfschritte XSD, EN 16931 und Peppol werden übersprungen. Diese Ausschnitte sind handgeschriebene Illustrationen eines Regressionsfalls. Es gibt kein herunterladbares Paar für diese Diagnose, weil die fehlerhafte Datei per Definition kein verwendbares Dokument ist.

Wo die Regel gilt

• Gilt für alles, was eingereicht wird, gleich was es sein sollte. Der Dokumenttyp kann keine Rolle spielen, weil die Eingabe nie als Invoice oder CreditNote gelesen wurde.
• Dies ist eine Ironfang-Diagnose. Ein anderer Validator beschreibt dieselbe Eingabe mit eigenen Worten und ist bei DOCTYPE und Kodierungen womöglich strenger oder weniger streng.
• Sie ist von den Größen- und Strukturgrenzen getrennt. Ein leerer Body wird als FW-INPUT-001 gemeldet, und Dokumente, die zu tief verschachtelt sind oder zu viele Elemente haben, haben eigene Kennungen FW-XML. Komprimierte Bodys und Archive weist die API mit einer Antwort 415 ab, bevor die Validierung beginnt, sodass sie diesen Befund nicht erzeugen.
• Wohlgeformtes XML, das nicht dem UBL-Schema folgt, ist ein anderer Fehler: Den meldet der XSD-Prüfschritt, nicht dieser.

Verwandte Regeln

• PEPPOL-EN16931-R008 betrifft Elemente, die wohlgeformt, aber leer sind: Der Parser akzeptiert sie, Peppol nicht
• BR-01 ist eine der ersten Inhaltsregeln, auf die ein Dokument trifft, sobald es sich parsen lässt: Die Spezifikationskennung muss vorhanden sein
• PEPPOL-EN16931-R004 prüft danach, dass die Spezifikationskennung die von Peppol Billing ist
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): How Peppol invoice validation actually works

Umfang und Quelle

Beschreibt, wie Ironfang Finance Eingaben vor der Validierung behandelt. Das gilt für jedes Regelwerk, das der Validator anbietet. Version des Hinweiskatalogs 2026-09-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-20.

Validierungsvertrag von Ironfang (auf Englisch)

Die Erklärung ändert das Urteil der Engine nicht. Dass Sie diesen Befund beheben, heißt nicht, dass das Dokument jeden Prüfschritt besteht. Die Validierung bescheinigt keine rechtliche oder steuerliche Konformität und überträgt kein Dokument über Peppol.