XML-Anhänge in BIS 3: Formate, Größenlimits und PDF-Rechnungen

Eine Rechnung nach Peppol BIS Billing 3.0 ist ein XML-Dokument. Dieses XML ist die Rechnung: Es enthält strukturierte Daten, die eine Buchhaltungssoftware validieren, buchen und automatisch verarbeiten kann. Manchmal benötigt die Rechnung zusätzlich Unterlagen, zum Beispiel einen Stundenzettel, einen Lieferschein oder eine für Menschen lesbare PDF-Datei. BIS 3.0 unterstützt das Mitsenden solcher Unterlagen als XML-Anhang.

Eine PDF-Datei kann die Rechnung für Menschen leichter lesbar machen, ersetzt aber nicht die strukturierte BIS-Rechnung. Das XML bleibt das Dokument, das Systeme für Validierung und automatische Verarbeitung verwenden sollen.

Wo gehört ein Anhang in BIS 3 hin?

Anhänge werden in cac:AdditionalDocumentReference/cac:Attachment übertragen. Diese Gruppe ist optional und kann mehrfach vorkommen. Die vollständige Struktur beschreibt die offizielle UBL-Invoice-Syntax von Peppol BIS Billing 3.0.

Für eine eingebettete Datei ist cbc:EmbeddedDocumentBinaryObject entscheidend. Das Element hat zwei obligatorische Attribute:

• mimeCode beschreibt den Medientyp der Datei;
• filename gibt den Dateinamen für den Empfänger an.

Ein eingebettetes PDF kann zum Beispiel so aussehen:

1
2
3
4
5
6
7
8
9

<cac:AdditionalDocumentReference>
  <cbc:ID>invoice-representation</cbc:ID>
  <cbc:DocumentDescription>Lesbare Darstellung der Rechnung</cbc:DocumentDescription>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject
      mimeCode="application/pdf"
      filename="rechnung-2026-0042.pdf">JVBERi0xLjQK...</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

Der Wert des Elements ist nicht die PDF-Datei selbst, sondern ihr Inhalt in Base64.

Welche Formate werden unterstützt?

BIS Billing 3 erlaubt keinen beliebigen MIME-Typ. Der Empfänger muss die eingeschränkte, von IANA abgeleitete Liste unterstützen. Die offizielle Codeliste für Medientypen angehängter Dokumente enthält:

mimeCode muss einem dieser Werte entsprechen, und die Dateiendung sollte dazu passen. Eine ZIP-Datei darf also nicht als PDF bezeichnet werden, und eine Excel-Datei darf nicht mit mimeCode="application/pdf" gesendet werden.

BIS unterstützt auch einen externen Verweis über cac:ExternalReference/cbc:URI. Ein eingebetteter Anhang ist für Rechnungsunterlagen meist zuverlässiger: Die Datei reist mit der Rechnung und hängt nicht von einer später erreichbaren URL, einer Anmeldung oder einer begrenzten Linkgültigkeit ab.

10 MiB versus 100 MiB

Diese beiden Größenangaben werden häufig verwechselt:

• 10 MiB ist das üblicherweise geprüfte Limit für die gesamte XML-Nachricht. Es ist kein Limit für einen einzelnen Anhang. Die Prüfung umfasst normalerweise die XML-Rechnung mit allen eingebetteten Anhängen und dem Nachrichteninhalt, den der Access Point empfängt. Mehrere kleine Anhänge können das Limit daher gemeinsam überschreiten.
• 100 MiB ist die allgemeine Transportkapazität. Eine Nachricht sollte grundsätzlich bis 100 MiB funktionieren, aber das konkrete Limit wird vom jeweiligen Access Point festgelegt. Einige Access Points können sie deutlich früher ablehnen.

Base64 vergrößert jeden eingebetteten Binärwert ungefähr um ein Drittel. Hinzu kommen XML, MIME-Verpackung und Sicherheits-Overhead. Entscheidend ist deshalb nicht die Größe der Dateien auf der Festplatte, sondern die Größe der fertigen Nachricht. Die Implementierung sollte die vollständig kodierte Nachricht messen und einen Puffer unter dem vom Access Point durchgesetzten Limit lassen.

Für größere Unterlagen sollte man einen kleineren, relevanten Export oder einen mit dem Empfänger abgestimmten externen Verweis verwenden. Die Rechnung ist kein allgemeines Dateiarchiv.

Wie wird die Datei kodiert?

Die Dateibytes werden als Base64 kodiert und in cbc:EmbeddedDocumentBinaryObject abgelegt. Base64 ist weder Verschlüsselung noch eine Sicherheitsprüfung. Der Empfänger dekodiert den Wert wieder in Bytes; Access Point und Zielanwendung benötigen weiterhin einen normalen Schutz vor schädlichen Inhalten.

Beim Erzeugen eines Anhangs sollte man:

1. die Originalbytes ohne Umwandlung in eine Textkodierung lesen;
2. sie in Base64 kodieren;
3. mimeCode und filename korrekt setzen;
4. den Wert im Test dekodieren und byteweise mit dem Original vergleichen;
5. die gesamte BIS-Rechnung und die Größe der fertigen Nachricht validieren.

Warum überhaupt einen Anhang senden?

Strukturiertes XML ist hervorragend für die Automatisierung, kann aber nicht jeden Nachweis eines Geschäftsprozesses enthalten. Ein Anhang kann beispielsweise einen Stundenzettel, einen Liefer- oder Abnahmebericht, eine Berechnung, ein Foto, eine Tabelle oder eine PDF-Darstellung für Menschen enthalten.

Das Mitsenden verbessert die Nachvollziehbarkeit. Der Empfänger muss keinen E-Mail-Anhang zuordnen und keinen Link abrufen, der später ablaufen kann. Der Anhang soll die Rechnung jedoch nur unterstützen und ihr nicht widersprechen. Beträge, Steuerinformationen und die Identifikation der Parteien müssen aus den strukturierten BIS-Daten stammen.

Warum kann ein Access Point ein PDF hinzufügen?

Einige Access Points erzeugen aus der XML-Rechnung eine PDF-Darstellung und fügen sie als Vorschau der Rechnung als Anhang hinzu. Das kann bei manueller Prüfung, beim Drucken oder in Archiven nützlich sein, wenn neben dem maschinenlesbaren XML eine visuelle Darstellung gebraucht wird.

Diese PDF ist eine Hilfsdarstellung und keine zweite autoritative Rechnung. Sie muss aus dem validierten XML erzeugt werden, einen eindeutigen Namen tragen und mimeCode="application/pdf" verwenden. Sie darf Beträge, Umsatzsteuer, Zahlungsreferenzen oder Parteien nicht unbemerkt ändern. Für die Buchung soll der Empfänger das XML verwenden, die PDF dient als Ansicht oder Nachweis.

Es sollte außerdem klar erkennbar sein, ob die PDF vom Absender geliefert oder vom Access Point erzeugt wurde. Eine erzeugte PDF vergrößert die Nachricht und wird vom Empfänger möglicherweise nicht erwartet.

Praktische Checkliste

Vor dem Versand sollte geprüft werden, dass:

• die XML-Rechnung nach Peppol BIS Billing 3.0 gültig ist;
• jeder Anhang einen erlaubten MIME-Typ und einen sinnvollen Namen hat;
• der Inhalt in Base64 kodiert ist und unverändert dekodiert werden kann;
• die gesamte Nachricht unter dem vom Access Point geprüften Limit bleibt;
• bekannt ist, ob der Access Point eine PDF erzeugt und wie er damit umgeht.

So bleibt das XML präzise und automatisierbar, während die Unterlagen gemeinsam mit der Transaktion übertragen werden.

Quellen: Peppol BIS Billing 3.0, UBL-Invoice-Syntax, Codeliste für Medientypen und Peppol AS4 Profile.