Warum die Rechnungserfassung in Deutschland mehr kostet
als die meisten Finanzteams glauben

Das DATEV-Paradoxon: Software überall, Hände trotzdem auf der Tastatur

Ein mittelständisches Produktionsunternehmen in NRW führt seine Buchhaltung über DATEV. Der Steuerberater besitzt die Firmenlizenz. Das Finanzteam hat die Zugangsdaten. Jeden Monat zahlen sie die Abonnementgebühr. Und jeden Monat verbringt jemand in diesem Büro zweieinhalb Tage damit, Lieferantenrechnungsdaten aus PDFs und gescannten Dokumenten Feld für Feld in eine Tabellenkalkulation einzutippen, damit der Steuerberater sie importieren kann.

Das ist kein Einzelfall. Es ist der Standard für tausende deutsche Mittelstandsunternehmen, die monatlich zwischen 100 und 500 Lieferantenrechnungen verarbeiten. Sie haben die Software. Sie haben die Schulung. Trotzdem führen sie manuelle Dateneingabe durch, als hätte es das letzte Jahrzehnt der Buchhaltungstechnologie nie gegeben.

Der Grund ist strukturell, nicht verhaltensbedingt. DATEV liest keine PDFs. Es verarbeitet strukturierte Eingaben – CSV-Dateien mit Semikolon-Trennzeichen und ANSI-Kodierung oder XML-Dokumente, die einem strengen Schema entsprechen. Jedes Feld hat einen Namen, den Ihr Steuerberater erwartet: Belegdatum im Format DD.MM.YYYY, nicht ISO 8601. Einen Steuerschlüssel – einen numerischen Steuercode, der DATEV mitteilt, ob diese Zeile 19 % MwSt, 7 % MwSt oder §13b Reverse-Charge betrifft. Ein Gegenkonto, das dem korrekten SKR03- oder SKR04-Kontocode zugeordnet ist, vier bis acht Stellen je nach Kontenrahmenstruktur. Die Software ist nicht das Hindernis. Die Lücke zwischen dem, was Ihre Lieferanten senden, und dem, was Ihr Buchhaltungssystem akzeptiert, ist es.

Und diese Lücke wird jeden Monat von einem Menschen gefüllt, der auf einen Bildschirm schaut und Zahlen in einen anderen Bildschirm tippt.

Der eigentliche Engpass ist nicht Ihre Buchhaltungssoftware

Gehen Sie einen typischen Monat eingehender Rechnungen in einem deutschen Unternehmen durch. Dienstagmorgen erhält das Postfach drei PDFs: eines von Metro, mit einem Spaltenlayout mit Artikeln, Mengen, Einzelpreisen, Nettobeträgen und den Umsatzsteuer-Zwischensummen, aufgeschlüsselt auf 19 % und 7 % in separaten Zeilen. Eines von einem lokalen Handwerker – eine gescannte A4-Seite mit einer handschriftlichen Rechnungsnummer, einem einzelnen Nettobetrag und „zzgl. 19 % MwSt.“, unten hingekritzelt. Eines von einem niederländischen Lieferanten, auf Englisch formatiert, ohne Steuernummer, ohne separate Umsatzsteuerzeile und mit einem Verweis auf „Reverse Charge“, versteckt im Kleingedruckten der Fußzeile.

Drei Rechnungen. Drei völlig unterschiedliche Extraktionsaufgaben. Die Metro-Rechnung erfordert die Identifizierung, welche Positionen welchem Steuersatz zugeordnet sind – eine Aufteilung, die Metros Layout auf der Seite explizit macht, die aber die Übersetzung in DATEVs einzelnen Steuerschlüssel pro Buchungszeile überstehen muss. Die Handwerker-Rechnung erfordert das Entziffern der Handschrift und die Bestätigung, dass „zzgl. 19 %“ tatsächlich den Nettobetrag plus MwSt. bedeutet, nicht eine Beschreibung einer separaten Gebühr. Die niederländische Rechnung erfordert das Erkennen eines innergemeinschaftlichen Reverse-Charge-Szenarios und die Verbuchung gemäß §13b UStG mit dem korrekten Steuerschlüssel, während auch zu vermerken ist, dass der Rechnung eine USt-IdNr fehlt – ein Pflichtfeld für grenzüberschreitende Abzüge.

Das ist das strukturelle Problem, das auf keiner Marketingseite eines Softwareanbieters erwähnt wird: Lieferantenrechnungsformate sind irreduzibel vielfältig, und die deutsche Buchhaltungs-Compliance ist irreduzibel präzise. Die Spannung zwischen diesen beiden Tatsachen hält Finanzteams beim Tippen.

Der Doppelstandard SKR03 und SKR04 verschärft das Ganze. Dieselbe Lieferantenrechnung für Büromiete wird je nach verwendetem Kontenrahmen des Unternehmens auf unterschiedliche Aufwandskonten gebucht – SKR03 könnte sie einer prozessorientierten Kontenfamilie zuordnen, SKR04 einer an der Finanzberichterstattung ausgerichteten. Die Person, die die Datenerfassung durchführt, muss wissen, in welchem System sie sich befindet, und jedes Mal die korrekte Kontierungslogik anwenden. Keine zwei Lieferanten präsentieren dasselbe Layout. Keine zwei Rechnungen desselben Lieferanten haben garantiert identische Feldplatzierungen. Die kognitive Belastung ist kumulativ und für jeden, der die Arbeit nicht macht, unsichtbar.

Was ein einziger falscher Tastendruck wirklich kostet

Der offensichtliche Kostenfaktor ist Zeit. Bei durchschnittlichen deutschen Arbeitskosten von 45,00 € pro Stunde über alle Branchen im Jahr 2025 (Destatis) und einer einzelnen Rechnung, die etwa 15 Minuten für das Auffinden der Felder, das Eintippen, die Prüfung der Steuercodes und die Bestätigung der Kontenzuordnung benötigt, verbrennt ein Unternehmen, das 200 Rechnungen pro Monat verarbeitet, 50 Stunden – das sind monatlich rund 2.250 € allein für reine Datenerfassungsarbeit. Das sind die sichtbaren Kosten. Die unsichtbaren sind größer.

Die manuelle Dateneingabe weist eine Fehlerquote von 3 % bis 5 % auf, abhängig von der Komplexität der Dokumente und der Ermüdung der Bearbeiter. Bei 200 Rechnungen pro Monat bedeutet das, dass 6 bis 10 Rechnungen einen Fehler enthalten. Eine vertauschte Ziffer in einer Rechnungsnummer führt zu einer Unstimmigkeit, wenn der Steuerberater versucht, die Konten abzugleichen. Ein falscher Steuerschlüssel auf einer Reverse-Charge-Rechnung führt nicht nur zu einem fehlgeschlagenen Import – er zieht eine Kette von falschen Umsatzsteuermeldungen nach sich, die Monate später bei einer Betriebsprüfung ans Licht kommen. Ein Datum im Format MM/DD/YYYY statt DD.MM.YYYY führt dazu, dass DATEV den gesamten Stapel ablehnt, nicht nur den einzelnen Datensatz. Der Steuerberater schickt ihn zurück, und der Monatsabschluss verzögert sich um Tage.

Es gibt auch Kosten, die schwerer zu quantifizieren sind. Eine Lieferantenrechnung mit 2 % Skonto, die am ersten Tag eingeht, aber erst am siebten Tag erfasst wird, weil sich ein Rückstau gebildet hat, bedeutet echtes liegen gelassenes Geld. Eine fehlende USt-IdNr auf einer EU-Lieferantenrechnung schafft ein Compliance-Risiko, das bei einer Prüfung dazu führen kann, dass das Finanzamt den Vorsteuerabzug gemäß §15 UStG versagt. Die Person, die diese Rechnung vor sechs Monaten eingegeben hat, arbeitet vielleicht nicht einmal mehr im Unternehmen, aber der Fehler sitzt im Archiv – das gemäß GoBD zehn Jahre lang im ursprünglichen strukturierten Format aufbewahrt werden muss.

Jeder Tastendruck wirkt nach. Das Finanzteam spürt die Kosten nicht im Moment der Eingabe. Es spürt sie, wenn der Monatsabschluss sich verzögert, wenn der Steuerberater Korrekturen anfordert oder wenn eine Steuerprüfung eine Unstimmigkeit aufdeckt, die auf einen Dienstagnachmittag vor drei Quartalen zurückgeht.

Das Mandat, das das Problem nicht lösen wird – zumindest noch nicht

Seit dem 1. Januar 2025 muss jedes deutsche B2B-Unternehmen in der Lage sein, strukturierte E-Rechnungen im XRechnung- oder ZUGFeRD-2.0.1+-Format zu empfangen. Bis Januar 2027 müssen Unternehmen mit einem Umsatz über 800.000 € diese ausstellen. Bis Januar 2028 gilt dies für alle Unternehmen. Auf dem Papier klingt das so, als würde es das Problem der manuellen Erfassung an der Quelle beseitigen: Wenn Rechnungen als strukturiertes XML eintreffen, muss niemand etwas eintippen.

Die betriebliche Realität während der Übergangsphase 2025–2028 ist das Gegenteil von sauber. In einer einzigen Woche könnte ein Finanzteam eine XRechnung-XML-Datei von einem großen Lieferanten erhalten (maschinenlesbar, aber zur Anzeige ist ein spezielles Viewer-Programm erforderlich – es gibt keine visuelle Komponente), ein ZUGFeRD-Hybrid-PDF von einem anderen (sieht aus wie ein normales PDF, enthält aber strukturiertes XML, das die meisten E-Mail-Postfächer entfernen), ein traditionelles PDF von einem kleineren Lieferanten, der noch nicht zur Umstellung verpflichtet ist, und eine fotografierte Papierrechnung von einem Einzelunternehmer, der weiterhin physische Post versendet. Vier Formate, vier Eingabekanäle, ein Ziel: die DATEV-CSV, die Ihr Steuerberater erwartet.

XRechnung und ZUGFeRD wurden entwickelt, um Rechnungen beim Empfänger maschinenverarbeitbar zu machen. Aber „maschinenverarbeitbar“ funktioniert nur, wenn das Empfangssystem die XML-Elemente parsen, sie den korrekten DATEV-Feldern zuordnen und die Steuerschlüssel gegen den Kontenrahmen validieren kann. Für Unternehmen, deren Arbeitsablauf darin besteht, dass ein Finanzteam-Mitglied ein PDF öffnet und Daten in eine Tabellenkalkulation eintippt, ändert das Eintreffen von XML-Dateien nichts – es könnte sogar Reibung erzeugen, da das XML ohne ein Viewer-Programm nicht gelesen werden kann und jemand nun entscheiden muss, ob er es programmatisch parst oder das Viewer-Programm öffnet, die Felder liest und sie trotzdem eintippt.

Die Übergangsphase läuft bis Ende 2027. Für das Finanzteam vor Ort bedeutet das drei weitere Jahre der Verarbeitung gemischter Formate – und das E-Rechnungs-Mandat, weit davon entfernt, das Problem zu lösen, fügt dem Stapel, der bereits PDFs, Scans, Fotos und handschriftliche Dokumente umfasst, ein weiteres Format hinzu. Das Mandat wurde für das Zielsystem konzipiert. Es hat die menschliche Brücke dazwischen nicht berücksichtigt.

Wenn Extraktion nicht mehr das Problem ist

Wenn der Engpass nicht die Buchhaltungssoftware ist, sondern der Schritt zwischen dem Format des Lieferanten und dem Format der Buchhaltungssoftware, dann ist die Lösung nicht bessere Buchhaltungssoftware. Es ist bessere Extraktion. Konkret: Extraktion, die nicht davon abhängt, im Voraus zu wissen, welches Layout der nächste Lieferant verwenden wird.

Traditionelle OCR-Tools gehen dieses Problem mit Vorlagen an: Sie definieren Zonen auf einer Seite, in denen bestimmte Felder erscheinen, und die Software liest diese Zonen. Das funktioniert für einen Lieferanten. Es scheitert in dem Moment, in dem ein zweiter Lieferant ein anderes Layout verwendet – was in der Praxis der Moment ist, in dem die zweite Rechnung eintrifft. Deutsche Finanzteams haben nicht den Luxus, Vorlagenbibliotheken für Dutzende von Lieferanten zu erstellen und zu pflegen, jeder mit seinen eigenen saisonalen Formatvariationen.

Ein anderer Ansatz – derjenige, der das strukturelle Problem tatsächlich angeht – besteht darin, die KI das Dokument so lesen zu lassen, wie es ein Mensch tut: indem sie versteht, was ein Feld bedeutet, nicht wo es steht. Das ist der Mechanismus hinter der Benutzerdefinierten Spaltenextraktion: Sie geben die gewünschten Spalten an – Rechnungsnummer, Belegdatum, Lieferant, Nettobetrag, USt-Betrag, USt-Satz, USt-IdNr – und die KI lokalisiert jeden Wert auf der Seite, indem sie die Semantik des Dokuments versteht, unabhängig davon, ob er oben, unten, in einer Tabelle oder in einem Absatz eingebettet erscheint. Keine Vorlage. Keine Zonendefinition. Keine Einrichtung pro Lieferant.

Eine Rechnung von Metro, ein Scan von einem lokalen Handwerker und eine niederländische Reverse-Charge-PDF durchlaufen alle dieselbe Pipeline. Die Ausgabe ist eine Tabelle, in der jede Zeile eine Rechnung ist und jede Spalte der Feldstruktur entspricht, die Ihr Steuerberater für den DATEV-Import erwartet. Die Rolle des Menschen verschiebt sich vom Transkribieren zum Verifizieren – eine Aufgabe, die Sekunden pro Rechnung dauert statt Minuten.

Die von Ihnen angegebenen Felder werden zu den Spalten Ihrer Ausgabedatei – genau die Struktur, die Ihr Steuerberater für den DATEV-CSV-Import benötigt. Wenn Sie bereits wissen, welche Felder Ihr Steuerberater benötigt, können Sie diese einmal definieren und dieselbe Spaltenliste jeden Monat wiederverwenden. Keine Neuformatierung. Keine manuelle Übertragung. Kein Rätselraten, ob das Datumsformat in Zeile 47 von DATEV akzeptiert wird.

Für Unternehmen, die deutsche Lieferantenrechnungen in großem Umfang verarbeiten, lässt sich dieser Ansatz direkt in den Batch-Workflow integrieren – laden Sie einen ganzen Monat Eingangsrechnungen auf einmal hoch, legen Sie Ihre Extraktionsspalten einmal fest und erhalten Sie eine einzige konsolidierte Tabelle, bereit für den Steuerberater. Die grundlegenden Mechanismen zur Überführung von Rechnungsdaten in DATEV, einschließlich der relevanten Felder gemäß §14 UStG und der Auswirkungen der SKR03/SKR04-Kontenstrukturen auf die Kontenzuordnung, wurden für deutsche Finanzteams, die diesen Workflow von Grund auf einrichten, bereits ausführlich behandelt.

Was sich ändert, wenn Sie die Abtipperei beenden

Die am meisten unterschätzten Kosten der manuellen Rechnungserfassung sind nicht die Zeit oder die Fehler. Es sind die kognitiven Wechselkosten. Ein Finanzprofi, der zweieinhalb Tage pro Monat damit verbringt, Lieferantendaten in Tabellen einzutippen, analysiert keinen Cashflow, verhandelt keine Zahlungsbedingungen und erkennt keine Ausgabenmuster. Die Arbeit, die Urteilsvermögen und Erfahrung erfordert, wird an den Rand gedrängt, weil die Arbeit, die beides nicht erfordert – aber dringend und termingetrieben ist – die verfügbaren Stunden verbraucht.

Der Wandel vollzieht sich, wenn die Extraktion zu einer Verifizierungsaufgabe statt zu einer Transkriptionsaufgabe wird. Die KI liest eine Metro-Rechnung, identifiziert den Nettobetrag, die Umsatzsteueraufteilung, den Lieferantennamen und das Rechnungsdatum – in 5 bis 10 Sekunden. Das Finanzteam prüft die extrahierten Felder, um zu bestätigen, dass sie mit dem Quelldokument übereinstimmen. Wenn ja, wird die Zeile freigegeben. Wenn nicht, ist die Korrektur eine einzelne Bearbeitung, keine vollständige Neueingabe. Der Durchsatz steigt von etwa vier Rechnungen pro Stunde auf etwa vier Rechnungen pro Minute.

Ein Unternehmen, das 200 Rechnungen pro Monat mit je 15 Minuten verarbeitet, verbringt 50 Stunden mit Dateneingabe. Bei 30 Sekunden pro Rechnung – 5 bis 10 Sekunden für die Extraktion, 20 Sekunden für die Verifizierung – benötigt dasselbe Volumen weniger als 2 Stunden. Die verbleibenden 48 Stunden pro Monat verlagern sich von der Transkription zur Analyse. Das ist der Unterschied zwischen einer Finanzabteilung, die darüber berichtet, was letzten Monat passiert ist, und einer, die gestaltet, was nächsten Monat passiert.

Bei deutschen Arbeitskosten von 45 € pro Stunde ist die Rechnung einfach: 2.250 € für manuelle Erfassung pro Monat werden zu rund 90 € für Verifizierung. Über ein Jahr ergibt das 25.920 € an eingesparten Arbeitskosten – und diese Zahl berücksichtigt nur die Zeit, nicht vermiedene Skonto-Verluste, nicht reduzierte Korrekturzyklen beim Steuerberater und nicht das durch konsistente Feldextraktion eliminierte Prüfungsrisiko.

Häufig gestellte Fragen

Funktioniert das mit XRechnung- und ZUGFeRD-E-Rechnungen?

XRechnung und ZUGFeRD sind strukturierte Formate – sie enthalten bereits maschinenlesbare Daten. Die Herausforderung bei der Extraktion während der Übergangsphase 2025–2028 ist die gemischte Realität: Sie erhalten XRechnung-XML, ZUGFeRD-Hybrid-PDFs, herkömmliche PDFs und gescannte Dokumente – alles im selben Monat. Das Tool verarbeitet herkömmliche PDFs und gescannte Dokumente gleichermaßen gut. Bei strukturierten XML-Dateien können diese oft direkt in Ihr Buchhaltungssystem importiert werden, sobald Ihr Steuerberater das Import-Mapping konfiguriert hat. Der Wert der Extraktion liegt in der Verarbeitung von allem, was nicht strukturiert ist – der Großteil dessen, was heute ankommt.

Kann es deutsche Rechnungsfelder wie Steuernummer und USt-IdNr verarbeiten?

Ja. Da die KI das Dokument semantisch liest und nicht per Vorlagenabgleich, kann sie Felder wie Steuernummer, USt-IdNr, Steuerschlüssel und Belegdatum identifizieren – unabhängig davon, wo sie auf der Seite erscheinen oder wie der Lieferant sie bezeichnet. Sie legen die gewünschten Spaltennamen in der Ausgabe fest, und die KI findet die entsprechenden Werte auf jedem Dokument. Eine ausführliche Anleitung dazu, welche Felder §14 UStG vorschreibt und wie man sie extrahiert, finden Sie im vollständigen Leitfaden zur deutschen Rechnungsextraktion.

Welches Datumsformat verwendet die Ausgabe für den DATEV-Import?

Die KI extrahiert den Datumswert aus dem Dokument und gibt ihn in dem Format aus, das Sie über Ihre Spaltenkonfiguration festlegen. Wenn Ihr Steuerberater DD.MM.YYYY für den DATEV-CSV-Import benötigt, können Sie die Spalte so konfigurieren, dass Daten in diesem Format ausgegeben werden. Gleiches gilt für Dezimaltrennzeichen – die deutsche Buchhaltungskonvention verwendet Kommas für Dezimalstellen (1.234,56), und die Ausgabe kann dieser Konvention entsprechen.

Was ist mit handschriftlichen Rechnungen von kleinen Lieferanten?

Handschriftliche Dokumente sind eine häufige Quelle von Erfassungsaufwand in der deutschen Buchhaltung, insbesondere bei kleineren Handwerkern und Einzelunternehmern. Die KI kann Handschrift lesen – einschließlich Schreibschrift – und dieselben Felder extrahieren, die sie aus einem gedruckten PDF extrahieren würde. Die Genauigkeit ist geringer als bei gedruckten Dokumenten, aber ein schneller manueller Prüfschritt fängt etwaige Fehllesungen ab – das ist dennoch deutlich schneller, als die gesamte Rechnung von Grund auf abzutippen.

Kann ich Rechnungen in verschiedenen Sprachen in derselben Charge verarbeiten?

Ja. Deutsche Unternehmen erhalten häufig Rechnungen von internationalen Lieferanten auf Englisch, Niederländisch, Französisch oder in anderen Sprachen, zusammen mit deutschsprachigen Rechnungen. Die KI verarbeitet alle Sprachen in derselben Charge. Eine niederländische Rechnung mit Reverse-Charge-Umsatzsteuerbehandlung, eine französische Rechnung mit TVA und eine deutsche Rechnung mit 19 % MwSt. können alle in dieselbe Verarbeitungswarteschlange gehen und eine einzige konsolidierte Ausgabe erzeugen.

Wie funktioniert das mit der bestehenden DATEV-Einrichtung unseres Steuerberaters?

Die Ausgabe ist eine Standard-Tabellenkalkulation (Excel oder CSV), die Sie gemäß den Feldanforderungen Ihres Steuerberaters strukturieren. Sie definieren die Spalten — Rechnungsnummer, Belegdatum, Nettobetrag, USt-Betrag, Steuerschlüssel, Gegenkonto — und das Tool füllt jede Zeile mit den extrahierten Werten. Die resultierende Datei ist bereit für den DATEV-Import per CSV-Upload oder Unternehmen Online, genau wie Ihr Steuerberater es erwartet. Es gibt keine Integration zu installieren oder API auf der Seite des Steuerberaters zu konfigurieren.

Das Problem der deutschen Rechnungsdatenerfassung ist nicht, dass die Software fehlt. Es ist, dass die Software nie dafür entwickelt wurde, die Lücke zwischen der Art und Weise, wie Lieferanten Dokumente senden, und der Art und Weise, wie Buchhaltungssysteme sie konsumieren, zu überbrücken. Diese Lücke wird von Menschen gefüllt — kompetenten, gut ausgebildeten Finanzfachleuten, die Arbeit erledigen, die eine Maschine übernehmen sollte. Die Rechnung dessen, was diese Lücke kostet, in Euro und in Stunden und in Prüfungsrisiko, verbessert sich nicht dadurch, dass man auf den Abschluss der E-Rechnungs-Pflicht wartet. Sie verbessert sich in dem Moment, in dem die Extraktion die Transkription übernimmt.