Warum die manuelle Rechnungserfassung in Deutschland teurer ist,
als die meisten Finanzteams glauben

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

Ein mittelständisches Produktionsunternehmen in NRW führt seine Buchhaltung über DATEV. Der Steuerberater hat die Firmenlizenz. Das Finanzteam hat die Zugangsdaten. Jeden Monat zahlen sie die Abogebü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 Tabelle zu tippen, damit der Steuerberater sie importieren kann.

Das ist kein Einzelfall. Es ist der Standard für Tausende deutsche Mittelständler, die zwischen 100 und 500 Lieferantenrechnungen pro Monat verarbeiten. Sie haben die Software. Sie haben die Schulung. Trotzdem geben sie Daten manuell ein, als hätte das letzte Jahrzehnt der Buchhaltungstechnologie nie stattgefunden.

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 nach einem strengen Schema. Jedes Feld hat einen Namen, den Ihr Steuerberater erwartet: Belegdatum im Format DD.MM.YYYY, nicht ISO 8601. Ein Steuerschlüssel – ein numerischer Steuercode, der DATEV mitteilt, ob diese Zeile 19 % USt, 7 % USt oder §13b Reverse Charge betrifft. Ein Gegenkonto, das dem korrekten SKR03- oder SKR04-Kontenplan zugeordnet ist, vier bis acht Stellen je nach Kontenstruktur. 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 wahre Engpass ist nicht Ihre Buchhaltungssoftware

Gehen Sie einen typischen Monat mit eingehenden Rechnungen in einem deutschen Unternehmen durch. Dienstagmorgen erhält der Posteingang drei PDFs: eine von Metro, mit einem Spaltenlayout, das Artikelnummern, Mengen, Einzelpreise, Nettobeträge und die Umsatzsteuer-Summen, aufgeteilt in 19 % und 7 % in separaten Zeilen, zeigt. Eine von einem lokalen Handwerker – eine gescannte A4-Seite mit einer handschriftlichen Rechnungsnummer, einem einzelnen Nettobetrag und „zzgl. 19 % MwSt.“ unten notiert. Eine von einem niederländischen Lieferanten, auf Englisch formatiert, ohne Steuernummer, ohne separate Umsatzsteuerzeile und mit einem Verweis auf „reverse charge“ 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, aber in der Übersetzung in DATEVs einzelnen Steuerschlüssel pro Buchungszeile erhalten bleiben muss. Die Handwerker-Rechnung erfordert das Entziffern der Handschrift und die Bestätigung, dass „zzgl. 19 %“ tatsächlich den Nettobetrag zuzüglich Umsatzsteuer bedeutet, nicht die Beschreibung einer separaten Gebühr. Die niederländische Rechnung erfordert das Erkennen eines innergemeinschaftlichen Reverse-Charge-Szenarios und die Buchung nach §13b UStG mit dem richtigen Steuerschlüssel, wobei auch zu beachten 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 unvermeidlich vielfältig, und die deutsche Buchhaltungscompliance ist unvermeidlich präzise. Die Spannung zwischen diesen beiden Tatsachen hält Finanzteams am Tippen.

Der Doppelstandard SKR03 und SKR04 verschärft dies. Dieselbe Lieferantenrechnung für Büromiete wird je nach verwendetem Kontenrahmen unterschiedlichen Aufwandskonten zugeordnet – SKR03 leitet sie möglicherweise an eine prozessorientierte Kontenfamilie weiter, SKR04 an eine auf den Jahresabschluss ausgerichtete. Die Person, die die Dateneingabe vornimmt, 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 Feldpositionen. Die kognitive Belastung ist kumulativ und für jeden, der die Arbeit nicht selbst erledigt, unsichtbar.

Was ein einziger falscher Tastenanschlag tatsächlich kostet

Die offensichtlichen Kosten sind Zeit. Bei durchschnittlichen deutschen Arbeitskosten von 45,00 € pro Stunde über alle Branchen hinweg im Jahr 2025 (Destatis) und einer Bearbeitungszeit von etwa 15 Minuten pro Rechnung für das Auffinden von Feldern, das Eintippen, die Überprüfung von Steuercodes und die Bestätigung von Kontenzuordnungen verbraucht ein Unternehmen mit 200 Rechnungen pro Monat 50 Stunden – das sind etwa 2.250 € reine Dateneingabekosten pro Monat. Das sind die sichtbaren Kosten. Die unsichtbaren sind höher.

Die manuelle Dateneingabe weist eine Fehlerquote von 3 % bis 5 % auf, abhängig von der Dokumentenkomplexität und der Ermüdung des Bearbeiters. 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 den Abgleich versucht. Ein falscher Steuerschlüssel auf einer Reverse-Charge-Rechnung führt nicht nur zu einem fehlgeschlagenen Import – er zieht eine fehlerhafte Umsatzsteuermeldung nach sich, die erst Monate später bei einer Betriebsprüfung auffällt. Ein Datum im Format MM/DD/YYYY statt DD.MM.YYYY führt dazu, dass DATEV den gesamten Batch ablehnt, nicht nur den einen Datensatz. Der Steuerberater schickt ihn zurück, und der Monatsabschluss verzögert sich um Tage.

Es gibt auch schwerer quantifizierbare Kosten. Eine Lieferantenrechnung mit 2 % Skonto, die am ersten Tag eingeht, aber aufgrund eines Rückstaus erst am siebten Tag erfasst wird, bedeutet bares Geld, das liegen bleibt. 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 nach §15 UStG versagt. Die Person, die diese Rechnung vor sechs Monaten erfasst hat, arbeitet vielleicht nicht mehr im Unternehmen, aber der Fehler liegt im Archiv – das nach 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 Erfassung. Sie spüren sie, wenn der Monatsabschluss sich verzögert, wenn der Steuerberater Korrekturen anfordert oder wenn eine Betriebsprü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 strukturierte E-Rechnungen im XRechnung- oder ZUGFeRD-2.0.1+-Format empfangen können. 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, als ob das Problem der manuellen Erfassung an der Quelle gelöst wird: Wenn Rechnungen als strukturiertes XML eingehen, muss niemand mehr etwas abtippen.

Die betriebliche Realität während der Übergangsphase 2025–2028 ist das Gegenteil von reibungslos. In einer einzigen Woche kann ein Finanzteam eine XRechnung-XML-Datei von einem großen Lieferanten erhalten (maschinenlesbar, aber zur Ansicht ist ein spezielles Programm nötig – 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 umstellen muss, und eine abfotografierte Papierrechnung von einem Einzelunternehmer, der weiterhin physische Post verschickt. Vier Formate, vier Eingangskanäle, ein Ziel: die DATEV-CSV, die Ihr Steuerberater erwartet.

XRechnung und ZUGFeRD wurden entwickelt, um Rechnungen auf der Empfängerseite maschinell verarbeitbar zu machen. Aber „maschinenverarbeitbar“ funktioniert nur, wenn das empfangende System die XML-Elemente parsen, sie den richtigen DATEV-Feldern zuordnen und die Steuerschlüssel mit dem Kontenrahmen abgleichen kann. Für Unternehmen, deren Arbeitsablauf darin besteht, dass ein Teammitglied ein PDF öffnet und die Daten in eine Tabelle eintippt, ändert das Eintreffen von XML-Dateien nichts – es kann sogar Reibung erzeugen, weil das XML ohne ein spezielles Programm nicht lesbar ist und jetzt jemand entscheiden muss, ob er es programmatisch parst oder das Programm öffnet, die Felder abliest und sie trotzdem abtippt.

Die Übergangsfrist läuft bis Ende 2027. Für das Finanzteam vor Ort bedeutet das drei weitere Jahre mit gemischten Formaten – und die E-Rechnungspflicht, weit davon entfernt, das Problem zu lösen, fügt dem Stapel aus PDFs, Scans, Fotos und handschriftlichen Dokumenten ein weiteres Format hinzu. Die Pflicht wurde für das Zielsystem konzipiert. Sie hat die menschliche Brücke dazwischen nicht berücksichtigt.

Wenn die 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 eine bessere Buchhaltungssoftware. Es ist eine bessere Extraktion. Insbesondere eine Extraktion, die nicht im Voraus wissen muss, welches Layout der nächste Lieferant verwendet.

Traditionelle OCR-Tools gehen dieses Problem mit Vorlagen an: Sie definieren Bereiche auf einer Seite, in denen bestimmte Felder erscheinen, und die Software liest diese Bereiche. Das funktioniert für einen Lieferanten. Es scheitert, sobald 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 löst – besteht darin, die KI das Dokument so lesen zu lassen, wie ein Mensch es tut: indem sie versteht, was ein Feld bedeutet, nicht wo es steht. Dies 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 findet 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 eines lokalen Handwerkers und eine niederländische Reverse-Charge-PDF durchlaufen alle denselben Prozess. Das Ergebnis 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 wechselt vom Transkribieren zum Überprüfen – eine Aufgabe, die pro Rechnung Sekunden statt Minuten dauert.

Die von Ihnen festgelegten 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 die gleiche Spaltenliste jeden Monat wiederverwenden. Keine Neuformatierung. Keine manuelle Übertragung. Kein Rätseln, 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, definieren Sie Ihre Extraktionsspalten einmal und erhalten Sie eine einzige konsolidierte Tabelle für den Steuerberater. Die grundlegende Mechanik, Rechnungsdaten in DATEV zu überführen – einschließlich der relevanten Felder gemäß §14 UStG und der Auswirkungen der SKR03/SKR04-Kontenrahmen auf die Kontenzuordnung – wurde für deutsche Finanzteams, die diesen Workflow von Grund auf aufsetzen, bereits ausführlich behandelt.

Was sich ändert, wenn Sie aufhören abzuschreiben

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

Der Wandel vollzieht sich, wenn die Extraktion zur Prüfaufgabe wird, statt zur Abschreibaufgabe. Die KI liest eine Metro-Rechnung, identifiziert Nettobetrag, Umsatzsteueraufteilung, Lieferantennamen und Rechnungsdatum – in 5 bis 10 Sekunden. Das Teammitglied prüft die extrahierten Felder auf Übereinstimmung mit dem Quelldokument. Stimmen sie, wird die Zeile freigegeben. Stimmen sie 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 Bearbeitungszeit verarbeitet, verbringt 50 Stunden mit der Dateneingabe. Bei 30 Sekunden pro Rechnung – 5 bis 10 Sekunden für die Extraktion, 20 Sekunden für die Prüfung – dauert die gleiche Menge unter 2 Stunden. Die verbleibenden 48 Stunden pro Monat verschieben sich von der Transkription zur Analyse. Das ist der Unterschied zwischen einer Finanzabteilung, die über den letzten Monat berichtet, und einer, die den nächsten Monat gestaltet.

Bei deutschen Arbeitskosten von 45 € pro Stunde ist die Rechnung einfach: 2.250 € für manuelle Eingabe pro Monat werden zu etwa 90 € für die Prüfung. Über ein Jahr sind das 25.920 € eingesparte 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, traditionelle PDFs und gescannte Dokumente im selben Monat. Das Tool verarbeitet traditionelle PDFs und gescannte Dokumente gleichermaßen gut. Strukturierte XML-Dateien können 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 eingeht.

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

Ja. Da die KI das Dokument semantisch und nicht per Vorlagenabgleich liest, erkennt sie Felder wie Steuernummer, USt-IdNr, Steuerschlüssel und Belegdatum unabhängig von deren Position auf der Seite oder der Bezeichnung durch den Lieferanten. Sie legen die gewünschten Spaltennamen im Export fest, und die KI findet die entsprechenden Werte in jedem Dokument. Eine detaillierte Anleitung zu den Pflichtfeldern nach §14 UStG und deren Extraktion finden Sie im vollständigen Leitfaden zur deutschen Rechnungsextraktion.

Welches Datumsformat wird für den DATEV-Import verwendet?

Die KI extrahiert das Datum aus dem Dokument und gibt es in dem von Ihnen über die Spaltenkonfiguration festgelegten Format aus. Wenn Ihr Steuerberater für den DATEV-CSV-Import das Format DD.MM.YYYY benötigt, können Sie die Spalte entsprechend konfigurieren. Gleiches gilt für Dezimaltrennzeichen – die deutsche Buchhaltung verwendet Kommas (1.234,56), und die Ausgabe kann dieser Konvention folgen.

Was ist mit handschriftlichen Rechnungen von Kleinlieferanten?

Handschriftliche Belege sind eine häufige Fehlerquelle in der deutschen Buchhaltung, insbesondere bei kleineren Handwerkern und Einzelunternehmern. Die KI kann Handschrift – auch Schreibschrift – lesen und dieselben Felder extrahieren wie aus einem gedruckten PDF. Die Genauigkeit ist geringer als bei gedruckten Dokumenten, aber eine kurze manuelle Prüfung fängt Fehler ab – das ist immer noch deutlich schneller, als die gesamte Rechnung manuell zu erfassen.

Kann ich Rechnungen in verschiedenen Sprachen im selben Batch verarbeiten?

Ja. Deutsche Unternehmen erhalten häufig Rechnungen von internationalen Lieferanten auf Englisch, Niederländisch, Französisch oder anderen Sprachen – zusätzlich zu deutschsprachigen Rechnungen. Die KI verarbeitet alle Sprachen im selben Durchlauf. Eine niederländische Rechnung mit Reverse-Charge-Umsatzsteuer, eine französische Rechnung mit TVA und eine deutsche Rechnung mit 19 % MwSt. können alle in dieselbe Verarbeitungswarteschlange gegeben werden und eine einzige konsolidierte Ausgabe erzeugen.

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

Die Ausgabe ist eine Standard-Tabelle (Excel oder CSV), die Sie nach 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 muss keine Integration installiert oder API auf Seiten des Steuerberaters konfiguriert werden.

Das Problem der deutschen Rechnungserfassung liegt nicht darin, dass die Software fehlt. Sondern darin, dass die Software nie dafür entwickelt wurde, die Lücke zwischen der Art, wie Lieferanten Dokumente senden, und der Art, wie Buchhaltungssysteme sie verarbeiten, zu schließen. Diese Lücke wird von Menschen gefüllt – kompetenten, gut ausgebildeten Finanzfachleuten, die Arbeit erledigen, die eine Maschine übernehmen sollte. Die Kalkulation dessen, was diese Lücke kostet – in Euro, in Stunden und in Prüfungsrisiken – verbessert sich nicht, indem man auf die vollständige Einführung der E-Rechnungspflicht wartet. Sie verbessert sich in dem Moment, in dem die Extraktion die Transkription übernimmt.