BR-IC-02: Die Umsatzsteuer-Identifikationsnummern von Verkäufer und Käufer in eine innergemeinschaftliche Lieferung aufnehmen

Die kurze Antwort

BR-IC-02 schlägt fehl, wenn eine Position als K eingestuft ist, innergemeinschaftliche Lieferung, und dem Dokument auf einer Seite eine Umsatzsteuer-Identifikationsnummer fehlt. Die Verkäuferseite braucht cbc:CompanyID in einem cac:PartyTaxScheme für VAT unter cac:AccountingSupplierParty/cac:Party oder unter cac:TaxRepresentativeParty; die Käuferseite braucht dasselbe unter cac:AccountingCustomerParty/cac:Party. Fügen Sie hinzu, was fehlt.

Der Befund sagt nicht, welche Seite fehlerhaft ist; prüfen Sie daher beide. Im aufgezeichneten Beispiel ist es die Umsatzsteuer-Identifikationsnummer des Käufers, und die Handelsregisternummer des Käufers, die das Dokument weiterhin trägt, ersetzt sie nicht.

Was die Regel prüft

Auslöser ist eine Position: jede cac:ClassifiedTaxCategory mit cbc:ID gleich K unter dem Steuerschema VAT, die in UBL im cac:Item einer Rechnungs- oder Gutschriftsposition steht. Eine K-Umsatzsteueraufschlüsselung oder ein Nachlass auf Dokumentenebene löst die Regel allein nicht aus, weil diese cac:TaxCategory verwenden.

Ist sie ausgelöst, muss beides vorhanden sein. Verkäuferseite: eine Umsatzsteuer-Identifikationsnummer des Verkäufers oder eine des Steuervertreters des Verkäufers; jede der beiden genügt. Käuferseite: eine Umsatzsteuer-Identifikationsnummer des Käufers, ohne Alternative.

Nur ein cac:PartyTaxScheme, dessen cac:TaxScheme/cbc:ID VAT ist, zählt, und zwar auf beiden Seiten. Im Versuch meldete die Käuferkennung DE123456789 unter dem Schema TAX weiterhin BR-IC-02. Die Prüfung für den Normalsatz, BR-S-02, ist auf der Verkäuferseite großzügiger und akzeptiert eine Steuerregistrierung unter jedem Schema.

Kennungen der rechtlichen Registrierung spielen keine Rolle. Die fehlerhafte Rechnung behält das cac:PartyLegalEntity/cbc:CompanyID des Käufers mit 87654321 und schlägt trotzdem fehl. Reverse-Charge ist anders: BR-AE-02 akzeptiert eine Kennung der rechtlichen Registrierung des Käufers anstelle einer Umsatzsteuer-Identifikationsnummer des Käufers.

Die Regel prüft das Vorhandensein, nicht den Inhalt. Ein leeres cbc:CompanyID des Käufers erfüllte sie im Versuch und wurde stattdessen von PEPPOL-EN16931-R008 gemeldet. Eine Umsatzsteuer-Identifikationsnummer des Käufers mit GB-Präfix, also demselben Land wie beim Verkäufer, bestand jeden Prüfschritt: Die beiden Länder werden nie verglichen.

Es gibt einen Befund pro Dokument, an der Wurzel, ob eine Kennung fehlt oder beide.

Wie es in einer Integration dazu kommt

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

• Die Umsatzsteuer-Identifikationsnummer des Käufers steht im Kundendatensatz, aber der Export bildet sie nur für Reverse-Charge-Dokumente ab, nicht für innergemeinschaftliche Lieferungen.
• Der Kundenstamm enthält eine Handelsregisternummer und sonst nichts, sodass der Käufer mit cac:PartyLegalEntity/cbc:CompanyID und ohne cac:PartyTaxScheme endet.
• Die Umsatzsteuer-Identifikationsnummer des Käufers wird unter einem anderen Steuerschema-Code als VAT geschrieben, übernommen aus einem allgemeinen Feld für die Steuerart im Quellsystem.
• Der Verkäufer rechnet über einen Steuervertreter ab, und die cac:TaxRepresentativeParty wird ohne eigenes cac:PartyTaxScheme gesendet, während auch die Kennung des Verkäufers fehlt.
• Die Kategorie K wird allein aus dem Lieferland abgeleitet, sodass auch ein Käufer, der nie eine Umsatzsteuer-Identifikationsnummer angegeben hat, K erhält. Dann ist die Entscheidung über die Kategorie zu korrigieren.

So korrigieren Sie das Dokument

1. Sehen Sie sich beide Parteien an. Suchen Sie unter cac:AccountingSupplierParty/cac:Party und cac:AccountingCustomerParty/cac:Party ein cac:PartyTaxScheme, dessen cac:TaxScheme/cbc:ID VAT ist und dessen cbc:CompanyID einen Wert hat.
2. Nehmen Sie für den Käufer die Umsatzsteuer-Identifikationsnummer, die der Käufer Ihnen gegeben hat und die im Kundendatensatz gespeichert ist, vollständig mit Länderpräfix. Gibt es keine, gehen Sie zurück zur Steuerermittlung: Die Kategorie K setzt eine Umsatzsteuer-Identifikationsnummer des Käufers voraus, und weder eine kopierte noch eine geratene Nummer ist eine Lösung.
3. Schreiben Sie sie als cac:PartyTaxScheme mit cbc:CompanyID und cac:TaxScheme/cbc:ID gleich VAT, nach cac:PostalAddress und vor cac:PartyLegalEntity. Nach der juristischen Person platziert, scheiterte sie im Versuch am XSD-Prüfschritt, und die Regeln der EN 16931 wurden übersprungen.
4. Senden Sie für den Verkäufer dessen Umsatzsteuer-Identifikationsnummer in derselben Struktur. Wird der Verkäufer vertreten, erfüllt auch eine cac:TaxRepresentativeParty mit Name, Postanschrift und einem cac:PartyTaxScheme für VAT die Verkäuferseite: Im Versuch machte sie das Dokument ohne Umsatzsteuer-Identifikationsnummer des Verkäufers gültig.

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: Der Käufer hat eine Kennung der rechtlichen Registrierung, aber keine Umsatzsteuer-Identifikationsnummer

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

Ausschnitt der korrigierten Rechnung: Die Umsatzsteuer-Identifikationsnummer des Käufers steht zwischen der Anschrift und der juristischen Person

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <!-- postal address in Berlin, DE, 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>

Die korrigierte Rechnung gibt dem Käufer ein cac:PartyTaxScheme mit DE123456789 unter dem Schema VAT; die fehlerhafte Rechnung hat keine Umsatzsteuer-Identifikationsnummer des Käufers. Die Umsatzsteuer-Identifikationsnummer des Verkäufers GB123456789 und die K-Position sind in beiden gleich. Das fehlerhafte Dokument meldet nur BR-IC-02, obwohl die Kennung der rechtlichen Registrierung des Käufers noch vorhanden ist.

Wo die Regel gilt

• Gilt für UBL Invoice und CreditNote. Die in eine Gutschrift umgewandelte fehlerhafte Rechnung, mit cac:CreditNoteLine für ihre Position, meldete im Versuch denselben einzelnen Befund.
• Wird vom Prüfschritt EN 16931 gemeldet, der erst läuft, wenn der XSD-Prüfschritt bestanden ist. Ein cac:PartyTaxScheme an falscher Stelle scheitert zuerst am Schema und verdeckt diese Regel.
• Die übrigen Regeln für innergemeinschaftliche Lieferungen sind eigene Befunde: BR-IC-10 für den Befreiungsgrund, BR-IC-11 für das Lieferdatum oder den Rechnungszeitraum und BR-IC-12 für das Lieferland. BR-CO-09 prüft dann das Länderpräfix der Kennungen, die Sie hinzufügen.
• Die Validierung prüft, dass die Kennungen vorhanden sind, nicht dass sie registriert sind. Eine Umsatzsteuer-Identifikationsnummer des Käufers zu bestätigen, etwa über den VIES-Dienst der EU, ist ein eigener Schritt.

Verwandte Regeln

• BR-AE-02 ist das Gegenstück für Reverse-Charge, das auch eine Kennung der rechtlichen Registrierung des Käufers akzeptiert
• BR-G-02 verlangt nur die Verkäuferseite, wenn die Position eine Ausfuhr außerhalb der EU ist
• BR-CO-09 prüft das Länderpräfix der Umsatzsteuer-Identifikationsnummern, die diese Regel verlangt
• BR-IC-12 ist die nächste Anforderung an dasselbe Dokument: das Lieferland
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): Understanding EN 16931 validation errors

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-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-24.

Die offizielle Definition von BR-IC-02 (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.