Zum Inhalt springen

Ironfang Finance - Regelreferenz

BR-AE-03: Verkäufer und Käufer identifizieren, wenn ein Nachlass auf Dokumentenebene dem Reverse Charge unterliegt

Ein Reverse-Charge-Nachlass auf Dokumentenebene braucht eine Steuerkennung des Verkäufers und für den Käufer eine Umsatzsteuer-Identifikationsnummer oder eine Kennung der rechtlichen Registrierung.

EN 16931Fehler: Das Dokument ist ungültigUmsatzsteuerBeteiligte und AdressenNachlässe und Zuschläge

Auf dieser Seite

Die kurze Antwort

BR-AE-03 schlägt fehl, wenn ein Nachlass eine cac:TaxCategory AE hat und dem Dokument eine Steuerkennung des Verkäufers oder eine Kennung des Käufers fehlt. Im aufgezeichneten Beispiel hat der Käufer weder eine Umsatzsteuer-Identifikationsnummer noch eine Kennung der rechtlichen Registrierung; eine von beiden wiederherzustellen genügt, und die korrigierte Rechnung hat beide, DE123456789 unter VAT und 87654321.

Wie BR-AE-02 akzeptiert diese Regel die Kennung der rechtlichen Registrierung des Käufers anstelle einer Umsatzsteuer-Identifikationsnummer. Senden Sie die Umsatzsteuer-Identifikationsnummer des Käufers trotzdem, wenn er eine hat: Der Validator sieht nur, dass irgendeine Kennung des Käufers vorhanden ist, nicht, ob der Käufer die Umsatzsteuer abrechnen kann.

Was die Regel prüft

Auslöser ist ein cac:AllowanceCharge mit cbc:ChargeIndicator false, dessen cac:TaxCategory die cbc:ID AE unter dem Schema VAT hat. Reverse-Charge-Positionen deckt BR-AE-02 ab und Reverse-Charge-Zuschläge BR-AE-04, die die Parteien auf dieselbe Weise prüfen.

Jede der beiden Kennungen des Käufers genügt für sich allein. Im Versuch blieb die Rechnung mit dem Rabatt gültig, wenn nur die Umsatzsteuer-Identifikationsnummer des Käufers entfernt wurde, und ebenso, wenn nur die Kennung der rechtlichen Registrierung entfernt wurde.

Die Umsatzsteuer-Identifikationsnummer des Käufers zählt nur unter dem Schema VAT. Ohne Kennung der rechtlichen Registrierung schlug im Versuch ein Schema TAX beim Käufer fehl, ebenso die nach cac:PartyIdentification/cbc:ID verschobene Umsatzsteuer-Identifikationsnummer des Käufers; jedes Mal kam BR-AE-02 hinzu.

Auf der Seite des Verkäufers genügt eine cbc:CompanyID unter beliebigem Schema. Im Versuch bestand das auf TAX gesetzte Schema des Verkäufers, während das Entfernen des Steuerschemas des Verkäufers diese Regel und BR-AE-02 meldete.

Der Nachlass bringt die Bedingung für den Käufer von sich aus mit. Im Versuch mit einer Rechnung mit einer Position zum Normalsatz, einem Reverse-Charge-Rabatt über 3.00 und einem Käufer ohne Kennung wurde nur diese Regel gemeldet.

BegriffBedeutungUBL-Element
BT-31Umsatzsteuer-Identifikationsnummer des Verkäuferscac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)
BT-32Steuernummer des Verkäuferscac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (a tax scheme other than VAT)
BT-63Umsatzsteuer-Identifikationsnummer des Steuervertreters des Verkäuferscac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID
BT-48Umsatzsteuer-Identifikationsnummer des Käuferscac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID (tax scheme VAT)
BT-47Kennung der rechtlichen Registrierung des Käuferscac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID
BT-95Code der Umsatzsteuerkategorie des Nachlasses auf Dokumentenebenecac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID

Wie es in einer Integration dazu kommt

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

  • Der Kunde wurde als Inlandskonto angelegt, sodass sein Datensatz weder eine Umsatzsteuer-Identifikationsnummer noch eine Registernummer enthält.
  • Die Partei des Käufers wird aus einer Liefer- oder Bestellanschrift ohne Steuerfelder gebildet.
  • Die Umsatzsteuer-Identifikationsnummer des Käufers wird unter einem anderen Schema als VAT oder nur als Kennung der Partei gesendet.
  • Das Steuerschema des Verkäufers wird bei Dokumenten ohne zu berechnende Umsatzsteuer weggelassen, und eine Reverse-Charge-Rechnung ist ein solches Dokument.

So korrigieren Sie das Dokument

  1. Prüfen Sie beide Parteien, denn der Befund sagt nicht, welcher Seite etwas fehlt: Der Verkäufer braucht eine cac:PartyTaxScheme/cbc:CompanyID oder einen Steuervertreter, der Käufer eine Umsatzsteuer-Identifikationsnummer unter VAT oder eine Kennung der rechtlichen Registrierung.
  2. Für den Käufer schreiben Sie die Umsatzsteuer-Identifikationsnummer in cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID mit cac:TaxScheme/cbc:ID VAT, zwischen cac:PostalAddress und cac:PartyLegalEntity, und eine bekannte Registernummer in cac:PartyLegalEntity/cbc:CompanyID.
  3. Lassen Sie den Nachlass, wie er ist: Ein Reverse-Charge-Mengenrabatt über 3.00 in der Kategorie AE mit 0 ist richtig, wenn er Reverse-Charge-Umsätze mindert.
  4. Validieren Sie erneut. BR-AE-02 liest dieselben Kennungen und verschwindet zur selben Zeit.

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: ein Käufer nur mit Name und Anschrift und ein Reverse-Charge-Mengenrabatt

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address omitted from this fragment -->
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Volume discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="GBP">3.00</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>AE</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>

Ausschnitt der korrigierten Rechnung: Umsatzsteuer-Identifikationsnummer und Kennung der rechtlichen Registrierung des Käufers sind beide zurück

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address omitted from this fragment -->
    <cac:PartyTaxScheme>
      <cbc:CompanyID>DE123456789</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
      <cbc:CompanyID>87654321</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

<!-- the reverse-charge volume discount of 3.00 is the same as in the failing invoice -->

Die korrigierte Rechnung gibt dem Käufer eine Umsatzsteuer-Identifikationsnummer, DE123456789 unter VAT, und eine Kennung der rechtlichen Registrierung, 87654321; die fehlerhafte Rechnung hat keine von beiden. Das fehlerhafte Dokument meldet außerdem BR-AE-02, weil seine Position über 25.00 ebenfalls dem Reverse Charge unterliegt und von denselben Kennungen des Käufers abhängt. Der Mengenrabatt über 3.00 und die Reverse-Charge-Aufschlüsselung über 22.00 sind in beiden Dokumenten gleich.

Was der Validator gemeldet hat

Aufgezeichnet mit phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, der Engine hinter dem kostenlosen Validator, mit synthetischen Daten. Ein aufgezeichnetes Ergebnis ist ein Regressionsnachweis für diese Dokumente, keine Zertifizierung.

Wo die Regel gilt

  • Gilt für UBL Invoice und CreditNote. Eine Reverse-Charge-Gutschrift mit dem Rabatt und ohne Kennungen des Käufers meldete im Versuch diese Regel und BR-AE-02.
  • Wird im Prüfschritt EN 16931 als ein einziger fataler Befund am Dokumentstamm gemeldet, der Verkäufer und Käufer zusammen abdeckt.
  • Die Regel für steuerbefreite Nachlässe, BR-E-03, verlangt nur die Kennung des Verkäufers. Ein Reverse-Charge-Nachlass muss außerdem nach BR-AE-06 einen Satz von 0 tragen.

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 BR-AE-03 (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.