Nordlet

← Blog

Entwicklung einer Buchhaltungs-API, die einer Betriebsprüfung standhält

Ein praktischer Leitfaden zu den Sicherheits- und Prüfungskontrollen, die eine Finanz-API benötigt, bevor niederländische Unternehmen ihr ihre Buchführung anvertrauen.

Nordlet Team · · 10 Min. Lesezeit

Eine Buchhaltungs-API, die bei einer Zahlungserfassung 200 OK zurückgibt, hat Ihnen fast nichts gesagt. Sie hat weder bestätigt, dass das Hauptbuch (Ledger) den Eintrag erfasst hat, noch dass der Akteur dazu autorisiert war, noch dass der Betrag die Validierung bestanden hat, oder dass jemand mit entsprechenden Befugnissen ihn genehmigt hat. Für Unternehmen in den Niederlanden, wo die Steuerbehörde erwartet, dass Aufzeichnungen rekonstruierbar sind und sieben Jahre lang aufbewahrt werden, ist genau diese Lücke zwischen „die Anfrage war erfolgreich“ und „die Bücher stimmen“ der Grund, warum Betriebsprüfungen (Audits) schiefgehen.

Prüfungssicherheit (Audit-readiness) ist ein operatives Designziel, kein Zertifikat. Es bedeutet, dass die API eine lückenlose Kette aufrechterhält: vom authentifizierten Akteur zur autorisierten Aktion, über die validierte Zustandsänderung und Genehmigung zum Hauptbuchergebnis bis hin zum manipulationssicheren Nachweis. Im Folgenden geht es darum, diese Kette bewusst aufzubauen, anstatt blind darauf zu vertrauen, dass Authentifizierung und TLS dies schon regeln.

Was eine Buchhaltungs-API „prüfungssicher“ macht

Ein Wirtschaftsprüfer (Auditor), der eine Transaktion rekonstruiert, muss eine bestimmte Abfolge von Fragen beantworten. Wer hat sie initiiert? War die Person dazu berechtigt? Hat die Änderung die buchhalterische Validierung bestanden? Wer hat sie genehmigt? Was wurde im Hauptbuch erfasst? Kann dieser Datensatz nachträglich spurlos geändert werden?

Wenn Ihre API nicht alle sechs Fragen anhand ihrer eigenen Protokolle und ihres Datenmodells beantworten kann, ist sie nicht prüfungssicher – ganz gleich, wie sauber der Code aussieht. Die meisten APIs meistern die erste Frage gut und versagen bei den restlichen.

Die Kontrollmechanismen, die diese Lücke schließen, lassen sich in einige Gruppen unterteilen: expliziter buchhalterischer Status, mehrschichtige Autorisierung, zweckgebundene Authentifizierung (scoped authentication), idempotente Schreibvorgänge, serverseitige Validierung, Funktionstrennung (Segregation of Duties) und manipulationssichere Protokollierung. Sie verstärken sich gegenseitig. Eine schwache Autorisierung untergräbt ein starkes Audit-Log, da Sie nicht mehr darauf vertrauen können, dass der protokollierte Akteur überhaupt berechtigt war, die Aktion durchzuführen.

Modellieren Sie Buchhaltungsstatus, bevor Sie Endpunkte modellieren

Der häufigste Designfehler besteht darin, jeden Finanzdatensatz als frei bearbeitbares Objekt mit create, read, update, delete zu behandeln. Die Buchhaltung funktioniert so nicht, und einem Prüfer wird sofort auffallen, wenn eine gebuchte Journalbuchung (Journal Entry) stillschweigend überschrieben werden kann.

Jede finanzrelevante Ressource benötigt einen expliziten Zustandsautomaten (State Machine). Eine Journalbuchung oder Zahlung durchläuft typischerweise folgende Phasen:

draft → submitted → approved → posted → settled

Korrekturen spulen diesen Pfad nicht zurück. Eine gebuchte Buchung, die fehlerhaft ist, erhält eine verknüpfte Stornierung (Reversal) oder eine Ausgleichsbuchung (Compensating Adjustment). Das Original bleibt unangetastet.

Ein praktikables Regelwerk:

  • Entwürfe (Drafts) können von autorisierten Benutzern bearbeitet werden.
  • Eingereichte Datensätze dürfen nur von zugelassenen Rollen bearbeitet oder in den Entwurfsstatus zurückversetzt werden.
  • Genehmigte Datensätze erfordern kontrollierte Änderungen und eine erneute Genehmigung.
  • Gebuchte Datensätze können nicht überschrieben oder gelöscht werden, sondern nur storniert oder berichtigt.
  • Änderungen in abgeschlossenen Buchungsperioden erfordern eine erweiterte Autorisierung, eine Begründung und ein Audit-Ereignis.

Der Versuch eines unzulässigen Statuswechsels, etwa die Bearbeitung eines gebuchten Eintrags, sollte einen stabilen Fehler zurückgeben und dennoch einen Audit-Eintrag schreiben. Der gescheiterte Versuch ist ebenfalls ein Nachweis.

Hier beweist ein unveränderliches Hauptbuch der doppelten Buchführung (Double-Entry Ledger) seinen Wert. Nordlets Hauptbuch ist so konzipiert, dass jede Transaktion als ausgeglichener, dauerhafter Eintrag erfasst wird. Das Gleichgewicht wird zum Zeitpunkt des Commits durch einen Datenbank-Trigger erzwungen, und Korrekturen erfolgen durch Stornierungen statt durch Überschreibungen. Diese Einschränkung fühlt sich während der Entwicklung restriktiv an, wird aber genau zu dem, worauf Ihr Buchhalter bei einer Betriebsprüfung vertraut.

Autorisieren Sie jede Anfrage, authentifizieren Sie sie nicht nur

Authentifizierung beweist, wer aufruft. Sie sagt nichts darüber aus, ob der Aufrufer eine bestimmte Rechnung, ein Journal oder einen Rechtsträger (Legal Entity) anfassen darf. Das OWASP API Security Project setzt eine fehlerhafte Autorisierung auf Objektebene (Broken Object-Level Authorization) ganz oben auf seine Risikoliste, und zwar genau deshalb, weil APIs Objektkennungen offenlegen, die bei fehlenden Prüfungen einen mandantenübergreifenden Zugriff leicht machen.

Jede Anfrage an eine Finanz-API sollte anhand einer Kombination von Faktoren autorisiert werden, nicht nur durch ein Token:

  • authentifizierter Akteur
  • Client-Anwendung oder Dienstkonto (Service Account)
  • Mandant (Tenant)
  • Rechtsträger
  • Ressourcen-ID
  • angeforderte Operation
  • aktueller Ressourcenstatus
  • Betrag oder Transaktionsgrenzwert

Zwei praktische Regeln sind wichtiger als der Rest. Erstens: Leiten Sie Mandanten- und Benutzerkontext aus der authentifizierten Identität ab und weisen Sie jegliche vom Client gelieferten Mandanten- oder Rollen-Claims ab, die hiermit in Konflikt stehen. Ein Aufrufer sollte niemals selbst behaupten dürfen, für welches Unternehmen er handelt. Zweitens: Verwenden Sie Deny-by-Default (standardmäßige Verweigerung). Wenn keine Richtlinie eine Aktion explizit erlaubt, schlägt sie fehl.

Testen Sie beide Richtungen. Horizontalen Zugriff, bei dem ein Mandant auf die Daten eines anderen Mandanten zugreift, und vertikalen Zugriff, bei dem ein normaler Benutzer Genehmigungs-, Buchungs- oder Exportfunktionen erreicht. Beides kommt häufig vor und beides ist bei Buchhaltungsdaten katastrophal.

Das Rollenmodell von Nordlet, das Inhaber (Owner), Administrator, Buchhalter, Manager, Entwickler und Betrachter (Viewer) über mehrere Unternehmen hinweg unter einem Konto umfasst, existiert, um diese Trennung durchsetzbar zu machen, anstatt sie nur anzustreben. Eine Entwicklerrolle, die Rechnungsentwürfe erstellen kann, sollte keine Zahlungen freigeben dürfen.

Beschränken Sie Token auf Geschäftsfunktionen, nicht auf CRUD-Verben

Für den delegierten Zugriff (Delegated Access) sollten Sie aktuelle OAuth 2.0-Sicherheitsrichtlinien anstelle von wiederverwendbaren Passwörtern oder breiten statischen API-Schlüsseln (API Keys) verwenden. RFC 9700 ist die aktuelle Best Current Practice und legt klare Anforderungen für Clients und Autorisierungsserver fest: validierte Redirect-URIs, PKCE (wo anwendbar), Issuer- und Audience-Prüfungen, kurze Access-Token-Lebensdauern sowie Refresh-Token-Rotation mit Widerruf (Revocation).

Bei der Definition von Scopes zeigt sich die buchhaltungsspezifische Denkweise. Generische Scopes wie read und write sind für die Funktionstrennung nahezu nutzlos. Scopes sollten auf Berechtigungen abgebildet werden:

  • journal:create und journal:approve sind separate Scopes.
  • Das Erstellen einer Zahlungsanweisung gewährt nicht die Erlaubnis, diese freizugeben.
  • Die Exportberechtigung ist von der Leseberechtigung zu trennen, da Massenexporte ein potenzieller Pfad für Datenabfluss (Data Leakage) sind.

Seien Sie präzise darüber, wo ein bestimmtes Produkt auf dieser Skala einzuordnen ist. Die API-Schlüssel von Nordlet verfügen über modulbasierte Scopes wie sales:read und sales:write, die bei jeder Aktion geprüft werden. Dies trennt Module und Lese- von Schreibzugriffen, jedoch nicht die Erstellung von der Genehmigung; wenn Sie heute diese feinere Unterteilung benötigen, erzwingen Sie sie in Ihrem eigenen Dienst vor dem API-Aufruf.

Bei besonders sensiblen Operationen lohnt es sich zu prüfen, ob das FAPI 2.0 Security Profile anwendbar ist. Es wurde für APIs entwickelt, die vertrauliche Finanzdaten schützen, und bietet stärkere Garantien als das Baseline-OAuth. Die meisten Buchhaltungsintegrationen für kleine und mittlere Unternehmen benötigen nicht das vollständige Profil, aber Zahlungsfreigabe- und Bankverbindungs-Abläufe sind die Bereiche, in denen man dies in Betracht ziehen sollte.

Die passwortlose Anmeldung von Nordlet über einmalige E-Mail-Links beseitigt das Problem wiederverwendbarer Passwörter für menschliche Benutzer, was eine Anmeldeinformation weniger bedeutet, die rotiert werden muss, durchsickern kann oder Phishing zum Opfer fällt.

Machen Sie finanzielle Schreibvorgänge idempotent

Netzwerke fallen mitten in einer Anfrage aus. Ein Client sendet eine Zahlungsanweisung, die Verbindung bricht ab, bevor die Antwort eintrifft, und der Client versucht es erneut. Ohne Schutz haben Sie nun zwei Zahlungen.

Idempotenz-Schlüssel (Idempotency Keys) lösen dieses Problem. Der Client sendet bei jedem Schreibvorgang einen eindeutigen Schlüssel; der Server zeichnet den Schlüssel und das zugehörige Ergebnis auf. Ein erneuter Versuch mit demselben Schlüssel liefert das ursprüngliche Ergebnis zurück, anstatt einen zweiten Eintrag anzulegen. Nordlet akzeptiert einen Idempotency-Key-Header bei jedem verändernden Aufruf, spielt die gespeicherte Antwort bei einem Wiederholungsversuch mit denselben Nutzdaten (Payload) erneut aus und lehnt denselben Schlüssel bei geänderten Nutzdaten ab. Jede Buchhaltungs-API, die auf diese Funktion verzichtet, wird unweigerlich doppelte Hauptbucheinträge produzieren, die jemand manuell wieder entwirren muss.

Kombinieren Sie dies mit serverseitiger Validierung. Vertrauen Sie niemals darauf, dass der Client überprüft, ob Soll und Haben übereinstimmen, ob ein Umsatzsteuersatz für das Land und den Zeitraum gültig ist oder ob ein Konto existiert. Die Validierung läuft auf dem Server ab, vor dem Statusübergang, und ein abgelehnter Schreibvorgang erzeugt einen stabilen Fehler und einen Audit-Eintrag.

Manipulationssichere Audit-Trails und niederländische Aufbewahrungsfristen

Das Audit-Log bildet die Nachweisschicht und stellt andere Anforderungen als gewöhnliche Geschäftsdaten. Es sollte die Autorisierungsentscheidung, Richtlinienversion, Akteur, Objekt, Operation, den vorherigen und neuen Zustand sowie den Grundcode (Reason Code) erfassen, ohne jemals Geheimnisse oder vollständige Zahlungsdaten aufzuzeichnen.

Die wichtigste Eigenschaft ist die Manipulationssicherheit (Tamper-evidence). Wenn ein Administrator unbemerkt Audit-Datensätze bearbeiten oder löschen kann, beweist das Log gar nichts. Append-only-Speicher, kryptografische Verkettung oder Write-Once-Aufbewahrung (WORM) bieten dafür Lösungen. Der springende Punkt ist, dass eine Modifikation erkennbar sein muss.

Die Aufbewahrung (Retention) verdient eine eigene Richtlinie, getrennt von der Löschung von Geschäftsdaten. In den Niederlanden beträgt die allgemeine Aufbewahrungsfrist für Verwaltungsunterlagen sieben Jahre; für Unterlagen im Zusammenhang mit unbeweglichem Vermögen beläuft sie sich auf zehn Jahre. Ihre gewöhnlichen Datenlösch- und DSGVO-Löschungsworkflows dürfen nicht in der Lage sein, Datensätze oder Prüfungsnachweise zu vernichten, die noch unter eine gesetzliche Aufbewahrungspflicht fallen. Definieren Sie Regeln für die Aufbewahrungspflicht (Legal Hold), Archivierung und Löschung von Prüfungsnachweisen unabhängig voneinander und stimmen Sie diese auf die Rechtsordnungen ab, in denen Sie tätig sind.

Die Periodensperre (Period Locking) unterstützt dies auf buchhalterischer Ebene. Sobald ein Monat abgeschlossen ist, können Einträge darin nicht ohne erweiterte Autorisierung und einen protokollierten Grund geändert werden. Nordlet erzwingt Periodensperren, sodass abgeschlossene Monate auch abgeschlossen bleiben, und lehnt jede Buchung ab, deren Datum in einer gesperrten Periode liegt – selbst über die API. Das ist eines der ersten Dinge, die ein niederländischer Prüfer kontrolliert.

Sichern Sie die Ränder: Webhooks, Exporte und Integrationen

Die Kern-API ist meist der bestgeschützte Teil des Systems. Die Ränder sind anfällig für Datenabfluss.

Webhooks bergen das Risiko gefälschter Anfragen. Ein Ereignis wie sale_invoice.paid sollte signiert sein, damit der Empfänger überprüfen kann, ob es von Ihnen stammt, und Empfänger sollten die Zustellung als „at-least-once“ behandeln und die Event-ID zur Deduplizierung nutzen. Nordlet signiert jede Webhook-Zustellung mit einer HMAC-Signatur über den rohen Body und wiederholt fehlgeschlagene Zustellungen mit exponentiellem Backoff. Daher muss ein Empfänger die Signatur verifizieren und anhand der Event-ID deduplizieren, anstatt von einer „exactly-once“-Zustellung auszugehen.

Exporte sind ein Pfad für den massenhaften Abfluss von Daten. Berichts-Exporte in XLSX, PDF oder JSON rufen in einem einzigen Vorgang große Mengen an Finanzdaten ab, weshalb sie eigene Berechtigungen, Ratenbegrenzungen und Audit-Logging benötigen. Drittanbieter-Integrationen, die Sie nutzen, sollten als nicht vertrauenswürdige Eingaben behandelt und genauso validiert werden wie direkte Client-Anfragen.

Checkliste für die Prüfungssicherheit einer niederländischen Buchhaltungs-API

Nutzen Sie dies, bevor Sie behaupten, eine Integration sei prüfungssicher:

  • Expliziter Zustandsautomat bei jeder Finanzressource; gebuchte Einträge können nicht überschrieben werden
  • Autorisierung auf Objektebene und für Rechtsträger bei jeder Anfrage, Deny-by-Default
  • Mandanten- und Rollenkontext wird aus dem Token abgeleitet, nicht aus Client-Claims
  • OAuth 2.0 gemäß RFC 9700; fähigkeitsbasierte Scopes; Trennung von Erstellung und Genehmigung
  • Funktionstrennung in Rollen durchgesetzt, nicht nur dokumentiert
  • Idempotenz-Schlüssel bei allen finanziellen Schreibvorgängen
  • Serverseitige Buchhaltungs- und Umsatzsteuer-Validierung vor Statusübergängen
  • Append-only, manipulationssicheres Audit-Log mit Grundcodes
  • Aufbewahrungs- und Legal-Hold-Regeln, die auf niederländische Fristen abgestimmt sind (sieben Jahre, zehn für Immobilien)
  • Periodensperre (Period Locking) bei abgeschlossenen Monaten
  • Signierte Webhooks mit Deduplizierung; limitierte (scoped), ratenbegrenzte und protokollierte Exporte

Was wir als Erstes bauen würden

Wenn wir morgen Buchhaltungsfunktionen in eine niederländische Plattform einbetten würden, würden wir mit dem Zustandsmodell und der Autorisierung auf Objektebene beginnen, bevor wir auch nur einen einzigen Geschäfts-Endpunkt schreiben. Diese beiden Entscheidungen schränken alles nachgelagerte ein, und sie nachträglich in ein System einzubauen, das Hauptbucheinträge als bearbeitbare Zeilen behandelte, ist schlichtweg schmerzhaft. Idempotenz und das Audit-Log kommen als Nächstes, denn sie lassen sich in einer frühen Phase kostengünstig implementieren, sind jedoch teuer hinzuzufügen, sobald Daten fließen.

Der Rest – zielgerichtete Token, signierte Webhooks, Periodensperren – folgt leichter, wenn das Fundament stabil ist. All dies kann mit einem Sandbox-Unternehmen durchgespielt werden, bevor auch nur irgendetwas davon Produktionsdaten berührt.

FAQ

Bedeutet eine prüfungssichere API, dass das Unternehmen compliant ist?

Nein, und es lohnt sich, hier sehr präzise zu sein. Prüfungssicherheit (Audit-readiness) ist eine Designeigenschaft des Systems: Das Hauptbuch, die Kontrollen und die Nachweiskette sind so aufgebaut, dass ein Audit erfolgreich durchgeführt werden kann. Die Compliance mit einem spezifischen Steuer-, Buchhaltungs- oder Sicherheitsrahmenwerk ist eine separate Bewertung, die diese Kontrollen einem benannten Standard zuordnet. Eine gut gebaute API erleichtert die Compliance-Arbeit; sie ersetzt sie jedoch nicht.

Wie lange müssen Buchhaltungsunterlagen in den Niederlanden aufbewahrt werden?

Die allgemeine Pflicht beträgt sieben Jahre für Verwaltungsunterlagen und verlängert sich auf zehn Jahre für Unterlagen im Zusammenhang mit Immobilien. Richten Sie Aufbewahrungs- und Legal-Hold-Regeln ein, die Ihre gewöhnlichen Löschungsworkflows nicht außer Kraft setzen können.

Reicht ein statischer API-Schlüssel für eine Finanzintegration aus?

Für eine Server-zu-Server-Automatisierung mit engem Scope kann das funktionieren, aber wiederverwendbare statische Schlüssel sind schwer zu rotieren und gefährlich, wenn sie durchsickern. Für den delegierten Zugriff und jeden auf menschliche Interaktion ausgelegten Ablauf ist OAuth 2.0 mit kurzlebigen, fähigkeitsbasierten Token die sicherere Wahl.

Warum ist Idempotenz gerade in der Buchhaltung so wichtig?

Weil ein doppelter Schreibvorgang in den meisten Systemen nur ein Ärgernis ist, in der Buchhaltung jedoch eine falsche Zahl in den Büchern bedeutet, die jemand finden und stornieren muss. Idempotenz-Schlüssel machen Wiederholungsversuche sicher anstatt riskant.

Weiterführende Literatur