Vom internen Werkzeug zum SaaS: Kontoauszugsdownloads automatisieren
Wir haben ein Skript entwickelt, das unsere Wise-Kontoauszüge automatisch herunterlädt. Das lässt sich an einem Nachmittag erledigen. Die interessantere Frage, deren Beantwortung deutlich länger dauerte, war, ob dasselbe Werkzeug anderen Unternehmen mit demselben Problem helfen könnte und was für einen verantwortungsvollen Übergang nötig wäre. Der Weg vom CLI-Skript auf einem Entwicklerlaptop zu einem Dienst im Container mit E-Mail-Benachrichtigungen brachte Entscheidungen ans Licht, die eine Dokumentation verdienen – besonders für Teams, die überlegen, ob sie aus einer internen Automatisierung ein Produkt machen sollten.
Das ursprüngliche Problem
Wise bietet eine API für den Zugriff auf Kontodaten. Der Standardablauf der meisten Finanzteams besteht jedoch darin, sich am Monatsende an der Weboberfläche anzumelden und einen Kontoauszug als CSV manuell herunterzuladen. Für ein Konto mit einer Währung dauert das zwei Minuten. Bei mehreren Währungen und Wise-Konten – häufig in Unternehmen mit regionalen Zahlungsströmen – wird daraus wiederkehrender Aufwand: Jemand muss daran denken, die Schritte zuverlässig ausführen und die Dateien korrekt ablegen.
Die Wise API stellt die nötigen Endpunkte bereit. Sie können Profile auflisten, Guthaben je Währung abrufen und Kontoauszüge für beliebige Zeiträume als CSV oder PDF anfordern. Die Authentifizierung erfolgt über ein persönliches Zugriffstoken, das Sie im Wise-Entwicklerdashboard erzeugen. Mit korrekt begrenzten Berechtigungen hat es nur lesenden Zugriff auf Kontodaten und lässt sich deshalb ohne das Risikoprofil eines Tokens speichern und nutzen, das Überweisungen auslösen könnte.
Unsere erste Implementierung bestand aus etwa 80 Zeilen Python. Sie las Zugangsdaten aus Umgebungsvariablen, durchlief Profile und Währungsguthaben, erstellte Kontoauszugsanfragen für den Vormonat und schrieb die Ausgabedateien in ein lokales Verzeichnis. Wir führten sie manuell aus. Das reichte damals für unsere Bedürfnisse.
Vom Skript zum geplanten Dienst
Der Übergang von „läuft manuell“ zu „läuft automatisch“ bringt eine andere Klasse von Problemen mit sich. Ein unbemerkter Fehler bei manueller Ausführung fällt sofort auf. Ein zeitgesteuertes Skript, das am ersten Tag jedes Monats ohne Fehlermeldung scheitert, kann dagegen mehrere Monate unbemerkt bleiben. Die Lücke im Kontoauszugsarchiv entdecken Sie dann erst bei einem Audit.
Wir verlagerten das Skript in einen Docker-Container mit einem einfachen Einstiegspunkt und ergänzten ein Wrapper-Skript, das nach Abschluss eine E-Mail sendet – bei Erfolg wie bei Fehlern. Sie enthält eine Übersicht der verarbeiteten Konten und Währungen, die Anzahl heruntergeladener Dateien und deren Größen. Im Fehlerfall enthält sie die Fehlerausgabe. Das ist eine minimale Investition in Beobachtbarkeit, verändert aber die betrieblichen Anforderungen: Die Automatisierung wird nun überwacht, obwohl sie unbeaufsichtigt läuft.
Die Zeitsteuerung übernimmt GitHub Actions statt cron innerhalb des Containers. Wir verwenden einen schedule-Trigger für einen Workflow, der zu Beginn jedes Monats läuft; ein cron-Zeitplan allein kann keine Geschäftstage berücksichtigen. Um Wochenenden und Feiertage zu überspringen, ist daher eine zusätzliche Datumsprüfung im Workflow erforderlich. Er checkt das Repository aus, baut das Docker-Image bei Änderungen neu, startet den Container mit aus GitHub Secrets übergebenen Geheimnissen und lädt die Ausgabedateien als Workflow-Artefakte hoch. Diese bleiben 90 Tage erhalten und bilden ein abrufbares Archiv unabhängig von lokaler Dateispeicherung.
Der Ansatz mit GitHub Actions hat gegenüber einem cron-Job auf einem Server einen praktischen Vorteil: Er ist sichtbar. Der Ausführungsverlauf zeigt jeden Lauf, seine Dauer, seinen Exit-Code und die erzeugten Artefakte. Ein cron-Job erzeugt leicht übersehbare Protokollausgaben und hängt von der Verfügbarkeit des Servers ab. Bei einer monatlichen Aufgabe rechtfertigt eine prüfbare Ausführungshistorie in einer versionierten Workflow-Definition den geringen Konfigurationsaufwand.
Was Mandantenfähigkeit tatsächlich erfordert
Nachdem die Container-Version mehrere Monate zuverlässig gelaufen war, fragten Kollegen aus anderen Unternehmen, ob sie sie ebenfalls nutzen könnten. Die Frage klingt einfach: Können andere Ihr Werkzeug ausführen? Tatsächlich umfasst „andere führen Ihr Werkzeug aus“ eine ganze Bandbreite von Betriebsmodellen mit sehr unterschiedlichen Folgen.
Das einfachste Modell: Sie teilen Repository und Dokumentation, andere betreiben das Werkzeug selbst in ihrer eigenen GitHub-Actions- oder Docker-Umgebung, und Sie leisten keinen Support. Das ist eine Open-Source-Veröffentlichung, kein SaaS-Produkt. Die Betriebsverantwortung liegt vollständig beim Nutzer.
Der nächste Schritt: Sie betreiben das Werkzeug und die Nutzer hinterlegen ihre eigenen Wise-API-Token über eine Konfigurationsoberfläche. Nun verwahren Sie Zugangsdaten. Daraus entstehen sofort Sicherheits- und Compliance-Pflichten, die sich grundsätzlich vom Betrieb einer persönlichen Automatisierung unterscheiden. Sie müssen beantworten, wie die Zugangsdaten gespeichert werden, wer Zugriff darauf hat, was bei einer Kompromittierung des Speichers geschieht und wie Sie haften, wenn über Ihre Plattform auf das Wise-Konto eines Nutzers zugegriffen wird.
Danach kommen Abrechnung, Support, zugesagte Servicelevels und der Aufwand für den Infrastrukturbetrieb für mehrere Nutzer hinzu. Nichts davon ist unüberwindbar. Jeder Punkt erfordert jedoch eine Entscheidung über den gewünschten Entwicklungsaufwand und die wiederkehrenden Betriebskosten, die Sie tragen möchten.
Die SaaS-Bewertung
Für unsere Bewertung listeten wir die Anforderungen einer minimalen mandantenfähigen Version auf und kalkulierten jede davon ehrlich. Allein die Zugangsdatenverwaltung – Wise-API-Token sicher speichern, eine Verwaltungsoberfläche bereitstellen und Zugriffskontrollen gegen mandantenübergreifenden Zugriff umsetzen – bedeutet eine Woche Entwicklungsarbeit, bevor die eigentliche Kontoauszugsfunktion angefasst wird. Nutzer-Authentifizierung, Abrechnung, ein E-Mail-Versanddienst mit Abmeldefunktion und Monitoring für fehlgeschlagene Jobs je Mandant machen daraus ein Produkt, dessen sicherer Betrieb dauerhaft Investitionen erfordert.
Auch der Markt für dieses konkrete Werkzeug ist begrenzt. Unternehmen, die groß genug sind, um Kontoauszugsdownloads automatisieren zu wollen, haben oft bereits direkt an Wise angebundene Buchhaltungssoftware oder Finanzteams, die das Problem selbst gelöst haben. Der erreichbare Markt liegt dazwischen: Unternehmen, die den Aufwand spüren, aber noch keine integrierten Buchhaltungssysteme nutzen.
Wir kamen zu dem Schluss, dass das Werkzeug für unser Team zum damaligen Zeitpunkt kein guter SaaS-Kandidat war. Das Umsatzpotenzial rechtfertigte den Entwicklungs- und Betriebsaufwand nicht. Eine Open-Source-Veröffentlichung deckt den tatsächlichen Bedarf, ohne Verpflichtungen zu schaffen, die wir nicht dauerhaft erfüllen können.
Was wir beibehalten und was wir geändert haben
Das interne Werkzeug läuft weiterhin. Mit der Zeit haben wir es um PDF-Ausgaben zusätzlich zu CSV, den direkten Versand der Kontoauszugsdateien an eine E-Mail-Adresse statt des Abrufs von Workflow-Artefakten und konfigurierbare Zeiträume erweitert. So lässt es sich bei Bedarf für einzelne Kontoauszugsanfragen manuell starten, ohne den geplanten monatlichen Lauf zu verändern.
Der GitHub-Actions-Workflow wurde zum maßgeblichen Deployment-Verfahren. Wir dokumentieren ihn in der README des Repositorys so ausführlich, dass jemand, der das Werkzeug sechs Monate nicht angefasst hat, seine Funktion und Bedienung verstehen kann. Diese Disziplin lohnt sich für jede interne Automatisierung: Behandeln Sie interne Werkzeuge so, als müssten Sie sie jemand anderem übergeben – irgendwann wird das nötig sein.
Die dauerhaft wichtigste Erkenntnis dieses Projekts betrifft den Abstand zwischen „das funktioniert für uns“ und „das funktioniert für andere“. Interne Werkzeuge sind auf Ihre konkreten Rahmenbedingungen zugeschnitten: den Umgang mit Zugangsdaten, Konventionen für die Dateiablage und Ihre E-Mail-Infrastruktur. Sie für andere nutzbar zu machen, erfordert mehr als eine zusätzliche Konfigurationsdatei. Annahmen müssen aus der Implementierung herausgelöst werden, die Sie erst als solche erkennen, wenn jemand anderes das Werkzeug nutzt und daran scheitert.