Eine Betriebsprüfung fragt selten nach dem Quellcode Ihrer Middleware. Sie fragt: Wie ist dieser eine Beleg entstanden, und wie kam er in die Buchhaltung? Die GoBD verlangen für jedes DV-System, das mit der Buchführung in Zusammenhang steht, eine übersichtlich gegliederte Verfahrensdokumentation, aus der Inhalt, Aufbau, Ablauf und Ergebnisse des Verfahrens vollständig und schlüssig ersichtlich sind (Bundesministerium der Finanzen). Sie muss verständlich und damit für einen sachverständigen Dritten in angemessener Zeit nachprüfbar sein (Bundesministerium der Finanzen). Genau daran scheitern Shop-ERP-Schnittstellen in der Prüfung: Der Shop hat eine Dokumentation, das Warenwirtschaftssystem hat eine Dokumentation, die Finanzbuchhaltung hat eine Dokumentation -- aber der Weg des Belegs vom Bestellabschluss über Middleware und Warenwirtschaft bis zur Buchung ist nirgends beschrieben. Dieser Beitrag zeigt, wie sich die vier Bestandteile der Verfahrensdokumentation für Schnittstellen und Middleware konkret füllen lassen -- vom Datenflussdiagramm über Feldmapping und Belegnummernkreise bis zu Protokollierung, Wiederanlauf und Aufbewahrung.
Warum die Schnittstelle zum blinden Fleck der Prüfung wird
Die steuerliche Außenprüfung ist kein seltenes Ereignis. Im Jahr 2024 waren bundesweit 12.359 Prüferinnen und Prüfer in den Betriebsprüfungen der Länder tätig und stellten ein Mehrergebnis von rund 10,9 Mrd. Euro fest (Bundesministerium der Finanzen). Von den 8.832.707 in der Betriebskartei erfassten Betrieben wurden 140.764 geprüft, was einer durchschnittlichen Prüfungsquote von 1,6 Prozent entspricht (Bundesministerium der Finanzen). Dieser Durchschnitt täuscht allerdings: Bei den Großbetrieben lag die Quote bei 29,6 Prozent, bei den Mittelbetrieben bei 18,5 Prozent (Bundesministerium der Finanzen). Wer eine relevante Betriebsgröße erreicht, wird in der Regel regelmäßig geprüft -- und zwar rückblickend über einen Prüfungszeitraum von durchschnittlich 3,3 Veranlagungsjahren bei Großbetrieben (Bundesministerium der Finanzen).
Diese gut drei Jahre Rückblick sind der Kern des Problems. Die Schnittstelle, die den geprüften Zeitraum verarbeitet hat, ist zum Zeitpunkt der Prüfung oft bereits abgelöst, migriert oder auf eine neue API-Version umgestellt. Das Team, das sie gebaut hat, ist ein anderes. Das Feldmapping von damals liegt bestenfalls in einem Git-Verlauf, den ein Prüfer weder lesen kann noch lesen muss. Die Frage des Prüfers lautet nicht: Wie funktioniert Ihre Schnittstelle heute? Sie lautet: Wie hat sie in dem Jahr funktioniert, in dem dieser Beleg entstanden ist?
Hinzu kommt eine organisatorische Lücke, die in Integrationsprojekten strukturell angelegt ist. Wird die Buchführung oder die digitale Belegverwaltung auf mehrere Beteiligte verteilt, umfasst der Gesamtprozess in der Regel bis zu drei Verantwortungsbereiche: den Buchführungs- beziehungsweise Aufzeichnungspflichtigen selbst, die Steuerberatungskanzlei und das IT-Unternehmen (AWV Muster-Verfahrensdokumentation). Jeder dieser Bereiche muss in der gemeinsamen oder in einer gesonderten Verfahrensdokumentation abgedeckt sein. Fehlt eine gemeinsame Dokumentation über den Gesamtprozess, sind gegenseitige Verweise unter Beachtung der System- und Prozess-Übergänge erforderlich (AWV Muster-Verfahrensdokumentation). Genau diese Übergänge sind die Schnittstellen -- und genau dort endet üblicherweise jede der drei Einzeldokumentationen.
Drei vollständige Dokumentationen ergeben noch keine vollständige Kette
Was die GoBD konkret verlangen
Maßgeblich ist die GoBD-Fassung vom 28. November 2019 in der durch zwei Änderungsschreiben geänderten Gestalt (IHK für München und Oberbayern). Das BMF-Schreiben vom 11. März 2024 (Aktenzeichen IV D 2 - S 0316/21/10001 :002) ist ab dem 1. April 2024 anzuwenden (Bundesministerium der Finanzen). Ergänzend gilt das Schreiben vom 14. Juli 2025, das die GoBD an die E-Rechnung angepasst hat (IHK für München und Oberbayern). Wer eine ältere GoBD-Fassung als Grundlage seiner Dokumentation zitiert, arbeitet mit einem überholten Stand.
Die zentralen Anforderungen an die Verfahrensdokumentation stehen in Abschnitt 10.1 der GoBD. Randziffer 151 verlangt für jedes DV-System eine übersichtlich gegliederte Verfahrensdokumentation und stellt klar, dass der Umfang davon bestimmt wird, was zum Verständnis des DV-Verfahrens, der Bücher und der aufbewahrten Unterlagen notwendig ist (Bundesministerium der Finanzen). Randziffer 152 beschreibt den Gegenstand: den organisatorisch und technisch gewollten Prozess von der Entstehung der Informationen über Indizierung, Verarbeitung und Speicherung bis zum eindeutigen Wiederfinden, zur maschinellen Auswertbarkeit, zur Absicherung gegen Verlust und Verfälschung und zur Reproduktion (Bundesministerium der Finanzen). Das ist, ins Integratorische übersetzt, eine ziemlich exakte Beschreibung dessen, was eine Middleware mit einem Beleg tut.
Besonders relevant für Schnittstellen ist Randziffer 66: Aus der Verfahrensdokumentation muss ersichtlich sein, wie die elektronischen Belege erfasst, empfangen, verarbeitet, ausgegeben und aufbewahrt werden (Bundesministerium der Finanzen). Diese fünf Verben sind faktisch eine Gliederungsvorlage für den Schnittstellenteil der Dokumentation. Ergänzend gilt: Die Beschreibung des internen Kontrollsystems ist ausdrücklich Bestandteil der Verfahrensdokumentation (Bundesministerium der Finanzen) -- Abstimmroutinen, Vier-Augen-Freigaben und Plausibilitätsprüfungen in der Middleware gehören also hinein, nicht in ein separates Betriebshandbuch.
| GoBD-Anforderung | Fundstelle | Was das für die Schnittstelle bedeutet |
|---|---|---|
| Für jedes DV-System eine gegliederte Verfahrensdokumentation | Rz. 151 | Die Middleware ist ein eigenes DV-System, kein Anhängsel von Shop oder ERP |
| Nachprüfbar für einen sachverständigen Dritten in angemessener Zeit | Rz. 151 | Fachsprache statt Quellcode, Diagramm vor Konfigurationsdatei |
| Prozess von Entstehung bis Reproduktion beschreiben | Rz. 152 | Bestellabschluss, Mapping, Übergabe, Buchung und Archiv als eine Kette |
| Erfassen, Empfangen, Verarbeiten, Ausgeben, Aufbewahren der Belege | Rz. 66 | Gliederungsvorlage für den Schnittstellenteil |
| Beschreibung des internen Kontrollsystems | Rz. 102 | Abstimmung, Freigaben und Plausibilitätsprüfungen dokumentieren |
| Programmidentität und historisch nachvollziehbare Änderungen | Rz. 154 | Versionierte Mappings mit Änderungshistorie über die Aufbewahrungsfrist |
Eine fehlende Dokumentation verwirft nicht automatisch die Buchführung
Die vier Bestandteile, auf Schnittstellen übersetzt
Die Verfahrensdokumentation besteht nach Randziffer 153 der GoBD in der Regel aus einer allgemeinen Beschreibung, einer Anwenderdokumentation, einer technischen Systemdokumentation und einer Betriebsdokumentation (Bundesministerium der Finanzen). Diese vier Bestandteile sind für ERP-Systeme etabliert; für Schnittstellen werden sie selten ausgefüllt. Dabei lässt sich jeder Bestandteil sauber auf die Integrationsebene übertragen.
Wichtig ist dabei: Eine Verfahrensdokumentation muss nicht zwingend aus einem einzigen geschlossenen Dokument bestehen. Sie kann aus einer Kombination von Dokumenten bestehen, die über ein Dachdokument miteinander verknüpft werden (AWV Muster-Verfahrensdokumentation). Oft liegen wesentliche Teile bereits vor -- als Arbeitsanweisung, Organisationsanweisung, Systembeschreibung oder Workflow-Beschreibung -- ohne dass sie explizit für diesen Zweck erstellt wurden; ihre Bezeichnung ist unerheblich, sofern sie die geforderten Inhalte abdecken (AWV Muster-Verfahrensdokumentation). In Integrationsprojekten heißt das konkret: Das API-Konzept, das Mapping-Sheet und das Betriebshandbuch sind bereits ein großer Teil der Arbeit. Es fehlt das Dachdokument, das sie zu einem Belegweg verbindet.
1. Allgemeine Beschreibung
Welche Kanäle speisen buchführungsrelevante Belege ein: eigener Shop, Marktplätze, Beschaffungsportale, Offline-Aufträge? Welche Belegarten entstehen: Auftrag, Rechnung, Storno, Gutschrift, Retoure? Wo verlaufen die Systemgrenzen zwischen Shop, Middleware, Warenwirtschaft und Finanzbuchhaltung, und wer verantwortet welchen Abschnitt? Diese Ebene liest der Prüfer zuerst.
2. Anwenderdokumentation
Was tun Menschen im Verfahren? Wer gibt einen Beleg frei, der in der Fehlerqueue liegt? Wer darf ein Mapping ändern, wer eine Buchung stornieren? Welche Bildschirmmasken und Rollen gibt es, und welche Handgriffe sind im Fehlerfall vorgesehen? Hier gehört auch hin, was ausdrücklich nicht manuell verändert werden darf.
3. Technische Systemdokumentation
Datenflussdiagramm je Kanal, Feldmapping mit Quell- und Zielfeldern, Belegnummernkreise und ihre Vergabelogik, Schnittstellenprotokolle und Datenformate, Idempotenzschlüssel, Schemaversionen. Diese Ebene erzeugt ein Entwicklungsteam ohnehin -- meist nur nicht in prüferlesbarer Form.
4. Betriebsdokumentation
Wie läuft der Betrieb: Zeitpläne und Auslöser der Übertragung, Monitoring und Alarmierung, Fehler- und Wiederanlaufverfahren, Umgang mit der Dead-Letter-Queue, Datensicherung, Zugriffsberechtigungen, Aufbewahrung der Rohdaten. Hier entscheidet sich, ob ein liegengebliebener Beleg auffällt.
Datenflussdiagramm und Feldmapping je Kanal
Der wirksamste einzelne Baustein ist ein Datenflussdiagramm pro Kanal. Nicht pro System -- pro Kanal. Ein Shop-Beleg, ein Marktplatz-Beleg und ein Beleg aus einem Beschaffungsportal nehmen unterschiedliche Wege, tragen unterschiedliche Nummernkreise und landen unter Umständen auf unterschiedlichen Erlöskonten. Wer die Wege in einem einzigen Diagramm zusammenfasst, produziert genau die Unschärfe, die in der Prüfung Rückfragen auslöst. Wie sich mehrere Verkaufskanäle über eine gemeinsame Integrationsschicht führen lassen, beschreibt unser Beitrag zur Marktplatz-Anbindung über Middleware.
Das Diagramm sollte je Kanal mindestens vier Stationen zeigen: auslösendes Ereignis, Übergabe an die Middleware, Verarbeitung in der Warenwirtschaft, Übergabe an die Finanzbuchhaltung. An jeder Kante gehört die Antwort auf drei Fragen: Was wird übertragen, wann wird übertragen, und was passiert, wenn die Übertragung fehlschlägt? Damit ist der Prüfer bereits bei der Nachvollziehbarkeit -- ohne eine Zeile Code gesehen zu haben.
- Datenflussdiagramm je Verkaufskanal mit benannten Systemen, Richtungen und Auslösern
- Feldmapping als Tabelle: Quellfeld, Zielfeld, Transformationsregel, Pflichtfeld ja oder nein, Standardwert
- Belegnummernkreise je Kanal und Belegart, inklusive Vergabestelle und Prüfung auf Lückenlosigkeit
- Behandlung von Rundungen, Währungen und Steuerschlüsseln an der Kante zur Buchhaltung
- Zuordnung von Zahlungsarten und Erlöskonten je Kanal
- Definierte Sortier- und Suchkriterien, damit ein einzelner Beleg über alle Stationen auffindbar bleibt
Die Belegnummernkreise verdienen dabei besondere Aufmerksamkeit. Sobald mehrere Systeme Nummern vergeben -- der Shop eine Bestellnummer, die Warenwirtschaft eine Auftragsnummer, die Finanzbuchhaltung eine Belegnummer -- muss die Dokumentation zeigen, wie sich diese Nummern eindeutig aufeinander abbilden lassen. Ohne diese Brücke ist eine progressive Prüfung vom Beleg zur Buchung und eine retrograde Prüfung von der Buchung zurück zum Beleg kaum durchführbar. Wie sich die Feldebene systematisch aufbereiten lässt, zeigt unser Beitrag zum Daten-Mapping zwischen ERP und Shop. Für die steuerliche Feldebene lohnt zusätzlich der Blick auf die Steuerfindung im B2B-Shop.
Der Prüfstein für jedes Diagramm
Stornos, Gutschriften und Retouren
Der Normalfall ist selten das Problem. Eine Bestellung wird abgeschlossen, ein Auftrag entsteht, eine Rechnung wird gebucht -- diesen Weg beschreibt fast jede Dokumentation. Kritisch werden die Ausnahmen, und zwar aus einem einfachen Grund: Sie verändern bereits gebuchte Sachverhalte. Genau dort setzt der Grundsatz der Unveränderbarkeit an, und genau dort schauen Prüfer hin.
Die Dokumentation muss je Ausnahmefall zeigen, welcher Beleg entsteht, in welchem Nummernkreis er läuft, welches System ihn erzeugt und wie er sich auf den Ursprungsbeleg bezieht. Ein Storno, das den Ursprungsbeleg im Shop stillschweigend überschreibt, ist ein Ordnungsmäßigkeitsproblem und keine Feinheit. Die operative Seite der Retourenabwicklung behandelt unser Beitrag zum RMA-Prozess zwischen Shop und ERP.
| Vorgang | Was dokumentiert sein muss | Typische Lücke |
|---|---|---|
| Storno vor Buchung | Wer darf stornieren, welcher Status wird gesetzt, ob ein Beleg entsteht | Shop setzt Status zurück, ohne dass die Middleware es erfährt |
| Storno nach Buchung | Stornobeleg mit eigenem Nummernkreis und Bezug zum Ursprungsbeleg | Ursprungsbeleg wird überschrieben statt storniert |
| Gutschrift | Auslöser, Berechnungsgrundlage, Steuerschlüssel, Kontierung | Gutschrift entsteht manuell im ERP und läuft an der Schnittstelle vorbei |
| Retoure mit Wertänderung | Weg vom Wareneingang über die Gutschrift bis zur Buchung | Bestandsbuchung und Wertbuchung sind ohne Verknüpfung dokumentiert |
| Teilretoure | Aufteilungslogik auf Positionen, Versandkosten und Rabatte | Nur der Vollfall ist beschrieben |
| Zahlungsrückabwicklung | Abgleich zwischen Zahlungsart, Rückzahlung und Buchung | Zahlungsdaten sind separat dokumentiert, ohne Bezug zum Beleg |
Die Zahlungsseite wird dabei regelmäßig unterschätzt. Wenn Rückzahlungen über einen anderen Weg laufen als die ursprüngliche Zahlung, muss die Dokumentation den Abgleich beschreiben -- sonst bleibt in der Prüfung offen, welcher Zahlungsvorgang zu welchem Beleg gehört. Die Grundlagen dazu behandeln wir auf unserer Seite zur Zahlungsanbindung an das ERP.
Protokollierung und unveränderbare Logs
Die GoBD lassen offen, mit welcher Technik Unveränderbarkeit erreicht wird, und benennen drei Wege: hardwaremäßig über unveränderbare Datenträger, softwaremäßig über Sicherungen, Sperren, Festschreibung, Löschmerker, automatische Protokollierung, Historisierungen und Versionierungen, oder organisatorisch über Zugriffsberechtigungskonzepte (Bundesministerium der Finanzen). Entscheidend ist ein Satz, der in der Praxis oft übersehen wird: Die Ablage von Daten und elektronischen Dokumenten in einem Dateisystem erfüllt die Anforderungen der Unveränderbarkeit regelmäßig nicht, soweit nicht zusätzliche Maßnahmen ergriffen werden (Bundesministerium der Finanzen).
Für Schnittstellen bedeutet das: Ein Log-Verzeichnis mit rotierenden Textdateien auf einem Applikationsserver ist als Nachweis in der Regel ungeeignet. Gebraucht wird eine Protokollierung, die den ursprünglichen Inhalt und die Tatsache einer Veränderung erkennbar hält. Die GoBD formulieren das ausdrücklich: Spätere Änderungen sind ausschließlich so vorzunehmen, dass sowohl der ursprüngliche Inhalt als auch die Tatsache, dass Veränderungen vorgenommen wurden, erkennbar bleiben (Bundesministerium der Finanzen).
Mapping-Änderungen sind protokollierungspflichtig
- Protokolle mit Zeitstempel, auslösender Identität und fachlichem Bezug zum Beleg, nicht nur mit technischer Transaktions-ID
- Änderungen an Mappings, Steuerschlüsseln und Kontenzuordnungen mit Vorher- und Nachher-Wert festhalten
- Aufbewahrung der eingehenden Rohdaten im empfangenen Format, damit sich jede Transformation nachrechnen lässt
- Schreibgeschützte Ablage der Protokolle über die Dauer der Aufbewahrungsfrist, getrennt vom Betriebssystem der Anwendung
- Zugriffsberechtigungskonzept, das beschreibt, wer Protokolle lesen und wer sie technisch löschen könnte
Die Rohdatenaufbewahrung ist dabei der unterschätzte Hebel. Wenn der eingehende Datensatz im empfangenen Format erhalten bleibt, lässt sich jede Transformation Jahre später rekonstruieren -- auch ohne das damalige Mapping. Ohne Rohdaten bleibt nur das Ergebnis, und das Ergebnis erklärt sich nicht selbst. Wie sich Protokollierung und Auswertbarkeit im laufenden Betrieb verbinden lassen, beschreibt unser Beitrag zu Observability und Monitoring von Schnittstellen.
Fehler und Wiederanlauf: DLQ-Belege dürfen nicht verschwinden
Jede Schnittstelle hat Fehlerfälle. Das ist kein Mangel, sondern Normalzustand -- ein Zielsystem ist nicht erreichbar, ein Pflichtfeld fehlt, ein Steuerschlüssel ist unbekannt. Der Mangel entsteht erst dann, wenn ein buchführungsrelevanter Beleg in einer Dead-Letter-Queue landet und dort stillschweigend liegen bleibt. Aus Sicht der Vollständigkeit ist das ein fehlender Geschäftsvorfall, unabhängig davon, wie sauber die Architektur ansonsten ist.
Die Betriebsdokumentation muss deshalb beschreiben, was mit einem Beleg passiert, der nicht durchläuft. Wer wird informiert, in welcher Frist, wer entscheidet über den Wiederanlauf, und wie wird sichergestellt, dass ein wiederholter Versuch keinen Doppelbeleg erzeugt? Die Antwort auf die letzte Frage ist technisch die Idempotenz; dokumentarisch ist es die Beschreibung des Schlüssels, über den ein Vorgang eindeutig identifiziert wird. Beide Aspekte behandeln unsere Beiträge zu Idempotenz und Retry-Strategien und zur Fehlerbehandlung in Schnittstellen.
Eskalation mit Frist
Wer wird nach welcher Zeit informiert, wenn ein Beleg nicht verarbeitet wurde? Eine Queue ohne benannten Verantwortlichen und ohne Frist ist dokumentarisch eine Sackgasse.
Wiederanlauf ohne Doppelbuchung
Welcher Schlüssel identifiziert den Vorgang eindeutig, und was passiert bei einem zweiten Versuch? Der Idempotenzschlüssel gehört fachlich beschrieben, nicht nur technisch implementiert.
Nachweis der Abarbeitung
Wie wird belegt, dass die Fehlerqueue zu einem Stichtag leer war? Ein regelmäßiger Abgleich zwischen Bestellungen im Shop und Belegen in der Buchhaltung ist Teil des internen Kontrollsystems.
Eine Schnittstelle ist in der Betriebsprüfung nur so gut wie die Antwort auf die Frage, was mit den Belegen passiert ist, die nicht durchgelaufen sind. Der Normalfall interessiert selten -- die Ausnahme entscheidet.
Praktisch bewährt hat sich ein periodischer Vollständigkeitsabgleich: Anzahl und Summe der Bestellungen im Shop je Zeitraum gegen Anzahl und Summe der Belege in der Buchhaltung, dokumentiert als wiederkehrende Kontrollhandlung mit benanntem Verantwortlichen (Projekterfahrung). Diese Kontrolle ist Teil des internen Kontrollsystems und damit ausdrücklich Bestandteil der Verfahrensdokumentation (Bundesministerium der Finanzen).
Änderungshistorie und Versionierung der Mappings
Randziffer 154 der GoBD ist für Integratoren die anspruchsvollste Vorschrift des gesamten Abschnitts. Für den Zeitraum der Aufbewahrungsfrist muss gewährleistet und nachgewiesen sein, dass das in der Dokumentation beschriebene Verfahren dem in der Praxis eingesetzten Verfahren voll entspricht; dies gilt insbesondere für die eingesetzten Versionen der Programme, die sogenannte Programmidentität (Bundesministerium der Finanzen). Änderungen einer Verfahrensdokumentation müssen historisch nachvollziehbar sein; dem wird genügt, wenn die Änderungen versioniert sind und eine nachvollziehbare Änderungshistorie vorgehalten wird (Bundesministerium der Finanzen).
Für die Prüfung ist zudem eine aussagefähige und aktuelle Verfahrensdokumentation notwendig, die alle System- beziehungsweise Verfahrensänderungen inhaltlich und zeitlich lückenlos dokumentiert (Bundesministerium der Finanzen). Übersetzt: Nicht nur der aktuelle Stand des Mappings zählt, sondern die Frage, welches Mapping am 14. März des Prüfungsjahres aktiv war. Ein Git-Verlauf erfüllt die inhaltliche Anforderung technisch -- die Anforderung, für einen sachverständigen Dritten in angemessener Zeit nachprüfbar zu sein, erfüllt er nur, wenn eine lesbare Änderungshistorie mit Datum, Grund und fachlicher Auswirkung daneben steht.
Die AWV empfiehlt dafür eine praktische Aufteilung: Die regelmäßige Überprüfung bei geänderten Verfahren lässt sich durch eine geschickte Aufteilung der Verfahrensbeschreibung in einen inhaltlich stabilen Hauptteil und sich häufiger ändernde Anlagen erheblich vereinfachen (AWV Muster-Verfahrensdokumentation). Für Schnittstellen heißt das: Der Belegweg gehört in den stabilen Hauptteil, das Feldmapping in eine versionierte Anlage. Ergänzend gilt, dass das tatsächlich durchgeführte Verfahren der Dokumentation entsprechen und regelmäßig angewendet werden muss; Änderungen am Verfahren oder an den Maßnahmen sind zu dokumentieren, woraus sich die Notwendigkeit der Versionierung ergibt (AWV Muster-Verfahrensdokumentation).
Die Abnahme der Dokumentation gehört in den Testlauf
Fristen: acht Jahre, zehn Jahre und abgelöste Schnittstellen
Die Fristenlage hat sich zum 1. Januar 2025 geändert, und die Änderung wird häufig zu weit ausgelegt. Mit dem Vierten Bürokratieentlastungsgesetz wurde die Aufbewahrungsfrist für Buchungsbelege von zehn auf acht Jahre verkürzt (Viertes Bürokratieentlastungsgesetz). Der Bundestag beschloss das Gesetz am 26. September 2024, der Bundesrat stimmte am 18. Oktober 2024 zu (Viertes Bürokratieentlastungsgesetz). Die verkürzte Frist gilt für alle Unterlagen, deren Aufbewahrungsfrist am 1. Januar 2025 noch nicht abgelaufen war -- also auch für Altbestände (Viertes Bürokratieentlastungsgesetz). Für Unternehmen unter Aufsicht der Bundesanstalt für Finanzdienstleistungsaufsicht greift die Verkürzung mit einer Verzögerung von einem Jahr (Viertes Bürokratieentlastungsgesetz). Nach Angaben der Bundesregierung entlastet das Gesetz die Wirtschaft jährlich um rund 944 Mio. Euro, davon rund 626 Mio. Euro allein durch die Fristverkürzung (Viertes Bürokratieentlastungsgesetz).
Für die Verfahrensdokumentation ändert das nichts. Sie ist kein Buchungsbeleg, sondern zählt zu den in Paragraf 147 Absatz 1 Nummer 1 der Abgabenordnung genannten Arbeitsanweisungen und sonstigen Organisationsunterlagen, die zum Verständnis der Bücher und Aufzeichnungen erforderlich sind (Abgabenordnung). Diese Unterlagen sind nach Paragraf 147 Absatz 3 der Abgabenordnung zehn Jahre aufzubewahren (Abgabenordnung). Die Frist beginnt mit dem Schluss des Kalenderjahres, in dem die letzte Eintragung vorgenommen wurde (Abgabenordnung).
| Unterlage | Frist | Rechtsgrundlage |
|---|---|---|
| Buchungsbelege, auch aus der Schnittstelle erzeugte Rechnungen | 8 Jahre | Paragraf 147 Absatz 1 Nummer 4 und Absatz 3 AO, seit 01.01.2025 |
| Verfahrensdokumentation als Organisationsunterlage | 10 Jahre | Paragraf 147 Absatz 1 Nummer 1 und Absatz 3 AO |
| Bücher, Aufzeichnungen, Jahresabschlüsse | 10 Jahre | Paragraf 147 Absatz 1 Nummer 1 und Absatz 3 AO |
| Sonstige steuerlich bedeutsame Unterlagen | 6 Jahre | Paragraf 147 Absatz 1 Nummer 5 und Absatz 3 AO |
| Alle vorgenannten bei laufender Festsetzungsfrist | Frist läuft nicht ab | Paragraf 147 Absatz 3 Satz 3 AO |
Zwei Regeln verlängern die Frist über die zehn Jahre hinaus. Erstens die allgemeine Ablaufhemmung: Die Aufbewahrungsfrist läuft nicht ab, soweit und solange die Unterlagen für Steuern von Bedeutung sind, für welche die Festsetzungsfrist noch nicht abgelaufen ist (Abgabenordnung). Zweitens eine Sonderregel speziell für die Verfahrensdokumentation: Ihre Aufbewahrungsfrist läuft nicht ab, soweit und solange die Aufbewahrungsfrist für die Unterlagen noch nicht abgelaufen ist, zu deren Verständnis sie erforderlich ist (Bundesministerium der Finanzen). Ergänzend stellt die AWV klar, dass die Verfahrensdokumentation mit allen gültigen Versionen zu den aufbewahrungspflichtigen Unterlagen gehört (AWV Muster-Verfahrensdokumentation).
Die abgelöste Schnittstelle bleibt dokumentationspflichtig
Daraus folgt eine Anforderung an die Archivierung, die über die Schnittstelle hinausgeht: Auch die Rohdaten und Protokolle müssen den Systemwechsel überleben, und zwar in maschinell auswertbarer Form. Wer beim Wechsel eines Cloud-Anbieters oder einer Middleware nur den laufenden Betrieb migriert, verliert genau das Material, mit dem sich der Belegweg später rekonstruieren ließe. Welche Rechte beim Anbieterwechsel bestehen und wie sich Portabilität vertraglich und technisch absichern lässt, behandelt unser Beitrag zum EU Data Act und der Portabilität von ERP-Cloud-Schnittstellen.
Wie die Dokumentation im Projekt entsteht
Eine Verfahrensdokumentation, die nach dem Projekt entsteht, ist teuer und ungenau. Sie muss rekonstruieren, was ohnehin einmal entschieden wurde -- meist ohne die Beteiligten von damals. Entsteht sie dagegen mit der Schnittstelle, fällt sie zu großen Teilen als Nebenprodukt an: Das Datenflussdiagramm ist das Ergebnis des Fachkonzepts, das Feldmapping das Ergebnis der Umsetzung, das Fehler- und Wiederanlaufverfahren das Ergebnis des Betriebskonzepts. Zusammengeführt werden sie über ein Dachdokument, das den Belegweg erzählt und in die vorhandenen Teile verweist.
Der Aufwand dafür ist überschaubar, wenn er im richtigen Moment anfällt. In Integrationsprojekten liegt der Zusatzaufwand typischerweise im niedrigen einstelligen Prozentbereich des Projektvolumens, sofern die Dokumentation parallel zur Umsetzung entsteht statt im Nachhinein (Projekterfahrung). Nachträglich entstehen dagegen Rekonstruktionsaufwände, die den ursprünglichen Dokumentationsaufwand deutlich übersteigen können (Projekterfahrung).
Ein Blick auf die möglichen Folgen ordnet den Aufwand ein. Bleiben Mitwirkungspflichten in der Außenprüfung unerfüllt, sieht die Abgabenordnung für Prüfungsanordnungen ab dem 1. Januar 2025 das qualifizierte Mitwirkungsverlangen mit einem Mitwirkungsverzögerungsgeld von 75 Euro je vollem Tag für höchstens 150 Kalendertage vor, also bis zu 11.250 Euro (Abgabenordnung). Ein Zuschlag kann in besonderen Fällen bis zu 25.000 Euro je Kalendertag betragen (Abgabenordnung). Unabhängig davon kann eine nicht ordnungsgemäße Buchführung nach Paragraf 158 der Abgabenordnung dazu führen, dass sie der Besteuerung nicht zugrunde gelegt wird, was Hinzuschätzungen nach sich ziehen kann (IHK für München und Oberbayern). Die AWV nennt als mögliche Folgen fehlender Ordnungsmäßigkeit unter anderem die Nichtanerkennung von Betriebsausgaben, Zuschätzungen von Betriebseinnahmen oder Gewinnen, Zwangsmittel, Bußgelder und gegebenenfalls Steuerstrafverfahren (AWV Muster-Verfahrensdokumentation).
Ein Ausblick gehört ebenfalls in die Planung: Die GoBD verweisen inzwischen auf eine einheitliche digitale Schnittstelle nach Paragraf 147b der Abgabenordnung; die zugehörige Rechtsverordnung steht allerdings noch aus (IHK für München und Oberbayern). Wer seine Datenflüsse heute sauber beschreibt und die Rohdaten maschinell auswertbar vorhält, ist auf eine solche standardisierte Datenanforderung besser vorbereitet als ein Betrieb, der seine Exporte für jede Prüfung neu zusammenstellt.
Den Rahmen dafür liefert die Integrationsarchitektur selbst. Ob die Belege über eine SAP-Anbindung, eine Warenwirtschafts-Anbindung oder eine individuelle API-Entwicklung laufen: Die dokumentarischen Anforderungen sind dieselben, nur die Fundstellen unterscheiden sich. Für die Übergabe an die Buchhaltung lohnt zusätzlich der Blick auf unsere DATEV-Anbindung und den Beitrag zur DATEV-Automatisierung im E-Commerce. Wer die E-Rechnungspflicht parallel umsetzt, findet die Fristenlage im Beitrag zur E-Rechnungspflicht 2027. Welche Punkte für Ihre konkrete Systemlandschaft zuerst zu klären sind, lässt sich am schnellsten in einem Gespräch über Ihr Integrationsprojekt einordnen.
Quellen und Studien