E-Invoicing in Polen und JPK_V7: Wie SAF-T die digitale Steuerwelt verändert


Polen gehört zu den Vorreitern in Europa, wenn es um digitale Steuerberichterstattung und strukturierte Datenmeldungen geht. Mit der Einführung von JPK_V7 wurde ein entscheidender Schritt in Richtung SAF-T-basierter Steuerkontrolle gemacht – und gleichzeitig die Grundlage für moderne E-Invoicing-Systeme geschaffen.

Gerade im Kontext von SAP Document and Reporting Compliance (DRC) zeigt sich: Klassische VAT-Reports reichen nicht mehr aus. Stattdessen müssen Unternehmen transaktionsbasierte, strukturierte Daten bereitstellen, die direkt aus den operativen Prozessen im ERP-System stammen.

Von JPK zu SAF-T – und was das für SAP DRC bedeutet

JPK (Jednolity Plik Kontrolny) ist die polnische Umsetzung des internationalen SAF-T-Standards (Standard Audit File for Tax). Technisch handelt es sich um ein XML-basiertes Format, das tief in Buchhaltungs- und Transaktionsdaten eingreift.

Mit SAP DRC wird genau diese Anforderung adressiert:
Die Lösung ermöglicht es, Daten direkt aus SAP S/4HANA oder ECC strukturiert aufzubereiten, zu validieren und im erforderlichen Format (z. B. JPK XML) bereitzustellen.

Die Einführung von JPK_V7 im Oktober 2020 markierte dabei einen Wendepunkt, da zwei bisher getrennte Welten zusammengeführt wurden:

  • Deklarative Steuerberichterstattung
  • Transaktionsbasierte Detailmeldungen

Für SAP-Kunden bedeutet das:
DRC muss sowohl klassische Steuerlogik als auch Line-Item-Level-Datenextraktion unterstützen – ohne Medienbrüche.


Aufbau von JPK_V7 aus Sicht von SAP DRC

Der JPK_V7-Standard lässt sich sehr gut entlang der DRC-Datenverarbeitung strukturieren:

1. Header-Daten

Im SAP-Datenmodell werden diese Informationen typischerweise aus Stammdaten und organisatorischen Einheiten gezogen:

  • Steuernummer (Tax Number)
  • Buchungskreis / Company Code
  • Reporting-Zeitraum

DRC-Funktion:
Aggregation und Mapping dieser Daten in die XML-Kopfstruktur.


2. Deklarativer Teil (VAT Return)

Dieser ersetzt die klassische Umsatzsteuererklärung und basiert auf:

  • Steuerkennzeichen (Tax Codes)
  • Steuerberechnung im FI-Modul
  • Aggregierten Salden

DRC-Funktion:

  • Nutzung vorhandener Tax-Reporting-Frameworks
  • Mapping von SAP-Steuerkennzeichen auf polnische Deklarationsfelder
  • Validierungsregeln vor der Übermittlung

3. Evidenzteil (Transaktionsdaten)

Der kritischste Teil – hier werden Einzeltransaktionen gemeldet:

  • Rechnungen (FI/SD/MM)
  • Geschäftspartnerdaten
  • Steuerklassifikationen wie GTU oder MPP

DRC-Funktion:

  • Extraktion von Belegpositionen (Line Items)
  • Erweiterung des Datenmodells um lokale Steuerattribute (z. B. GTU-Codes)
  • Konsistenzprüfung zwischen Belegen und Steuerlogik

Gerade hier zeigt sich der Mehrwert von SAP DRC:
Die Lösung verbindet operative Belegdaten direkt mit regulatorischen Reporting-Anforderungen.


JPK_V7 als Grundlage für E-Invoicing (KSeF)

Auch wenn JPK_V7 selbst noch kein E-Invoicing-System ist, bildet es die technische Grundlage für die nächste Entwicklungsstufe: KSeF (Krajowy System e-Faktur).

Für SAP-Systeme bedeutet das:

  • Übergang von periodischem Reporting → Echtzeit-/Near-Realtime-Kommunikation
  • Nutzung strukturierter XML-Rechnungen
  • Integration in staatliche Plattformen

SAP DRC spielt hier eine zentrale Rolle:

  • Erstellung von strukturierten E-Rechnungen
  • Integration mit Government Platforms (z. B. KSeF APIs)
  • Verarbeitung von Statusmeldungen (Accepted, Rejected, etc.)

Verbindung von E-Invoicing und SAF-T im SAP-Kontext

Langfristig verschmelzen zwei bisher getrennte Welten:

Bereich Früher Zukunft
VAT Reporting Periodisch Kontinuierlich
Datenbasis Aggregiert Transaktionsbasiert
E-Invoicing Optional Verpflichtend
SAP Rolle Reporting End-to-End Compliance Plattform

Mit SAP DRC bedeutet das konkret:

  • Single Source of Truth im ERP
  • Wiederverwendung von E-Invoice-Daten für JPK/SAF-T
  • Durchgängige Validierung entlang des gesamten Prozesses

Auswirkungen auf Unternehmen und SAP-Systemlandschaften

1. Erweiterte Datenanforderungen

In SAP müssen zusätzliche Felder gepflegt werden, z. B.:

  • GTU-Klassifikationen (oft via Custom Fields oder Add-ons)
  • MPP-Indikatoren
  • Erweiterte Tax-Attribute auf Positionsebene

DRC übernimmt hier das Mapping und die Validierung.


2. Integration von E-Invoicing-Prozessen

Mit KSeF wird SAP zum integralen Bestandteil des Rechnungsprozesses:

  • Erstellung strukturierter XML-Rechnungen aus SD/FI
  • Übergabe über DRC an staatliche Plattform
  • Empfang und Verarbeitung von Rückmeldungen

3. End-to-End Compliance im ERP

SAP DRC ermöglicht:

  • Kombination von Transaktionsdaten + Reporting
  • Reduktion externer Tools
  • zentrale Steuerung von Compliance-Prozessen

Risiken bei fehlender Integration

Ohne eine saubere DRC-Implementierung entstehen erhebliche Risiken:

  • Inkonsistente Daten zwischen SAP-Belegen und JPK-Reporting
  • Fehlende oder falsche GTU-Klassifikationen
  • Ablehnung von E-Rechnungen im KSeF
  • Automatisierte Strafmechanismen durch Behörden

Die polnischen Steuerbehörden prüfen zunehmend systematisch und datengetrieben –
Fehler werden nicht mehr manuell, sondern algorithmisch erkannt.


Fazit

Polen entwickelt sich konsequent von klassischem VAT-Reporting hin zu einer vollständig digitalisierten Steuerlandschaft mit JPK_V7, SAF-T und verpflichtendem E-Invoicing über KSeF.

Für SAP-Kunden bedeutet das:

  • SAP DRC wird zum zentralen Compliance-Enabler
  • Steuerreporting und operative Prozesse verschmelzen
  • Datenqualität im ERP wird geschäftskritisch

Unternehmen, die frühzeitig auf eine integrierte DRC- und E-Invoicing-Architektur setzen, profitieren von:

  • geringeren Compliance-Risiken
  • effizienteren Prozessen
  • und einer skalierbaren Basis für zukünftige EU-weite Digital Reporting Anforderungen

Entdecke mehr von SAP-Projektmanagement und Beratung

Jetzt abonnieren, um weiterzulesen und auf das gesamte Archiv zuzugreifen.

Weiterlesen