Premium-To-Tax (Versicherungs-Premium Steuer-Compliance)

Wie man einen Prozess analysiert, der mit Premium-Transaktionen beginnt, mithilfe eines Event-Wissensgraphen, kausaler Prozesslogik und KI

Hinweis zur Demo: Der in diesem Beitrag gezeigte Datensatz ist ein synthetischer Demonstrationsdatensatz. Er ist bewusst nicht perfekt standardisiert: Es wurden mehrere realistische Abweichungen eingebaut, um typische Process-Mining-Fragen rund um Compliance, Nachbearbeitung, fehlende Prozessschritte, falsche Reihenfolgen und unvollständige Fälle zu veranschaulichen. Die Kennzahlen sind keine Produktivkennzahlen eines Kunden.

Wenn man Tax Compliance aus der Vogelperspektive beschreibt, klingt der Ablauf einfach: Eine Prämie wird gebucht, die Steuer wird ermittelt und berechnet, die Steuererklärung wird vorbereitet, freigegeben, eingereicht und bezahlt.

In der Realität ist ein Prozess zur Versicherungsteuer (Insurance Premium Tax, IPT) deutlich komplexer. Eine einzelne steuerrelevante Versicherungstransaktion muss operative Versicherungsdaten, Steuerermittlung und -berechnung, Buchhaltung, Abstimmung, Erstellung der Steuererklärung, Freigabe, Einreichung und Zahlung durchlaufen, bevor ein Fall wirklich abgeschlossen ist. Jedes Geschäftsobjekt trägt einen created_at-Zeitstempel, und diese Zeitstempel werden verwendet, um den tatsächlichen Prozessablauf zu rekonstruieren.

Genau bei solchen Prozessen zeigt sich der Nutzen von Process Mining: Eine einzige Prozesskarte beantwortet nicht jede fachliche Frage, und die interessanten Erkenntnisse liegen weniger im Happy Path als in den Abweichungen davon.

Die zentrale Frage lautet deshalb nicht nur: Wie visualisieren wir den Prozess?

Sondern: Wie läuft der Prozess tatsächlich ab im Vergleich zum erwarteten Prozess – wo treten Abweichungen auf, und welche davon erzeugen Compliance- oder operative Risiken?


1. Das Prozessziel: von der Prämientransaktion bis zur Steuerzahlung

Der Zweck des Prozesses besteht darin, sicherzustellen, dass Versicherungsprämientransaktionen korrekt als steuerrelevant erkannt, der richtigen Steuerjurisdiktion zugeordnet, nach den passenden Steuerregeln besteuert, korrekt berechnet und in der Buchhaltung verbucht, gegen die Finanzdaten abgestimmt, in die passende Steuererklärung aufgenommen, geprüft und freigegeben, bei der zuständigen Steuerbehörde eingereicht und schließlich durch die entsprechende Steuerzahlung beglichen werden.

Der vorgesehene Prozess folgt einer klaren Abfolge:

Prämientransaktion erfassen → Risikoort bestimmen → Steuerermittlung durchführen → Steuerbetrag berechnen → Steuer im Hauptbuch verbuchen → Steuerbeträge abstimmen → Steuererklärung vorbereiten → Steuererklärungsposition vorbereiten → Steuererklärung prüfen und freigeben → Steuererklärung einreichen → Steuerzahlung ausführen

Jeder Schritt ist als sequenzieller Prozess-Slot mit realistischen Wartezeiten zwischen den einzelnen Aktivitäten modelliert. Ein erfolgreich abgeschlossener Fall endet daher damit, dass die Steuererklärung sowohl eingereicht als auch bezahlt wurde.


2. Die Prozessschritte im Detail

Der End-to-End-Ablauf besteht aus elf Kernaktivitäten, die jeweils durch ein eigenes Quellobjekt gestützt werden.

Prämientransaktion erfassen

Quelltabelle: PREMIUM_TRANSACTION. Der Prozess beginnt, wenn eine Versicherungsprämientransaktion angelegt wird – zum Beispiel eine Neuprämie, eine Folgeprämie, eine Anpassung, eine Stornierung oder eine Erstattung im Zusammenhang mit einer Police. Sie bildet die finanzielle Grundlage für die anschließende Steuerermittlung und trägt typischerweise Policenreferenz, Prämienbetrag, Währung, Transaktionstyp, Buchungsinformationen und Buchungsstatus. Typische Dauer bis zur nächsten Aktivität: etwa 4 Stunden.

Risikoort bestimmen

Quelltabelle: RISK_LOCATION. Der Ort des versicherten Risikos wird bestimmt. Das ist für die Versicherungsbesteuerung besonders wichtig, weil der Risikoort darüber entscheiden kann, welches Land bzw. welche Jurisdiktion das Recht hat, die Versicherungsteuer zu erheben. Typische Informationen sind Land, Region, Risikoart und Gültigkeitszeitraum. Typische Dauer bis zur nächsten Aktivität: etwa 3 Stunden.

Steuerermittlung durchführen

Quelltabelle: TAX_DETERMINATION. Auf Basis der Prämientransaktion, des Risikoorts und der anwendbaren Steuerregeln wird die passende steuerliche Behandlung ermittelt – Steuerart, Steuerjurisdiktion, anwendbarer Steuercode, anwendbarer Steuersatz und Ermittlungsstatus. Die Ermittlung kann auf zentral gepflegte Regeln aus der Stammdatentabelle TAX_RULE verweisen. Typische Dauer bis zur nächsten Aktivität: etwa 2 Stunden.

Steuerbetrag berechnen

Quelltabelle: TAX_CALCULATION. Die tatsächliche Steuerschuld wird anhand der ermittelten Behandlung berechnet und enthält Bemessungsgrundlage, Steuersatz, berechneten Steuerbetrag und Berechnungsstatus. Damit entsteht der monetäre Steuerwert, der anschließend verbucht und abgestimmt wird. Typische Dauer bis zur nächsten Aktivität: etwa 4 Stunden.

Steuer im Hauptbuch verbuchen

Quelltabelle: GL_POSTING. Die Finanztransaktion und der zugehörige Steuerbetrag werden im Hauptbuch verbucht, mit Sachkonto, Buchungskreis, Soll-/Haben-Kennzeichen, Buchungsbetrag, Buchungsdatum und Buchhaltungsbelegreferenz. Die Buchung liefert den finanziellen Nachweis, gegen den die Steuerberechnung anschließend abgestimmt werden kann. Typische Dauer bis zur nächsten Aktivität: etwa 4 Stunden.

Steuerbeträge abstimmen

Quelltabelle: TAX_RECONCILIATION. Der berechnete Steuerbetrag wird mit der entsprechenden Buchhaltungsbuchung verglichen, um Abweichungen zwischen der operativen Steuerberechnung und den Finanzdaten zu identifizieren. Relevante Informationen sind Steuerberechnung, Buchhaltungsbuchung, Differenzbetrag, Abstimmungsergebnis und potenziell eine zugehörige Steuerausnahme. Die Abstimmung ist einer der wichtigsten Kontrollpunkte im Gesamtprozess. Typische Dauer bis zur nächsten Aktivität: etwa 24 Stunden.

Steuererklärung und Steuererklärungsposition vorbereiten

Quelltabellen: TAX_RETURN und TAX_RETURN_ITEM. Sobald die relevanten Transaktionen verarbeitet und abgestimmt sind, wird die Steuererklärung für den passenden Meldezeitraum vorbereitet und gruppiert die Steuerinformationen nach Rechtsträger, Steuerart, Jurisdiktion, Meldezeitraum, Fälligkeitsdatum und gesamter Steuerschuld. Einzelne Steuerberechnungen werden der Erklärung anschließend als Steuererklärungspositionen zugeordnet und stellen so die Verbindung zwischen den Berechnungen auf Transaktionsebene und der aggregierten Erklärung her. Typische Dauer bis zur nächsten Aktivität: etwa 12 Stunden bzw. etwa 36 Stunden.

Steuererklärung prüfen und freigeben

Quelltabelle: TAX_APPROVAL. Bevor die Erklärung extern eingereicht wird, wird sie geprüft und freigegeben, wobei Steuerexperten, Führungskräfte oder andere Mitglieder der Steuerorganisation beteiligt sein können. Typische Informationen sind Prüfer, Freigabestufe, Freigabestatus und die zugehörige Steuererklärung. Diese Aktivität stellt eine wichtige interne Compliance-Kontrolle dar. Typische Dauer bis zur nächsten Aktivität: etwa 24 Stunden.

Steuererklärung einreichen und Steuerzahlung ausführen

Quelltabellen: TAX_FILING und TAX_PAYMENT. Nach der Freigabe wird die Erklärung bei der zuständigen Steuerbehörde eingereicht, mit Einreichungsstatus, Behördenreferenz und Bestätigungsinformationen. Der letzte Schritt ist die Begleichung der Steuerschuld mit Zahlungsbetrag, Zahlungsstatus, Steuererklärungsreferenz und Bankreferenz. Typische Dauer zwischen Einreichung und Zahlung: etwa 48 Stunden.

Ein erfolgreich abgeschlossener Fall endet damit, dass die Steuererklärung sowohl eingereicht als auch bezahlt wurde. Alles dazwischen ist ein Kontrollpunkt, den Process Mining sichtbar machen kann.


3. Unterstützende Datenobjekte

Zusätzlich zu den operativen Aktivitäten enthält das Modell unterstützende Objekte, die Kontext liefern, ohne zwingend verpflichtende Schritte im Happy Path darzustellen.

  • POLICY repräsentiert den zugrunde liegenden Versicherungsvertrag und verknüpft Transaktionen und Risikoinformationen mit dem Versicherungsgeschäft.
  • LEGAL_ENTITY identifiziert das meldende Unternehmen bzw. den Buchungskreis, der für die Transaktion und die Steuererklärung verantwortlich ist.
  • TAX_RULE enthält die bei der Ermittlung verwendeten Steuerregeln, einschließlich Jurisdiktion, Steuerart, Satz und Regelversion.
  • USER_ORG repräsentiert Mitarbeitende, Rollen, Teams und organisatorische Informationen, die für Verantwortlichkeiten, Ausnahmebehandlung und Freigaben genutzt werden.
  • TAX_EXCEPTION speichert Ausnahmen der Steuerverarbeitung und kann mit fehlerhaften Berechnungen, Abstimmungsdifferenzen oder fehlenden Informationen verknüpft sein.

Diese Objekte bereichern die Analyse, weil sie es ermöglichen, nicht nur zu fragen, was passiert ist, sondern auch wer beteiligt war, welche Regel galt und welche Ausnahme ausgelöst wurde.


4. Prozessprobleme und Abweichungen

Der Kern des Use Case ist das bewusste Einbringen von Prozessabweichungen. Sie ermöglichen es dem Process Mining, aussagekräftige Compliance- und Effizienzprobleme zu identifizieren, statt einen perfekt standardisierten Prozess zu zeigen. Sechs besonders relevante Probleme wurden in den Datensatz aufgenommen.

Problem 1 – Bestimmung des Risikoorts wird übersprungen

Abweichungstyp: Übersprung  ·  Wahrscheinlichkeit: etwa 5 %

Screenshot: Bestimmung des Risikoorts wird übersprungenScreenshot-Platzhalter – Problem 1: Steuerermittlung ohne vorangehende Bestimmung des Risikoorts

Erwartet: Prämientransaktion → Risikoort → Steuerermittlung. Problematisch: Prämientransaktion → Steuerermittlung. In diesen Fällen wird die Aktivität zur Risikoortbestimmung übersprungen und der Prozess geht direkt zur Steuerermittlung über.

Warum das problematisch ist: Für die Versicherungsteuer kann der Ort des versicherten Risikos entscheidend für die Bestimmung der korrekten Steuerjurisdiktion sein. Das Überspringen dieses Schritts kann zu einer falschen Steuerjurisdiktion, einem falschen Steuersatz, einer falschen steuerlichen Behandlung oder zu unzureichenden Nachweisen für die Steuerentscheidung führen.

Process-Mining-Frage: Wie viele Transaktionen erhalten eine Steuerermittlung ohne vorangehende Bestimmung des Risikoorts?

Problem 2 – Steuererklärung wird vor der Freigabe eingereicht

Abweichungstyp: Falsche Reihenfolge  ·  Wahrscheinlichkeit: etwa 3 %

Screenshot: Steuererklärung vor Freigabe eingereichtScreenshot-Platzhalter – Problem 2: Einreichung erfolgt vor der erforderlichen Freigabe

Erwartet: Steuererklärung prüfen und freigeben → Steuererklärung einreichen. Problematisch: Steuererklärung einreichen → Steuererklärung prüfen und freigeben. Die erforderlichen Aktivitäten finden zwar statt, jedoch in der falschen Reihenfolge.

Warum das problematisch ist: Die Freigabeaktivität ist eine wichtige interne Kontrolle. Eine Einreichung vor der Freigabe bedeutet, dass Informationen extern übermittelt werden können, bevor die erforderliche Prüfung abgeschlossen ist – mit möglichen Folgen wie nicht autorisierten Einreichungen, fehlerhaften Erklärungen, Verstößen gegen interne Kontrollen, zusätzlichen Korrekturen und Compliance-Feststellungen.

Process-Mining-Frage: Wie oft werden Steuererklärungen vor der formalen Freigabe eingereicht? Das zeigt, warum es nicht ausreicht, nur zu prüfen, ob Aktivitäten stattgefunden haben – auch die Reihenfolge der Ausführung ist entscheidend.

Problem 3 – Steuerberechnung muss nach der Abstimmung nachbearbeitet werden

Abweichungstyp: Nachbearbeitung  ·  Wahrscheinlichkeit: etwa 8 %

Screenshot: Steuerberechnung nach Abstimmung nachbearbeitetScreenshot-Platzhalter – Problem 3: Abstimmung löst eine erneute Steuerberechnung aus

Erwartet: Steuerberechnung → Hauptbuchbuchung → Abstimmung → Steuererklärung. Problematisch: Steuerberechnung → Hauptbuchbuchung → Abstimmung → Steuerberechnung → …. Die Abstimmung identifiziert ein Problem, das dazu führt, dass die Steuerberechnung erneut ausgeführt wird.

Mögliche Ursachen: falscher Steuersatz, falsche Bemessungsgrundlage, falsche Steuerjurisdiktion, eine Differenz zwischen Steuerberechnung und Hauptbuchbuchung, eine veraltete Steuerregel oder unvollständige Quellinformationen.

Warum das interessant ist: Dies ist wahrscheinlich eine der wichtigsten operativen Ineffizienzen im Prozess, weil dadurch zusätzliche Bearbeitungszeit, manuelle Untersuchung, wiederholte Berechnungen, zusätzlicher Buchhaltungsaufwand und potenziell eine verzögerte Einreichung entstehen.

Process-Mining-Fragen: Wie oft werden Steuerberechnungen wiederholt? Welche Jurisdiktionen oder Steuerarten erzeugen die meiste Berechnungs-Nachbearbeitung? Wie viel zusätzliche Bearbeitungszeit entsteht durch fehlgeschlagene Abstimmungen?

Problem 4 – Steuererklärungspositionen müssen während der Freigabe nachbearbeitet werden

Abweichungstyp: Nachbearbeitung  ·  Wahrscheinlichkeit: etwa 5 %

Screenshot: Steuererklärungspositionen während der Freigabe nachbearbeitetScreenshot-Platzhalter – Problem 4: Die Erklärung wird während der Freigabe zur Korrektur zurückgegeben

Erwartet: Steuererklärungsposition vorbereiten → Steuererklärung prüfen und freigeben → Einreichung. Problematisch: Steuererklärungsposition vorbereiten → Freigabe → Steuererklärungsposition vorbereiten → Freigabe. Während der Prüfung identifiziert der Prüfer ein Problem mit dem Inhalt der Erklärung und gibt den Prozess zur Korrektur zurück.

Mögliche Ursachen: fehlende Transaktionen, fälschlicherweise aufgenommene Transaktionen, falsche Steuerbeträge, falscher Meldezeitraum, falsche Jurisdiktion oder unvollständige Nachweisunterlagen.

Warum das problematisch ist: Späte Nachbearbeitung ist in der Regel teurer, als ein Problem früher zu erkennen, und sie kann den Prozess näher an die gesetzliche Einreichungsfrist heranrücken.

Process-Mining-Fragen: Wie oft werden Steuererklärungen während der Freigabe zurückgegeben? Welche Teams oder Jurisdiktionen erzeugen die höchsten Freigabe-Nachbearbeitungsraten? Wie viel zusätzliche Durchlaufzeit entsteht durch Freigabe-Nachbearbeitung?

Problem 5 – Prozess stoppt nach der Abstimmung

Abweichungstyp: Abbruch  ·  Wahrscheinlichkeit: etwa 2 %

Screenshot: Prozess stoppt nach der AbstimmungScreenshot-Platzhalter – Problem 5: Eine abgestimmte Transaktion erreicht nie die Erstellung der Steuererklärung

Erwartet: Abstimmung → Steuererklärung → … → Zahlung. Problematisch: Abstimmung → ENDE. Die Transaktion wird verarbeitet und abgestimmt, aber es wird anschließend keine Steuererklärung erstellt.

Warum das problematisch ist: Eine solche Transaktion kann effektiv zwischen der operativen Steuerverarbeitung und der Steuermeldung verloren gehen – mit möglichen Folgen wie nicht gemeldeten steuerpflichtigen Transaktionen, unvollständigen Erklärungen, zu niedrig ausgewiesenen Steuerschulden, versäumten Meldepflichten und Compliance-Risiken.

Process-Mining-Frage: Welche erfolgreich abgestimmten Transaktionen erreichen nie die Erstellung der Steuererklärung? Dies ist ein Beispiel für einen unvollständigen Prozessfall.

Problem 6 – Steuererklärung wird eingereicht, aber es erfolgt keine Zahlung

Abweichungstyp: Abbruch  ·  Wahrscheinlichkeit: etwa 2 %

Screenshot: Steuererklärung eingereicht, aber nicht bezahltScreenshot-Platzhalter – Problem 6: Die Einreichung erfolgt, aber die Zahlung wird nie ausgeführt

Erwartet: Freigabe → Einreichung → Zahlung. Problematisch: Freigabe → Einreichung → ENDE. Die Erklärung wurde bei der Behörde eingereicht, aber der Prozess endet, bevor die entsprechende Zahlung ausgeführt wird.

Warum das problematisch ist: Dies ist ein besonders wichtiges Compliance-Risiko, weil die Meldepflicht möglicherweise erfüllt wurde, während die finanzielle Verpflichtung offen bleibt – was zu überfälligen Steuerschulden, Zinsen, Strafzahlungen, Zahlungserinnerungen und zusätzlicher manueller Untersuchung führt.

Process-Mining-Frage: Welche eingereichten Steuererklärungen haben keine entsprechende Steuerzahlung? Das schafft eine sehr klare Kontrolle rund um eingereichte, aber nicht bezahlte Steuererklärungen.


5. Zentrale Process-Mining-Fragen

Der resultierende Datensatz ermöglicht es der Analyse, über die reine Visualisierung des Happy Path hinauszugehen. Wichtige Fragen sind unter anderem:

  • Welcher Prozentsatz der Fälle folgt dem erwarteten Prozess, und welche Varianten treten am häufigsten auf?
  • Wo werden verpflichtende Aktivitäten übersprungen, und welche Aktivitäten treten in der falschen Reihenfolge auf?
  • Wie oft tritt Nachbearbeitung auf, und wie viel zusätzliche Durchlaufzeit erzeugt sie?
  • Wo brechen Fälle vorzeitig ab?
  • Welche Jurisdiktionen, Rechtsträger, Transaktionstypen oder Steuerarten haben die höchsten Abweichungsraten?
  • Welche Fälle wurden ohne vorherige Freigabe eingereicht, und welche eingereichten Erklärungen wurden nicht bezahlt?
  • Welche Transaktionen erreichten die Steuerermittlung ohne dokumentierte Bestimmung des Risikoorts?
  • Wo liegen die größten Abstimmungsdifferenzen, und welche Prozessteile erzeugen die längsten Wartezeiten?

Fazit: von „Wurde eingereicht?“ zu „Wie sind wir dahin gekommen?“

Die eigentliche Geschichte des Use Case ist nicht einfach, dass ein Versicherer Steuern berechnet und zahlt. Der Prozess beginnt mit einem hohen Volumen einzelner Versicherungstransaktionen, von denen jede korrekt klassifiziert, besteuert, verbucht und abgestimmt werden muss, bevor sie zu einer Steuererklärung beitragen kann.

Während die Mehrheit der Fälle dem erwarteten Prozess folgt, enthält eine kleinere Anzahl aussagekräftige Abweichungen. Einige Transaktionen überspringen erforderliche Kontrollaktivitäten. Einige Aktivitäten treten in der falschen Reihenfolge auf. Einige Fälle erfordern Nachbearbeitung, weil ein früheres Ergebnis fehlerhaft war. Andere stoppen, bevor der Steuermeldeprozess abgeschlossen ist.

Process Mining macht diese Abweichungen sichtbar und quantifizierbar. Statt nur zu fragen, ob eine Erklärung letztlich eingereicht wurde, kann die Analyse bestimmen, wie die Organisation dorthin gelangt ist, welche Kontrollen eingehalten wurden, wo zusätzliche Arbeit erforderlich war und wo potenziell riskantes Prozessverhalten auftrat.

Der Use Case demonstriert damit drei große Nutzenbereiche des Process Mining:

  1. Compliance: Identifizieren übersprungener Kontrollen, falscher Reihenfolgen, fehlender Freigaben und unvollständiger Steuerpflichten.
  2. Effizienz: Identifizieren von Nachbearbeitungsschleifen, Engpässen, unnötigen Wiederholungen und langen Wartezeiten.
  3. Transparenz: Verbinden von Steuerverarbeitung auf Transaktionsebene, Buchhaltung, Steuermeldung, Freigabe, Einreichung und Zahlung zu einer durchgängigen End-to-End-Sicht.

Transparenz allein ist nicht das Ziel. Der Nutzen liegt darin, zu verstehen, welche Kontrollen gegriffen haben, wo Arbeit wiederholt werden musste und wo eine Steuerpflicht unvollständig blieb – und anschließend danach zu handeln.