Steuer-News aktuell
In der Welt der deutschen Finanz-Compliance ist der Begriff „GoBD-Export“ (oft synonym mit GDPdU-Export verwendet) für Entwickler von Finanz- und ERP-Software eine ständige Herausforderung. Ob für Odoo, Tryton oder maßgeschneiderte Eigenentwicklungen – das Ziel bleibt gleich: Steuerrelevante Daten müssen so exportiert werden, dass sie von der Prüfsoftware der Finanzverwaltung (IDEA) maschinell ausgewertet werden können.
In diesem Beitrag erfährst du, wie du eine universelle Export-Engine mit Python aufbaust, die den Anforderungen der Datenträgerüberlassung (Z3-Zugriff) entspricht.
Ein valider Export ist kein bloßer CSV-Dump. Er besteht aus drei unverzichtbaren Komponenten, die in einem ZIP-Archiv zusammengefasst werden:
Datendateien: Meist CSV- oder ASCII-Dateien mit festen Feldlängen, die die eigentlichen Buchungs- und Stammdaten enthalten.
Die Indexdatei (index.xml): Das „Gehirn“ des Exports. Sie beschreibt die Struktur, Feldtypen und Relationen der Datendateien.
Die Strukturdefinition (gdpdu-01-08-2002.dtd): Eine offizielle Datei der Finanzverwaltung, gegen die die index.xml validiert wird.
Der erste Schritt ist die Aufbereitung der Daten. Da steuerlich relevante Daten (Journal, Kontenplan, Debitoren/Kreditoren) oft in relationalen Datenbanken liegen, ist pandas in Kombination mit SQLAlchemy das Werkzeug der Wahl.
Pro-Tipp: Achte auf die Formatierung. Wenn in der index.xml ein Komma als Dezimaltrenner definiert ist, muss die CSV-Ausgabe exakt so erfolgen.
import pandas as pd
def export_table_to_csv(df, filepath):
# GoBD-Vorgabe: Keine Header in der CSV, da diese in der index.xml stehen
df.to_csv(
filepath,
sep=';',
index=False,
header=False,
decimal=',',
quoting=1 # Schützt AlphaNumeric-Felder
)index.xmlDie index.xml muss jedes Feld präzise beschreiben. Besonders kritisch sind die numerischen Typen. Hier nutzt man Bibliotheken wie lxml für eine saubere XML-Struktur.
| Datentyp | Bedeutung | Wichtiges Attribut |
| AlphaNumeric | Textfelder |
|
| Numeric | Beträge/Mengen |
|
| Date | Datumsangaben |
|
Ein technischer Fallstrick ist die Accuracy. Ein Wert von 1000,25 bei einer definierten Accuracy von 0 führt zu Fehlern oder Datenverlust beim Import in IDEA.
Ein Export ist nur so gut wie die Integrität der Quelldaten. Die GoBD fordern Unveränderbarkeit und Lückenlosigkeit. In Python-Systemen wie Audipy, Odoo oder Tryton sollte jede Änderung über einen Audit Trail protokolliert werden.
Modernere Ansätze nutzen kryptographische Hash-Ketten, um die Unveränderbarkeit der Logs mathematisch nachweisbar zu machen. Dabei wird jeder Log-Eintrag mit dem Hash des vorherigen verknüpft.
Bevor der Export an den Prüfer geht, solltest du eine technische Plausibilitätsprüfung durchführen. Ein einfacher, aber effektiver Check für jedes Konto im Exportzeitraum ist die Saldenprüfung:
Stimmt diese Gleichung nicht, fehlen entweder Datensätze im Export oder die Extraktionslogik ist fehlerhaft.
Seit Juli 2025 gelten aktualisierte GoBD-Regeln, die vor allem die E-Rechnungspflicht berücksichtigen. Für Entwickler wichtig:
Bei hybriden Formaten (wie ZUGFeRD) reicht es nun oft aus, nur den strukturierten XML-Teil zu archivieren.
Die Aufbewahrungsfrist für Rechnungen wurde in einigen Bereichen von 10 auf 8 Jahre verkürzt.
Python bietet mit seinem Ökosystem aus pandas, lxml und mächtigen ORMs die perfekte Basis für GoBD-konforme Systeme. Wer die Trennung von Daten (CSV) und Metadaten (XML) sauber implementiert und die neuen Anforderungen von 2025 im Blick behält, kann Prüfungen gelassen entgegensehen.
FAQ-Katalog der BStBK zur E-Rechnung (Stand 19.03.2026):
"Die Bundessteuerberaterkammer (BStBK) veröffentlicht einen FAQ-Katalog zur E-Rechnung. Er beantwortet grundlegende Fragen zur Einführung sowie zur GoBD-konformen Ablage, Aufbewahrung und Löschung und bietet Orientierung für Eingangs- und Ausgangsprozesse."
Download unter https://www.bstbk.de/downloads/bstbk/steuerrecht-und-rechnungslegung/fachinfos/BStBK_FAQ_E-Rechnung_final.pdf
Neufassung der BpO: Allgemeine Verwaltungsvorschrift der Bundesregierung für die Außenprüfung – Außenprüfungsordnung (ApO) - Entwurf - Download unter https://www.bundesfinanzministerium.de/Content/DE/Gesetzestexte/Gesetze_Gesetzesvorhaben/Abteilungen/Abteilung_IV/21_Legislaturperiode/2026-03-23-ApO/0-Verordnung.html oder direkt unter https://www.bundesfinanzministerium.de/Content/DE/Gesetzestexte/Gesetze_Gesetzesvorhaben/Abteilungen/Abteilung_IV/21_Legislaturperiode/2026-03-23-ApO/1-Referentenentwurf.pdf?__blob=publicationFile&v=2
erste Ausführungen zu den aktuell geplanten Änderungen unter https://www.haufe.de/steuern/gesetzgebung-politik/bmf-entwurf-aussenpruefungsordnung-ersetzt-betriebspruefungsordnung_168_680492.html
Viele „KI-Chats“ wirken beeindruckend – solange sie nur allgemeines Wissen wiedergeben. In der Praxis (Audit, Compliance, Fachabteilungen) zählt aber etwas anderes: Antworten müssen aus konkreten Dokumenten stammen und nachvollziehbar belegt sein. Genau dafür eignet sich RAG (Retrieval-Augmented Generation): Erst werden passende Textstellen aus deinen Unterlagen gefunden, dann wird darauf basierend geantwortet.
In diesem Beitrag zeige ich ein Verfahren, das vollständig im Browser online läuft, aber trotzdem lokale Ordner einliest und einen Such-/Chat-Workflow ermöglicht – inklusive inkrementellem Update und sauberer Quellenreferenz:
PDF: Treffer mit Seitenzahl
Nicht-PDF (TXT/MD/CSV/JSON/XML/HTML/DOCX): Treffer mit Zeilen n–m
Hinweis: Das Beispiel nutzt im Kern ein Retrieval (BM25). Eine echte LLM-Antwortgenerierung kannst du optional später ergänzen (z. B. via API). Der zentrale Mehrwert hier ist der belastbare Retrieval-Layer inkl. Quellen.
1) Datenaufnahme (Ingestion)
Du lädst eine Dummy-Quelle (z. B. Wikipedia-Summary) per Button, um das System sofort zu testen.
Optional wählst du einen lokalen Ordner aus:
Chromium/Edge: showDirectoryPicker() (HTTPS oder localhost)
Firefox: Fallback per webkitdirectory
2) Parsing / Extraktion
PDF wird mit PDF.js seitenweise extrahiert, damit Treffer später korrekt als „Seite X“ referenziert werden können.
DOCX wird im Browser via Mammoth.js in Text umgewandelt.
Weitere Textformate werden direkt gelesen (CSV/JSON/XML/HTML werden dabei in ein gut chunkbares Textformat umgeformt).
3) Cleaning (Qualitätssicherung)
Whitespace-Normalisierung, aber Zeilen werden bewusst erhalten, damit wir später Zeilenbereiche als Quellenangabe ausweisen können.
Bei CSV: Erkennung des Trennzeichens und zeilenorientierte Darstellung.
Bei HTML: Entfernen von Skript/Style/Navigation und Extraktion des sichtbaren Textes.
4) Chunking
Dokumente werden in Chunks zerlegt, die „retrieval-freundlich“ sind:
wortsaubere Chunk-Grenzen (kein Start mitten im Wort)
Overlap (Überlappung) für Kontextstabilität
Zu jedem Chunk werden Metadaten berechnet:
PDF: page
Nicht-PDF: line_from / line_to (Zeilen n–m)
5) Index / Retrieval
Im Worker läuft ein BM25-Index:
Tokenisierung + Stopword-Filter (DE/EN)
BM25-Scoring
Ergebnisliste (Top-K) inkl. Kontext-Snippet um den Treffer herum (nicht einfach Chunk-Start)
6) Inkrementelles Update
Beim erneuten Ordner-Scan werden Dateien über Signatur erkannt (Pfad + Größe + lastModified):
unveränderte Dateien werden nicht neu verarbeitet
geänderte Dateien: alte Chunks werden gelöscht, neue erzeugt
gelöschte Dateien: Chunks werden entfernt
7) Persistenz (Cache)
Alle Chunks + Dateisignaturen werden in IndexedDB gespeichert:
Browser schließen/öffnen → Cache laden → sofort wieder suchbar
Kein Server-State nötig
Für professionelle Nutzung ist es nicht genug, „irgendwo stand das“ zu sagen. Du willst:
schnell zur Stelle springen
bei Reviews/Audits die Quelle belegen
Ergebnisse reproduzierbar machen
Darum ist die Quelle in unserem Tool nicht nur „Dokumentname“, sondern:
PDF Seite X
Text Zeilen n–m
Das ist die Brücke zwischen KI-UX und klassischer Nachvollziehbarkeit.
Damit das Ganze flüssig im Browser bleibt, gelten pragmatische Limits:
max. 2 MB pro Datei (konfigurierbar)
max. ~5 Mio Zeichen pro Scan (konfigurierbar)
Als Faustregel: Für interaktive Nutzung (ohne Warteorgien) ist ein Ordnerumfang im Bereich einige 10–200 Text/PDF-Seiten gut beherrschbar – abhängig von Gerät/Browser. Wenn du deutlich mehr brauchst:
aggressiver chunking/cleaning
Vorfilter (nur relevante Unterordner)
optional: „Index-Build“ in Batches, oder Worker-Sharding
interne Richtlinien, Arbeitsanweisungen, Prozessdokumente
Audit-/Prüfungsakten (PDF)
Log- und Exportdateien (CSV/JSON)
Projektdokumentation (MD/TXT)
Word-Dokumente als DOCX
Mit diesem Ansatz bekommst du eine nachvollziehbare RAG-Basis im Browser:
lokale Dokumente einlesen
inkrementell aktualisieren
schnell durchsuchen
Treffer mit Seiten und Zeilen belegen
Hierkommst du zum Online-Demo des RAG-Systems!
Wenn du darauf aufbauen willst, ist der nächste Schritt die Antwortgenerierung über ein LLM (API oder eigenes Modell) – aber der kritische Teil für Professionalität ist oft genau das, was hier schon steht: guter Index + gute Quellen.