Peppol BIS nach KSeF FA(3)

Diese Seite beschreibt, wie xTool Peppol BIS Billing 3.0 (UBL-Rechnung oder Gutschrift) auf KSeF FA(3) abbildet.

Die Konvertierung ist einseitig: Peppol → KSeF. Der umgekehrte Weg (KSeF → Peppol) existiert separat und wird hier nicht beschrieben.

1

Peppol-BIS-XML  →  xtool.canonical.1_0  →  KSeF-FA(3)-XML

xTool mappt Peppol zuerst in den Canonical-Hub (xtool.canonical.1_0) und erzeugt daraus FA(3). Das Ergebnis wird gegen die offizielle FA(3)-XSD validiert.

Zum Verbinden der Organisation mit KSeF vor dem Versand: Mit KSeF verbinden. Zum automatischen Konvertieren: Validieren und konvertieren und SFTP (+fa3 im Dateinamen). Bei einem Raw PDF per SFTP nutzt xTool PDF-Erkennung nach FA(3) statt Peppol-zu-FA-Konvertierung — siehe Raw PDF mit Formatcode.

Rechnungen (Typ 380)

Eine Peppol-Handelsrechnung (InvoiceTypeCode = 380) wird zu einem Standard-KSeF-Dokument mit RodzajFaktury = VAT. Beträge werden unverändert übernommen — das Vorzeichen wird nicht geändert.

Gutschriften (Typ 381)

KSeF kennt keinen eigenen „negativen“ Dokumenttyp. Eine Peppol-Gutschrift (381) wird entweder als Korrekturrechnung (KOR) oder als Standardrechnung (VAT) mit negativen Nettobeträgen dargestellt.

KOR oder VAT

Die Wahl hängt von einer Referenz auf die Ursprungsrechnung (BG-3) ab:

Platzhalter gelten als fehlend: N/A, NA, -, none, null oder leere Zeichenkette. So entsteht kein KOR-Dokument ohne echte Originalnummer.

DaneFaKorygowanej (korrigierte Rechnung)

Nur bei KOR:

NrKSeFN = 1 gilt für alle eingehenden Peppol-Gutschriften: xTool hat keine KSeF-Nummer des Originals, weil es über Peppol ausgestellt wurde.

Beim VAT-Fallback entfällt DaneFaKorygowanej. PrzyczynaKorekty und TypKorekty werden geleert — sie sind bei VAT unzulässig.

Vorzeichen der Beträge

KSeF erwartet eine Korrektur als Delta nach der Korrektur. Bei einer mindernden Gutschrift ist das Netto-Delta negativ. xTool wendet -abs() auf Positionsnetto, Einzelpreis, Positionsrabatt und Dokumentensummen (einschließlich Zahlbetrag) an:

1

FA3_Betrag = -abs(Peppol_Betrag)

Unbedingtes × -1 würde einen bereits negativen Betrag positiv machen. -abs() verhindert das.

Dieses Vorzeichen gilt für:

• Positionen (FaWiersz): P_11 (Netto), P_9A (Einzelpreis), P_10 (Positionsrabatt, falls vorhanden)
• Kopf (Fa): P_13_x (Bemessungsgrundlagen aus den Positionen), P_15 (Zahlbetrag)

USt-Beträge werden nicht ebenso invertiert. Die Steueraufschlüsselung auf Dokumentebene (Peppol-TaxSubtotal) wird unverändert nach P_14_x übernommen. Die Zeilen-P_11_VAT wird anschließend an diese Kopf-USt angeglichen. Bei der üblichen Peppol-Konvention (positive TaxSubtotals) bleiben P_14_x und die abgeglichene P_11_VAT positiv, während Netto und Zahlbetrag negativ sind.

Hat eine Peppol-Zeile eine negative Menge, nimmt xTool den Betrag der Menge und setzt das Vorzeichen auf den Einzelpreis. KSeF erwartet bei Gutschriften eine positive Menge und einen negativen Preis.

Korrekturgrund

Peppol BIS hat im xTool-Modell kein eigenes Feld für Korrekturgrund oder Korrekturtyp. Bei KOR setzt xTool PrzyczynaKorekty immer auf Korekta faktury (vom FA(3)-Schema verlangt). TypKorekty wird nicht gesetzt.

Parteien (Podmiot)

Podmiot1 (Verkäufer)

Die Verkäufer-NIP ist pflicht. Kann xTool keine 10-stellige polnische NIP ermitteln, schlägt die Konvertierung fehl.

Podmiot2 (Käufer)

Die Käuferidentifikation wird in dieser Reihenfolge gewählt:

1. Polnische NIP (Käufer-USt-IdNr. beginnt mit PL oder 10-stellige Steuernummer)
2. EU-USt-IdNr. (Ländercode + Nummer, für nicht-PL-USt-IdNrn.)
3. Steuernummer (Land + Nummer)
4. Andere Partei-ID (Land + Nummer)
5. Endpoint-ID (Schema 9945 → PL-NIP; andere EU-USt-Schemata → EU-USt-IdNr.; übrige Schemata → ID)
6. Brak ID = 1, wenn nichts gefunden wird

Podmiot3 (Lieferempfänger)

Wird angelegt, wenn Lieferdaten eine Adresse enthalten. Rolle = 2 (Odbiorca).

Steuersätze

Ein nicht unterstützter Prozentsatz (z. B. 19 %) bricht die Konvertierung mit einer klaren Fehlermeldung ab. Eine 0-%-Zeile mit einem anderen Code als E / ZW / AE / OO schlägt nicht fehl: sie wird als 0 KR geschrieben. Innergemeinschaftliche (K) und Export-Codes (G) werden nicht auf 0 WDT bzw. 0 EX abgebildet.

Die Zeilen-USt (P_11_VAT) wird immer als Netto × Satz berechnet (übersprungen für Codes E, AE, O). Die Kopf-USt (P_14_x) bevorzugt die Steueraufschlüsselung auf Dokumentebene, sofern vorhanden. Weicht die Summe der Zeilen-USt von der Kopfaufschlüsselung ab, wird die Differenz auf die letzte Zeile dieses Satzes gelegt.

Positionen (FaWiersz)

Jede Peppol-Position wird zu einer FaWiersz (oder ZamowienieWiersz bei Anzahlungsrechnungen ZAL / KOR_ZAL):

Zahlung (Platnosc)

Der Zahlungsblock entsteht, wenn Zahlungsdaten oder ein Fälligkeitsdatum vorhanden sind.

Währung und Kurs

Ist die Rechnung nicht in PLN:

1. KodWaluty erhält die Rechnungswährung.
2. Ist ein Wechselkurs vorhanden, füllt xTool KursWalutyZ und USt-Beträge in PLN (P_14_1W, P_14_2W, P_14_3W).
3. Ohne Kurs wird eine Warnung protokolliert; die PLN-Umrechnungsfelder bleiben leer (von der XSD erlaubt).

Zusätzliche Beschreibungen (DodatkowyOpis)

Heißt eine Positionseigenschaft unit_of_measure, wird ihr Wert nach P_8A geschrieben und nicht als DodatkowyOpis angelegt.

Annotationen (Adnotacje)

Mit schema-sicheren Standardwerten:

Fußzeile (Stopka)

Dokumenthinweise (BT-22) werden zusammengeführt und nach Stopka/Informacje geschrieben.

XSD-Validierung

Das konvertierte XML wird gegen FA(3) geprüft. Dazu gehören:

• Elementreihenfolge in Sequenzen
• Pflichtfelder
• Auswahlen (z. B. NrKSeF / NrKSeFFaKorygowanej oder NrKSeFN in DaneFaKorygowanej)
• Datentypen (TKwotowy, TWybor1, TStawkaPodatku, TFormaPlatnosci)
• Zeichenkettenlängen

Validierungsfehler beenden die Konvertierung mit einer ausführlichen Meldung.

Aktuelle Einschränkungen

Rechnung vs. Gutschrift

Nächste Schritte

• KSeF verbinden — Mit KSeF verbinden.
• Konvertieren — Validieren und konvertieren.
• Per SFTP senden — Senden und Empfangen per SFTP.