Buchungslauf
← Zurück zur Startseite

GoBD und Buchungslauf

Diese Seite klärt, was Buchungslauf zur GoBD-konformen Vorbuchhaltung beiträgt — und was ausdrücklich nicht. Die Trennung halten wir bewusst präzise: pauschale „GoBD-konform"-Werbung ist im deutschen Markt weit verbreitet, aber rechtlich und sachlich nicht haltbar. Wir wollen, dass Sie wissen, worauf Sie sich verlassen können — und worauf nicht.

Was die GoBD sind

Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) sind ein Verwaltungs- Schreiben des Bundesministeriums der Finanzen vom 28. November 2019 (Geschäftszeichen IV A 4 - S 0316/19/10003 :001), zuletzt geändert durch BMF-Schreiben vom 14. Juli 2025. Sie richten sich an Steuerpflichtige, nicht an Software-Hersteller. Geregelt wird, wie elektronische Buchführung und Belegerhaltung zu gestalten sind, damit sie bei einer steuerlichen Außenprüfung Bestand haben: Nachvollziehbarkeit und Nachprüfbarkeit sowie die Grundsätze der Wahrheit, Klarheit und fortlaufenden Aufzeichnung — letztere umfassen Vollständigkeit, Einzelaufzeichnungspflicht, Richtigkeit, zeitgerechte Buchungen und Aufzeichnungen, Ordnung und Unveränderbarkeit (GoBD Rz. 26).

Was die GoBD nicht sind

Was Buchungslauf konkret beiträgt

Buchungslauf bringt mehrere technische Mechanismen mit, die einzeln und nachweisbar GoBD-Prinzipien für den Vor-Buchungs-Schritt umsetzen. Die folgenden Abschnitte beschreiben diese Mechanismen.

Nachweispfad und Unveränderbarkeit

Jeder Einleselauf wird versioniert protokolliert. Eingehende Belege und Bankumsätze werden als Snapshot abgelegt und nicht überschrieben — auch wenn der Beleg im DMS später korrigiert wird, bleibt die Version, mit der Buchungslauf gebucht hat, im Nachweispfad erhalten.

Jeder Schritt der Verarbeitungskette (Einlesen, Abgleich, Kontierungsvorschlag, Prüfung, Export, Rückverknüpfung) ist mit Zeitstempel, ausführendem Konto und Vorgangs-ID protokolliert. Manuelle Eingriffe in der Prüfung ([OK], [KORREKTUR], [SKIP]) sind dem prüfenden Benutzerkonto namentlich zugeordnet. Der Datenbestand ist append-only — Korrekturen erzeugen neue Versionen, nicht überschriebene Datensätze.

Personalisierte Aktionen über das Rollenkonzept

Jede in der Web-GUI ausgelöste Aktion ist einem angemeldeten Benutzerkonto zugeordnet. Das Rollenkonzept unterscheidet typischerweise:

Damit ist das Vier-Augen-Prinzip auch im Kleinteam technisch darstellbar: eine Person bereitet vor, eine andere gibt frei. Im Nachweispfad sind beide Aktionen mit dem jeweiligen Konto verankert. Die Definition und der laufende Betrieb des internen Kontrollsystems (IKS) bleiben Aufgabe des Betreibers.

Deterministischer Abgleich — keine KI-Black-Box

Der Bankumsatz-Abgleich folgt einer expliziten, dokumentierbaren Hierarchie: IBAN + Rechnungsnummer (inkl. Sammelvarianten), Kartenzahlungs-Pfad, Datum-/Betrags-Heuristik. Zusätzlich erkennt Buchungslauf, wenn ein einziger Bankumsatz die Summe mehrerer Belege darstellt: deterministische Teilbetrags-Erkennung mit konfigurierbarer Toleranzgrenze, keine Score-Magie.

Beispiel: Ihr Cloud-Hosting-Anbieter zieht einmal monatlich eine Summe ein, die fünf einzelne Rechnungen (Hosting, Backup, Domain, Mailbox, Support) umfasst. Buchungslauf erkennt die fünf Belege als Teilbeträge der einen Bankbuchung, bietet die Zuordnung als Vorschlag an und protokolliert die Teilbetrags-Logik nachvollziehbar.

Jede Zuordnung ist gegenüber einer Außenprüfung erklärbar, weil sie auf einer Regel beruht, nicht auf einer undurchschaubaren Bewertungsfunktion.

Personenkonten und Stammdaten

Stammdaten zu Lieferanten und Kunden (Personenkonten-Nummern, Standard-Kontierung, USt-Sätze) werden in der Web-GUI verwaltet und per CSV importierbar — sinnvoll, wenn die Stammdaten in der Buchhaltungssoftware bereits gepflegt sind. Pro Lieferant lässt sich hinterlegen:

Buchungslauf wendet diese Stammdaten beim Kontierungsvorschlag an; jede Abweichung in der Prüfung wird im Nachweispfad festgehalten.

Belegnummern-Rückverknüpfung ins DMS

Sobald die Buchhaltungssoftware nach dem Export eine Belegnummer vergibt, schreibt Buchungslauf diese Belegnummer automatisch ins DMS zurück. Beleg und Buchung bleiben damit dauerhaft verlinkt — die nach GoBD geforderte Beleg-zu- Buchung-Verknüpfung entsteht ohne Handarbeit.

Verfahrensdokumentation

Die GoBD verlangt vom Steuerpflichtigen eine Verfahrensdokumentation für die eingesetzten Systeme (GoBD Rz. 151 ff.). Buchungslauf liefert dafür einen generischen Vorlagentext, der die konfigurationsspezifischen Werte (DMS-Adapter, Banking-Adapter, Buchhaltungs-Adapter, Kontenplan, Rollenmodell) automatisch einsetzt. Sie haben damit eine fertige Anlage zur Buchführung, die Sie an Ihre Steuerberatung weitergeben können.

Hinweis: Die Verfahrensdokumentation für die eigentliche Buchhaltungssoftware (Taxpool, DATEV, lexoffice, sevDesk, …) liegt weiterhin bei deren Hersteller bzw. bei Ihnen als Anwender. Buchungslauf dokumentiert nur den Vor-Buchungs-Schritt.

Aufbewahrungsfristen

Der vollständige Nachweispfad — Belegversionen, Bankumsatz- Snapshots, Abgleichs-Entscheidungen, Kontierungsvorschläge, Prüfaktionen, Exporte, Rückverknüpfungen — wird so lange vorgehalten, wie die handels- und steuerrechtlichen Aufbewahrungsfristen für den jeweiligen Datentyp verlangen.

Seit dem 1. Januar 2025 — durch das Vierte Bürokratieentlastungsgesetz (§ 147 Abs. 3 Satz 1 AO i. d. F. des Art. 3 Nr. 4 BEG IV) — gilt für Buchungsbelege regelmäßig eine verkürzte Aufbewahrungsfrist von 8 Jahren. Die Verkürzung gilt für alle Buchungsbelege, deren Aufbewahrungsfrist nach § 147 Abs. 3 AO in der bis 31. Dezember 2024 geltenden Fassung noch nicht abgelaufen ist (Art. 97 § 19a Abs. 2 EGAO). Für Jahresabschlüsse, Inventare, Eröffnungsbilanzen und Lageberichte bleibt es bei 10 Jahren. Die Aufbewahrung der ursprünglichen Belege im DMS und der gebuchten Sätze in der Buchhaltungssoftware liegt nicht bei Buchungslauf, sondern bei diesen Systemen bzw. beim Betreiber.

Daten verlassen den eigenen Host nicht. Buchungslauf bietet einen Export des Nachweispfads in einem maschinenlesbaren Format an, damit eine Migration auf eine Nachfolgelösung oder eine Übergabe an ein Archivsystem ohne Datenverlust möglich ist.

Was Buchungslauf nicht abdeckt

Damit es keine Missverständnisse gibt — folgende GoBD-relevanten Themen liegen außerhalb des Funktionsumfangs von Buchungslauf und in der Verantwortung des Betreibers:

Belastbarkeit bei einer Betriebsprüfung

Im Fall einer Außenprüfung können Sie der Prüfung den Nachweispfad zu jeder einzelnen Buchung zeigen: welcher Beleg, welcher Bankumsatz, welche Abgleichs-Logik wurde angewandt, welche Person hat freigegeben. Der Export-Pfad und die Belegnummern-Rückverknüpfung ins DMS schließen die Kette hin zur Buchhaltungssoftware bzw. zur archivierten Originaldatei.

Was wir konkret zusagen

Buchungslauf liefert die technischen Voraussetzungen für eine GoBD-konforme Vorbuchhaltung. Die GoBD-Konformität der gesamten Buchführung verantwortet der Betreiber — inklusive Verfahrensdokumentation, Aufbewahrung und IKS. Diese Aufteilung ist Teil des Vertrags, nicht nur dieser Seite.

Wenn Sie für Ihren Steuerberater oder eine laufende Betriebsprüfung eine schriftliche Beschreibung der konkreten Mechanismen (Append-only-Protokoll, Versionierung, Rollennachweis, Abgleichs-Hierarchie) brauchen, stellen wir ein Dokument bereit, das Ihr Steuerberater in die Verfahrensdokumentation übernehmen kann. Schreiben Sie uns an.

Buchungslauf ersetzt keinen Steuerberater und keine inhaltliche GoBD-Beratung. Verbindliche Aussagen zur Anwendbarkeit auf Ihren konkreten Fall klärt im Zweifelsfall Ihre Steuerberatung.

Quellen

Stand: 22. Mai 2026 — Diese Seite beschreibt den geplanten und teilweise umgesetzten Funktionsumfang in der Alpha-Phase. Details können sich bis 1.0 noch ändern.