Sidebar

IDEA-Hilfe.de
  • Suche
  • Newsfeeds
    • Newsletter
  • Home
  • Steuer-News
    • allgemeine Steuer-News
    • GOBD
    • IDEA
    • Kasse
    • SRP - Summarische Risikoprüfung
    • BFH-Entscheidungen
    • FG-Entscheidungen
    • E-Rechnungen
    • Umsatzsteuer
  • Webverzeichnis
    • Steuerrecht
      • BFH-Urteile
      • FG-Urteile
      • Steuerbehörden
      • Finanzämter
      • Formulare / Vordrucke
      • Steuersoftware
      • IDEA
      • Steuerkanzleien
      • Zeitschriften
      • Allgemeine Steuerlinks
      • E-Rechnungen-Links
      • Kassenlinks
      • Webinare
      • Umsatzsteuer
      • Gesetze
      • Verwaltungsschreiben
      • Open Data Links
    • Handelsrecht
    • Strafrecht
    • Steuerrecht Ausland
      • Österreich
      • Schweiz
      • USA
    • Google-Suchhilfe
    • Tools for Data Science
  • Datenanalyse
    • IDEA
    • Microsoft Power BI
    • Netzwerkanalyse
    • Python
    • Open_Data
    • Machine_Learning
  • KI-Tools
    • KI-Tools Text zu Text
    • KI-Tools Text zu Bild
    • KI-Tools Text zu Sprache
    • KI-Tools Text zu Audio
    • KI-Tools Text zu Video
    • KI-Erkenner
    • KI-Tools-Sammlung
    • KI-Suchmaschinen
    • KI-PROMT-Sammlung
    • KI-PROMPT-Management
    • KI-Offline-Tools
    • KI-Spass
  • Chatbot

Home

GoBD-Export mit Python: Ein Guide für Entwickler und offene ERP-Systeme

Details
Super User
IDEA - Datenanalyse
28. März 2026
Zugriffe: 76

GoBD-Export mit Python: Ein Guide für Entwickler und offene ERP-Systeme

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.

 

Die Anatomie eines GoBD-Exports

Ein valider Export ist kein bloßer CSV-Dump. Er besteht aus drei unverzichtbaren Komponenten, die in einem ZIP-Archiv zusammengefasst werden:

 

  1. Datendateien: Meist CSV- oder ASCII-Dateien mit festen Feldlängen, die die eigentlichen Buchungs- und Stammdaten enthalten.

  2. Die Indexdatei (index.xml): Das „Gehirn“ des Exports. Sie beschreibt die Struktur, Feldtypen und Relationen der Datendateien.

  3. Die Strukturdefinition (gdpdu-01-08-2002.dtd): Eine offizielle Datei der Finanzverwaltung, gegen die die index.xml validiert wird.

     

Schritt 1: Datenextraktion mit Pandas

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.

 

Python-Code
 
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
    )
 

Schritt 2: Dynamische Generierung der index.xml

Die 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

MaxLength (optimiert den Import).

 

Numeric Beträge/Mengen

Accuracy (Nachkommastellen).

 

Date Datumsangaben

Format (z. B. DD.MM.YYYY).

 

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.

 

Schritt 3: Compliance durch Audit-Logs

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.

 

Schritt 4: Validierung und Konsistenzprüfung

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:

 

Anfangsbestand zzgl. Bewegungen = Endbestand

Stimmt diese Gleichung nicht, fehlen entweder Datensätze im Export oder die Extraktionslogik ist fehlerhaft.

 

Update 2025: Was hat sich geändert?

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.

Fazit

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.

GOBD Python Export
powered by social2s

FAQ-Katalog der BStBK zur E-Rechnung (Stand 19.03.2026)

Details
Super User
E-Rechnung - elektronische Rechnungen
25. März 2026
Zugriffe: 71

FAQ-Katalog der BStBK zur E-Rechnung (Stand 19.03.2026):

"Die Bundessteuer­beraterkammer (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 Ausgangs­prozesse."

Download unter https://www.bstbk.de/downloads/bstbk/steuerrecht-und-rechnungslegung/fachinfos/BStBK_FAQ_E-Rechnung_final.pdf 

GOBD BStBK E-Rechnung Aufbewahrungsfrist
powered by social2s

Neufassung der BpO: Allgemeine Verwaltungsvorschrift der Bundesregierung für die Außenprüfung – Außenprüfungsordnung (ApO) - Entwurf

Details
Super User
allgemeine Steuer-News
25. März 2026
Zugriffe: 61

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 

BMF Betriebsprüfung Aussenprüfung BpO ApO
powered by social2s

RAG komplett im Browser: Lokale Dokumente durchsuchen, chatten und Quellen sauber belegen (PDF-Seiten + Zeilen n–m)

Details
Super User
Natural Language Processing (NLP)
21. Februar 2026
Zugriffe: 88

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.


Was ist das Verfahren?

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


Warum „Seite“ und „Zeilen n–m“ so wichtig sind

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.


Grenzen und sinnvolle Datenvolumen-Limits

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


Typische Use Cases

  • interne Richtlinien, Arbeitsanweisungen, Prozessdokumente

  • Audit-/Prüfungsakten (PDF)

  • Log- und Exportdateien (CSV/JSON)

  • Projektdokumentation (MD/TXT)

  • Word-Dokumente als DOCX


Fazit

Mit diesem Ansatz bekommst du eine nachvollziehbare RAG-Basis im Browser:

  • lokale Dokumente einlesen

  • inkrementell aktualisieren

  • schnell durchsuchen

  • Treffer mit Seiten und Zeilen belegen

 

Hier kommst 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.

Chat Chatbot RAG
powered by social2s
Seite 1 von 101
  • Start
  • Zurück
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • Weiter
  • Ende
Bootstrap is a front-end framework of Twitter, Inc. Code licensed under MIT License. Font Awesome font licensed under SIL OFL 1.1.
Powered by T3 Framework