3 Jahre japanischer Sparbuchseiten
Ein Jahresausgaben-Hauptbuch
Ein Einzelunternehmer in Osaka, der eine Blaue Steuererklärung (青色申告) einreicht, sammelt drei Banksparbücher (通帳, tsūchō) für den Zeitraum 2023 bis 2025 – MUFG für den laufenden Betrieb, Japan Post Bank (ゆうちょ銀行) für Steuerrücklagen und eine regionale Kreditgenossenschaft (信用金庫) für die Gehaltsabrechnung. Zusammen: rund 36 Seiten gedruckter Transaktionen, 280 Zeilen Ein- und Auszahlungshistorie, an drei verschiedenen Geldautomaten mit drei verschiedenen Nadeldruckköpfen eingezahlt und in drei Sparbüchern mit unterschiedlichem Abnutzungsgrad gebunden. Die Blaue Steuererklärung gewährt einen Abzug von ¥650.000 im Austausch für doppelte Buchführung – das bedeutet, dass jede dieser 280 Zeilen als kategorisierter Buchungssatz in Yayoi Accounting (弥生会計), freee oder MoneyForward Cloud Accounting landen muss. Eine Seite nach der anderen zu extrahieren, drei Sparbuchsalden abzugleichen und japanische Zeitrechnungsdaten (和暦) manuell in den gregorianischen Kalender umzurechnen, ist für ein einzelnes Transaktionsjahr machbar. Für drei Jahre über drei Banken hinweg bricht der Einzelseiten-Workflow unter seinem eigenen manuellen Zusammenführungsschritt zusammen.
Wichtigste Erkenntnisse
- Drei Jahre Sparbuchseiten besiegen Sie nicht in der Eingabephase. Sie besiegen Sie in der Zusammenführungsphase – wenn 36 Einzelseiten-Extraktionen zu einem sortierten Hauptbuch werden müssen.
- Der laufende Saldo eines Sparbuchs ist seine größte Prüfspur – aber ein einziger Fehllesevorgang verwandelt ihn in eine Zeitbombe, die jede nachfolgende Zeile korrumpiert, still, über Seitengrenzen hinweg.
- Die Batch-Extraktion mit einer berechneten Saldenprüfung erkennt einen Fehllesevorgang im Moment seines Auftretens – Sie korrigieren eine Zeile in zwei Minuten, statt eine Stunde später, wenn die Probebilanz fehlschlägt, rückwärts durch 280 Zeilen zu jagen.
Die Batch-to-Ledger-Lücke: Warum die Einzelseiten-Extraktion das 3-Jahre-Problem nicht löst
Eine einzelne Sparbuchseite zu extrahieren ist die gelöste Hälfte des Problems. Der Workflow zur Extraktion japanischer Sparbücher — fünf Spalten definieren, die Seite hochladen, eine Tabellenzeile pro Transaktion erhalten — verarbeitet 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 eine Master-Tabelle einfügen, nach Datum sortiert über drei verschiedene Jahreszeitalter-Header hinweg (令和5年 auf der MUFG-Seite, R6 auf der Japan-Post-Bank-Seite, 2024 bei einem digitalen Export), und die Salden-Spalten müssen über Sparbücher hinweg kreuzgeprüft werden, die dieselbe bankinterne Überweisung an unterschiedlichen Daten erfasst haben.
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 über zwei physische Sparbuchhefte mit je 50–100 Seiten), was etwa 250 Transaktionen ergibt, die in ein einziges jährliches Haushaltsbuch zusammengeführt werden müssen. MoneyForward ME und Zaim ziehen täglich neue Transaktionen über Bank-APIs — aber sie reichen nicht zurück in die Jahre vor der API-Anmeldung, und genau das ist die Sammlung von Seiten, die in der Sparbuchschublade liegt. Die Apps lösen die tägliche Sichtbarkeit. Sie lösen nicht den einmal-im-Jahr-Moment, in dem drei Jahre Papier zu einer Tabelle werden müssen.
Die Batch-Lücke in einer Zahl: drei Sparbücher × 280 Transaktionen × 5 Felder = 1.400 extrahierte Datenpunkte. Mit Einzelseiten-Extraktion landen diese 1.400 Punkte in 36 separaten Dateien, die eine Person zusammenführen muss. Mit Batch-Extraktion landen sie in einer Tabelle, in der jede Zeile sortiert, jedes Datum in den gregorianischen Kalender umgerechnet und jeder Saldo gegen seinen Vorgänger geprüft ist — kein Zusammenführungsschritt, kein Kopieren-Einfügen, kein manuelles Sortieren.
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 Zeitrechnungsdaten (和暦) auf einer einzelnen Sparbuchseite ist ein überschaubarer manueller Schritt: Jahreskopf oben lesen, die Epochen-Offset kennen und jedes Datum im Kopf umrechnen. Über 36 Seiten aus drei Sparbüchern – wobei der Jahreskopf nur auf der ersten Seite jedes Monatsblocks von Geldautomaten-Auszügen erscheint und dann für die nächsten 5–7 Fortsetzungsseiten verschwindet – verschiebt sich der manuelle Umrechnungsaufwand von „überschaubar" zu „der Hauptfehlerquelle, die zu Ablehnungen in der Buchhaltungssoftware führt".
Betrachten wir den Datenpfad. Ein Sparbuch, das an einem MUFG-Geldautomaten gedruckt wurde, 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 den vollständigen Epochennamen 令和6年7月15日 verwenden. Exportiert der Nutzer einige Monate aus dem Internet-Banking als CSV, kommen diese Daten als 2024-07-15 an. Drei Darstellungen desselben Datums in einem einzigen Batch.
Yayoi Accounting (弥生会計) erwartet Daten im Format yyyy-mm-dd für den CSV-Import. Senden Sie eine Datumszeichenfolge „R6.7.15" und der Import schlägt still fehl – die Transaktionszeile wird übersprungen, und der Fehler tritt erst Stunden später zutage, wenn die Probebilanz nicht mit dem Sparbuch übereinstimmt.
Die Batch-Extraktion übernimmt die Epochenumrechnung auf der Ausgabeebene: Unabhängig davon, wie das Datum auf jeder Sparbuchseite erscheint – abgekürzte Epoche + Monat.Tag, vollständiger Epochenname + 年月日 oder bereits im gregorianischen Kalender – kommt jedes Datum in der konsolidierten Tabelle als yyyy-mm-dd an. Für einen Batch, der drei Jahre und zwei Epochen umspannt (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 Anmerkung des Nutzers.
Die Epochenumrechnungslogik ist deterministisch: Reiwa-Jahr n = gregorianisches Jahr (n + 2018), Heisei n = (n + 1988), Showa n = (n + 1925). Die Herausforderung ist nicht die Arithmetik – es ist die Erkennung, welche Epoche für welche Zeile auf welcher Seite gilt, wenn der Epochenkopf nur alle paar Seiten erscheint und sich die Epoche selbst mitten im Batch ändern kann. Vorlagenbasierte OCR kann diese Bestimmung nicht treffen, weil sie isolierte Zellen liest. Semantische Extraktion mit Batch-Kontext kann es, weil sie die Beziehung zwischen einem Seitenkopf und seinen Inhaltszeilen liest.
Batch-Workflow für Sparbücher in drei Schritten aufbauen
Der Workflow, der drei Jahre Sparbuchseiten in einem einzigen Jahresausgaben-Hauptbuch batch-verarbeitet, 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 Einzel-Sparbuch-Extraktion eingerichtet haben, verwenden Sie hier dasselbe Spaltenschema.
Definieren Sie Ihre Ausgabespalten und Prüfregeln – einmal 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 Sparbuch-Extraktion ist das Standardschema: Datum, Beschreibung (摘要), 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 liest, nicht die Feldposition. Dieselben Spaltennamen funktionieren über das einzeilige Format von MUFG, das zweizeilige Layout pro Transaktion der Japan Post Bank und den kompakten Druck einer regionalen Kreditgenossenschaft – alle drei Sparbücher im selben Batch erzeugen eine einheitliche Tabelle. Für ein jährliches Ausgabenbuch ergänzen Sie berechnete Spalten, die während der Extraktion laufen: Eine Saldo-Prüf-Spalte (vorheriger Saldo + Einzahlung − Auszahlung = aktueller Saldo? 'OK' : 'PRÜFEN') kennzeichnet Saldierungsfehler, bevor die Daten in Ihre Buchhaltungssoftware gelangen, und eine Kategorie-Spalte (wenn Beschreibung "給与" 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 ist, nicht nur eine chronologisch geordnete Liste.
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 Kontonummern und der Rückseite mit dem Magnetstreifen (磁気ストライプ) – und legen Sie alle Bilder in einen Batch-Upload. Die 12 Seiten eines MUFG-Sparbuchs von 2023, die 10 Seiten eines Japan-Post-Bank-Sparbuchs aus demselben Jahr und die 14 Seiten eines Kreditgenossenschafts-Sparbuchs für 2023–2025 gehen alle in denselben Upload. Die Batch-Verarbeitung behandelt sie als einen einzigen Auftrag: Jede Seite wird unabhängig mit Ihrem Spaltenschema verarbeitet, die japanische Zeitrechnung wird mit korrektem Seitenkontext in den gregorianischen Kalender umgerechnet, und alle Ergebnisse werden in einer nach Datum sortierten Tabelle zusammengeführt. Seiten können Scans von einem Dokumentenscanner, Fotos von einem Smartphone oder PDF-Exporte aus dem Online-Banking sein, die sparbuchartige Transaktionslisten enthalten. Die Gesamtuploadzeit wird vom Scannen dominiert – bei etwa 30 Sekunden pro Seite zum Ausrichten und Scannen dauern 36 Seiten etwa 18 Minuten Vorbereitung. Die Extraktion selbst ist in wenigen Minuten abgeschlossen.
Exportieren Sie das konsolidierte Sparbuch und starten Sie Ihren Buchhaltungs-Workflow
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 Accounting, freee Accounting oder MoneyForward Cloud Accounting. Die Spalte „Saldo-Check“ zeigt OK neben jeder Transaktion, bei der die Rechnung aufgeht, und REVIEW neben Zeilen, bei denen der laufende Saldo nicht übereinstimmt – typischerweise ein oder zwei Zeilen von 280, verursacht durch ein falsch gelesenes Komma oder eine verschmierte Ziffer auf einer älteren Sparbuchseite. Korrigieren Sie diese zwei Zeilen, und die restlichen 278 sind verifiziert. Die Spalte „Kontenbezeichnung“ gruppiert Transaktionen nach Typ, sodass Sie mit dem Filter „Lastschrift (引落)“ ein Jahr Miete, Nebenkosten und Versicherungszahlungen in einer einzigen Ansicht sehen. Dasselbe Spaltenschema funktioniert im nächsten Jahr für dieselben Sparbücher – die Felder eines japanischen Sparbuchs, definiert vom Japanischen Bankenverband (全国銀行協会), werden sich nicht ändern.
Dateien werden sicher verarbeitet und nicht gespeichert.
Verwendungszweck-Codes und das Jahresausgaben-Hauptbuch
Die Verwendungszweck-Spalte (摘要) eines Sparbuchs verwendet kompakte Codes, die ein japanischer Leser sofort einordnet: 給与 ist Gehalt, 振込 ist eine Überweisung, 引落 ist eine Lastschrift, 手数料 ist eine Bankgebühr, 利息 ist Zinsen, カード ist 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 Jahresausgaben-Hauptbuch.
Der Unterschied ist wichtig, weil die Ziel-Buchhaltungssoftware – Yayoi, freee oder MoneyForward Cloud Accounting – Journalbuchungen mit Kontenbezeichnungen (勘定科目) benötigt, nicht rohe 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) den Gehaltszahlungen und 水道光熱費 (Versorgungskosten) den Lastschriften zuzuordnen. Für einen Batch von drei Jahren sind das etwa 45 Minuten repetitiver Kategorisierung – länger, wenn ein Code wie 振込 weiter unterteilt werden muss (Kundenzahlung vs. Freund, der Essensgeld zurückzahlt).
Eine berechnete Spalte, die Verwendungszweck-Codes während der Extraktion Ausgabenkategorien zuordnet – „Gehaltseinkommen" für 給与, „Versorgungskosten" für 引落 an Tokyo Electric (東京電力), „Bankgebühr" für 手数料, „Zinseinkommen" für 利息 – verwandelt die Ausgabe von einer Transaktionsliste in ein vorkategorisiertes Hauptbuch. Die Zuordnungsregeln werden einmal im Spaltenschema definiert und automatisch auf alle 280 Zeilen angewendet.
Dieselbe berechnete Klassifizierung verarbeitet auch die Codes, die über das Beschreibungsfeld hinaus Kontext benötigen. Eine 振込 von ¥500.000 von einem bekannten Kundenunternehmen im Zahlungsempfängerfeld ist 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 Extraktionsengine wertet diese Logik während der Verarbeitung aus, und die Ausgabe kommt mit bereits getroffenen Klassifizierungsentscheidungen an – der Benutzer genehmigt oder überschreibt, statt jede Entscheidung von Grund auf selbst zu treffen.
Saldo-Abweichung: Warum ein einziger Fehllesefehler 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 Fehllesefehler in Zeile 14 betrifft nur Zeile 14. Ein Sparbuch ist ein Hauptbuch: Der Saldo in Zeile 15 entspricht dem Saldo in Zeile 14 plus der Einzahlung in Zeile 15 minus der Auszahlung in Zeile 15. Ein Fehllesefehler in Zeile 14 – ein übersehenes Komma, das ¥30.000 in ¥3.000 verwandelt – korrumpiert den Saldo von Zeile 14, was die Saldoprüfung von Zeile 15 korrumpiert, was wiederum 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 mit eigener Saldokontinuität. Bei einem Batch von 280 Transaktionen aus 36 Seiten überschreitet die Kaskade Seitengrenzen, da der Saldo von der letzten Zeile der Seite N auf die erste Zeile der Seite N+1 übertragen wird. Ein einziger Komma-Fehllesefehler auf Seite 3, Zeile 7 erzeugt 253 falsche Saldoprüfungsergebnisse – jede Zeile ab diesem Punkt fällt durch die Saldoprüfung, was es unmöglich macht, die Ursache zu identifizieren, ohne Zeile für Zeile rückwärts zu arbeiten.
Der Ansatz mit berechneten Spalten – Balance Check (previous Balance + Deposit − Withdrawal = current Balance? 'OK' : 'REVIEW') – erkennt das Problem am Punkt des Fehlers. Zeile 3-7 wird als REVIEW markiert. Zeile 3-8, deren Saldo vom Saldo der Zeile 3-7 abhängt, wird ebenfalls als REVIEW markiert – aber der Benutzer weiß, dass er zuerst Zeile 3-7 korrigieren muss, wonach sich 3-8 bis zum Ende des Batches korrekt neu berechnen. 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 Vorteil der Batch-Prüfung: Ein Sparbuch, das seit drei Jahren geführt wird, hat 36 Seiten mit gedruckten Salden, die abgeglichen werden müssen. Eine berechnete Spalte, die die Saldenmathematik in jeder extrahierten Zeile während der Verarbeitung prüft, erkennt die Abweichung zum Zeitpunkt der Extraktion. Ohne sie tritt der Fehler in der Buchhaltungssoftware auf, wenn die Summenbilanz nicht mit dem Kontoauszug übereinstimmt – ein Abgleich, der rückwärts durch 280 Zeilen über drei Sparbücher führen muss, um den einzelnen Fehllesefehler zu finden, der die Kaskade ausgelöst hat. Die Kennzeichnung zur Extraktionszeit ist eine Korrektur von zwei Minuten. Die Kennzeichnung zur Buchhaltungszeit ist eine Stunde forensischer Buchführung.
Diese Verifizierungslogik lässt sich direkt auf andere Batch-Extraktionsszenarien übertragen, bei denen die Dokument-zu-Dokument-Kontinuität dasselbe Kaskadenrisiko erzeugt. Eine britische Steuerkanzlei, die 80 SA100-Selbstauskünfte in einer Tabelle konsolidiert, verarbeitet unabhängige Dokumente – die Daten jeder Auskunft sind in sich abgeschlossen. Ein australisches Lohnbuchhaltungsteam, das 300 PAYG-Zahlungsbelege im Batch verarbeitet, steht vor derselben Unabhängigkeit. Der Sparbuch-Batch ist anders, weil das Dokument selbst die Kontinuität erzeugt – und diese Kontinuität wird bei batch-bewusster Extraktion zu einem eingebauten Prüfpfad statt zu einer versteckten Zeitbombe.
Häufig gestellte Fragen
Kann ich Sparbücher verschiedener Banken im selben Upload im Batch verarbeiten?
Ja – und das ist eines der stärksten Argumente dafür, alle drei Jahre Sparbuch zusammen im Batch zu extrahieren statt sie getrennt zu verarbeiten. 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 (信用金庫) druckt in einer leicht anderen Schriftgröße und Ausrichtung. 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 ist – können alle drei Formate im selben Batch hochgeladen werden und eine einheitliche Tabelle mit konsistenten Spalten erzeugen. Dasselbe Spaltenschema, das das Saldo-Feld auf einem sauberen MUFG-Druck findet, findet es auch in einem abgenutzten Japan-Post-Bank-Sparbuch mit verblasster Tinte, weil die KI semantischen Inhalt liest, keine vorlagenbasierten Pixelkoordinaten.
Was passiert, wenn ein Sparbuch zwei japanische Zeitrechnungen umspannt – Heisei und Reiwa?
Die Extraktion erkennt den Epochenwechsel auf der Seite, auf der die Jahreskopfzeile wechselt. Ein Sparbuch, das von Heisei 30 (2018) bis Reiwa 6 (2024) läuft, enthält beide Epochenkopfzeilen. Die Batch-Engine liest die Kopfzeile auf jeder Seite, bestimmt, ob die Epoche Heisei oder Reiwa ist, und wendet den korrekten Umrechnungsoffset 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 – ist die Kopfzeile auf der Seite mit den Mai-Transaktionen bereits auf Reiwa umgestellt, und alle Transaktionen auf dieser und den folgenden Seiten werden mit dem Reiwa-Offset (+2018) umgerechnet. Transaktionen auf Seiten mit der Heisei-Kopfzeile verwenden den Heisei-Offset (+1988). Für Sparbücher mit noch früheren Transaktionen aus der Showa-Ära (昭和, 1926–1989) gilt dieselbe Logik mit Showa + 1925.
Wie behandelt der Batch Seiten, auf denen die Jahreskopfzeile fehlt?
Fortsetzungsseiten – Seiten innerhalb desselben Sparbuchs, die die Jahreskopfzeile nicht erneut drucken, weil sie von einer vorherigen Seite fortgesetzt werden – übernehmen den Epochenkontext von der letzten Seite mit Kopfzeile. Wenn Seite 5 oben 令和6年 druckt und die Seiten 6–8 nur Monat und Tag für jede Transaktion 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 1.-Januar-Grenze – wird der Kontext aktualisiert. Die Weitergabe vermeidet den häufigsten Epochenumrechnungsfehler bei der manuellen Sparbuchverarbeitung: eine Januar-Transaktion auf einer Fortsetzungsseite als Vorjahr zu behandeln, weil die Jahreskopfzeile drei Seiten zurückliegt und der Nutzer 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.