80 deutsche Rechnungen, eine Tabelle
So gelingt die Batch-Rechnungsverarbeitung ohne manuelle Eingabe

Wenn 80 Rechnungen eintreffen – warum Batch nicht einfach „Einzeln × 80" ist

Die Einzelverarbeitung von Rechnungen funktioniert, bis sie es nicht mehr tut. Für die meisten deutschen Unternehmen liegt der Wendepunkt irgendwo zwischen 30 und 50 Eingangsrechnungen pro Monat – die Schwelle, an der sich die Kluft zwischen „Das schaffe ich am Freitagnachmittag" und „Das frisst mein Wochenende" auftut. Bei 80 Rechnungen ist nicht die Datenerfassungsgeschwindigkeit pro Rechnung das Problem. Es ist vielmehr so, dass Einzelrechnungs-Workflows vier strukturelle Probleme mit sich bringen, die die Batch-Verarbeitung erbt und verstärkt:

Formatdrift. Wenn Sie Rechnungen einzeln verarbeiten und Daten manuell in Lexware oder sevDesk eingeben, gleicht Ihr Gehirn Unterschiede im Layout aus – Sie sehen „Rechnungs-Nr." auf einer Metro-Rechnung und „Rechnungsnummer" auf einer Transgourmet-Rechnung und wissen, dass es dasselbe Feld ist. Eine automatisierte Batch-Extraktion hat diese Intuition nicht, es sei denn, Sie haben ihr beigebracht, worauf sie achten soll – nicht nach Vorlagenposition, sondern nach semantischer Bedeutung. Acht Lieferanten, acht Layouts und eine Batch-Ausgabe, die alles in einer Tabelle vermischt.

Umsatzsteuer-Fragmentierung. Deutsche Eingangsrechnungen verwenden nicht einheitlich einen einzigen Umsatzsteuersatz. In einem Batch von 80 Rechnungen von Gastronomie-Lieferanten können bis zu vier Umsatzsteuer-Behandlungen auftreten: Standard 19 % (Ausrüstung, Reinigung), ermäßigt 7 % (Lebensmittel, Bücher), §13b Reverse-Charge (Subunternehmer-Bauarbeiten) und §19 Kleinunternehmer (keine Umsatzsteuer). Eine einzelne Spalte „Steuer", die eine Zahl aus jeder Rechnung erfasst, ist nutzlos – denn diese Zahl bedeutet in jeder Zeile etwas anderes, und Ihre Vorsteuerabzugs-Berechnung benötigt eine Trennung nach Typ. Die §14 UStG-Pflichtfelder auf jeder Rechnung bestimmen, was extrahiert werden muss – aber die Batch-Verarbeitung fügt die Ebene hinzu, diese Extraktion über alle 80 Zeilen hinweg semantisch konsistent zu halten.

Fehlerfortpflanzung. Wenn Sie 80 Rechnungen manuell eingeben, ist jeder Vorgang unabhängig – ein Tippfehler bei Rechnung Nr. 44 führt nicht zu einem Tippfehler bei Nr. 45. Bei einer Batch-Extraktion wissen Sie nicht, ob die KI den Lieferantennamen bei einer Rechnung falsch identifiziert hat, weil sich die Logo-Platzierung verschoben hat – Sie merken es erst bei der Prüfung der gesamten Ausgabe. Und wenn die Spaltenzuordnung nicht stimmt – sagen wir, die Leistungsdatum-Spalte hat bei einem Lieferanten, der Daten anders formatiert, das Rechnungsdatum erfasst – müssen Sie jede Zeile prüfen, nicht nur die, die Ihnen aufgefallen ist.

Nachvollziehbarkeitslücken. Eine zusammengeführte Tabelle mit 80 Zeilen muss Ihnen sagen, welche Zeile aus welcher Datei stammt. Wenn Sie zur Überprüfung einer USt-IdNr oder einer Rabattzeile zur Originalrechnung zurückgehen müssen, benötigen Sie eine zuverlässige Datei-zu-Zeile-Zuordnung. Batch-Tools, die eine CSV ohne Quelldokument-Spalte ausgeben, machen die Prüfung zu einer Schnitzeljagd durch Ihren Downloads-Ordner.

Keines dieser Probleme existiert, wenn Sie drei Rechnungen verarbeiten. Bei 80 sind alle vier gleichzeitig aktiv – und sie zu lösen ist das, was einen Batch-Verarbeitungs-Workflow von „Einzelextraktion, 80-mal wiederholt" unterscheidet.

Das Lieferantenformat-Problem – eine Tabelle, acht verschiedene Layouts

Eine Metro-Rechnung und eine Transgourmet-Rechnung haben dieselbe rechtliche Struktur gemäß §14 UStG, sehen aber völlig unterschiedlich aus. Metro platziert die Rechnungsnummer oben rechts, Transgourmet in einer Tabellenkopfzeile. Die lokale Bäckerei sendet möglicherweise eine handschriftliche Rechnung, bei der der Lieferantenadressblock überhaupt keine explizite Beschriftung hat – Sie erkennen ihn daran, dass er oben links steht und mit dem Straßennamen beginnt. Dies ist das Kernargument gegen die templatebasierte Batch-Extraktion für deutsche Rechnungen: Jeder neue Lieferant zwingt Sie dazu, eine neue Extraktionsvorlage zu erstellen und zu pflegen.

Um das einzuordnen: Eine mittelgroße deutsche Restaurantgruppe könnte Rechnungen von Metro (Lebensmittelgroßhandel), Transgourmet (Getränke), einem lokalen Gemüsehändler, mehreren Getränkelieferanten, einem Reinigungsdienst, einer Wartungsfirma und einer Marketingagentur erhalten – plus gelegentliche Einmallieferanten. Das sind acht verschiedene Rechnungsformate, bevor man die Variationen innerhalb von Metro selbst berücksichtigt (Standardrechnung, Lieferschein, Stornorechnung), die dasselbe Markenlayout verwenden, aber Felder umstellen. Templatebasierte Tools erfordern eine separate Konfiguration für jede Variante. Mit semantischer Extraktion definieren Sie die Spaltennamen nur einmal.

Dies ist der Unterschied zwischen dem Spaltennamen-Ansatz und einem Template-Ansatz in großem Maßstab. Benutzerdefinierte Spaltenextraktion – der Mechanismus, den ImageToTable.ai verwendet – funktioniert, indem er die Feldbedeutung versteht, nicht durch Koordinaten. Sie geben Ihre gewünschten Spaltennamen ein: „Rechnungsnummer", „Lieferant", „Rechnungsdatum", „Leistungsdatum", „Nettobetrag", „USt-Satz", „USt-Betrag", „Bruttobetrag", „USt-IdNr" – und die KI findet jeden Wert auf jeder Rechnung im Batch, indem sie versteht, was die Beschriftung bedeutet, unabhängig davon, wo sie erscheint oder ob der Beschriftungstext variiert („Rechnungs-Nr." vs. „Rechnungsnummer" vs. „RNr."). Eine Spaltendefinition deckt alle acht Lieferantenlayouts in einem Batch-Upload ab.

Die praktische Auswirkung: Sie laden den gesamten Ordner des Monats mit Eingangsrechnungen hoch – 80 PDFs, JPGs und gescannte Dokumente von allen Lieferanten – und erhalten eine zusammengeführte Tabelle, in der jede Zeile eine Rechnung mit denselben Spalten darstellt, unabhängig vom Format. Keine Vorlage pro Lieferant, keine Format-Vorsortierung, kein „Die Rechnungen dieses Lieferanten müssen separat hochgeladen werden, weil das Layout anders ist."

Der USt-Satz-Split über 80 Rechnungen – warum eine einzige „Steuer“-Spalte scheitert

Angenommen, die Batch-Extraktion hat funktioniert – alle 80 Rechnungen sind mit konsistenten Spalten in Ihrer Tabelle. Das nächste Problem: Die Spalte USt-Satz enthält vier verschiedene Werte – 19 %, 7 %, 0 % (oder leer) und „§13b“ – und jeder erfordert eine andere buchhalterische Behandlung. Wenn Sie einfach die Spalte USt-Betrag summieren, addieren Sie 19 % reguläre USt, die als Vorsteuerabzug (gemäß §15 UStG) geltend gemacht werden kann, 7 % ermäßigte USt, die ebenfalls abzugsfähig ist, aber separat gemeldet werden muss (Kennzahl 66 der Umsatzsteuervoranmeldung), und §13b-Beträge, bei denen die Steuerschuld auf den Empfänger übergeht – das bedeutet kein Vorsteuerabzug und eine separate Meldepflicht.

Die Umsatzsteuervoranmeldung – Deutschlands monatliche oder vierteljährliche USt-Voranmeldung, eingereicht über ELSTER – verlangt, dass USt-Beträge unter bestimmten Steuerkennzahlen (Kennzahlen) gemeldet werden:

Ein praktischer Ansatz für die Batch-Extraktion: Definieren Sie eine abgeleitete Spalte – eine Spalte, in der die KI die Rechnung anhand ihres Inhalts klassifiziert, statt einen Wert zu extrahieren, der explizit auf der Seite steht. Beispielsweise weist eine Spalte mit dem Namen USt-Art (Optionen: Standard 19 %/Ermäßigt 7 %/§13b Reverse Charge/Kleinunternehmer §19) die KI an, jede Rechnung zu lesen, zu bestimmen, welches Umsatzsteuerregime gilt, und die korrekte Kategoriebezeichnung auszugeben. So erhalten Sie eine filterbare Spalte – und von dort aus gruppieren Sie nach USt-Art und summieren den USt-Betrag jeder Gruppe separat für Ihre Vorsteuerabzug-Meldung. Extraktion und Klassifizierung erfolgen in einem Durchgang, nicht in zwei getrennten Vorgängen.

Das ist auch für die Ausgabenseite Ihrer Buchhaltung wichtig. Der Nettobetrag auf einer §13b-Rechnung ist weiterhin eine Betriebsausgabe (Aufwand), auch wenn er keine Vorsteuer enthält – wenn Sie ihn mit der Begründung „keine Steuer = nicht relevant" aus Ihrer Kostenübersicht ausschließen, unterschlagen Sie Ausgaben. Die Batch-Extraktion muss das vollständige finanzielle Bild erfassen, nicht nur den umsatzsteuerrelevanten Ausschnitt.

Von der Batch-Extraktion zu Ihrem Steuerberater – DATEV-bereit in einem Export

80 Rechnungen in eine Tabellenkalkulation zu extrahieren löst das Datenerfassungsproblem. Es löst jedoch nicht automatisch das Übergabeproblem – den Schritt, in dem diese Tabellenkalkulation zu etwas werden muss, das Ihr Steuerberater ohne erneutes Eintippen jeder Zeile in DATEV importieren kann. Deutsche Steuerberater nutzen DATEVs Kanzlei-Rechnungswesen und Unternehmen Online-Plattformen, die Daten über zwei primäre Batch-Mechanismen importieren:

CSV-Import (DATEV-Format) für Kanzlei-Rechnungswesen – eine CSV mit festen Spalten und spezifischer Feldreihenfolge: Belegdatum, Buchungstext, Gegenkonto, Betrag, Soll/Haben-Kennzeichen und optional Buchungsschlüssel und Kontierung (Kontonummer nach SKR03 oder SKR04). Die Datei muss Semikolons als Trennzeichen, ISO-8859-1-Kodierung und das Datumsformat TT.MM.JJJJ verwenden – CSV-Exporte aus englischsprachigen Tools, die standardmäßig Kommas und MM/TT/JJJJ verwenden, schlagen still fehl.

XML-Import (dxso-Jobs) für DATEV Unternehmen Online – eine Batch-Job-Übermittlung mit DATEVs proprietärem XML-Schema. Der dxso-Mechanismus (DATA XML Send Online) akzeptiert Rechnungsdaten als XML-Dokumente, validiert gegen DATEVs XSD-Schemata. XML ist für Unternehmen Online verpflichtend; CSV ist für die Desktop-Anwendung Rechnungswesen – und Ihr Steuerberater kann je nach Arbeitsablauf eines oder beide verwenden.

Die zentrale Erkenntnis: Ihre Extraktionsspalten sollten die Importspalten widerspiegeln, die Ihr Zielsystem erwartet. Wenn Ihr Steuerberater Belegdatum im Format TT.MM.JJJJ benötigt, definieren Sie Ihre Extraktionsspalte als „Belegdatum" – nicht als „Invoice Date". Wenn er Ausgaben auf Konto 4930 (SKR03: Sonstige Kosten) bucht, fügen Sie eine Spalte namens „SKR03 Konto" mit dem entsprechenden Code hinzu. Das eliminiert den Zwischenschritt der Neuformatierung einer generischen Extraktionsausgabe an die Schemata der Buchhaltungssoftware. Die Extraktion ist die Importdatei.

Für einen Batch von 80 Rechnungen für DATEV könnte der Spaltensatz so aussehen:

• Belegdatum – TT.MM.JJJJ
• Buchungstext – Kombination aus Lieferant + Rechnungsnummer
• Gegenkonto – die Kreditorennummer des Lieferanten (70000er-Serie in SKR04)
• Betrag – Bruttobetrag
• Soll/Haben – „S" für Soll (Aufwand), „H" für Haben
• SKR03 Konto – das Aufwandskonto (z. B. 4930 für sonstige Kosten, 3400 für Waren)
• USt-Satz – 19 oder 7 oder 0
• Vorsteuerbetrag – der abzugsfähige Vorsteuerbetrag

Lexware Office und sevDesk verwenden eigene CSV-Vorlagen, aber das Prinzip ist dasselbe: Extraktionsspalten passend zum Importschema definieren, als CSV exportieren und direkt importieren. Das Versprechen der Batch-Verarbeitung — 80 Rechnungen in Minuten — wird nur dann vollständig erreicht, wenn die Ausgabe nicht noch eine weitere Stunde Tabellen-Nachbearbeitung erfordert.

Der Workflow — So verarbeiten Sie 80 Eingangsrechnungen auf einmal

Nachdem die strukturellen Herausforderungen erfasst sind — Formatvielfalt, Umsatzsteuer-Fragmentierung und DATEV-Kompatibilität — folgt hier der vollständige Batch-Workflow von einem Ordner mit 80 Rechnungen bis zu einer Steuerberater-fertigen Tabelle:

Speziell für den Prüfschritt: Die größten Risiken in einem Stapel sind nicht die Positionen, die falsch aussehen – sondern die, die richtig aussehen, aber ein Feld enthalten, das aufgrund einer lieferantenspezifischen Formatierungseigenheit systematisch falsch gelesen wurde. Eine Metro-Rechnung, die ihren Nettobetrag anders ausrichtet als die anderen 79 Rechnungen, zeigt keinen Fehler – die Zelle enthält eine Zahl, und die Zahl sieht plausibel aus. Die Prüfung, die dies aufdeckt, ist die Stichprobenprüfung der Top-10-nach-Bruttobetrag: Öffnen Sie die Original-Metro-Rechnung und vergleichen Sie den Bruttobetrag mit dem extrahierten Bruttobetrag. Stimmt er überein, ist die Extraktion wahrscheinlich korrekt. Stimmt er nicht überein, liegt eine Formatierungseigenheit vor, die untersucht werden muss.

GoBD-konforme Batch-Archivierung – Nicht die Excel archivieren, sondern die Originale

Die Batch-Verarbeitung schafft eine verlockende Abkürzung: 80 Rechnungen in eine übersichtliche Tabelle extrahieren, die Tabelle archivieren und die unübersichtlichen Originale löschen. Dies ist der häufigste GoBD-Konformitätsfehler bei der automatisierten Rechnungsverarbeitung – und er scheitert auf mehreren Ebenen an den Prüfungsanforderungen.

Die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern), überarbeitet im Juli 2025 zur Angleichung an die deutsche E-Rechnungspflicht, verlangt, dass steuerrelevante Dokumente in ihrem ursprünglichen Empfangsformat aufbewahrt werden, nicht in einer abgeleiteten oder transformierten Version. Im Einzelnen:

• Strukturierte E-Rechnungen (XRechnung-XML, ZUGFeRD-Hybrid-PDF): Das XML ist der maßgebliche Steuerbeleg. Wenn die Rechnung als ZUGFeRD-PDF eingegangen ist, muss die gesamte PDF/A-3-Datei (einschließlich des eingebetteten XML) als eine Einheit archiviert werden. Die Änderung vom Juli 2025 bestätigte, dass eine separate, für Menschen lesbare PDF-Kopie nicht erforderlich ist, es sei denn, sie enthält zusätzliche steuerrelevante Informationen, die nicht im XML enthalten sind – wie handschriftliche Zahlungsvermerke auf der visuellen Ebene.
• Einfache PDFs und gescannte Dokumente: Die Originaldatei muss gemäß §147 AO 10 Jahre lang unverändert aufbewahrt werden. Eine extrahierte Excel-Zeile ist eine Arbeitskopie – sie ist kein Archiversatz.
• Fotografierte Papierrechnungen: Das digitale Foto wird zum Beleg. Der GoBD-Grundsatz der Unveränderbarkeit bedeutet, dass die Fotodatei so gespeichert werden muss, dass eine spätere Änderung verhindert wird – mit Zeitstempel, Hash oder in einem revisionssicheren System.

Das Extraktionsergebnis – Ihre 80-zeilige Excel-Tabelle – ist ein operatives Dokument, kein Archivdokument. Es dient Ihrer täglichen Buchhaltung, der Vorsteuerabzugs-Berechnung und dem DATEV-Import. Bei einer Betriebsprüfung wird der Prüfer die Originalrechnungsdateien anfordern, nicht Ihre Extraktionstabelle. Die Extraktion muss lediglich die Rückverfolgbarkeit zu diesen Originalen ermöglichen – das bedeutet, dass die Tabelle eine Spalte enthalten muss, die die Quelldatei für jede Zeile identifiziert (Dateiname oder Referenznummer). Ohne diese Rückverfolgbarkeitsspalte erzeugt eine Batch-Extraktion von 80 Rechnungen 80 Datenzeilen, die nicht gegen ihre Quellen verifiziert werden können – ein GoBD-Konformitätsfehler, unabhängig davon, wie genau die Extraktion war.

Der praktische Batch-Archivierungs-Workflow: Bewahren Sie die Originaldateien in einem datierten Ordner auf (z. B. /Eingangsrechnungen/2026-05/), benennen Sie sie konsistent (2026-05-03_Metro_INV-48291.pdf) und stellen Sie sicher, dass Ihr Extraktionsergebnis den Dateinamen als Spalte beibehält. Wenn Ihr Steuerberater DATEV Unternehmen Online verwendet, können die Originalrechnungsdateien über die Belegverwaltung an die entsprechenden Buchungsbelege angehängt werden – das schließt die Rückverfolgbarkeitsschleife von der Tabelle zurück zum Quelldokument und in den DATEV-Prüfpfad.

Die gestaffelte E-Rechnungspflicht in Deutschland – verpflichtender Empfang seit Januar 2025, verpflichtendes Senden für Unternehmen mit mehr als 800.000 € Umsatz ab 2027, universelles Senden ab 2028 – reduziert das Problem der „unübersichtlichen Originale“ schrittweise. Da Lieferanten auf ZUGFeRD und XRechnung umsteigen, liefert die eingebettete XML-Ebene strukturierte Daten ohne OCR. Aber während der Übergangsphase wird Ihre Batch-Pipeline eine Mischung verarbeiten: einige ZUGFeRD-PDFs, einige einfache PDFs, einige gescannte Rechnungen von Lieferanten, die erst 2028 umstellen. Der Extraktions-Workflow muss alle drei Formate verarbeiten, und der Archivierungs-Workflow muss alle drei in ihren jeweiligen Originalformaten aufbewahren.

Häufig gestellte Fragen

So bringen Sie Ihre deutsche Rechnungs-Stapelverarbeitung zum Laufen

Die Stapelverarbeitung deutscher Eingangsrechnungen liegt an einer besonderen Schnittstelle: Es ist der Punkt, an dem die Anzahl der Rechnungen von „manuelle Erfassung ist nervig, aber machbar" zu „manuelle Erfassung ist ein struktureller Zeitfresser" übergeht. Für die meisten deutschen KMU liegt diese Grenze irgendwo zwischen 40 und 60 Rechnungen pro Monat. Darunter entsteht die Reibung durch den Workflow – DATEV öffnen, Felder eingeben, speichern. Darüber ist die Reibung systemisch: Formatiervielfalt, Umsatzsteuer-Fragmentierung und Nachvollziehbarkeitslücken, die jeder Einzelrechnungs-Workflow übersteht.

Der hier beschriebene Stapelverarbeitungsansatz – spaltennamenbasierte Extraktion, die über Lieferantenformate hinweg funktioniert, abgeleitete Spalten für die automatische Umsatzsteuer-Klassifizierung und DATEV-konforme Exportschemata – adressiert die systemischen Probleme, nicht nur die Geschwindigkeit pro Rechnung. Der 18-fache Effizienzgewinn (3 Minuten pro Rechnung manuell vs. 5-10 Sekunden mit Extraktion) ist die Schlagzeilenzahl. Aber die größere betriebliche Veränderung ist diese: Die gesamten Eingangsrechnungen des Monats werden zu einem einzigen Vorgang. Nicht 80 schnelle Vorgänge – ein Vorgang, einmal durchgeführt. Der Unterschied ist der Unterschied zwischen „Ich bin schneller bei der Dateneingabe geworden" und „Dateneingabe ist kein Teil meines Monatsabschlusses mehr."