Migration von Finanzreports: Der neue Report zeigt zuerst dieselbe Zahl
ErgebnisSenior-Entwickler fürs Team
Für ein Fintech bauen wir Finanzreports als eigene Ansichten neu. Wir arbeiten in ihrem Repo mit ihren Entwicklern. Die Regel: Die neue Zahl muss zuerst mit der alten übereinstimmen.
tschechisches FintechKlient
Wie es anfing: die Berichte waren nur aus einem älteren Tool eingebettet · Dauer: seit Juli 2026
Überblick
Ein tschechisches Fintech erstellt das Finanzreporting für eine Unternehmensgruppe. GuV, Bilanz, Cashflow und die Übersicht für die Geschäftsführung waren aus einem älteren Reporting-Tool eingebettet. Die Firma wollte sie als eigene Ansichten in ihrer App haben.
Wir arbeiten in ihrem Repository und in ihrem Prozess. Ihr Team verantwortet das Datenmodell. Wir bauen die Ansichten darauf.
Die Herausforderung
Ein Finanzer traut keinem neuen Report, der eine andere Zahl zeigt als der alte. Auch nicht, wenn die neue Zahl „richtiger“ ist. Für ihn ist das nur eine weitere Zahl, die man erklären muss.
Schlimmer ist eine Zahl, die falsch ist, und niemand merkt es. Genau das ist passiert.
Der Moment: Der Report war falsch und ist nicht abgestürzt
Bei den großen Firmen der Gruppe zeigte der Report falsche Summen. Kein Fehler, keine Warnung. Die Datenschnittstelle hat ein Zeilenlimit und hat die Daten bei großen Firmen stillschweigend abgeschnitten.
Unser erster Fix hat das Laden beschleunigt. Das Problem hat er nicht gelöst. Bemerkt hat es der Entwickler des Kunden, nicht wir.
Wir haben es anders gelöst. Der Report fragt Monat für Monat ab und fügt die Ergebnisse zusammen. Die Jahresansicht stimmt mit dem alten Report überein. Seitdem prüfen wir bei jedem Report die Summen gegen die Quelle.
Die Regeln, die daraus entstanden sind
- Der neue Report rechnet zuerst wie der alte. Auch das, was wir heute anders rechnen würden. Verbesserungen kommen erst, wenn die Zahlen stimmen.
- Gemeinsame Kennzahlen gehören ins Datenmodell, nicht in die Ansicht. Sonst rechnet jede Ansicht sie auf ihre Art, und der Finanzer sieht drei Zahlen. Wo wir wegen eines Termins in der Ansicht gerechnet haben, haben wir es als Schuld mit einem Verantwortlichen notiert.
- Ein Kommentar bleibt bei der Zahl, zu der er gehört. Der Controller schreibt, warum der Umsatz gesunken ist. Dann bucht die Buchhaltung um, und die Zahl ändert sich. Ein kommentierter Report friert deshalb die Werte samt Kommentar ein.
- Jede Firma zeigt, von welchem Tag ihre Daten sind. Eine Firma hat den Abschluss gestern gemacht, eine andere letzte Woche. Der konsolidierte Report darf das nicht verstecken.
Was noch nicht stimmt
Bei Firmen mit konzerninternen Transaktionen gibt es noch eine kleine Abweichung zum alten Report. Die Ursache liegt im Datenmodell, und das Datenteam des Kunden kümmert sich darum. Solange sie nicht stimmt, betrachten wir den Report für diese Firmen nicht als fertig.
Was sich geändert hat
GuV, Bilanz und Cashflow laufen auf dem neuen Datenmodell ohne die alten eingebetteten Reports. Die Firma hat ihre Reports in der eigenen App, im eigenen Code und mit einem eigenen Team, das sie versteht.
Für einen CTO zählt eines: Der externe Entwickler hat in ihrem Repo und über ihr Review gearbeitet. Keine Blackbox, die das Team später übernehmen müsste.
Was wir geliefert haben
- Finanzreports in der eigenen App
- Prüfung der Summen gegen die Quelle
- Kommentare mit eingefrorenen Zahlen
- Datenstand bei jeder Firma


