Quellensteuer-Software für KVGs: warum sie anders arbeiten muss

Banken und Verwahrstellen haben die Quellensteuer-Erstattung über Jahrzehnte geprägt, und die Software für diesen Prozess merkt man das an. Sie funktioniert, solange der Anwender die Lagerstellen kennt, die Zentralverwahrer im Blick hat und die Verwahrkette eines Bestands ohne Nachfragen rekonstruieren kann. Eine Kapitalverwaltungsgesellschaft (KVG), die den Prozess heute selbst übernimmt, arbeitet unter anderen Voraussetzungen, als die Software annimmt.

Ich beschreibe hier, warum dasselbe System, das bei einer Bank zuverlässig läuft, an einer KVG an Grenzen stößt. Und woran man in der Ist-Analyse erkennt, dass meist ein Datensatz fehlt, den vorher niemand brauchte, und die Software selbst gar nicht versagt.

Die Verwahrstelle als Eigentümerin des Prozesses

Historisch lag die Rückforderung von Quellensteuer bei der Verwahrstelle. Sie kannte die Lagerstellen, führte die Bestände und wusste, über welche Zwischenstationen ein Wertpapier gelaufen war. Die KVG hielt sich an das Investmentgesetz und an die Anlagestrategie, die operative Verantwortung für die Depotkette lag weiter unten. Der Datensatz, den ein Reclaim-System braucht, war also in der eigenen Hausbank vorhanden, und zwar als Teil des laufenden Buchhaltungssystems und nicht als Export.

Software für die Quellensteuer-Erstattung wurde für genau diese Lage gebaut. Sie setzt voraus, dass die Verwahrkette pro Bestand vorliegt: jede Lagerstelle, jeder Zentralverwahrer, jede Umschichtung im Laufe des Jahres. Fehlen diese Daten, fordert das System sie an der Stelle an, an der in der Bankwelt der Depotstamm sitzt.

Was sich ändert, wenn die KVG den Prozess übernimmt

Manche KVGs entscheiden, die Erstattung selbst zu steuern, etwa weil sie mehrere Verwahrstellen nutzen, Vorabbefreiungen strategisch steuern wollen oder Meldepflichten wie die neue Kapitalertragsteuer-Meldepflicht nach §§ 45b, 45c EStG eigenverantwortlich abbilden müssen. Dann verschiebt sich die Eigentümerschaft. An der KVG sitzt nun ein Team, das die Fachlichkeit des Reclaim-Prozesses versteht, die Depotkette aber nicht zwangsläufig im eigenen Haus vorliegen hat.

Die Daten liegen weiter bei den Verwahrstellen, verteilt, in unterschiedlichen Formaten und mit unterschiedlicher Granularität. Eine KVG mit mehreren Dutzend Fonds und zwei oder drei Verwahrstellen bekommt kein einheitliches Bild der Verwahrkette geliefert, sondern Ausschnitte. Das Reclaim-System setzt aber das vollständige Bild als selbstverständlich voraus.

Die Software ist deshalb nicht schlecht. Es fehlt der Eingangsdatensatz, und im Betrieb wirkt dieser Mangel wie ein Fehler der Software, obwohl es ein Problem der Datenhaltung ist.

Die Verwahrkette als Eingangsdatensatz und warum sie oft fehlt

Die Verwahrkette ist die Abfolge der Lagerstellen, über die ein Bestand im Laufe eines Steuerjahres läuft. Sie beginnt beim Zentralverwahrer, kann über eine Zwischenlagerstelle gehen und endet bei der depotführenden Stelle. Für die Erstattung bestimmt diese Kette, welche Quellensteuer anfällt, welche Befreiung greift und bei welcher Stelle die Erstattung beantragt wird.

In einer Bank liegt diese Kette im Buchungssystem. In einer KVG liegt sie, wenn überhaupt, in einer Mischung aus Verwahrstellen-Reports, manuell gepflegten Tabellen und Einzelfällen, in denen der Fondsmanager es noch weiß. Das ist kein Vorwurf an die KVG, sondern die Folge einer historischen Aufgabenteilung, die gerade neu verhandelt wird.

Wo die Verwahrkette fehlt, sieht man typischerweise drei Symptome:

• Anträge werden mit Platzhaltern gefüllt, weil die Lagerstelle „irgendwo“ eingetragen wird.
• Erstattungen bleiben liegen, weil niemand die Zuständigkeit der Zwischenlagerstelle klären kann.
• Vorabbefreiungen werden nicht oder zu spät beantragt, weil die Kette zum Stichtag nicht vorliegt.

Alle drei zeigen, dass ein Datensatz, den das System als Eingang erwartet, im Haus nicht existiert.

Was das für Konfiguration, Fachbereich und Entwicklung bedeutet

Wer ein Reclaim-System an einer KVG einführt, muss die Verwahrkette als Pflicht-Eingangsdatensatz behandeln. Das betrifft drei Gruppen.

In der Konfiguration ist die Schnittstelle zu den Verwahrstellen die kritische Vorstufe und mehr als ein Import unter vielen. Sie muss Formattoleranz, Historie und Umschichtungen abbilden und erkennen, wenn eine Kette lückenhaft ist, statt die Lücke stillschweigend aufzufüllen.

Im Fachbereich muss jemand die Verantwortung für die Qualität der Verwahrkette tragen. Oft ist das eine neue Rolle. Früher lag diese Verantwortung stillschweigend bei der Verwahrstelle, jetzt muss die KVG sie ausdrücklich vergeben: mit Namen, mit Prozess und mit dem Recht, bei Lücken nachzufragen.

In der Entwicklung muss das System mit unvollständigen Ketten umgehen können. Ein Fehlerbericht „Lagerstelle fehlt“ hilft mehr als eine automatische Plausibilisierung, die den Mangel überdeckt. Eine sichtbare Lücke lässt sich korrigieren. Eine versteckte Lücke führt im Folgejahr zu einer Erstattung, die niemand mehr erklären kann.

Wie man beginnt: Fragen für die Ist-Analyse

Bevor eine Software ausgewählt oder konfiguriert wird, lohnt sich eine Ist-Analyse, die genau diesen Datensatz in den Mittelpunkt stellt. Die Fragen sind einfach, die Antworten meist unbequem.

• Wer im Haus kennt die Verwahrkette pro Fonds zum Stichtag, und zwar namentlich?
• In welchem Format liegen die Verwahrstellen-Reports vor, und wie aktuell sind sie?
• Wie werden Umschichtungen zwischen Lagerstellen im Laufe des Jahres erfasst?
• Wer entscheidet bei Lücken, ob nachgefragt oder ein Platzhalter gesetzt wird?
• Gibt es einen Ort, an dem die Kette über das Jahr nachvollziehbar bleibt, oder lebt sie nur im Kopf der Verwahrstelle?

Wer diese Fragen nicht beantworten kann, hat ein Eigentümerschaftsproblem. Ein Tool löst das nicht. Das Haus muss entscheiden, wer die Verwahrkette pflegt.

Ein Beispiel, das die Lücke zeigt

Nehmen wir eine KVG mit drei Verwahrstellen und rund vierzig Fonds. Im Jahr X wird ein Bestand im Sommer von einer Lagerstelle an eine andere umgelagert, ein ganz normaler Vorgang. Im Dezember fällt eine Erstattung an. Das Reclaim-System fragt die Verwahrkette zum Stichtag ab und bekommt als Antwort eine Lagerstelle. Welche der beiden es ist, steht im Bericht der Verwahrstelle, und den gibt es in dieser Form im Haus nicht.

Der Sachbearbeiter trägt eine der beiden Lagerstellen ein, meist die, die zum Stichtag aktuell ist, und die Erstattung wird beantragt. Im besten Fall kommt sie durch. Realistischer ist, dass sie nicht durchkommt, weil die zuständige Stelle die andere Lagerstelle erwartet. Falsch gemacht hat dabei niemand etwas. Der Datensatz, der den Unterschied erklären würde, lag einfach nicht vor.

Das Beispiel ist erfunden, aber typisch. Der Schaden entsteht dort, wo das Haus entscheidet, wie es mit einer Lücke umgeht, und nicht in der Software. Wer diese Stelle vor der Einführung kennt, vermeidet die meisten Folgeschäden.

Was wir daraus lernen

Die Erstattung von Quellensteuer hängt an einem Datensatz, der historisch bei der Verwahrstelle lag und den eine KVG, die den Prozess übernimmt, erst aufbauen muss. Software kann diese Lücke nicht füllen. Sie kann nur zeigen, wo sie besteht.

Wer eine KVG bei dieser Einführung begleitet, sollte deshalb mit der Frage anfangen, wer im Haus die Verwahrkette kennt, und erst danach mit der Software. Aus der Antwort ergibt sich fast alles Weitere: die Schnittstelle, die Konfiguration, die Rolle des Fachbereichs und die Art, wie das System mit Lücken umgeht.

Stehen Sie vor derselben Frage, etwa nach einer Verwahrstellen-Migration, bei einem Systemwechsel oder beim Aufbau eines eigenen Reclaim-Teams? Dann lohnt sich ein Erstgespräch. Wir schauen uns an, wo die Verwahrkette heute liegt und was es braucht, damit sie ein verlässlicher Eingangsdatensatz wird.