30 Lieferantenrechnungen, einezahlungsbereite AP-Tabelle

Ein mittelständisches japanisches Unternehmen erhält zum Monatsende dreißig bis fünfzig Lieferantenrechnungen (請求書, seikyūsho). Jede enthält die Bankverbindung (振込先, furikomisaki) – Bankname, Filialname, Kontotyp, Kontonummer – die der AP-Sachbearbeiter zur Ausführung einer Überweisung (振込) in das Online-Banking-System neu eingeben muss. Jede enthält eine Zahlungsbedingung wie „20日締翌月末払い“, die den Abrechnungstag und die Zahlungsverzögerung kodiert, was bestimmt, wann Geld das Konto verlässt und welchem Geschäftsjahr die Ausgabe zuzuordnen ist. Einige enthalten eine Quellensteuerklassifikation (源泉徴収区分, gensen chōshū kubun), die bedeutet, dass der Zahlungspflichtige vor der Überweisung 10,21 % einbehalten muss – und wird dieser Abzug versäumt, zahlt das Unternehmen dem Lieferanten diesen Betrag zu viel, während er ihn dem Finanzamt schuldet. Jede Rechnung seit Oktober 2023 trägt eine Registrierungsnummer für qualifizierte Rechnungen (インボイス登録番号), die mit „T“ beginnt – ohne diese wird der Vorsteuerabzug nach einem Übergangsplan, der auf Null reduziert wird, gemindert. Die manuelle Verarbeitung von dreißig Rechnungen bedeutet, dass das AP-Team nicht dreißig Dokumente liest. Es tippt dreißig Sätze von Bankdaten ein, die bereits im Lieferantenstamm vorhanden sind, berechnet dreißig Quellensteuerabzüge auf einem Taschenrechner und trägt dreißig Zahlungstermine in einen Kalender ein, indem es Textzeichenfolgen gedanklich analysiert, die ein Computer hätte analysieren sollen. Im nächsten Monat senden dieselben dreißig Lieferanten dieselben dreißig Rechnungen in leicht unterschiedlichen Layouts, und das erneute Eintippen beginnt von vorn.

Schluss mit Abtippen — lassen Sie KI Ihre Dokumente lesen
Bild oder PDF hochladen — strukturierte Daten in 10 Sekunden
Jetzt testen
Keine Anmeldung · Keine Kreditkarte · Ergebnis in 10 Sekunden
Stapelverarbeitung japanischer Lieferantenrechnungen – dreißig Seikyusho-PDFs werden zu einer zahlungsbereiten Kreditorenbuchhaltungstabelle mit Furikomi-Überweisungsdaten verarbeitet

Wichtige Erkenntnisse

  1. Jeden Monat gibt ein japanischer AP-Sachbearbeiter 120 Bankfeldeinträge neu ein, die bereits im Lieferantenstamm vorhanden sind – weil kein Tool das verbindet, was aus der Rechnung extrahiert wurde, mit dem Überweisungsbildschirm, der dieselben vier Felder als Eingabe benötigt.
  2. Einzeldatei-Extraktionstools hören beim Lesen auf. Die wahren Kosten entstehen bei der Zusammenstellung – jemand muss immer noch dreißig Tabellenzeilen auseinandernehmen und in die Zahlungsstapeldatei, die Umsatzsteuervoranmeldung und den Quellensteuerplan umformatieren, eine versteckte zweite Aufgabe, die niemand je zusammengerechnet hat.
  3. Die Stapelverarbeitung behandelt alle dreißig Seikyūsho als eine Arbeitseinheit – Extrahieren von Daten und Zusammenstellen von vier zahlungsbereiten Ausgaben in einem Durchgang, sodass sich der Monatsabschluss vom Neueintippen von 120 Feldern auf das Überprüfen von dreißig Zeilen verschiebt.

Was die Einzeldatei-Extraktion ungenutzt lässt

Der Hauptartikel zur Extraktion japanischer Rechnungsdaten nach Excel behandelt die vollständige Feldstruktur – wie Sie Bankverbindungen, Zahlungsbedingungen, Umsatzsteuer und Quellensteuer aus einer einzigen 請求書 erfassen. Ein Einzeldatei-Workflow löst jedoch nur das Problem der Extraktion pro Dokument. Er löst nicht das Problem der Stapelverarbeitung bis zur Zahlung – ein anderes Problem mit einer anderen Art von Ausgabe.

Ein Kreditorenbuchhalter, der dreißig Rechnungen manuell bearbeitet, durchläuft eine feste Abfolge: PDF öffnen, Bankverbindung finden, die vier Bankfelder in das Online-Banking eintippen, Zahlungsbedingungen prüfen, Fälligkeitsdatum ermitteln, Quellensteuer prüfen, Umsatzsteueraufschlüsselung bestätigen und die Rechnungsregistrierungsnummer mit dem Lieferantenstamm abgleichen. Diese Abfolge wiederholt sich dreißig Mal. Der Extraktionsvorgang – das Auslesen der Daten aus der Rechnung – und die Zahlungsvorbereitung – das Zusammenstellen dieser Daten in ein banktransferfähiges Format – verschmelzen zu einer einzigen, sich wiederholenden Aufgabe. Ein Einzeldatei-Extraktionstool trennt diese Schritte: Die Daten werden in eine Zeile einer Tabelle extrahiert. Die Zahlungsvorbereitung – das Zusammenstellen dieser dreißig Zeilen zu einer Zahlungsdatei, einem Zahlungskalender, einem Quellensteuer-Ablieferungsplan und einer steuerfertigen Umsatzsteuerzusammenfassung – erfordert jedoch weiterhin manuelle Arbeit. Die Extraktion hat das Leseproblem gelöst. Sie hat das Zusammenstellungsproblem nicht gelöst.

Die Stapelverarbeitung löst beide Probleme gleichzeitig, da 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 für die menschliche Ansicht.

Der Batch-Workflow: Einmal definieren, jeden Monat verarbeiten

Das Spaltenschema für die Stapelverarbeitung japanischer Rechnungen wird einmal definiert. Dieselben über zwanzig Spaltennamen – Rechnungsnummer (請求書番号), Ausstellungsdatum (発行日), Lieferant (発行元), Registrierungsnummer für qualifizierte Rechnungen (インボイス登録番号), Artikelname (品名), Menge (数量), Einzelpreis (単価), Zeilenbetrag (金額), Zwischensumme (小計), 10 % steuerpflichtiger Betrag, 10 % Umsatzsteuer, 8 % steuerpflichtiger Betrag, 8 % Umsatzsteuer, Gesamtbetrag (合計金額), Quellensteuerkategorie (源泉徴収区分), Bankname (振込先銀行名), Filialname (支店名), Kontotyp (口座種別), Kontonummer (口座番号), Kontoinhaber (口座名義), Zahlungsbedingungen (支払条件), Abrechnungstag (締日), Überweisungsgebührenverantwortung (振込手数料負担) – werden einmal eingegeben. In jedem Folgemonat legt das Kreditorenteam den Monatsendstapel der Rechnungs-PDFs in den Upload, die Stapelverarbeitung verarbeitet alle Dokumente gleichzeitig, und die Ausgabetabelle erscheint mit allen dreißig gefüllten Zeilen. Die Spaltennamen ändern sich nicht. Die Rechnungsformate der Lieferanten können sich ändern – ein neues ERP-System bei einem Lieferanten, eine Umstellung der Abrechnungsplattform 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 Feldes versteht – nicht durch eine feste Position, die von einem Rechnungslayout des Lieferanten zum anderen 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 Zahlungsverzögerung in Monaten (wenn "翌月末払い" dann 1) – die Textzeichenfolge "20日締翌月末払い" wird in zwei berechenbare Zahlen aufgespalten, die eine Zahlungskalenderformel direkt lesen kann.

JPG/PNG/PDF KI-Extraktion

Dateien werden sicher verarbeitet und nicht gespeichert.

Ausgabe 1: Bankverbindungsdaten werden zu einem Zahlungsbatch

Die sich am häufigsten wiederholende Dateneingabeaufgabe in der japanischen Kreditorenbuchhaltung ist das erneute Abtippen von Bankverbindungsdaten von der Rechnung in das Online-Banking-System. Jede 請求書 enthält einen 振込先-Block mit vier separaten Feldern: Bankname (銀行名), Filialname (支店名), Kontotyp (口座種別 — 普通 für Girokonto oder 当座 für Scheckkonto) und Kontonummer (口座番号). Der AP-Sachbearbeiter liest diese vier Felder von der Rechnung ab, wechselt zum Internet-Banking-Bildschirm der Bank und gibt 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 am 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 Zahlungsbatch-Datei. Japanische Banken akzeptieren Batch-Überweisungsdateien im 全銀フォーマット (Zengin-Format), einem festformatigen Standard der japanischen Banken-Zahlungsverkehrsnetzwerks (全国銀行資金決済ネットワーク), der 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: die Bankleitzahl der überweisenden Filiale, die Kontonummer des Überweisenden, die Bankleitzahl des Empfängers, die Filialleitzahl des Empfängers, die Kontonummer des Empfängers, den Namen des Empfängers 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 abgebildet werden. Die Daten sind bereits strukturiert – die Abbildung ist ein einmaliger Export von Tabelle zu Festformat, nicht dreißig Runden des erneuten Eintippens von Bankleitzahlen. Derselbe Ansatz gilt für die 総合振込 (konsolidierte Überweisung), bei der ein Überweisungsauftrag mehrere Zahlungen von einem einzigen Firmenkonto abdeckt – die gängigste Methode für japanische Unternehmen, die am selben Abrechnungstag mehrere Lieferantenrechnungen bezahlen. Die extrahierten Bankdaten, gruppiert nach Abrechnungstag, bilden die Eingabe für einen konsolidierten Überweisungsbatch: Alle Rechnungen mit Fälligkeit am 20. und Zahlung am Monatsende gehen in einen Überweisungsauftrag, alle Rechnungen mit Fälligkeit am Monatsende und Zahlung im Folgemonat in einen anderen.

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.

📮 contact email: [email protected]