PEPPOL-EN16931-P0112: Die Rechnungstypen 326 und 384 Rechnungen zwischen zwei deutschen Parteien vorbehalten

Die kurze Antwort

PEPPOL-EN16931-P0112 schlägt fehl, wenn cbc:InvoiceTypeCode 326 oder 384 ist und Verkäufer und Käufer nicht beide in Deutschland sind. Beide Codes stehen auf der Peppol-Liste der Rechnungstypen, aber diese Regel behält sie innerdeutschen Rechnungen vor. Senden Sie zwischen allen anderen Parteien eine gewöhnliche Rechnung, 380, und korrigieren Sie eine frühere Rechnung mit einer Gutschrift statt mit einer korrigierten Rechnung.

Was als Deutschland gilt, entscheidet allein die Postanschrift. Die Regel liest den Ländercode in der Postanschrift des Verkäufers und in der des Käufers, ohne Randleerzeichen und in Großbuchstaben, und beide müssen DE sein. Umsatzsteuer-Identifikationsnummern, ein Steuervertreter und die Lieferanschrift spielen keine Rolle.

Was die Regel prüft

Die Regel läuft auf cbc:InvoiceTypeCode, entfernt Randleerzeichen und schlägt bei 326 oder 384 fehl, sofern nicht beide Ländercodes der Postanschriften DE sind. Jeden anderen Code überlässt sie PEPPOL-EN16931-P0100; im Versuch wurde 326 mit Leerzeichen davor und danach hier weiterhin gemeldet.

Eine deutsche Partei genügt nicht. Im Versuch schlug 384 fehl, als die Anschrift des Verkäufers nach Berlin verlegt wurde und der Käufer in London blieb, ebenso bei einem Verkäufer in London mit der Umsatzsteuer-Identifikationsnummer DE123456789, der an einen Käufer in München verkauft.

Auch umgekehrt gilt das: Mit beiden Postanschriften in Deutschland bestand 384 diese Regel im Versuch, obwohl die Umsatzsteuer-Identifikationsnummer des Verkäufers mit GB begann.

Kleinschreibung zählt hier als deutsch, weil der Ländercode zuerst in Großbuchstaben umgewandelt wird. Im Versuch erfüllte de in beiden Anschriften diese Regel, während BR-CL-14 beide Codes ablehnte.

Zwei deutsche Anschriften schalten auch die deutschen nationalen Regeln ein, die denselben Test verwenden. Im Versuch bestand das aufgezeichnete Beispiel, nach Berlin und München verlegt und mit 384, diese Regel und brachte DE-R-001 (Zahlungsanweisungen), DE-R-002 (Kontakt des Verkäufers) und die Warnung DE-R-026 (ein Verweis auf die korrigierte Rechnung) hervor.

Wie es in einer Integration dazu kommt

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

• Eine für deutsche Kunden gebaute Anbindung, in der beide Codes verwendet werden, wird für Kunden in anderen Ländern wiederverwendet.
• Korrekturen werden als neue Rechnung mit dem Code 384 gesendet statt als Gutschrift, der bei Bedarf eine neue Rechnung folgt.
• Abschlags- oder Fortschrittsrechnungen werden für Kunden außerhalb Deutschlands mit 326, Teilrechnung, codiert.
• Die Parteien sind im Geschäftssystem deutsch, aber eine in die Rechnung geschriebene Anschrift ist es nicht, etwa die eines Hauptsitzes im Ausland.

So korrigieren Sie das Dokument

1. Prüfen Sie die Ländercodes, die die Rechnung tatsächlich in beiden Gruppen cac:PostalAddress trägt. Sind beide Parteien in Deutschland und sagt eine Anschrift etwas anderes, korrigieren Sie die Anschrift.
2. Andernfalls wählen Sie einen anderen Rechnungstyp. Eine Teil- oder Abschlagsrechnung kann als 380, Handelsrechnung, gehen. Für eine Korrektur senden Sie eine Gutschrift, 381, zur ursprünglichen Rechnung und danach eine neue Rechnung, falls noch ein Betrag geschuldet ist.
3. Verweisen Sie in cac:BillingReference/cac:InvoiceDocumentReference auf die korrigierte Rechnung, in der Gutschrift oder in der neuen Rechnung.
4. Sind beide Parteien in Deutschland und behalten Sie 326 oder 384, erfüllen Sie auch die deutschen nationalen Regeln. Im Versuch bestand das Beispiel in Berlin und München jeden Prüfschritt, sobald es eine Zahlungsart, einen Kontakt des Verkäufers und eine cac:BillingReference hatte.

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.

Ausschnitt der fehlerhaften Rechnung: Rechnungstyp 384 zwischen einem Verkäufer und einem Käufer im Vereinigten Königreich

<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
<!-- currency and buyer reference omitted from this fragment -->
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Ausschnitt der korrigierten Rechnung: Rechnungstyp 380 für dieselben beiden Parteien

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<!-- currency and buyer reference omitted from this fragment -->
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Nur cbc:InvoiceTypeCode unterscheidet sich: 384 in der fehlerhaften Rechnung, 380 in der korrigierten, und beide Parteien bleiben in GB. Das fehlerhafte Dokument meldet nur diese Regel; BR-CL-01 und PEPPOL-EN16931-P0100 bestehen, weil 384 auf beiden Listen steht. Das Umcodieren passt zu diesem Beispiel, das eine gewöhnliche Rechnung ist; eine echte Korrektur außerhalb Deutschlands läuft über eine Gutschrift.

Wo die Regel gilt

• Gilt nur für UBL Invoice, da die Regel cbc:InvoiceTypeCode liest. Eine Gutschrift kann 384 überhaupt nicht verwenden: Im Versuch wurde ein cbc:CreditNoteTypeCode mit 384 von BR-CL-01 und PEPPOL-EN16931-P0101 abgelehnt.
• Wird im Peppol-Prüfschritt gemeldet. EN 16931 kennt keine solche Bedingung, und beide Codes bestehen BR-CL-01, wer auch immer die Parteien sind.
• Der Test für eine deutsche Rechnung ist derselbe, mit dem sich die deutschen nationalen Regeln einschalten. Eine Rechnung, die diese Regel mit 326 oder 384 besteht, wird deshalb immer auch von jenen Regeln geprüft.

Verwandte Regeln

• PEPPOL-EN16931-P0100 prüft den Rechnungstyp gegen die Peppol-Liste, bevor diese Regel zwei ihrer Codes einschränkt
• BR-CL-01 akzeptiert 326 und 384 im Prüfschritt EN 16931 für beliebige Parteien
• BR-CL-14 prüft die Ländercodes der Postanschriften, die entscheiden, ob beide Parteien deutsch sind
• PEPPOL-EN16931-P0101 hält Gutschriften an ihre eigene Liste von Typcodes
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): How Peppol invoice validation actually works

Umfang und Quelle

Geschrieben für Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, angewendet auf Invoice- und CreditNote-Dokumente in UBL 2.1. Andere Profile, Syntaxen und Releases können diese Kennung anders definieren. Version des Hinweiskatalogs 2026-09-28.1: Quelle geprüft am 2026-09-28, Erklärung zuletzt aktualisiert am 2026-09-28.

Die offizielle Definition von PEPPOL-EN16931-P0112 (auf Englisch) enthält den normativen Wortlaut und den Test. Diese Seite ist unsere Erklärung dazu, keine Kopie.

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.