E-Rechnung in DE, ES und PL: Ein Datensatz, drei Adapter
Verkaufen Sie in Warschau, München und Valencia, haben Sie bereits drei E-Rechnungsmaschinen. Hier der gemeinsame Datensatz, die Validatoren je Markt, die Aufbewahrungsfristen und die Transporte, die nicht ineinander laufen dürfen.
E-Rechnung in DE, ES und PL: Ein Datensatz, drei Adapter
Ein Betrieb, der einen deutschen Großhändler, eine spanische Hotelgruppe und einen polnischen Distributor fakturiert, "macht nicht E-Rechnung". Er betreibt drei rechtliche Maschinen, die eine kaufmännische Tatsache teilen: wer was gekauft hat, zu welchem Preis, in welcher Währung, zahlbar wie.
Legen Sie diese Tatsache in drei unverbundene Werkzeuge, rechnen Sie sich in ein viertes hinein. Legen Sie sie in einen Datensatz mit drei Adaptern.
Der gemeinsame Datensatz
Jeder Markt braucht denselben Kern:
- Rechtliche Identität von Verkäufer und Käufer (Name, Steuer-ID, Anschrift, in Spanien zusätzlich die SIF-Identität der Software)
- Dokumenttyp (Rechnung, Gutschrift, Anzahlung, Korrektur)
- Positionen: Menge, Netto, USt-Satz, Befreiungen, Reverse Charge
- Summen, die arithmetisch zu den Positionen passen
- Währung, Kursquelle und Datum, wenn nicht die lokale Steuerwährung
- Zahlungsmittel (IBAN, Konditionen, in Polen später die KSeF-Nummer im Verwendungszweck)
- Käuferreferenzen (Bestellung, BT-10, Leitweg-ID, spanische Verwaltungsreferenzen)
- Ausstellungsdatum, Steuerpunkt, Fälligkeit
Dieser Datensatz ist keine EN-16931-Datei. EN 16931 ist eine Projektion. FA(3) ist eine Projektion. Facturae ist eine Projektion. Speichern Sie nur das XML, das Sie an KSeF geschickt haben, können Sie ohne verlustreichen Rückweg keine XRechnung erzeugen.
Validatoren sind je Markt Pflicht, nicht optional
| Markt | Validator | Fehler, die wie "die Rechnung ist raus" aussehen |
|---|---|---|
| Polen | KSeF-Schema plus Geschäftsregeln, dann der produktive Knoten | Fehlercodes auf der Sitzung; keine KSeF-Nummer, keine Rechnung |
| Deutschland | Schema plus KoSIT- / EN-16931-Geschäftsregeln | Leeres BT-10, Rechenfehler, falsches ZUGFeRD-Profil. Der Empfänger lehnt ab oder parkt sie. |
| Spanien | Facturae / UBL / CII, Signatur, Verifactu-Hash und QR falls SIF gilt | Unsigniertes PDF, fehlender QR, Plattformablehnung, verpasster 4-Tage-Status |
Fahren Sie den Validator vor dem Transport. Ein deutscher Versand von ZUGFeRD Minimum (nicht EN 16931) ist eine erfolgreiche E-Mail einer Nicht-Rechnung. Ein spanischer Versand ohne Signatur ist ein PDF mit Anspruch.
Transporte dürfen nicht lecken
KSeF-Offline-Modi sind ein polnisches Rechtsdesign. Sie sind kein Weg, "deutsche Rechnungen in die Warteschlange zu legen, wenn SMTP ausfällt". Deutscher E-Mail-Ausfall ist ein erneuter Sendeversuch auf dem Kanal, kein Offline-Clearance. Der spanische Verifactu-Störungsmodus ist eine SIF-Regel mit späterem Nachzug. TicketBAI setzt weiter Konnektivität voraus und hat keine höfliche Offline-Geschichte.
Die Konfiguration sitzt am Käufer: Polen immer KSeF für USt-Rechnungen im Anwendungsbereich; Deutschland E-Mail oder Peppol je Peppol-ID; Spanien die akkreditierte Plattform, auf der die Gegenpartei ist, mit Vernetzung. Der Betreiber soll den Kanal nicht aus einer globalen Auswahlliste wählen.
Archiv heißt nicht "das PDF behalten"
| Markt | Was unverändert bleiben muss | Heutige Arbeits-Aufbewahrung |
|---|---|---|
| Polen | FA(3) und das UPO, Signatur intakt | 10 Jahre (die KSeF-Sitzungshistorie ist nicht Ihre einzige Kopie) |
| Deutschland | Der strukturierte Datensatz (XML, oder PDF/A-3 mit eingebettetem XML). Ein ZUGFeRD zu einem einfachen PDF flachzumachen zerstört die GoBD-Konformität. | 10 Jahre. Der BMF-Aktionsplan vom 16. Juli 2026 schlägt 15 Jahre vor (Maßnahme 19) und Spiegelspeicherung für manche Drittlandsfälle (Maßnahme 20). Legen Sie 15 zugrunde. |
| Spanien | Signierte E-Rechnung, Verifactu-Kette, TicketBAI-Datei wo sie gilt | AEAT- / Provinzregeln folgen; nicht nur das Ticket-PDF behalten |
Ein Objektspeicher mit rechtlichen Kennzeichen je Dokument ist billiger als drei "Archivprodukte". Der Export muss die Originalbytes liefern, keine neu erzeugte Visualisierung.
Status und Zahlungseingang sind marktspezifisch
Polen: Zugang gilt mit der KSeF-Vergabe als bewirkt, UPO als Zustellnachweis, KSeF-Nummer im Verwendungszweck ab dem 1. Januar 2027 für die Zuordnung.
Deutschland: kein staatlicher Zahlungsstrom. Die Altersstruktur sind Ihre Bücher plus die Bank. Das Mahnwesen ist zivilrechtlich (Mahnung, BGB § 286 / § 288).
Spanien: Annahme, Ablehnung, wirksames Zahlungsdatum, 4 Kalendertage. Die Altersstruktur sollte den Rechtsstatus neben den überfälligen Tagen zeigen.
Eine einzige DSO-Zahl über PL, DE und ES ist eine Management-Eitelkeit, wenn Sie nicht auch nach Markt splitten. Spanische 80-Tage-Wartezeiten der KMU und polnische 53-Tage-Durchschnittsverzüge (Coface Payment Survey 2026) sind verschiedene Krankheiten. Sie brauchen verschiedene Nachweispakete.
Bauordnung für einen Betreiber in mehreren Märkten
- Kanonische Rechnung und Käuferstammdaten (Steuer-IDs, Peppol-IDs, Rechnungspostfächer, Plattformmitgliedschaft, Leitweg-ID).
- Polnischer Adapter, wenn Sie bereits in KSeF ausstellen. Er lehrt Sie, dass das rechtliche Artefakt nicht das PDF ist.
- Deutscher Validator und doppelte Syntax vor dem 1. Januar 2027, wenn Ihr Gesamtumsatz 2026 über 800.000 EUR liegt.
- Spanisches SIF / Verifactu, wenn Sie in Spanien Bargeld annehmen oder Tickets ausstellen; Crea-y-Crece-Konnektor nach dem Kalender der Ministerialverordnung.
- Zahlungseingang: SEPA-Verwendungszweck heute, KSeF-Nummern 2027, spanischer Zahlungsdatum-Status als eigenständiges Feld.
Plandesk ist dieser Stack für Läden und Restaurants, die bereits Kasse und B2B auf einer Datenbank fahren. Die Rechnung ist eine Zeile. Die Adapter sind kein PDF-Aufsatz.
Dieses Material dient der allgemeinen Information und stellt keine Rechts- oder Steuerberatung dar. Prüfen Sie im Einzelfall die aktuellen Regelungen oder konsultieren Sie einen qualifizierten Berater.