80 deutsche Rechnungen, eine Tabelle
So meistern Sie die Stapelverarbeitung von Rechnungen ohne manuelle Eingabe

Wenn 80 Rechnungen eintreffen – Warum Batch nicht einfach „Einzeln × 80“ ist

Eine Rechnung nach der anderen zu verarbeiten, funktioniert – bis es nicht mehr funktioniert. Für die meisten deutschen Unternehmen liegt die Schwelle zwischen 30 und 50 Eingangsrechnungen pro Monat – der Punkt, an dem aus „Das erledige ich Freitagnachmittag“ ein „Das frisst mein Wochenende“ wird. Bei 80 Rechnungen liegt das Problem nicht in der Geschwindigkeit der Datenerfassung pro Rechnung. Sondern darin, dass Einzelrechnungs-Workflows vier strukturelle Probleme mit sich bringen, die die Batch-Verarbeitung übernimmt und verstärkt:

Format-Vielfalt. Wenn Sie Rechnungen einzeln bearbeiten und Daten manuell in Lexware oder sevDesk eingeben, gleicht Ihr Gehirn Layout-Unterschiede 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, wonach sie suchen soll – nicht nach Vorlagenposition, sondern nach semantischer Bedeutung. Acht Lieferanten, acht Layouts und ein Batch-Output, der alles in einer Tabelle vermischt.

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

Fehlerfortpflanzung. Wenn Sie 80 Rechnungen manuell erfassen, ist jeder Vorgang unabhängig – ein Tippfehler auf Rechnung #44 wirkt sich nicht auf #45 aus. Bei einer Stapelerkennung kann es passieren, dass die KI den Lieferantennamen auf einer Rechnung falsch erkennt, weil sich die Position des Logos verschoben hat – und Sie merken es erst, wenn Sie die gesamte Ausgabe prüfen. Und wenn die Spaltenzuordnung nicht stimmt – etwa die Spalte Leistungsdatum fälschlich das Rechnungsdatum erfasst hat, weil ein Lieferant Daten anders formatiert – müssen Sie jede Zeile kontrollieren, nicht nur die auffällige.

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 eines Rabattpostens zur Originalrechnung zurückgehen müssen, brauchen Sie eine zuverlässige Zuordnung von Dateiname zu Zeile. Stapeltools, die eine CSV ohne Quelldokument-Spalte ausgeben, machen die Prüfung zur Schnitzeljagd durch Ihren Download-Ordner.

Keines dieser Probleme tritt auf, wenn Sie drei Rechnungen verarbeiten. Bei 80 sind alle vier gleichzeitig aktiv – und sie zu lösen, unterscheidet einen echten Stapelverarbeitungs-Workflow von „einmal extrahieren, 80 Mal wiederholen".

Das Lieferantenformat-Problem – Eine Tabelle, acht verschiedene Layouts

Eine Metro-Rechnung und eine Transgourmet-Rechnung haben die gleiche rechtliche Struktur nach §14 UStG, sehen aber völlig unterschiedlich aus. Metro platziert die Rechnungsnummer oben rechts, Transgourmet in einer Tabellenüberschrift. Die örtliche Bäckerei schickt vielleicht eine handschriftliche Rechnung, bei der der Lieferanten-Adressblock gar keine explizite Bezeichnung hat – Sie erkennen ihn daran, dass er oben links steht und mit der Straße beginnt. Das ist das Kernargument gegen vorlagenbasierte Stapelerkennung für deutsche Rechnungen: Jeder neue Lieferant zwingt Sie, eine neue Extraktionsvorlage zu erstellen und zu pflegen.

Um das einzuordnen: Eine mittelgroße deutsche Restaurantgruppe erhält Rechnungen von Metro (Großhandel Lebensmittel), Transgourmet (Getränke), einem lokalen Gemüsehändler, mehreren Getränkelieferanten, einer Reinigungsfirma, einer Wartungsfirma und einer Marketingagentur – plus gelegentliche Einmallieferanten. Das sind acht verschiedene Rechnungsformate, noch bevor man die Varianten innerhalb von Metro selbst betrachtet (Standardrechnung, Lieferschein, Stornorechnung), die dasselbe Markenlayout nutzen, aber Felder umstellen. Vorlagenbasierte Tools benötigen eine separate Konfiguration für jede Variante. Mit semantischer Extraktion definieren Sie die Spaltennamen einmal.

Das ist der Unterschied zwischen dem Spaltennamen-Ansatz und einem Vorlagenansatz im großen 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 Bezeichnung bedeutet, unabhängig davon, wo sie erscheint oder ob die Bezeichnung 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 Umsatzsteuersatz-Split über 80 Rechnungen – Warum eine einzige „Steuer"-Spalte scheitert

Nehmen wir an, die Stapelübernahme hat funktioniert – alle 80 Rechnungen sind mit einheitlichen 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 % Regelsteuer (als Vorsteuer abziehbar nach §15 UStG), 7 % ermäßigte Steuer (ebenfalls abziehbar, aber gesondert zu melden, Zeile 66 der Umsatzsteuervoranmeldung) und §13b-Beträge, bei denen die Steuerschuld auf den Leistungsempfänger übergeht – also kein Vorsteuerabzug und separate Meldepflicht.

Die Umsatzsteuervoranmeldung – Deutschlands monatliche oder vierteljährliche Voranmeldung, eingereicht über ELSTER – verlangt die Meldung der Umsatzsteuerbeträge unter bestimmten Kennzahlen:

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, anstatt einen explizit auf der Seite stehenden Wert zu extrahieren. Beispielsweise weist eine Spalte mit dem Namen USt-Art (Optionen: 19%/7% Regelsteuersatz/§13b Reverse Charge/Kleinunternehmer §19) die KI an, jede Rechnung zu lesen, den anzuwendenden Umsatzsteuersatz zu ermitteln und die korrekte Kategoriebezeichnung auszugeben. So erhalten Sie eine filterbare Spalte – und können anschließend nach USt-Art gruppieren und die USt-Beträge jeder Gruppe für Ihre Vorsteueranmeldung separat summieren. Extraktion und Klassifizierung erfolgen in einem Durchgang, nicht in zwei getrennten Schritten.

Dies ist auch für die Ausgabenseite Ihrer Buchhaltung relevant. Der Nettobetrag einer §13b-Rechnung ist weiterhin eine Betriebsausgabe (Aufwand), auch wenn er keine Vorsteuer enthält – wenn Sie ihn aus Ihrer Kostenübersicht ausschließen, weil „keine Steuer = nicht relevant", melden Sie zu wenig Aufwand. Die Batch-Extraktion muss das gesamte finanzielle Bild erfassen, nicht nur den umsatzsteuerrelevanten Teil.

Von der Batch-Extraktion zum Steuerberater – DATEV-fertig in einem Export

80 Rechnungen in eine Tabelle zu extrahieren, löst das Problem der Dateneingabe. Es löst jedoch nicht automatisch das Übergabeproblem – den Schritt, in dem diese Tabelle in ein Format gebracht werden muss, das Ihr Steuerberater ohne manuelle Neueingabe jeder Zeile in DATEV importieren kann. Deutsche Steuerberater nutzen die DATEV-Plattformen Kanzlei-Rechnungswesen und Unternehmen Online, die Daten über zwei primäre Batch-Mechanismen importieren:

CSV-Import (DATEV-Format) für Kanzlei-Rechnungswesen – eine festspaltige CSV mit spezifischer Feldreihenfolge: Belegdatum, Buchungstext, Gegenkonto, Betrag, Soll/Haben-Kennzeichen sowie 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 nutzen, scheitern stillschweigend.

XML-Import (dxso-Jobs) für DATEV Unternehmen Online – eine Stapelverarbeitung mittels DATEV-eigenem XML-Schema. Der dxso-Mechanismus (DATA XML Send Online) akzeptiert Rechnungsdaten als XML-Dokumente, validiert gegen DATEV-XSD-Schemata. XML ist für Unternehmen Online Pflicht; CSV ist für die Desktop-Anwendung Rechnungswesen – Ihr Steuerberater kann je nach Arbeitsablauf beides oder nur eines nutzen.

Der entscheidende Punkt: Ihre Extraktionsspalten sollten den Importspalten Ihres Zielsystems entsprechen. Wenn Ihr Steuerberater das 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 „SKR03 Konto“ mit dem passenden Code hinzu. Das vermeidet den Zwischenschritt, ein generisches Extraktionsergebnis an die Buchhaltungssoftware anzupassen. Die Extraktion ist die Importdatei.

Für einen Stapel von 80 Rechnungen für DATEV könnte die Spaltenliste so aussehen:

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

Lexware Office und sevDesk verwenden eigene CSV-Vorlagen, das Prinzip ist aber dasselbe: Extraktionsspalten auf das Importschema abstimmen, als CSV exportieren und direkt importieren. Das Versprechen der Stapelverarbeitung – 80 Rechnungen in Minuten – wird nur dann voll ausgeschöpft, wenn die Ausgabe keine weitere Stunde Tabellen-Nachbearbeitung erfordert.

Der Workflow – So verarbeiten Sie 80 Eingangsrechnungen auf einmal

Nachdem die strukturellen Herausforderungen – Formatvielfalt, USt-Aufteilung und DATEV-Kompatibilität – aufgezeigt sind, folgt hier der vollständige Batch-Workflow von einem Ordner mit 80 Rechnungen bis zur steuerberaterfertigen Tabelle:

Speziell für den Prüfschritt: Die risikoreichsten Positionen in einem Batch sind nicht die, die falsch aussehen – sondern die, die richtig aussehen, aber ein Feld enthalten, das aufgrund einer lieferantenspezifischen Formatierungseigenheit systematisch falsch gelesen wurde. Eine Metro-Rechnung, deren Nettobetrag anders ausgerichtet ist als bei den anderen 79 Rechnungen, zeigt keinen Fehler an – die Zelle enthält eine Zahl, und die Zahl sieht plausibel aus. Die Prüfung, die dies erfasst, ist die Top-10-nach-Bruttobetrag-Stichprobe: Öffnen Sie die originale Metro-Rechnung, vergleichen Sie den Bruttobetrag mit dem extrahierten Bruttobetrag. Stimmt er überein, ist die Extraktion vermutlich korrekt. Stimmt er nicht, liegt eine Formatierungseigenheit vor, die untersucht werden muss.

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

Die Batch-Verarbeitung verleitet zu einer verlockenden Abkürzung: 80 Rechnungen in eine saubere Tabelle extrahieren, die Tabelle archivieren und die unordentlichen Originale löschen. Dies ist der mit Abstand 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. Konkret:

• Strukturierte E-Rechnungen (XRechnung XML, ZUGFeRD Hybrid-PDF): Das XML ist der maßgebliche Steuerbeleg. Erfolgte der Rechnungseingang als ZUGFeRD-PDF, muss die gesamte PDF/A-3-Datei (einschließlich des eingebetteten XML) als eine Einheit archiviert werden. Die Novelle vom Juli 2025 bestätigte, dass eine separate, lesbare PDF-Kopie nicht erforderlich ist, es sei denn, sie enthält zusätzliche steuerrelevante Informationen, die nicht im XML enthalten sind – etwa handschriftliche Zahlungsvermerke auf der visuellen Ebene.
• Einfache PDFs und gescannte Dokumente: Die Originaldatei muss gemäß §147 AO für 10 Jahre unverändert aufbewahrt werden. Eine exportierte Excel-Zeile ist eine Arbeitskopie – 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 nachträgliche Änderungen verhindert werden – zeitgestempelt, gehasht oder in einem revisionssicheren System abgelegt.

Das Extraktionsergebnis – Ihre 80-zeilige Excel-Tabelle – ist ein Arbeitsdokument, kein Archivdokument. Es dient Ihrer täglichen Buchhaltung, Vorsteuerabzugsberechnung 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, die Tabelle muss eine Spalte enthalten, die die Quelldatei für jede Zeile identifiziert (Dateiname oder Referenznummer). Ohne diese Rückverfolgungsspalte erzeugt eine Stapel-Extraktion von 80 Rechnungen 80 Datenzeilen, die nicht auf ihre Quellen überprüft werden können – ein GoBD-Compliance-Verstoß, unabhängig von der Genauigkeit der Extraktion.

Der praktische Batch-Archivierungs-Workflow: Originaldateien in einem datierten Ordner ablegen (z. B. /Eingangsrechnungen/2026-05/), einheitlich benennen (2026-05-03_Metro_INV-48291.pdf) und sicherstellen, dass die Extraktionsausgabe den Dateinamen als Spalte enthält. Wenn Ihr Steuerberater DATEV Unternehmen Online nutzt, können die Originalrechnungsdateien über die Belegverwaltung den entsprechenden Buchungssätzen zugeordnet werden – so schließt sich der Nachweiskreis von der Tabelle zurück zum Quelldokument und in den DATEV-Prüfpfad.

Die gestaffelte E-Rechnungspflicht in Deutschland – verpflichtender Empfang seit Januar 2025, verpflichtender Versand für Unternehmen über 800.000 € Umsatz ab 2027, universeller Versand ab 2028 – reduziert schrittweise das Problem der „unstrukturierten Originale“. Da Lieferanten auf ZUGFeRD und XRechnung umsteigen, liefert die eingebettete XML-Ebene strukturierte Daten ohne OCR. In der Übergangsphase verarbeitet Ihre Batch-Pipeline jedoch eine Mischung: 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 erhalten.

Häufig gestellte Fragen

Starten Sie Ihre Stapelverarbeitung für deutsche Rechnungen

Die Stapelverarbeitung deutscher Eingangsrechnungen steht an einem spezifischen Punkt: dem Übergang von „manuelle Erfassung ist nervig, aber machbar“ zu „manuelle Erfassung ist ein struktureller Zeitfresser“. Für die meisten deutschen KMU liegt diese Grenze irgendwo zwischen 40 und 60 Rechnungen pro Monat. Darunter liegt die Reibung im Workflow – DATEV öffnen, Felder tippen, speichern. Darüber ist die Reibung systemisch: Formatvielfalt, Umsatzsteuer-Fragmentierung und Nachweislücken, die kein Einzelrechnungs-Workflow behebt.

Der hier skizzierte Ansatz zur Stapelverarbeitung – spaltennamenbasierte Extraktion über Lieferantenformate hinweg, abgeleitete Spalten zur automatischen 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 Schlagzeile. Doch die größere betriebliche Verschiebung ist diese: Der gesamte Monat an Eingangsrechnungen wird zu einem Vorgang. Nicht 80 schnell ausgeführte Vorgänge – ein Vorgang, einmal erledigt. Der Unterschied ist der Unterschied zwischen „Ich wurde schneller bei der Dateneingabe“ und „Dateneingabe war kein Teil meines Monatsabschlusses mehr.“