Korrekte Peppol-BIS-3.0-Rechnungen aus Tschechien und der Slowakei erstellen

Der häufigste Grund, warum eine Rechnung aus einem tschechischen oder slowakischen System beim Empfänger nicht korrekt ankommt, ist keine fehlerhafte XML-Datei - es ist eine Diskrepanz zwischen Begriffen wie Gutschrift, Lastschrift oder Anzahlungsrechnung im Quellsystem und dem, was EN 16931 und Peppol BIS Billing 3.0 dafür vorsehen. BIS 3.0 kennt nur zwei Dokumenttypen, Invoice und CreditNote, sowie eine feste Liste von Belegtyp-Codes - jeder lokale Begriff muss also korrekt darauf abgebildet werden, sonst stimmt am Ende der Betrag nicht, den der Kunde zahlen soll.

Wir zeigen, wie wir das auf unserem Access Point umsetzen, damit Integratoren und Buchhaltungssoftware-Anbieter ihre eigene Implementierung damit abgleichen können.

Belegtyp-Codes: nicht alles als “380” senden

BT-3 (cbc:InvoiceTypeCode, bei einer Gutschrift cbc:CreditNoteTypeCode) teilt dem Empfänger mit, um welche Art von Beleg es sich handelt. Tschechische und slowakische Buchhaltungssysteme unterscheiden mehr Belegtypen, als üblicherweise über Peppol übertragen werden - wird alles standardmäßig als 380 gesendet, geht diese Unterscheidung verloren.

Ein Punkt überrascht Integratoren regelmäßig: BIS 3.0 kennt keinen eigenen DebitNote-Dokumenttyp. Ein Korrekturbeleg, der den Betrag erhöht, muss als Invoice mit Code 384 gesendet werden, mit Verweis auf den Originalbeleg über cac:BillingReference - nicht als CreditNote mit negativem Betrag, was mehrere Empfängersysteme ablehnen oder falsch verarbeiten.

Zahlungsreferenzen: VS, KS und SS

Tschechische und slowakische Banken sowie Buchhaltungssoftware gleichen eingehende Zahlungen anhand von drei Symbolen ab, für die UBL kein eigenes Feld vorsieht:

• VS (Variabler Symbol) - identifiziert, zu welchem Beleg die Zahlung gehört, meist die Rechnungsnummer.
• KS (Konstanter Symbol) - ein vierstelliger, bankseitig vergebener Code für die Art der Zahlung.
• SS (Spezifisches Symbol) - eine zusätzliche zehnstellige Referenz; wird von Banken zunehmend nicht mehr unterstützt (SEPA sieht dafür kein Feld vor), von manchen Empfängern aber weiterhin erwartet.

EN 16931 definiert BT-83 (cbc:PaymentID) wörtlich als “einen Wert, der die Zahlung mit der Rechnung verknüpft” - genau das, was ein bloßer VS leisten soll. Ist VS das einzige Symbol, gehört er deshalb direkt dort hinein, als reiner Wert, ohne Präfix und ohne cac:PaymentMeans/cbc:InstructionID:

1
2
3
4

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>42</cbc:PaymentMeansCode>
  <cbc:PaymentID>176692026</cbc:PaymentID>
</cac:PaymentMeans>

Die strukturierte Kodierung VS:...;KS:...;SS:... in InstructionID (mit einem lesbaren VS.../KS.../SS... als Rückfallwert auch in PaymentID) verwenden wir erst, wenn mehr als ein Symbol kodiert werden muss - also sobald KS oder SS dazukommt:

1
2
3
4
5

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>42</cbc:PaymentMeansCode>
  <cbc:InstructionID>VS:176692026;KS:0008;SS:1234567890</cbc:InstructionID>
  <cbc:PaymentID>VS176692026/KS0008/SS1234567890</cbc:PaymentID>
</cac:PaymentMeans>

Das Weglassen von VS ist der häufigste Grund, warum eine Zahlung zwar beim Empfänger eingeht, aber nie der auslösenden Rechnung zugeordnet wird. Der zweithäufigste Fehler ist, einen einzelnen VS trotzdem in das VS:-Präfix und InstructionID zu verpacken, obwohl weder KS noch SS vorhanden sind - für einen allgemeinen (nicht tschechischen/slowakischen) Empfänger ist das nur Rauschen in einem Feld, das eine saubere Referenz enthalten sollte.

Anzahlungen und ihr Abzug

Der übliche Ablauf umfasst drei Schritte: Der Verkäufer stellt eine Anzahlungsrechnung (Zahlungsaufforderung, Code 386, kein Steuerbeleg), erhält die Zahlung und stellt einen Steuerbeleg über den Zahlungseingang aus (Code 388 - die Umsatzsteuer wird innerhalb von 15 Tagen nach Zahlungseingang fällig), und stellt bei Lieferung eine Schlussrechnung aus, die jede bereits versteuerte Anzahlung abziehen muss.

Dieser Abzug ist BT-113, cbc:PrepaidAmount in cac:LegalMonetaryTotal, und muss nach der Standardformel (BR-CO-16) in cbc:PayableAmount einfließen:

PayableAmount = TaxInclusiveAmount − PrepaidAmount + PayableRoundingAmount

Beispiel: Waren im Wert von 25.000 CZK zzgl. 21 % USt. (30.250 CZK gesamt). Für eine Anzahlung von 10.000 CZK zzgl. USt. (12.100 CZK) wurde bereits ein Steuerbeleg ausgestellt und bezahlt. Die Schlussrechnung muss dann Folgendes zeigen:

1
2
3
4
5

<cac:LegalMonetaryTotal>
  <cbc:TaxInclusiveAmount currencyID="CZK">30250.00</cbc:TaxInclusiveAmount>
  <cbc:PrepaidAmount currencyID="CZK">12100.00</cbc:PrepaidAmount>
  <cbc:PayableAmount currencyID="CZK">18150.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Ohne PrepaidAmount besteht die Rechnung die EN-16931-Validierung trotzdem - sie fordert vom Kunden nur erneut die vollen 30.250 CZK. Führt das Quellsystem Anzahlungen mit (bei ISDOC in TaxedDeposits/NonTaxedDeposits), muss deren Summe bei jedem Export in BT-113 einfließen, nicht nur als Belegverweis erscheinen.

Gutschrift oder Lastschrift?

Beide sind Korrekturbelege, nur in entgegengesetzter Richtung:

• Eine Gutschrift (tschechisch: dobropis) mindert den geschuldeten Betrag - wird als CreditNote, Code 381, gesendet.
• Eine Lastschrift/Belastungsanzeige (tschechisch: vrubopis) erhöht den geschuldeten Betrag - wird als Invoice, Code 384, gesendet, da BIS 3.0 keinen DebitNote-Dokumenttyp kennt.

Beide sollten cac:BillingReference mit Verweis auf die ID des Originalbelegs tragen, damit das Buchhaltungssystem des Empfängers die Korrektur dem richtigen Vorgang zuordnet, statt sie als eigenständigen Beleg zu behandeln.

VAT Category Code und VATEX: warum 0 % USt. nicht genügt

BT-118 (cbc:ID in cac:TaxCategory) legt den steuerlichen Regime der Lieferung fest - nicht, wie viel USt. auf der Rechnung steht. Ein USt.-Betrag von 0,00 bedeutet für sich genommen nicht Kategorie Z: Es kann sich um eine steuerfreie Lieferung (E), eine innergemeinschaftliche Lieferung (K), eine Ausfuhr (G), eine Umkehr der Steuerschuldnerschaft (AE) oder einen Umsatz außerhalb des Anwendungsbereichs der USt. (O) handeln. Kategorie Z gilt nur dort, wo das Gesetz tatsächlich einen Nullsatz vorsieht.

Für jede Kategorie außer S und Z ist zusätzlich ein Grund anzugeben - entweder als VATEX-Code (BT-121, cbc:TaxExemptionReasonCode) oder als Freitext (BT-120, cbc:TaxExemptionReason), idealerweise beides. Das FAQ der Finančná správa SR (August 2026) empfiehlt, BT-121 primär und BT-120 als ergänzenden Erklärtext zu verwenden. Die Basiszuordnung für slowakische Verhältnisse:

VATEX ist ein europäisches/Peppol-Verzeichnis, kein slowakisches Gesetzesverzeichnis - nicht jede Bestimmung des USt.-Gesetzes hat einen eigenen Code. Ist der genaue Grund innerhalb von Art. 132 unklar, ist der generische Code VATEX-EU-132 die sicherere Wahl gegenüber dem Raten eines konkreten Untercodes.

Unser ISDOC-zu-BIS3-Konverter (und die Gegenrichtung) berücksichtigt das inzwischen: ISDOC kennt keine eigene VAT-Category-Codeliste, führt aber zwei strukturierte Signale - LocalReverseCharge (eine Position unter inländischer Steuerschuldumkehr) und VATApplicable (eine Position außerhalb des USt.-Anwendungsbereichs) -, die jetzt korrekt auf AE/O und den passenden VATEX-Code abgebildet werden, statt beide stillschweigend als Regelsatz oder allgemein “steuerfrei” zu behandeln.

Slowakei: SK CIUS und der Stichtag 1. Januar 2027

Die slowakische Finančná správa SR definiert zusätzlich zu EN 16931/BIS 3.0 eigene Pflichtfelder (SK CIUS): Steuerentstehungsdatum (BT-7), Fälligkeitsdatum (BT-9), Handelsregisternummer und USt-IdNr. des Verkäufers (BT-30, BT-31), USt-IdNr. des Käufers (BT-48), vollständige Adressen beider Parteien (BT-35/37/38, BT-50/52/53), den USt.-Satz (BT-119) sowie bei steuerbefreiten Umsätzen den Befreiungsgrund (BT-120/121).

Die elektronische Rechnungsstellung über Peppol ist in der Slowakei seit dem zweiten Quartal 2026 freiwillig und wird ab dem 1. Januar 2027 für alle umsatzsteuerpflichtigen Unternehmen verpflichtend, übermittelt über zertifizierte Access Points. Mehr dazu in unseren Artikeln Wie die Slowakei die E-Rechnung für uns gelöst hat und den häufigen Fragen zur verpflichtenden E-Rechnung in der Slowakei.

Zusammenfassung

Bei Rechnungen an tschechische oder slowakische Empfänger reicht die reine EN-16931-Schemavalidierung nicht aus - ein Beleg mit falschem Typ-Code, fehlendem Anzahlungsabzug, ohne VS oder mit falscher USt.-Kategorie validiert trotzdem fehlerfrei. Checkliste: Korrekturbelege tragen den richtigen Typ (Gutschrift als CreditNote/381, Lastschrift als Invoice/384), Anzahlungen werden über PrepaidAmount abgezogen, Zahlungssymbole stehen in PaymentID/InstructionID, die USt.-Kategorie entspricht dem tatsächlichen steuerlichen Regime (nicht nur der Höhe der USt.) und trägt den passenden VATEX-Code, und slowakische Rechnungen enthalten alle SK-CIUS-Pflichtfelder. Genau das prüfen wir bei der Erstellung und Validierung von Rechnungen auf unserem Access Point automatisch.

Quellen: ISDOC - Formatspezifikation, Finančná správa SR - E-Rechnung, Peppol BIS Billing 3.0