SuSa-Extraktion
Vom Saldenlisten-PDF zum validierten JSON
Die Summen- und Saldenliste ist das Rückgrat der deutschen Buchhaltung. Jeder Prüfer, jeder Kreditgeber, jeder Analyst braucht sie strukturiert. Aber sie kommt als PDF: ein dichtes Raster aus Kontonummern, Soll/Haben-Spalten und deutschen Zahlenformaten, an denen herkömmliche OCR scheitert. Holofin extrahiert sie, ordnet sie SKR03/SKR04 zu und beweist das Ergebnis durch Kreuzprüfung jeder Summe.
Demo vereinbaren15.03.2024 09:22 Uhr
Summen- und Saldenliste
Warum Standard-OCR
an der SuSa scheitert
Eine SuSa sieht aus wie eine einfache Tabelle. Ist sie aber nicht. Das dichte Raster aus Kontonummern, deutschem Zahlenformat und Soll/Haben-Konventionen macht sie zu einem der schwierigsten Finanzdokumente für die automatische Extraktion.
Jedes Buchhaltungssystem formatiert anders
DATEV, SAP, Lexware, Agenda, ADDISON: jedes System erzeugt SuSa-PDFs mit unterschiedlichen Spaltenlayouts, Kopfzeilenstrukturen und Gruppierungskonventionen. Allein DATEV hat je nach Version und Konfiguration ein halbes Dutzend Layout-Varianten. Ein Template, das auf ein Format trainiert wurde, liefert bei einem anderen nur Müll.
Soll, Haben, S, H oder nur ein Vorzeichen?
Die deutsche Buchhaltung verwendet „Soll“ und „Haben“ statt +/-. Manche Systeme kürzen zu „S“ und „H“ ab. Andere nutzen getrennte Spalten. Wieder andere verwenden eine einzige Saldo-Spalte mit S/H-Kennzeichen.
Und dann gibt es Systeme, die Konventionen mischen: S/H für Salden, aber getrennte Soll-/Haben-Spalten für Bewegungen. Ein falsches Vorzeichen, und alle Beträge stimmen nicht mehr.
Vertauscht man das Vorzeichen bei einem Konto, stimmt die Bilanzsumme nicht mehr. Aktiva und Passiva gehen nicht auf. Ohne Fehlermeldung.
1.250,00 oder 1.250.00?
Deutsches Zahlenformat: Punkt als Tausendertrennzeichen, Komma als Dezimaltrennzeichen. „1.250,00“ sind eintausendzweihundertfünfzig Euro. Aber OCR verwechselt häufig den deutschen Punkt mit dem englischen Dezimalpunkt und macht aus 1.250,00 € plötzlich 1,25 €. Bei Hunderten von Konten summieren sich diese Fehler unbemerkt.
Tabellen über 20+ Seiten
Eine typische SuSa hat 100–300 Konten. Das sind 10–30 Seiten dichte Tabellendaten. Kopfzeilen wiederholen sich (oder auch nicht), Zwischensummen erscheinen an Gruppenrändern, und die Tabelle bricht mitten in einer Zeile auf die nächste Seite um. Man muss die gesamte Tabelle zusammenfügen, bevor man einen einzigen Wert extrahieren kann.
SKR03, SKR04 oder etwas ganz anderes
Der Kontenrahmen bestimmt, was jede Kontonummer bedeutet. Konto 1200 ist „Bank“ im SKR03, aber etwas anderes im SKR04. Ohne Kenntnis des verwendeten Kontenrahmens sind die extrahierten Zahlen bedeutungslos. Und manche Unternehmen verwenden individuelle Kontenrahmen, die keinem Standard folgen.
So funktioniert es
Jede SuSa durchläuft vier Stufen. Keine Templates, keine systemspezifische Konfiguration. Die gleiche Pipeline verarbeitet DATEV, SAP und Lexware.
Klassifikation
Das Dokument wird als Summen- und Saldenliste identifiziert und das Quellsystem (DATEV, SAP, Lexware etc.) erkannt. Der Kontenrahmen (SKR03, SKR04 oder individuell) wird automatisch anhand der Kontonummernmuster bestimmt.
Segmentierung
Mehrperioden-SuSa werden nach Perioden segmentiert. Enthält das PDF mehrere Geschäftsjahre oder Monatsaufschlüsselungen, wird jede Periode isoliert. Kontengruppenränder (Aktiva, Passiva, Erträge, Aufwendungen) werden erkannt.
Extraktion
Ein visuelles Modell liest das Seitenlayout und extrahiert jede Kontozeile: Kontonummer, Bezeichnung, Anfangssaldo, Periodensoll, Periodenkredit und Abschlusssaldo. Soll/Haben-Kennzeichen werden unabhängig von der Formatkonvention korrekt interpretiert.
Jede Extraktion liefert ein JSON wie dieses:
{
"company": "Bergmann Handels GmbH, Lindenstraße 12, 80331 München",
"ref": "2024-003",
"period": "2024-01-01 to 2024-03-31",
"doc_date": "2024-03-31",
"accounts": [
{
"account_number": "480",
"description": "GWG bis 800 EUR",
"account_class": null,
"opening_balance": -1540.80,
"closing_balance": -1412.40,
"debit": null,
"credit": 128.40,
"cumulative_debit": 897.20,
"cumulative_credit": 128.40
},
{
"account_number": "1200",
"description": "Bank",
"account_class": null,
"opening_balance": 12.50,
"closing_balance": 23272.23,
"debit": 342180.45,
"credit": 318920.72,
"cumulative_debit": 342180.45,
"cumulative_credit": 318920.72
}
]
}Validierung
Die SuSa ist eines der wenigen Finanzdokumente, bei dem jede Zahl gegengeprüft werden kann. Wir validieren umfassend:
- Soll/Haben-Gleichgewicht: Gesamtsoll muss gleich Gesamthaben über alle Konten sein. Das ist die Grundprüfung der doppelten Buchführung. Jede Abweichung bedeutet, dass die Extraktion einen Wert verpasst oder falsch zugeordnet hat.
- Kontenkontinuität: Pro Konto gilt: Anfangssaldo + Periodensoll − Periodenkredit = Abschlusssaldo. Damit werden Extraktionsfehler auf Zeilenebene erkannt.
- Fußzeilenabgleich: Die extrahierten Zeilensummen werden mit den gedruckten Gesamtsummen in der Dokumentfußzeile abgeglichen. Abweichungen deuten auf fehlende Zeilen hin.
- Kontonummernprüfung: Extrahierte Kontonummern werden gegen den erkannten Kontenrahmen geprüft. Ungültige oder außerhalb des Bereichs liegende Nummern werden markiert.
Nachvollziehbare Ergebnisse
Jeder extrahierte Wert trägt Koordinaten, die auf seine exakte Position auf der Quellseite verweisen. Wenn der Wirtschaftsprüfer fragt „Woher kommt diese Zahl?“, zeigen Sie es ihm.
Prüfungssichere Rückverfolgbarkeit
Wenn der Wirtschaftsprüfer einen Saldo hinterfragt, klicken Sie darauf und sehen die exakte Quellzelle im Original-PDF, hervorgehoben. Kein „Das hat das System gesagt“.
Fehler sofort erkennen
Ein Prüfer markiert den Saldo von Konto 1400 als verdächtig. Er klickt auf den Wert. Der Quellbereich wird im Originaldokument hervorgehoben. Vergleichen, korrigieren, weiter. Kein Durchblättern von 20-seitigen PDFs.
Lückenlose Datenherkunft
Verfolgen Sie jeden Kontensaldo von der Kreditentscheidung zurück zur Original-SuSa, Seite, Zeile und Zelle. Die vollständige Kette ist dokumentiert. Die BaFin muss Ihnen nicht aufs Wort glauben.
Summen- und Saldenliste
Wer nutzt das
Die SuSa ist das erste Dokument, das Kreditgeber, Wirtschaftsprüfer und Analysten anfordern. So nutzen Teams die strukturierten SuSa-Daten.
Anwendungsfälle
Kreditanalyse & Kreditvergabe
Kreditgeber brauchen strukturierte SuSa-Daten zur Bonitätsprüfung. Einmal extrahieren, automatisch in Scoring-Modelle einspeisen. Kein manuelles Abtippen aus PDFs.
Jahresabschlussprüfung
Wirtschaftsprüfer und Steuerberater erhalten jeden Januar Stapel von SuSa-PDFs. Strukturierte Extraktion spart Wochen manueller Dateneingabe pro Mandant.
Mehrjahres-Trendanalyse
SuSa-Daten über 3–5 Geschäftsjahre vergleichen. Umsatztrends, Kostenstrukturveränderungen und Bilanzverschiebungen automatisch erkennen.
Unterstützte Buchhaltungssysteme
DATEV
Alle gängigen DATEV-SuSa-Layouts, einschließlich Kanzlei-Rechnungswesen, DATEV Unternehmen online und Legacy-Formate. SKR03 und SKR04 werden automatisch erkannt.
SAP
SAP FI Saldenlisten-Reports (S_ALR_87012277 und Varianten). Verarbeitet sowohl Standard- als auch kundenspezifische Report-Layouts.
Lexware, Agenda, ADDISON
Buchhaltungssoftware für den Mittelstand. Jedes System erzeugt SuSa in eigenem Format. Alle werden ohne Konfiguration verarbeitet.
Weitere Systeme
Sage, BMD, Diamant, orgaMAX, sevDesk und kundenspezifische ERP-Exporte. Die Extraktions-Engine liest das Layout direkt aus dem Dokument.
Ihr System ist nicht dabei? Es funktioniert wahrscheinlich trotzdem.
Wir verwenden keine Templates. Die Extraktions-Engine liest das Layout direkt aus dem Dokument. Neue Systeme funktionieren ohne Setup.
Häufige Fragen
Die Fragen, die uns Kreditgeber, Prüfer und Steuerberater am häufigsten stellen.
Die SuSa (Summen- und Saldenliste) ist die deutsche Saldenbilanz. Sie listet jedes Sachkonto mit Anfangssaldo, Soll- und Haben-Umsätzen der Periode sowie Abschlusssaldo auf. Sie ist die Standardausgabe deutscher Buchhaltungssysteme (DATEV, SAP, Lexware) und unverzichtbar für Jahresabschluss, Prüfung, Steuererklärung und Kreditanalyse. Im englischsprachigen Raum entspricht sie am ehesten dem „Trial Balance“.
Holofin extrahiert SuSa-Dokumente unabhängig vom verwendeten Kontenrahmen. SKR03 (Prozessgliederungsprinzip) und SKR04 (Abschlussgliederungsprinzip) sind am weitesten verbreitet und werden vollständig unterstützt, einschließlich automatischer Erkennung. Branchenspezifische Kontenrahmen (SKR45 für das Gesundheitswesen, SKR49 für gemeinnützige Organisationen) und individuelle Kontenrahmen funktionieren ebenfalls. Die Extraktion hängt nicht von einer vordefinierten Zuordnung ab, sondern liest Kontonummern und Bezeichnungen so, wie sie im Dokument erscheinen.
Jede Extraktion wird gegen die Grundgleichung der Buchhaltung geprüft: Gesamtsoll muss gleich Gesamthaben über alle Konten sein (doppelte Buchführung). Pro Konto muss Anfangssaldo + Periodensoll − Periodenkredit den Abschlusssaldo ergeben. Extrahierte Zeilensummen werden mit den gedruckten Gesamtsummen abgeglichen. Kontonummern werden gegen den erkannten Kontenrahmen geprüft. Abweichungen werden mit den betroffenen Konten und Beträgen angezeigt, nicht nur ein generisches „Validierung fehlgeschlagen“.
Ja. DATEV ist die häufigste Quelle für SuSa-Dokumente in Deutschland, genutzt von über 40.000 Steuerberatern. Holofin verarbeitet DATEV-generierte PDFs in allen gängigen Layouts, einschließlich Kanzlei-Rechnungswesen, DATEV Unternehmen online und Legacy-Formate. Mehrperioden-SuSa, konsolidierte SuSa über Kostenstellen und SuSa mit Vorjahresvergleich werden unterstützt. Keine DATEV-spezifische Konfiguration erforderlich.
Mehrperioden-SuSa (z.B. Monatsspalten über ein Geschäftsjahr oder Jahresvergleiche) werden in Einzelperioden segmentiert. Jede Periode wird separat extrahiert und validiert, dann in einem strukturierten JSON mit Periodengranularität zusammengeführt. Besonders nützlich für Trendanalysen bei Kreditentscheidungen oder Mehrjahres-Prüfungsvergleiche.
Ja. Holofin bietet eine REST-API für die programmatische Dokumentenübermittlung und Ergebnisabfrage. PDF hochladen, Webhook bei Fertigstellung erhalten, strukturiertes JSON-Ergebnis abrufen. Batch-Verarbeitung wird unterstützt: Hunderte von SuSa-Dokumenten in einem API-Aufruf übermitteln und Ergebnisse bei Fertigstellung abrufen. Authentifizierung über API-Schlüssel mit organisationsbezogenem Scoping.
Die deutsche Buchhaltung verwendet das Komma als Dezimaltrennzeichen und den Punkt oder Leerzeichen als Tausendertrennzeichen (z.B. „1.234,56“ = eintausendzweihundertvierundreißig Euro und 56 Cent). Holofin erkennt das im Dokument verwendete Zahlenformat automatisch. Auch S/H-Kennzeichen (Soll/Haben), getrennte Soll-/Haben-Spalten und verschiedene Negativ-Konventionen (Minuszeichen, Klammern oder Rotdruck im Original) werden verarbeitet. Keine Locale-Konfiguration erforderlich.
Ja. Holofin verarbeitet alle Daten auf europäischer Infrastruktur. Die Dokumentenaufbewahrung ist pro Organisation konfigurierbar. Daten werden im Ruhezustand und bei der Übertragung verschlüsselt. Keine Dokumenteninhalte werden für Modelltraining verwendet. Holofin kann Löschanfragen gemäß DSGVO Art. 17 (Recht auf Löschung) ausführen. Ein Auftragsverarbeitungsvertrag (AVV) ist für Enterprise-Kunden verfügbar.
Saldenlisten-Daten,
denen Sie vertrauen können.
Schicken Sie uns die SuSa-PDFs, an denen Ihr letztes Tool gescheitert ist. Die 30-seitigen DATEV-Reports. Die Mehrperioden-Vergleiche. Die Legacy-SAP-Exporte. Wir zeigen Ihnen validiertes, strukturiertes JSON auf der anderen Seite.