30 Lieferantenrechnungen, eine
zahlungsbereite AP-Tabelle

Was die Einzeldatei-Extraktion ungenutzt lässt

Der Hub-Artikel zum Extrahieren japanischer Rechnungsdaten in Excel behandelt die vollständige Feldstruktur – wie Sie Banküberweisungsdetails, Zahlungsbedingungen, Verbrauchssteuer und Quellensteuer aus einer einzelnen 請求書 erfassen. Aber ein Einzeldatei-Workflow löst das Problem der Extraktion pro Dokument. Er löst nicht das Problem der Batch-Zahlung, das ein anderes Problem mit einer anderen Reihe von Ausgaben ist.

Der AP-Sachbearbeiter, der dreißig Rechnungen von Hand verarbeitet, hat eine Abfolge: die Rechnungs-PDF öffnen, den Banküberweisungsblock finden, die vier Bankfelder in den Internetbanking-Bildschirm eingeben, die Zahlungsbedingungen parsen, um das Fälligkeitsdatum zu bestimmen, auf Quellensteuer prüfen, die Verbrauchssteueraufschlüsselung verifizieren und die Registrierungsnummer für qualifizierte Rechnungen gegen den Lieferantenstamm bestätigen. Diese Abfolge wiederholt sich dreißig Mal. Der Akt der Extraktion – das Lesen der Daten von der Rechnung – und der Akt der Zahlungsvorbereitung – das Zusammenstellen dieser Daten in ein banküberweisungsfertiges Format – sind zu einer einzigen, sich wiederholenden Aufgabe verschmolzen. Ein Einzeldatei-Extraktionstool trennt sie: Die Daten werden in eine Tabellenzeile extrahiert. Aber die Zahlungsvorbereitung – das Zusammenstellen dieser dreißig Zeilen in eine Zahlungsbatch-Datei, einen Zahlungskalender, einen Quellensteuer-Hinterlegungsplan und eine steuererklärungsfertige Verbrauchssteuerzusammenfassung – erfordert weiterhin manuelle Zusammenstellung. Die Extraktion hat das Leseproblem gelöst. Sie hat das Zusammenstellungsproblem nicht gelöst.

Die Batch-Verarbeitung löst beides gleichzeitig, weil sie die dreißig Rechnungen als eine Arbeitseinheit behandelt – die Daten aus allen dreißig Dokumenten in einem Durchlauf extrahiert und Ausgaben erzeugt, die für nachgelagerte Systeme strukturiert sind, nicht nur zum Ansehen durch einen Menschen.

Der Batch-Workflow: Einmal definieren, jeden Monat verarbeiten

Das Spaltenschema für die Batch-Verarbeitung japanischer Rechnungen wird einmal definiert. Dieselben über zwanzig Spaltennamen — Rechnungsnummer (請求書番号), Ausstellungsdatum (発行日), Lieferant (発行元), Registrierungsnummer für qualifizierte Rechnungen (インボイス登録番号), Artikelname (品名), Menge (数量), Einzelpreis (単価), Positionsbetrag (金額), Zwischensumme (小計), 10 % steuerpflichtiger Betrag, 10 % Verbrauchssteuer, 8 % steuerpflichtiger Betrag, 8 % Verbrauchssteuer, Gesamtbetrag (合計金額), Quellensteuerklassifizierung (源泉徴収区分), Bankname (振込先銀行名), Filialname (支店名), Kontotyp (口座種別), Kontonummer (口座番号), Kontoinhaber (口座名義), Zahlungsbedingungen (支払条件), Abrechnungstag (締日), Überweisungsgebührenübernahme (振込手数料負担) — werden einmal eingegeben. In jedem Folgemonat lädt das AP-Team den Monatsstapel der Rechnungs-PDFs in den Upload, der Batch verarbeitet alle Dokumente gleichzeitig, und die Ausgabetabelle erscheint mit allen dreißig Zeilen befüllt. Die Spaltennamen ändern sich nicht. Die Rechnungsformate der Lieferanten können sich ändern — ein neues ERP-System bei einem Lieferanten, eine Abrechnungsplattform-Migration bei einem anderen — aber die KI liest jedes Dokument, indem sie versteht, was jedes Feld bedeutet, nicht indem sie sich merkt, wo jeder Lieferant seine Bankdaten auf der Seite platziert.

Dieses Schema erfasst die Benutzerdefinierte Spaltenextraktion: Sie geben die gewünschten Spaltennamen für die Ausgabe ein, und die KI findet die passenden Daten in jedem Dokument, indem sie die Bedeutung des Felds versteht — nicht durch eine feste Position, die je nach Rechnungslayout des Lieferanten variiert. Eine berechnete Spalte kann während der Extraktion zusätzliche Werte ableiten: eine Spalte wie Nettozahlungsbetrag (falls Quellensteuer anwendbar: Gesamtbetrag × 0,8979; andernfalls: Gesamtbetrag) berechnet den tatsächlichen Überweisungsbetrag direkt. Eine abgeleitete Spalte kann den kompakten Zahlungsbedingungstext in strukturierte Werte umwandeln: Abrechnungstag (aus Zahlungsbedingungen: wenn „20日締" dann 20) und Zahlungsverzugsmonate (wenn „翌月末払い" dann 1) — der Textstring „20日締翌月末払い" wird in zwei berechenbare Zahlen aufgeteilt, die eine Zahlungskalenderformel direkt lesen kann.

Ausgabe 1: Bankverbindungsdaten werden zu einem Zahlungslauf

Die sich am häufigsten wiederholende Dateneingabeaufgabe in der japanischen Kreditorenbuchhaltung ist das erneute Eintippen der Bankverbindungsdaten von der Rechnung in das Online-Banking-System. Jede 請求書 enthält einen 振込先-Block mit vier separaten Feldern: Bankname (銀行名), Filialname (支店名), Kontotyp (口座種別 — 普通 für ordentlich oder 当座 für Giro) und Kontonummer (口座番号). Der AP-Sachbearbeiter liest diese vier Felder von der Rechnung ab, wechselt zum Internet-Banking-Bildschirm der Bank und tippt sie ein — dieselben vier Felder, die bereits im Lieferantenstamm des Buchhaltungssystems gespeichert sind, werden für jede Rechnung jeden Monat neu eingegeben. Dreißig Rechnungen zum Monatsende: 120 einzelne Bankfeldeingaben, die bereits vorhandene Daten duplizieren.

Wenn die Batch-Ausgabe jedes der vier Bankfelder in einer eigenen Spalte enthält — Bankname, Filialname, Kontotyp, Kontonummer — sind diese Spalten die Eingabe für eine Zahlungsstapeldatei. Japanische Banken akzeptieren Batch-Überweisungsdateien im Zengin-Format (全銀フォーマット), einem festformatigen Format, das von der Japanese Banks' Payment Clearing Network (全国銀行資金決済ネットワーク) standardisiert wurde und es einem Unternehmen ermöglicht, mehrere Furikomi-Überweisungen in einem einzigen Upload einzureichen, anstatt sie einzeln über den Internet-Banking-Bildschirm einzugeben. Das Format erfordert für jede Überweisung: den Bankleitzahl-Code der überweisenden Bank, die überweisende Kontonummer, den Bankleitzahl-Code der begünstigten Bank, den Filialcode des Begünstigten, die Kontonummer des Begünstigten, den Namen des Begünstigten und den Überweisungsbetrag — alles an präzisen Zeichenpositionen.

Eine Tabelle mit dreißig Zeilen, die jeweils Bankname, Filialname, Kontotyp, Kontonummer, Kontoinhaber und Nettobetrag in separaten Spalten enthält, kann über eine einfache Vorlage in das Zengin-Format übertragen werden. Die Daten sind bereits strukturiert — die Zuordnung ist ein einmaliger Export von Tabelle zu Festformat, nicht dreißig Runden des erneuten Eintippens von Bankcodes. Derselbe Ansatz gilt für konsolidierte Überweisung (総合振込), bei der eine Überweisungsanweisung mehrere Zahlungen von einem einzigen Firmenkonto abdeckt — die gängigste Methode für japanische Unternehmen, die mehrere Lieferantenrechnungen am selben Abrechnungstag bezahlen. Die extrahierten Bankdaten, gruppiert nach Abrechnungstag, bilden die Eingabe für einen konsolidierten Überweisungslauf: Alle Rechnungen, die am 20. abgeschlossen werden und deren Zahlung zum Monatsende fällig ist, gehen in eine Überweisungsanweisung ein; alle Rechnungen, die am Monatsende abgeschlossen werden und deren Zahlung im Folgemonat fällig ist, in eine andere.

Output 2: Zahlungsbedingungen werden zum Abrechnungskalender

Das Feld „Zahlungsbedingungen“ auf einer japanischen Rechnung ist eine kompakte Textzeichenfolge, die AP-Teams fließend lesen, die sich aber einer formelhaften Verarbeitung widersetzt. „20日締翌月末払い“ – Abrechnungsschluss am 20., Zahlung bis Ende des Folgemonats fällig. „末日締翌々月10日払い“ – Abrechnungsschluss am Monatsende, Zahlung bis zum 10. des übernächsten Monats fällig. „15日締翌月末払い“ – Abrechnungsschluss am 15., Zahlung bis Ende des Folgemonats fällig. Jede Zeichenfolge kodiert zwei Werte: einen Abrechnungstag (締日) und einen Zahlungsverzug. In einem Single-File-Workflow liest ein Mitarbeiter die Zeichenfolge für jede Rechnung, berechnet das Fälligkeitsdatum gedanklich und trägt es in einen Kalender ein. In einem Batch-Workflow analysiert eine berechnete Spalte diese Zeichenfolgen in strukturierte Zahlen – Abrechnungstag und Zahlungsverzug in Monaten – und die Tabelle gruppiert Zahlungen automatisch nach Abrechnungstag.

Diese Gruppierung ist wichtig, da sie den Mittelabfluss steuert. Rechnungen mit Abrechnungsschluss am 20. und Zahlung am Ende des Folgemonats belasten das Konto alle am selben Tag. Rechnungen mit Abrechnungsschluss am Monatsende und Zahlung am Ende des Folgemonats belasten das Konto zwei bis drei Wochen später, an einem anderen Tag. Ohne die Batch-Gruppierung sieht das AP-Team dreißig einzelne Fälligkeitstermine. Mit der Batch-Gruppierung sieht das AP-Team zwei oder drei Auszahlungstage mit den zugehörigen Gesamtbeträgen – genau die Informationen, die die Treasury-Abteilung für das Working-Capital-Management benötigt. Der Abrechnungstag, nicht das Rechnungsdatum oder der Kalendermonat, bestimmt, welchem Geschäftsjahr die Ausgabe zuzuordnen ist. Eine Rechnung vom 18. März mit den Bedingungen „20日締“ ist eine Ausgabe im März – zahlbar im April, aber abgegrenzt im am 31. März endenden Geschäftsjahr. Eine Rechnung vom 22. März mit denselben Bedingungen „20日締“ ist eine Ausgabe im April – zahlbar im Mai, abgegrenzt im nächsten Geschäftsjahr. Der Abrechnungstag ist die Grenze des Geschäftsjahres, und die Batch-Ausgabe gruppiert automatisch nach dieser Grenze, da die berechnete Spalte sie als Zahl extrahiert hat.

Output 3: Umsatzsteuerbeträge fließen direkt in die Steuererklärung ein

Das japanische Umsatzsteuersystem wendet zwei Steuersätze an – 10 % Standardsatz und 8 % ermäßigter Satz – und das System der qualifizierten Rechnungen verlangt, dass jede Rechnung die Steuerbemessungsgrundlage und den Steuerbetrag pro Steuersatzkategorie getrennt ausweist. Für ein Unternehmen, das die Akkumulationsmethode (積上げ計算) für die Umsatzsteuererklärung verwendet, benötigt die Steuererklärung die Steuerdaten pro Rechnung – nicht nur eine aggregierte Zwischensumme, sondern die einzelnen Steuerbeträge aus jeder qualifizierten Rechnung, die auf Dokumentebene erhalten bleiben.

Die Batch-Ausgabe erfasst den steuerpflichtigen Betrag zu 10 %, die Umsatzsteuer zu 10 %, den steuerpflichtigen Betrag zu 8 % und die Umsatzsteuer zu 8 % aus jeder Rechnung in separaten Spalten. Die Tabelle liefert nach Steuersätzen gruppierte Summen, die mit der gedruckten Steueraufschlüsselung jeder Rechnung abgeglichen werden können – dieselbe Prüfung, die das AP-Team manuell für jede Rechnung durchführen würde, die aber automatisch für alle dreißig Rechnungen in einer einzigen Ausgabe durchgeführt wird. Weicht der extrahierte Umsatzsteuerbetrag zu 8 % einer Rechnung vom gedruckten Betrag auf dem Dokument ab, wird die Abweichung in der Tabelle zur Überprüfung markiert. Der Stapel von dreißig Rechnungen wird zu einer Prüfliste anstelle von dreißig einzelnen Prüfaufgaben, und die nach Steuersätzen gruppierten Summen bilden die Eingabe für die vierteljährliche Umsatzsteuererklärung, ohne dass ein separater manueller Aggregationsdurchlauf erforderlich ist.

Ausgabe 4: Quellensteuer wird zum Nettobetrag

Das japanische Quellensteuersystem (源泉徴収制度), geregelt durch Artikel 204 des Einkommensteuergesetzes (所得税法), verpflichtet den Zahlungspflichtigen, bei Zahlungen an bestimmte freiberufliche Dienstleister – Steuerberater (税理士), Wirtschaftsprüfer (公認会計士), Rechtsanwälte (弁護士), Justizbeamte (司法書士), Designer (デザイナー), Schriftsteller (著作家) und andere qualifizierte Kategorien – die Einkommensteuer an der Quelle einzubehalten. Der Quellensteuersatz beträgt 10,21 % für Zahlungen bis zu 1 Mio. Yen und 20,42 % für den 1 Mio. Yen übersteigenden Betrag, wie in den Quellensteuer-Richtlinien der Nationalen Steuerbehörde bestätigt. Der Zahlungspflichtige führt den einbehaltenen Betrag an das Finanzamt ab und zahlt dem Lieferanten den verbleibenden Saldo.

Eine Rechnung eines qualifizierten Lieferanten, die eine Quellensteuerklassifizierung aufweist – oft gekennzeichnet als 源泉徴収あり oder mit einer separaten Zeile für den „源泉徴収額“ – ändert die Zahlungsberechnung. Die Kreditorenbuchhaltung muss ermitteln, welche Rechnungen quellensteuerpflichtig sind, den Abzugsbetrag pro Rechnung berechnen, ihn vom Zahlungsbetrag abziehen und den einbehaltenen Betrag als separate Steuerhinterlegungsverbindlichkeit verbuchen. In einem Einzeldatei-Workflow ist dies manuelle Arithmetik pro qualifizierter Rechnung. In einem Batch-Workflow übernehmen zwei Spalten dies:

• Quellensteuer-Klassifizierung – eine abgeleitete Spalte, die prüft, ob die Rechnung 源泉徴収 erwähnt und ob der Lieferant ein qualifizierter Freiberufler ist. Ausgabe: „Anwendbar“ oder „Nicht anwendbar“.
• Nettobetrag – eine berechnete Spalte: wenn Quellensteuer anwendbar ist und der Gesamtbetrag unter 1 Mio. Yen liegt, Ausgabe Gesamtbetrag × 0,8979. Gibt den tatsächlichen Überweisungsbetrag für jede Rechnung aus.

Die Tabelle enthält drei Spalten pro qualifizierter Rechnung: Bruttobetrag (Rechnungssumme), Quellensteuerbetrag (der Abzug) und Nettobetrag (der Überweisungsbetrag). Die Zahlungs-Batchdatei verwendet den Nettobetrag. Der Steuerhinterlegungsplan verwendet den Quellensteuerbetrag. Beide stammen aus denselben Quelldaten – einmal extrahiert, einmal berechnet, sowohl für Zahlung als auch Compliance verfügbar. Derselbe Batch-Verarbeitungsansatz für japanische Bestellungen erfasst dieselben Zahlungsbedingungen und Quellensteuerfelder von der Beschaffungsseite und schafft so eine durchgängige Pipeline zwischen dem Bestellten und dem in Rechnung Gestellten.

Die Rechnungsnummernkette: Von der PDF bis zur Zahlungsbestätigung

Eine Rechnungsnummer (請求書番号) ist der Primärschlüssel für die Kreditorenbuchhaltung und Zahlungsverfolgung. Wenn eine Zahlungsbestätigung von der Bank eingeht – ein Transaktionsbeleg mit einer Überweisung von 847.200 ¥ an die Mitsubishi UFJ Bank, Filiale Shinjuku, Konto 1234567 – muss die AP-Abteilung diese mit der ursprünglichen Rechnung abgleichen, um zu bestätigen, dass der richtige Betrag auf das richtige Konto für die richtige Rechnung überwiesen wurde. Ohne die Rechnungsnummer wird der Abgleich einer Banktransaktion mit einer Lieferantenrechnung zu einem Abstimmungsproblem, das mit der Menge wächst: 30 Lieferantenzahlungen pro Monat, 12 Monate im Jahr, 360 potenzielle Fehlpaarungen.

Der Batch-Output führt die Rechnungsnummer in einer eigenen Spalte. Jede Zahlungsbestätigung der Bank kann anhand der Rechnungsnummer mit der Batch-Tabelle abgeglichen werden – nicht anhand des Betrags, der mehrdeutig sein kann, wenn zwei Rechnungen denselben Gesamtbetrag aufweisen – und schafft so einen Prüfpfad von der ursprünglichen Rechnungs-PDF über die Extraktionstabelle bis zum Bankzahlungsbeleg. Die Registrierungsnummer für qualifizierte Rechnungen (インボイス登録番号), die zusammen mit der Rechnungsnummer extrahiert wird, bietet einen zweiten Verifikationspunkt: Die T-Nummer in den extrahierten Daten sollte mit der T-Nummer im Lieferantenstamm übereinstimmen. Eine Abweichung weist auf einen Lieferanten hin, dessen Registrierungsstatus sich möglicherweise geändert hat – ein Datenpunkt, der in einem manuellen Workflow unentdeckt bliebe, bis die Umsatzsteuervoranmeldung eine Prüfungsanfrage auslöst.

Diese Kette – Rechnungsnummer → Banküberweisung → Zahlungsbestätigung – macht aus 30 einzelnen Überweisungen eine einzige Abstimmungsaufgabe. Der Batch extrahiert Daten nicht nur schneller. Er schafft die Verknüpfungsstruktur, die 30 Zahlungen als Gruppe abstimmbar macht, anstatt als 30 separate Einzelfälle. Das gleiche Verknüpfungsprinzip aus der Beschaffung treibt den Bestell-Liefer-Rechnungs-Abgleich-Workflow und den vierteljährlichen BAS-Batch-Ansatz für Australien – der Extraktionsoutput ist kein Endpunkt, sondern ein Zwischenpunkt in einer Dokumentenkette, die mit einer Bestellung beginnt und mit einer Steuererklärung endet.

FAQ

Kann der Batch Rechnungen von Lieferanten verarbeiten, die unterschiedliche Rechnungsformate verwenden?

Ja. Das Spaltenschema wird einmal definiert und auf jede Rechnung im Batch angewendet, unabhängig vom Layout. Ein Lieferant verwendet möglicherweise eine PDF aus seinem ERP-System mit den Bankdaten in einem umrandeten Feld am unteren Seitenrand. Ein anderer sendet möglicherweise eine gescannte handschriftliche Rechnung, bei der die Bankdaten im Bemerkungsfeld erscheinen. Die KI liest jedes Dokument, indem sie versteht, was jedes Feld bedeutet – ein Bankname ist ein Bankname, egal wo er erscheint – und nicht, indem sie ein festes Layout pro Lieferant erwartet. Die dreißig Rechnungen können von dreißig verschiedenen Abrechnungssystemen in dreißig verschiedenen Formaten stammen, und die Ausgabe ist eine konsistente Tabelle.

Wie verarbeitet der Batch das Kontonummernformat der Japan Post Bank (ゆうちょ銀行)?

Die Japan Post Bank (ゆうちょ銀行) verwendet ein 記号-番号-Format, das sich von den 7-stelligen Kontonummern unterscheidet, die von Geschäftsbanken für Furikomi-Überweisungen verwendet werden. Wenn die Batch-Ausgabe ゆうちょ銀行 als Banknamen erkennt, kann eine abgeleitete Spalte das 記号-番号-Paar in die für das Banksystem erforderliche 7-stellige Überweisungskontonummer umwandeln. Die Japan Post Bank veröffentlicht die Umrechnungsregel auf ihrer Website. Die Spaltenlogik analysiert die 記号-Ziffern und die 番号-Ziffern und gibt die überweisungsbereite Kontonummer zusammen mit dem ursprünglichen Format zur Überprüfung aus.

Was ist, wenn einige Rechnungen inkl. Steuer (税込) und andere zzgl. Steuer (税抜) sind?

Die Spaltendefinition sollte die gewünschte Ausgabenormalisierung festlegen. Wenn die Einheitspreise auf einigen Lieferantenrechnungen inkl. Steuer und auf anderen zzgl. Steuer sind, normalisiert eine berechnete Spalte sie während der Extraktion: Positionsbetrag zzgl. Steuer (wenn der Rechnungsvermerk 税込 ist, dividiere den Einheitspreis durch 1,1 für 10%-Artikel oder 1,08 für 8%-Artikel; andernfalls verwende wie angegeben). Die KI liest den Dokumentkontext – einschließlich etwaiger 税込- oder 税抜-Vermerke –, um die steuerliche Behandlung zu bestimmen und alle Positionsbeträge auf einer konsistenten Basis auszugeben. Die Tabelle kommt mit jeder normalisierten Zeile an, sodass die Verbrauchsteuersummen über alle dreißig Rechnungen von einer konsistenten Basis aus berechnet werden.

Wie interagiert die Spalte zur Quellensteuer (源泉徴収) mit der Berechnung der Umsatzsteuer?

Gemäß den Richtlinien der NTA gilt: Wenn Vergütung und Umsatzsteuer auf der Rechnung klar getrennt ausgewiesen sind, wird die Quellensteuer nur auf den Vergütungsbetrag berechnet – der Umsatzsteueranteil unterliegt nicht der Quellensteuer. Sind sie nicht getrennt, wird in der Regel der Bruttobetrag (inkl. Steuer) für die Quellensteuerberechnung herangezogen. Die Spaltendefinition sollte die Berechnungsregel festlegen: Quellensteuer-Bemessungsgrundlage (falls Rechnung 報酬 und 消費税 klar trennt, verwende 報酬; andernfalls Gesamtbetrag) und Quellensteuerbetrag (Bemessungsgrundlage × 0,1021, gedeckelt auf Bemessungsgrundlage × 0,1021 für Anteile bis 1 Mio. ¥). Der Batch wendet dieselbe Regel auf alle dreißig Rechnungen an, sodass die Quellensteuerberechnung konsistent und prüfbar ist.

Kann die Batch-Ausgabe direkt in japanische Buchhaltungssoftware importiert werden?

Ja. Jede gängige japanische Buchhaltungsplattform – 弥生会計 (Yayoi), freee, マネーフォワード クラウド会計 (MoneyForward Cloud), 勘定奉行 (Kanjo Bugyo) – akzeptiert den CSV-Import von Kreditorendaten. Die Batch-Ausgabe wird direkt zugeordnet: Rechnungsnummer → Belegnummer (伝票番号), Lieferant → Lieferantenname (仕入先), Rechnungsdatum → Buchungsdatum (日付), Gesamtbetrag → Betrag (金額). Die Umsatzsteuerspalten nach Steuersätzen fließen in das Steuermelde-Modul ein. Die Registrierungsnummer für qualifizierte Rechnungen (インボイス登録番号) wird in die Prüfung qualifizierter Rechnungen übernommen, die Plattformen wie freee automatisch durchführen. Die Bankverbindungsdaten – in separaten Spalten – bilden die Grundlage für die Batch-Zahlungsdatei der Bank, unabhängig vom Buchhaltungssoftware-Import.

Von dreißig PDFs zu einem zahlungsbereiten Hauptbuch

Der monatliche Rechnungsstapel in einem japanischen Unternehmen besteht nicht einfach aus dreißig zu bezahlenden Rechnungen. Es sind dreißig Zahlungsanweisungen – jede mit Bankverbindungsdaten, die erneut in das Banksystem eingegeben werden müssen. Es sind dreißig Steuerdokumente – jedes mit Umsatzsteuerbeträgen nach Steuersätzen, die in die vierteljährliche Umsatzsteuervoranmeldung einfließen. Es sind dreißig Compliance-Nachweise – einige mit Quellensteuerverpflichtungen, die separate Steuerzahlungen erfordern. Und es sind dreißig Abstimmungsbelege – Rechnungsnummern, die mit Bestellungen, Lieferscheinen und Bankzahlungsaufzeichnungen übereinstimmen müssen.

Ein Batch-Extraktions-Workflow, der alle dreißig Rechnungen als eine Arbeitseinheit verarbeitet, erzeugt nicht dreißig einzelne Tabellenzeilen, sondern vier sofort nutzbare Ausgaben: eine Zahlungs-Batch-Datei mit Bankdaten in bereits transferbereiten Spalten, einen Zahlungskalender gruppiert nach Fälligkeitstagen, eine Umsatzsteuer-Zusammenfassung nach Steuersätzen für die Steuererklärung und einen Quellensteuerplan mit bereits berechneten Nettozahlungsbeträgen. Die Aufgabe der Kreditorenbuchhaltung am Monatsende verschiebt sich von der Dateneingabe zur Datenprüfung – vom dreißigmaligen Eintippen derselben vier Bankfelder hin zur Überprüfung, ob dreißig extrahierte Zeilen mit den Quelldokumenten übereinstimmen. Die Tabelle ist die Ausgabe. Die Tabelle ist auch die Eingabe – für das Bankzahlungssystem, die Buchhaltungssoftware und die Steuererklärung. Der Batch verbindet sie, indem er Daten in der Struktur erzeugt, die jedes nachgelagerte System erwartet, und nicht Daten, die ein Mensch vor jeder Übergabe neu formatieren muss.