3 Jahre japanische Sparbuchseiten
Ein jährliches Ausgabenbuch
Ein Einzelunternehmer in Osaka, der eine Blaue Steuererklärung (青色申告) einreicht, sammelt drei Banksparbücher (通帳, tsūchō) für die Jahre 2023 bis 2025 – MUFG für den täglichen Geschäftsbetrieb, Japan Post Bank (ゆうちょ銀行) für Steuerrücklagen und eine regionale Kreditgenossenschaft (信用金庫) für die Gehaltsabrechnung. Zusammen: etwa 36 Seiten mit gedruckten Transaktionen, 280 Zeilen Ein- und Auszahlungshistorie, eingezahlt an drei verschiedenen Geldautomaten mit drei verschiedenen Punktmatrix-Druckköpfen und gebunden in drei unterschiedlich abgenutzten Sparbüchern. Die Blaue Steuererklärung gewährt einen Abzug von 650.000 Yen im Austausch für eine doppelte Buchführung – was bedeutet, dass jede dieser 280 Zeilen als kategorisierter Buchungssatz in Yayoi Accounting (弥生会計), freee oder MoneyForward Cloud Accounting landen muss. Das Extrahieren einer Seite nach der anderen, das Abgleichen von drei Sparbuchsalden und das manuelle Umrechnen japanischer Epochendaten (和暦) in den gregorianischen Kalender ist für ein einzelnes Jahr mit Transaktionen machbar. Für drei Jahre über drei Banken hinweg bricht der Einzelseiten-Workflow unter seinem eigenen manuellen Zusammenführungsschritt zusammen.
Wichtige Erkenntnisse
- Drei Jahre Sparbuchseiten überwältigen Sie nicht in der Eingabephase. Sie überwältigen Sie in der Zusammenführungsphase – wenn aus 36 Einzelseiten-Extraktionen ein einziges sortiertes Buch werden muss.
- Der laufende Saldo eines Sparbuchs ist die größte Prüfspur – aber ein einziger Lesefehler verwandelt ihn in eine Zeitbombe, die jede nachfolgende Zeile still und leise über Seitengrenzen hinweg verfälscht.
- Die Batch-Extraktion mit einer berechneten Saldenprüfung erkennt einen Lesefehler in dem Moment, in dem er passiert – Sie korrigieren eine Zeile in zwei Minuten, anstatt eine Stunde später, wenn die Saldenbilanz nicht aufgeht, rückwärts durch 280 Zeilen zu jagen.
Die Lücke zwischen Extraktion und Hauptbuch: Warum die Einzelseiten-Extraktion das 3-Jahre-Problem nicht löst
Das Extrahieren einer einzelnen Sparbuchseite ist die gelöste Hälfte des Problems. Der Workflow zur japanischen Sparbuch-Extraktion – fünf Spalten definieren, die Seite hochladen, eine Tabellenzeile pro Transaktion erhalten – bewältigt eine Seite zuverlässig. Die ungelöste Hälfte ist das, was passiert, wenn die Extraktion abgeschlossen ist und 36 einzelne Tabellenkalkulationen auf dem Desktop liegen, jede mit 8 bis 10 Transaktionen, jede von einer anderen Seite eines anderen Sparbuchs einer anderen Bank.
Die manuelle Zusammenführung ist der Punkt, an dem die Effizienz der Einzelseiten-Extraktion verpufft. Drei Sparbücher × 12 Seiten = 36 separate Excel-Dateien. Jede Datei muss ihre Transaktionen in ein Master-Blatt einfügen, datumsmäßig sortiert über drei verschiedene japanische Jahresüberschriften hinweg (令和5年 auf der MUFG-Seite, R6 auf der Seite der Japan Post Bank, 2024 bei einem digitalen Export), und die Salden-Spalten müssen sparbuchübergreifend abgeglichen werden, die dieselbe bankinterne Überweisung an unterschiedlichen Daten verbuchten.
Ein Haushalt, der monatliche Ausgaben verfolgt, steht vor einer milderen Version derselben Rechnung: zwei persönliche Sparbücher, monatlich über drei Jahre aktualisiert (36 Aktualisierungen, möglicherweise verteilt auf zwei physische Sparbuchhefte mit je 50–100 Seiten), was etwa 250 Transaktionen ergibt, die in ein einziges jährliches Ausgaben-Hauptbuch (家計簿) zusammengeführt werden müssen. MoneyForward ME und Zaim ziehen täglich neue Transaktionen über Bank-APIs – aber sie greifen nicht auf die Jahre vor der API-Anmeldung zurück, also genau auf die Sammlung von Seiten, die in der Sparbuchschublade liegen. Die Apps lösen die tägliche Sichtbarkeit. Sie lösen nicht den einmal im Jahr anstehenden Moment, in dem drei Jahre Papier zu einer Tabellenkalkulation werden müssen.
Die Batch-Lücke in einer Zahl: drei Sparbücher × 280 Transaktionen × 5 Felder = 1.400 extrahierte Datenpunkte. Bei Einzelseiten-Extraktion landen diese 1.400 Punkte in 36 separaten Dateien, die eine Person zusammenführen muss. Bei Batch-Extraktion landen sie in einer einzigen Tabellenkalkulation, in der jede Zeile sortiert, jedes Datum in den gregorianischen Kalender umgerechnet und jeder Saldo gegen seinen Vorgänger verifiziert ist – kein Zusammenführungsschritt, kein Kopieren-Einfügen, keine manuelle Sortierung.
Was die Batch-Verarbeitung für japanische Sparbücher tatsächlich ändert
Die Batch-Verarbeitung unterscheidet sich bei Sparbüchern (通帳) grundlegend von der Verarbeitung eines Stapels Rechnungen oder Quittungen. Ein Rechnungsstapel besteht aus unabhängigen Dokumenten – die Daten jeder Rechnung sind in sich abgeschlossen, und ein Lesefehler auf Rechnung 47 betrifft nur Rechnung 47. Ein Sparbuch-Stapel hingegen besteht aus voneinander abhängigen Seiten: Jede Seite setzt dort an, wo die vorherige aufgehört hat, der Saldo (差引残高) wird fortlaufend übertragen, und der Datumskontext – einschließlich des Jahreszeitalter-Kopfes – setzt sich über Seitengrenzen hinweg fort. Ein einziger Lesefehler auf Seite 3 eines 12-seitigen Stapels verfälscht stillschweigend die Saldenprüfung aller nachfolgenden Seiten.
Drei Dimensionen machen die Batch-Verarbeitung von Sparbüchern zu einem grundlegend anderen Problem als die Einzelseiten-Extraktion:
Zusammenführung mehrerer Sparbücher. Ein Kleinunternehmen mit Betriebs-, Steuerrücklagen- und Gehalts-Sparbüchern führt drei separate laufende Salden. Überweisungen zwischen Konten – z. B. 200.000 ¥ vom Betriebskonto auf das Steuerrücklagenkonto – erscheinen als Abhebung im einen und als Einzahlung im anderen Sparbuch, oft an unterschiedlichen Tagen. Eine Batch-Ausgabe, die alle drei Sparbücher in einem einzigen sortierten Kontoauszug zusammenführt, macht die Überweisung kontenübergreifend nachvollziehbar. Drei separate Tabellenblätter machen sie unsichtbar.
Übertrag des Jahreszeitalters über Seiten hinweg. Eine Sparbuchseite druckt den Jahreskopf – 令和6年 oder R6 – nur einmal oben. Nachfolgende Zeilen auf derselben Seite führen nur Monat und Tag (7.15). Wenn die Extraktion Seiten einzeln verarbeitet, werden die Transaktionen von Seite 7 zu schwebenden Daten – „7.15“ ohne Jahresbezug, weil der Kopf auf Seite 6 steht. Batch-bewusste Extraktion liest den Kopf einmal und wendet ihn auf jede Transaktion dieser Seite sowie auf fortgeführte Seiten an, wobei alle Daten in der Ausgabe in den gregorianischen Kalender (西暦) umgewandelt werden. Wenn das Jahreszeitalter am 1. Januar wechselt, verarbeitet die Batch-Logik den Wechsel mitten im Stapel – sodass der 30. Dezember 令和6年 und der 5. Januar 令和7年 beide ohne manuellen Eingriff in die korrekten gregorianischen Daten aufgelöst werden.
Sparbücher mit Zeitalterwechsel. Ein 2018 eröffnetes und 2024 erneuertes Sparbuch enthält Transaktionen aus zwei Kaiserzeitaltern: 平成 (Heisei, 1989–2019) und 令和 (Reiwa, seit 2019). Der Zeitalterwechsel erfolgt mitten im Sparbuch – Heisei 31 wird am 1. Mai 2019 zu Reiwa 1. Eine Extraktion, die jeweils nur eine Seite verarbeitet, könnte Transaktionen nahe der Grenze den falschen Zeitalterkontext zuweisen. Die Batch-bewusste Extraktion erkennt den Zeitalterwechsel auf der Seite, auf der der Kopf von 平成 zu 令和 wechselt, und wendet auf jede Transaktion basierend auf ihrer Position den korrekten Zeitalter-Offset an (Heisei + 1988, Reiwa + 2018). Für Sparbücher, die auch Transaktionen aus der späten Showa-Ära (昭和) enthalten – Konten, die in den 1980er Jahren eröffnet wurden – erweitert sich dieselbe Logik auf Showa + 1925.
Ein Einzelseiten-Extraktionstool verarbeitet jede Seite als isolierte Einheit. Ein Batch-Tool verarbeitet sie als Sequenz – und bei einem Dokumenttyp, der von seiner fortlaufenden Kontinuität lebt, entscheidet dieser Unterschied darüber, ob die Ausgabe sofort nutzbar ist oder stundenlange manuelle Nacharbeit erfordert.
Die 和暦-Herausforderung, multipliziert mit dem Batch-Volumen
Die Umrechnung japanischer Jahresdaten (和暦) auf einer einzelnen Sparbuchseite ist ein überschaubarer manueller Schritt: Sie lesen die Jahresüberschrift oben, kennen den Epochen-Offset und rechnen jedes Datum im Kopf um. Über 36 Seiten aus drei Sparbüchern – wo die Jahresüberschrift nur auf der ersten Seite jedes monatlichen Kontoauszugs-Batches erscheint und dann für die nächsten 5–7 Folgeseiten fehlt – wird der manuelle Umrechnungsaufwand von „überschaubar" zur „Hauptfehlerquelle, die zu Ablehnungen in der Buchhaltungssoftware führt".
Betrachten Sie den Datenpfad. Ein von einem MUFG-Geldautomaten gedrucktes Sparbuch verwendet das Format R6.7.15 für den 15. Juli 2024 (Reiwa-Jahr 6). Dieselbe Transaktion, gedruckt am Geldautomaten der Japan Post Bank, könnte die vollständige Epochenbezeichnung 令和6年7月15日 verwenden. Exportiert der Benutzer einige Monate aus dem Online-Banking als CSV, kommen diese Daten als 2024-07-15 an. Drei Darstellungen desselben Datums innerhalb eines Batches.
Yayoi Accounting (弥生会計) erwartet Daten im Format yyyy-mm-dd für den CSV-Import. Wenn Sie eine Datumszeichenfolge „R6.7.15" senden, schlägt der Import stillschweigend fehl – die Transaktionszeile wird übersprungen, und der Fehler zeigt sich erst Stunden später, wenn die Saldenliste nicht mit dem Sparbuch übereinstimmt.
Die Batch-Extraktion behandelt die Epochenumrechnung auf der Ausgabeebene: Unabhängig davon, wie das Datum auf jeder Sparbuchseite erscheint – abgekürzte Epoche + Monat.Tag, vollständige Epochenbezeichnung + 年月日 oder bereits im gregorianischen Kalender – jedes Datum in der konsolidierten Tabelle kommt als yyyy-mm-dd an. Für einen Batch, der drei Jahre und zwei Epochen umfasst (2019 überspannt 平成31年 Januar–April und 令和元年 Mai–Dezember), wendet die Extraktions-Engine den korrekten Offset pro Transaktion an, basierend auf dem Epochenkontext, der auf jeder Seite erkannt wird, nicht auf einer manuellen Annotation durch den Benutzer.
Die Epochenumrechnungslogik ist deterministisch: Reiwa-Jahr n = gregorianisches Jahr (n + 2018), Heisei n = (n + 1988), Showa n = (n + 1925). Die Herausforderung liegt nicht in der Arithmetik – sondern darin, zu erkennen, welche Epoche für welche Zeile auf welcher Seite gilt, wenn die Epochenüberschrift nur alle paar Seiten einmal erscheint und die Epoche selbst mitten im Batch wechseln kann. Vorlagenbasierte OCR kann diese Bestimmung nicht treffen, da sie isolierte Zellen liest. Semantische Extraktion mit Batch-Kontext kann es, weil sie die Beziehung zwischen einer Seitenüberschrift und ihren Inhaltszeilen liest.
Einen Batch-Workflow für Sparbücher in drei Schritten aufbauen
Der Workflow, der drei Jahre Sparbuchseiten in einem Jahresausgabenbuch stapelverarbeitet, ist derselbe, ob Sie drei oder dreißig Sparbücher verarbeiten. Der Einrichtungsschritt – das Definieren Ihrer Ausgabespalten – wird einmal durchgeführt und für jeden Batch, jede Bank und jedes Steuerjahr wiederverwendet. Wenn Sie bereits Spalten für die einzelne Sparbuchextraktion eingerichtet haben, verwenden Sie dasselbe Spaltenschema hier erneut.
Definieren Sie Ihre Ausgabespalten und Prüfregeln – einmalig, für jede Bank und jedes Jahr
Geben Sie die Feldnamen genau so ein, wie sie als Spaltenüberschriften in der Ausgabetabelle erscheinen sollen. Für die Extraktion aus Sparbüchern lautet das Standardschema: Datum, Verwendungszweck (摘要), Auszahlung (お支払金額), Einzahlung (お預り金額), Saldo (差引残高). Dies ist die Benutzerdefinierte Spaltenextraktion: Sie definieren das Ausgabeschema, und die KI ordnet die gedruckten Felder jedes Sparbuchs Ihren Spalten zu, indem sie die Feldbedeutung und nicht die Feldposition liest. Dieselben Spaltennamen funktionieren mit dem einzeiligen Format der MUFG, dem zweizeiligen Layout der Japan Post Bank und dem kompakten Druck einer regionalen Kreditgenossenschaft – alle drei Sparbücher im selben Batch erzeugen eine einheitliche Tabelle. Ergänzen Sie für ein jährliches Ausgabenbuch berechnete Spalten, die während der Extraktion ausgeführt werden: Eine Spalte Saldenprüfung (vorheriger Saldo + Einzahlung − Auszahlung = aktueller Saldo? 'OK' : 'PRÜFEN') kennzeichnet Saldenfehler, bevor die Daten in Ihre Buchhaltungssoftware gelangen, und eine Spalte Kategorie (wenn Verwendungszweck "給与" enthält, dann "Gehalt"; wenn "振込" enthält, dann "Überweisung"; wenn "引落" enthält, dann "Lastschrift"; wenn "手数料" enthält, dann "Gebühr"; sonst "Sonstiges") sortiert Transaktionen vorab nach Typ, sodass die Ausgabe ein jährliches Ausgabenbuch und nicht nur eine chronologisch geordnete Liste ist.
Laden Sie den gesamten Batch hoch – alle Sparbücher, alle Seiten, ein Upload
Scannen oder fotografieren Sie jede Seite jedes Sparbuchs – einschließlich der Vorderseiten mit den Kontonummern und der Rückseite mit dem Magnetstreifen (磁気ストライプ) – und legen Sie alle Bilder in einem Batch-Upload ab. Ein MUFG-Sparbuch mit 12 Seiten aus dem Jahr 2023, ein Japan-Post-Bank-Sparbuch mit 10 Seiten aus demselben Jahr und ein Kreditgenossenschafts-Sparbuch mit 14 Seiten für den Zeitraum 2023–2025 werden alle in denselben Upload gegeben. Die Batch-First-Verarbeitung behandelt sie als einen einzigen Auftrag: Jede Seite wird unabhängig mit Ihrem Spaltenschema verarbeitet, Ära-Daten werden mit korrektem Seitenkontext in den gregorianischen Kalender umgewandelt, und alle Ergebnisse werden in einer nach Datum sortierten Tabelle zusammengeführt. Die Seiten können Scans eines Dokumentenscanners, mit einem Smartphone aufgenommene Fotos oder PDF-Exporte aus dem Online-Banking sein, die sparbuchähnliche Transaktionslisten enthalten. Die gesamte Upload-Zeit wird vom Scannen dominiert – bei etwa 30 Sekunden pro Seite zum Ausrichten und Scannen dauert die Vorbereitung von 36 Seiten etwa 18 Minuten. Die Extraktion selbst ist in wenigen Minuten abgeschlossen.
Exportieren Sie das konsolidierte Kassenbuch und starten Sie Ihre Buchhaltung
Laden Sie eine Excel-Datei mit rund 280 Zeilen herunter – eine pro Transaktion – und jedes Feld in einer eigenen Spalte. Die Datumsspalte ist im gregorianischen Kalender (jjjj-mm-tt) und bereit für den CSV-Import in Yayoi, freee oder MoneyForward Cloud Accounting. In der Spalte „Saldenprüfung“ steht neben jeder Transaktion, bei der die Rechnung aufgeht, „OK“, und neben Zeilen, bei denen der laufende Saldo nicht stimmt, „PRÜFEN“ – in der Regel ein bis zwei von 280 Zeilen, verursacht durch ein überlesenes Komma oder eine verschmierte Ziffer auf einer vergilbten Sparbuchseite. Korrigieren Sie diese zwei Zeilen, und die restlichen 278 sind verifiziert. Die Spalte „Kategorie“ gruppiert Transaktionen nach Typ, sodass Sie durch Filtern nach „Lastschrift (引落)“ Miete, Nebenkosten und Versicherungszahlungen eines ganzen Jahres auf einen Blick sehen. Das gleiche Spaltenschema funktioniert im nächsten Jahr für dieselben Sparbücher – die Felder eines japanischen Sparbuchs, definiert vom Japanischen Bankenverband (全国銀行協会), ändern sich nicht.
Dateien werden sicher verarbeitet und nicht gespeichert.
Verwendungszweck-Codes und das Jahresausgabenbuch
Die Verwendungszweck-Spalte (摘要) eines Sparbuchs verwendet kompakte Codes, die ein japanischer Leser sofort kategorisiert: 給与 steht für Gehalt, 振込 für eine Überweisung, 引落 für eine Lastschrift, 手数料 für eine Bankgebühr, 利息 für Zinsen, カード für eine Kartentransaktion. Eine rohe Extraktion, die diese Codes originalgetreu wiedergibt – 振込, 振込, 引落, 給与, 振込 – erzeugt eine Transaktionsliste. Eine Batch-Extraktion, die sie während der Verarbeitung klassifiziert, erzeugt ein Jahresausgabenbuch.
Der Unterschied ist wichtig, weil die Ziel-Buchhaltungssoftware – Yayoi, freee oder MoneyForward Cloud Accounting – Buchungssätze mit Kontenbezeichnungen (勘定科目) benötigt, nicht mit rohen Verwendungszweck-Codes. Der manuelle Workflow nach der Einzelseiten-Extraktion besteht darin, die Tabelle zu öffnen, eine Kategorie-Spalte hinzuzufügen und 280 Zeilen durchzugehen, um 売上 (Umsatzerlöse) Gehaltseingängen und 水道光熱費 (Betriebskosten) Lastschriften zuzuweisen. Für einen Batch von drei Jahren sind das etwa 45 Minuten wiederholter Kategorisierung – länger, wenn ein Code wie 振込 eine Unterklassifizierung benötigt (Kundenzahlung vs. Freund, der Essensgeld zurückzahlt).
Eine berechnete Spalte, die Verwendungszweck-Codes während der Extraktion Ausgabenkategorien zuordnet – „Gehaltseinkommen“ für 給与, „Betriebskosten“ für 引落 an Tokyo Electric (東京電力), „Bankgebühr“ für 手数料, „Zinsertrag“ für 利息 – verwandelt die Ausgabe von einer Transaktionsliste in ein vorkategorisiertes Buch. Die Zuordnungsregeln werden einmal im Spaltenschema definiert und automatisch auf alle 280 Zeilen angewendet.
Die gleiche berechnete Klassifizierung verarbeitet die Codes, die über das Beschreibungsfeld hinaus Kontext benötigen. Eine 振込 von 500.000 ¥ von einem bekannten Kundenunternehmen im Zahlungsempfängerfeld ist ein Geschäftseinkommen. Eine 振込 von 15.000 ¥ von einer Privatperson ist wahrscheinlich privat. Eine berechnete Spalte kann den Beschreibungscode mit dem Einzahlungsbetrag kombinieren, um die Klassifizierung vorzunehmen: if Description="振込" and Amount > 100000 then "Business Income"; if Description="振込" and Amount <= 100000 then "Personal Transfer". Die Extraktions-Engine wertet diese Logik während der Verarbeitung aus, und die Ausgabe enthält bereits getroffene Klassifizierungsentscheidungen – der Benutzer genehmigt oder überschreibt, anstatt jede Entscheidung von Grund auf neu zu treffen.
Saldo-Abweichung: Warum ein einziger Lesefehler in einem Batch jede nachfolgende Zeile zerstört
Der laufende Saldo des Sparbuchs (差引残高) ist sowohl seine größte Stärke für die Buchhaltungsprüfung als auch sein gefährlichster Fehlermodus bei der Batch-Verarbeitung. Ein Kontoauszug ist eine monatliche Zusammenfassung: Ein Lesefehler in Zeile 14 betrifft nur Zeile 14. Ein Sparbuch ist ein Hauptbuch: Der Saldo in Zeile 15 entspricht dem Saldo in Zeile 14 zuzüglich der Einzahlung von Zeile 15 abzüglich der Auszahlung von Zeile 15. Ein Lesefehler in Zeile 14 – ein übersehenes Komma, das 30.000 ¥ in 3.000 ¥ verwandelt – korrumpiert den Saldo von Zeile 14, was die Saldenprüfung von Zeile 15 korrumpiert, was Zeile 16 korrumpiert, und so weiter durch jede nachfolgende Zeile im Sparbuch.
Bei einer einseitigen Extraktion von 10 Transaktionen stoppt die Kaskade an der Seitengrenze – die nächste Seite beginnt neu mit ihrer eigenen Saldenkontinuität. In einem Batch von 280 Transaktionen, die aus 36 Seiten zusammengeführt wurden, überschreitet die Kaskade die Seitengrenzen, weil der Saldo von der letzten Zeile von Seite N auf die erste Zeile von Seite N+1 übertragen wird. Ein einziger Komma-Lesefehler auf Seite 3, Zeile 7, erzeugt 253 falsche Saldenprüfergebnisse – jede Zeile ab diesem Punkt fällt bei der Saldenprüfung durch, was es unmöglich macht, die problematische Zeile zu identifizieren, ohne rückwärts Zeile für Zeile zu arbeiten.
Der Ansatz der berechneten Spalte – Balance Check (previous Balance + Deposit − Withdrawal = current Balance? 'OK' : 'REVIEW') – erkennt das Problem an der Fehlerstelle. Zeile 3-7 wird als REVIEW markiert. Zeile 3-8, deren Saldo vom Saldo von 3-7 abhängt, wird ebenfalls als REVIEW markiert – aber der Benutzer weiß, dass er zuerst Zeile 3-7 korrigieren muss, wonach 3-8 bis zum Ende des Batches korrekt neu berechnet werden. Eine einzelne REVIEW-Zeile in einem Meer von OKs ist eine punktgenaue Korrektur. Zweihundert REVIEW-Zeilen in Folge sind eine einzige Ursache in der ersten markierten Zeile.
Der Batch-Prüfvorteil: Ein Sparbuch, das seit drei Jahren geführt wird, hat 36 Seiten mit ausgedruckten Salden, die abgeglichen werden müssen. Eine berechnete Spalte, die die Saldenmathematik für jede extrahierte Zeile während der Verarbeitung prüft, erkennt die Abweichung zum Zeitpunkt der Extraktion. Ohne sie tritt der Fehler innerhalb der Buchhaltungssoftware auf, wenn die Summenbilanz nicht mit dem Kontoauszug übereinstimmt – ein Abgleich, der rückwärts durch 280 Zeilen, über drei Sparbücher hinweg, verfolgen muss, um den einzelnen Lesefehler zu finden, der die Kaskade ausgelöst hat. Die Markierung zum Extraktionszeitpunkt ist eine Korrektur von zwei Minuten. Die Markierung zum Buchhaltungszeitpunkt ist eine Stunde forensischer Buchführung.
Diese Prüflogik lässt sich direkt auf andere Batch-Extraktionsszenarien übertragen, bei denen die Dokument-zu-Dokument-Kontinuität das gleiche Kaskadenrisiko erzeugt. Eine britische Steuerpraxis, die 80 SA100-Selbstausfüllungen in einer Tabelle konsolidiert, verarbeitet unabhängige Dokumente – die Daten jeder Ausfüllung sind in sich abgeschlossen. Ein australisches Lohnbuchhaltungsteam, das 300 PAYG-Zahlungsbelege im Batch verarbeitet, steht vor der gleichen Unabhängigkeit. Der Sparbuch-Batch ist anders, weil das Dokument selbst die Kontinuität erzeugt – und diese Kontinuität wird, wenn sie von einer batch-bewussten Extraktion respektiert wird, zu einem eingebauten Prüfpfad und nicht zu einer versteckten Zeitbombe.
Häufig gestellte Fragen
Kann ich Sparbücher verschiedener Banken im selben Upload stapelverarbeiten?
Ja – und das ist eines der stärksten Argumente dafür, alle drei Jahrgänge der Sparbücher gemeinsam statt getrennt zu extrahieren. Ein Sparbuch der MUFG druckt Transaktionen einzeilig mit dem Datum links. Ein Sparbuch der Japan Post Bank (ゆうちょ銀行) verwendet oft ein zweizeiliges Format pro Transaktion, bei dem das Beschreibungsfeld umbricht. Ein Sparbuch einer regionalen Kreditgenossenschaft (信用金庫) wird in einer etwas anderen Schriftgröße und Ausrichtung gedruckt. Da die Extraktion die Feldbedeutung liest – ein Datum ist ein Datum, egal ob es auf einem Sparbuch als R6.7.15 oder auf einem anderen als 令和6年7月15日 gedruckt wird – können alle drei Formate im selben Batch hochgeladen werden und eine einheitliche Tabelle mit konsistenten Spalten erzeugen. Das gleiche Spaltenschema, das das Saldo-Feld auf einem sauberen MUFG-Druck lokalisiert, findet es auch in einem abgenutzten Sparbuch der Japan Post Bank mit verblasster Tinte, weil die KI semantische Inhalte liest, keine vorlagenbasierten Pixelkoordinaten.
Was passiert, wenn ein Sparbuch zwei japanische Zeitrechnungen umspannt – 平成 und 令和?
Die Extraktion erkennt den Zeitrechnungswechsel auf der Seite, auf der die Jahreskopfzeile wechselt. Ein Sparbuch, das von Heisei 30 (2018) bis Reiwa 6 (2024) läuft, enthält beide Zeitrechnungs-Kopfzeilen. Die Batch-Engine liest die Kopfzeile auf jeder Seite, ermittelt, ob die Zeitrechnung 平成 oder 令和 ist, und wendet den korrekten Umrechnungs-Offset pro Transaktion an. Für das kritische Übergangsjahr – 2019, das vom 1. Januar bis 30. April Heisei 31 und vom 1. Mai bis 31. Dezember Reiwa 1 (令和元年) ist – wechselt die Kopfzeile auf der Seite mit den Mai-Transaktionen zu 令和, und alle Transaktionen auf dieser und den folgenden Seiten werden mit dem Reiwa-Offset (+2018) umgerechnet. Transaktionen auf Seiten mit der 平成-Kopfzeile verwenden den Heisei-Offset (+1988). Für Sparbücher mit noch früheren Transaktionen aus der Showa-Ära (昭和, 1926–1989) gilt die gleiche Logik erweitert auf Showa + 1925.
Wie verarbeitet der Batch Seiten, auf denen die Jahreskopfzeile fehlt?
Fortsetzungsseiten – Seiten innerhalb desselben Sparbuchs, die die Jahreskopfzeile nicht wiederholen, weil sie von einer vorherigen Seite fortgesetzt werden – übernehmen den Zeitrechnungskontext von der letzten Seite mit einer Kopfzeile. Wenn Seite 5 oben 令和6年 druckt und die Seiten 6–8 für jede Transaktion nur Monat und Tag drucken, wendet die Extraktion den Kontext 令和6年 auf alle Transaktionen auf den Seiten 5 bis 8 an. Wenn Seite 9 eine neue Kopfzeile druckt – 令和7年 nach der Jahresgrenze am 1. Januar – wird der Kontext aktualisiert. Diese Übernahme vermeidet den häufigsten Fehler bei der Zeitrechnungsumrechnung in der manuellen Sparbuchverarbeitung: eine Januar-Transaktion auf einer Fortsetzungsseite als Vorjahr zu behandeln, weil die Jahreskopfzeile drei Seiten zurückliegt und der Benutzer vergessen hat, nachzusehen.
Was ist, wenn einige Sparbuchseiten handschriftliche Randnotizen enthalten – Miete, Inventarkäufe, Gehaltsaufschlüsselungen?
Viele Sparbücher enthalten handschriftliche Anmerkungen – etwa ein mit Kugelschreiber neben einer gedruckten Transaktion notierter Vermerk wie 家賃 (Miete) oder 仕入 (Inventarkauf). Wenn das Extraktionstool neben gedrucktem Text auch Handschrifterkennung unterstützt, erscheinen diese Randnotizen als zusätzlicher Kontext in den extrahierten Daten. Definieren Sie in Ihrem Schema eine Spalte namens „Notizen“, und jede lesbare handschriftliche Anmerkung in der Nähe einer Transaktionszeile wird bei der Extraktion erfasst. Beachten Sie, dass die Handschriftqualität variiert: Eine klare Kugelschreibernotiz in Standard-Kanji ist in der Regel lesbar; ein verblasster Bleistiftvermerk, der schräg geschrieben ist und die gedruckten Gitterlinien kreuzt, ist weniger zuverlässig. Bei Sparbüchern, in denen handschriftliche Notizen kritische Buchhaltungsinformationen enthalten – etwa die einzige Aufzeichnung eines Einzelunternehmers, ob eine 振込 eine Kunden- oder eine private Überweisung war – sollte die extrahierte Tabelle mit dem physischen Sparbuch für die wenigen Zeilen abgeglichen werden, bei denen die Handschrift mehrdeutig war. Die KI erledigt die lesbare Mehrheit und reduziert die Prüfung von einer zeilenweisen auf eine Ausnahmebehandlung.
In welchem Datenformat erfolgt die Extraktion und akzeptiert Yayoi Accounting dieses?
Die Batch-Ausgabe ist eine einzige Excel-Datei (.xlsx) mit allen Sparbuchtransaktionen in einem Blatt. Alle Daten sind im Format JJJJ-MM-TT – bereit für den direkten CSV-Import in Yayoi Accounting (弥生会計) über die Smart Transaction Import (スマート取引取込)-Funktion, freee Accounting (freee会計) über den manuellen CSV-Upload-Pfad oder MoneyForward Cloud Accounting (マネーフォワード クラウド会計) über die Datenmigrationsfunktion. Andere japanische Buchhaltungsplattformen, die dasselbe CSV-Importformat akzeptieren, umfassen MJS Accounting (会計大将), TKC (FX2/MX-Serie), OBC (勘定奉行), Sorimachi (会計王), EPSON (財務応援R4) und PCA (PCA会計). Das fünfspaltige Format des Sparbuchs – Datum, Verwendungszweck, Auszahlung, Einzahlung, Saldo – ist bei allen japanischen Banken standardisiert, sodass dieselbe Ausgabe mit jeder Buchhaltungsplattform funktioniert, die CSV-Transaktionsdaten importiert.
Muss ich die physischen Sparbücher nach der Batch-Extraktion weiterhin aufbewahren?
Nach dem japanischen Gesetz zur elektronischen Aufbewahrung von Büchern und Unterlagen (電子帳簿保存法) können gescannte Kopien von Finanzdokumenten als rechtlich zulässige Aufzeichnungen dienen – die Novelle von 2022 hat die Anforderungen an Auflösung und Zeitstempel deutlich gelockert. Das physische Sparbuch bleibt jedoch das definitive Original. Die Nationale Steuerbehörde (国税庁) kann bei einer Steuerprüfung die Originale anfordern. Beste Praxis für Einreicher der Blauen Steuererklärung: Extrahieren Sie alle Sparbücher per Batch in das jährliche Ausgabenbuch für Ihren Buchhaltungs-Workflow, bewahren Sie aber jedes physische Sparbuch für die gesetzliche Aufbewahrungsfrist von sieben Jahren auf. Die Extraktion ersetzt die manuelle Dateneingabe und die Zusammenführungsschritte – sie ersetzt nicht die rechtliche Aufzeichnung.
Das Sparbuch, das im Schrank wartet
Drei Jahre lang liegen die Seiten eines Sparbuchs in einer Schublade – nicht weil die Daten unzugänglich wären (jede Transaktion ist klar gedruckt, fünf Spalten pro Zeile, Saldo in jeder Zeile), sondern weil der Umfang die Schwelle überschreitet, ab der die manuelle Eingabe nicht mehr nur mühsam, sondern regelrecht Zeitverschwendung ist. Ein Blaue-Steuererklärung-Einreicher, der 280 Transaktionen manuell eintippt – zwei Minuten pro Zeile: Datum lesen, Verwendungszweck-Code entziffern, Betrag eintippen, Saldo prüfen – verbringt damit rund neun Stunden. Neun Stunden, die der Steuerfreibetrag von 650.000 Yen für die Sorgfalt der Buchführung belohnt – nicht für das Abtippen von Bankdaten.
Die Batch-Extraktion ändert die Rechnung. Aus neun Stunden Tipparbeit werden 18 Minuten Scannen der Sparbuchseiten plus zwei Minuten Prüfung der Flags in den berechneten Spalten – die ein oder zwei PRÜFEN-Zeilen von 280, bei denen die Saldenprüfung einen möglichen Lesefehler signalisiert hat. Die restlichen 278 Zeilen haben die automatisierte Prüfung während der Extraktion bestanden und sind ohne weitere Kontrolle für den Import in die Buchhaltungssoftware bereit. Im nächsten Jahr verwendet derselbe Batch dasselbe Spaltenschema mit anderen Seiten. Im Jahr darauf wieder. Das Sparbuchformat – festgelegt vom Japanischen Bankenverband, von Bankautomaten gedruckt, bei allen Finanzinstituten des Landes standardisiert – wird sich nicht ändern.