Comment extraire les données d'un livret bancaire japonais vers Excel
pour la comptabilité domestique (Guide 2026)
Un foyer de deux personnes au Japon dépense en moyenne 300 243 ¥ par mois selon l'enquête 2024 sur les revenus et dépenses des ménages du Bureau des statistiques — soit environ 3,6 millions de ¥ par an qui transitent par un compte bancaire, imprimés ligne par ligne dans un petit livret au distributeur. Pour les plus de 4 millions de travailleurs indépendants et freelances qui déclarent une déclaration bleue (青色申告) — l'option fiscale japonaise qui accorde une déduction de 650 000 ¥ en échange d'une comptabilité en partie double — chacune de ces transactions doit être traçable. Le livret bancaire (通帳) est le document de référence. Et pour les transactions antérieures à l'inscription à la banque en ligne, c'est aussi le seul document. L'extraire dans un tableur n'est pas facultatif — c'est le prérequis pour remplir la déclaration d'impôts.
Points clés à retenir
- Le solde cumulé du livret était conçu pour rendre la vérification infaillible — mais une virgule mal lue corrompt silencieusement tous les soldes qui suivent.
- Une erreur de relevé bancaire reste dans sa ligne — une erreur de livret se propage à tous les soldes suivants car le calcul de chaque ligne dépend de l'exactitude de toutes les lignes précédentes.
- Ajoutez une colonne calculée qui vérifie le calcul du solde sur chaque ligne lors de l'extraction, et les erreurs se signalent d'elles-mêmes avant que vos données n'entrent dans le logiciel comptable.
Ce que contient un livret bancaire japonais — et ce que chaque colonne signifie pour l'extraction
Le livret bancaire japonais (通帳, tsūchō) est un document financier unique au monde. Aucune autre économie développée n'utilise encore des livrets physiques à cette échelle — un carnet imprimé, délivré par la banque, dans lequel chaque distributeur automatique (ATM) inscrit les lignes de transactions : une ligne par opération, cinq colonnes par ligne, solde courant sur chaque ligne. Le format est tellement standardisé entre les institutions financières japonaises qu'à première vue, il semble s'agir d'un problème d'extraction résolu. La réalité est plus spécifique.
La disposition à cinq colonnes d'un livret est fixe — date, description, retrait, dépôt, solde — mais le contenu de ces colonnes reflète des décennies de conventions bancaires, de technologies d'impression mécanique et d'histoire réglementaire qu'aucun système OCR générique n'a été conçu pour comprendre.
Les cinq colonnes standard
- 月日 (Date) — mois et jour, généralement au format d'ère japonaise (令和6年 ou R6). L'en-tête d'année apparaît une fois par page. Convertir les dates d'ère en dates grégoriennes nécessite de savoir dans quelle ère on se trouve — et de ne pas confondre 平成30年 (2018) avec 令和6年 (2024).
- 摘要 (Description) — un code compact indiquant le type de transaction : 振込 (virement bancaire), ATM, 給与 (dépôt de salaire), 利息 (intérêts), 引落 (prélèvement automatique), 手数料 (frais). Ces codes sont la clé de la catégorisation des transactions, mais ils sont imprimés en caractères japonais monospaces serrés que l'OCR standard fusionne ou lit souvent de travers.
Colonnes des montants et du solde
- お支払金額 (Retrait) — le montant débité du compte. Imprimé avec des virgules alignées à droite (ex. 30,000). La lecture OCR des nombres séparés par des virgules dans des colonnes étroites est un point de défaillance connu — une virgule manquante transforme 30 000 ¥ en 3 000 ¥.
- お預り金額 (Dépôt) — le montant crédité. Une transaction unique a une entrée soit dans cette colonne, soit dans la colonne des retraits, jamais dans les deux. Cette exclusivité mutuelle est la base de la vérification du solde.
- 差引残高 (Solde) — le solde courant après la transaction. Imprimé après chaque ligne. Cette colonne permet une vérification automatique : solde précédent + dépôt − retrait doit être égal au solde actuel. Une seule erreur de lecture crée une cascade d'erreurs — le solde de chaque ligne suivante sera décalé, un problème connu sous le nom de dérive du solde (残高ずれ).
Le format physique du livret est régi par l'Association des banquiers japonais (全国銀行協会), qui établit des normes pour l'échange de données interbancaires, l'interopérabilité des ATM et la piste magnétique (磁気ストライプ) au dos qui stocke les informations du compte. L'ATM lit cette piste pour identifier le compte, puis imprime les lignes de transaction à l'aide d'une imprimante matricielle ou thermique directement sur la page du livret — ce qui signifie que le livret que vous tenez est une sortie d'imprimante, pas un document typographié. Cette distinction est importante pour l'extraction : la qualité d'impression varie selon le modèle d'ATM, l'âge du ruban encreur et la propreté de la tête d'impression. Deux livrets de la même banque, imprimés à des ATM différents à six mois d'intervalle, peuvent avoir une netteté et un alignement des caractères sensiblement différents.
Le principe fondamental d'extraction : Vous définissez cinq colonnes de sortie — « Date », « Description », « Retrait », « Dépôt », « Solde » — et l'IA localise chaque valeur sur chaque page en comprenant ce que les données représentent sémantiquement, et non en faisant correspondre des coordonnées de pixels sur un modèle. La même définition de colonne fonctionne sur les livrets de MUFG, SMBC, Mizuho, Japan Post Bank (ゆうちょ銀行) et les shinkin régionaux (信用金庫), car l'IA lit le sens des champs — une date est une date, qu'elle soit imprimée R6.7.15 sur un livret ou 2024-07-15 sur un autre.
Pourquoi transmettre le livret à une application de budgétisation ne suffit pas
Le Japon compte trois applications de finances personnelles dominantes qui couvrent ensemble la grande majorité des foyers numériquement avertis : MoneyForward ME (マネーフォワード ME, plus de 2 451 connexions à des services financiers), Zaim (plus de 1 300 connexions, 12 millions de téléchargements) et Moneytree (plus de 2 387 connexions). Toutes trois se connectent aux comptes bancaires japonais via API et importent automatiquement les données de transaction dans des rapports de dépenses catégorisés. Pour un suivi continu et prospectif des dépenses, elles fonctionnent bien — l'API bancaire leur fournit quotidiennement les nouvelles transactions, et l'utilisateur ne touche jamais à un livret papier.
La lacune concerne ce qui s'est passé avant votre inscription. Une connexion API bancaire extrait les données à partir de la date à laquelle vous l'autorisez — généralement, les 90 derniers jours à un an, selon la banque. Les transactions de 2022, 2021, 2019 — des années qui n'existent que sous forme de pages imprimées dans un livret physique — n'apparaissent pas dans l'application. Pour un travailleur indépendant déposant une déclaration bleue (青色申告) qui doit comptabiliser toutes les transactions professionnelles sur l'année civile, l'application couvre le présent mais laisse le passé sur papier. De même, pour un propriétaire de petite entreprise qui reçoit un livret physique de la banque et le partage avec un comptable fiscaliste (税理士) pour une tenue de livres mensuelle — le comptable ne se connecte pas au compte MoneyForward du propriétaire. Il travaille à partir du livret, ou de ses scans.
Les applications résolvent la visibilité des dépenses quotidiennes. Elles ne résolvent pas le moment annuel où cinq ans de transactions papier doivent devenir un seul tableur — ce qui est précisément le moment qui motive la recherche d'extraction de livret.
Il existe une troisième voie qui mérite d'être comprise : certaines banques proposent désormais des livrets numériques (デジタル通帳), éliminant complètement le livret physique au profit de vues de transactions en ligne et d'exportations CSV téléchargeables. La Association des banquiers japonais promeut les livrets numériques dans le cadre d'une digitalisation bancaire plus large. Cependant, l'adoption est inégale — les grandes banques comme MUFG et SMBC proposent des livrets numériques pour les nouveaux comptes, mais de nombreuses banques régionales et coopératives de crédit (信用金庫) délivrent encore des livrets physiques par défaut. Et même pour les comptes avec accès au livret numérique, le format d'exportation et la plage de dates diffèrent souvent de ce qu'un logiciel comptable attend. Le livret physique, malgré tous ses inconvénients, reste le format au plus petit dénominateur commun : chaque banque en imprime un, chaque transaction y apparaît, et il couvre l'intégralité de l'historique du compte.
Cette dernière propriété — la couverture de l'historique complet du compte — explique pourquoi l'extraction de livret est fondamentalement différente de l'extraction de relevé bancaire dans d'autres pays. Un relevé bancaire britannique ou un relevé mensuel américain est un résumé d'une période spécifique. Un livret japonais est un grand livre — un enregistrement continu et cumulatif de la première à la dernière page imprimée. Dans le flux de travail d'extraction qui suit, cette continuité est à la fois la plus grande force du document et la source de son mode d'erreur le plus courant.
Configuration de votre flux d'extraction de livret bancaire
Le flux de travail qui remplace la ressaisie des données de livret bancaire comporte trois étapes. La première — définir vos colonnes — est effectuée une fois et réutilisée pour chaque livret, chaque banque et chaque année fiscale.
Définissez vos cinq colonnes de sortie — une fois, pour toutes les banques
Saisissez les noms de champs exactement comme vous souhaitez les voir apparaître en en-têtes de colonnes dans votre tableur. Pour l'extraction de livret bancaire, l'ensemble standard est : Date, Description (摘要), Retrait (お支払金額), Dépôt (お預り金額), Solde (差引残高). Il s'agit de l'Extraction de colonnes personnalisées : vous définissez le schéma de sortie, et l'IA fait correspondre les champs imprimés de chaque livret à vos colonnes par leur sens sémantique. Les mêmes noms de colonnes fonctionnent avec la disposition verticale de MUFG, le format à deux lignes par transaction de SMBC et le style d'impression compact de Japan Post Bank, car l'IA lit le sens du champ, pas sa position. À des fins comptables, ajoutez une colonne Catégorie en tant que colonne calculée — par exemple, Catégorie (si Description contient "給与" alors "Revenu salarial" ; si contient "振込" et montant > 50000 alors "Revenu professionnel" ; sinon "Virement") — que l'IA évalue lors de l'extraction afin que votre sortie arrive déjà catégorisée.
Téléchargez toutes les pages du livret en un seul lot
Numérisez ou photographiez chaque page de chaque livret — y compris la couverture avant indiquant le numéro de compte et la couverture arrière avec la bande magnétique — et déposez toutes les images en un seul téléchargement. Le traitement par lots les gère comme une seule tâche : chaque page est traitée indépendamment avec votre schéma de colonnes appliqué, et tous les résultats sont fusionnés en un seul tableau unifié. Un livret sur trois ans avec environ 280 transactions sur 30 pages (typique pour un compte à activité modérée) est traité en un seul lot. Les pages peuvent être des numérisations issues d'un scanner document, des photos prises avec un smartphone ou des exportations PDF depuis la banque en ligne incluant des listes de transactions au format livret.
Exportez vers Excel et commencez votre flux comptable
Téléchargez le tableau fusionné sous forme de fichier Excel. Vous avez désormais une ligne par transaction, chaque champ dans sa propre colonne. Le tableau est immédiatement importable dans Yayoi (弥生会計), freee, MoneyForward Cloud Accounting ou tout autre logiciel de comptabilité japonais acceptant les importations CSV — la section suivante couvre ce pipeline. Plus important encore, la colonne du solde cumulé vous offre une piste d'audit intégrée : triez par date décroissante et parcourez la colonne du solde. Toute ligne où le solde n'est pas égal au solde de la ligne précédente plus le dépôt moins le retrait est signalée — l'extraction a détecté une erreur de lecture, et vous corrigez une cellule au lieu de chercher parmi 280 lignes.
Le même schéma de colonnes fonctionne l'année suivante, pour les livrets de différentes banques, et pour les comptes fermés depuis des années mais dont vous êtes tenu de conserver les relevés. Le format du livret — défini par les conventions d'impression de l'Association des banquiers japonais, et non par un choix de conception d'une banque particulière — ne changera pas.
Les fichiers sont traités de manière sécurisée et ne sont pas conservés.
Gestion des dates d'ère japonaise et des codes de description
Deux aspects des données des livrets rendent l'extraction spécifiquement plus difficile dans le contexte japonais que pour les documents bancaires de tout autre marché. Aucun des deux n'est une limitation générale de l'IA — ce sont tous deux des artefacts de la façon dont le système bancaire japonais s'est développé.
Dates d'ère japonaise (和暦)
Les dates de transaction sur les livrets sont imprimées selon le calendrier des ères impériales japonaises : 令和 (Reiwa, début en 2019), 平成 (Heisei, 1989–2019), ou 昭和 (Showa, 1926–1989), souvent abrégées en R, H ou S suivies du numéro de l'année dans cette ère. Une date comme R6.7.15 signifie le 15 juillet 2024 (Reiwa année 6). H30.3.31 signifie le 31 mars 2018 (Heisei année 30). S62.1.10 signifie le 10 janvier 1987 (Showa année 62). La conversion en calendrier grégorien (西暦) nécessite de connaître l'année de début de chaque ère — Reiwa = 2018 + n, Heisei = 1988 + n, Showa = 1925 + n — et la conversion doit gérer la limite de page où une nouvelle année commence en milieu de page. De nombreux livrets impriment le numéro de l'année d'ère une fois en haut de la page, puis seulement le mois et le jour pour les lignes suivantes. Un résultat OCR brut qui lit « 7.15 » comme une date sans contexte produit une valeur qui ne peut pas être placée dans une chronologie — l'en-tête d'année quelques millimètres au-dessus détermine s'il s'agit de juillet 2023 ou juillet 2024.
La solution est une stratégie d'extraction en deux passes. Première passe : lire l'en-tête d'année de la page et déterminer l'ère. Deuxième passe : analyser chaque date de transaction, en appliquant le contexte de l'année provenant de l'en-tête. Lorsque le mois passe de 12 à 1 à la limite de l'année, l'année d'ère augmente d'un. C'est exactement le type de raisonnement structuré que l'OCR basé sur des modèles ne peut pas effectuer — il lit des cellules individuelles, pas la relation entre un en-tête et ses lignes dépendantes — mais que l'extraction par IA gère en comprenant le document dans son ensemble plutôt que comme une grille de zones de texte isolées.
Codes de description (摘要)
La colonne de description d'un livret bancaire utilise des codes abrégés, immédiatement compréhensibles pour un lecteur japonais, mais opaques pour un analyseur de texte générique. Les entrées courantes incluent : 振込 (virement bancaire — peut être un paiement client ou un virement personnel), ATM (retrait ou dépôt au distributeur — sans indication du type), 給与 (dépôt de salaire — la ligne de revenu la plus importante pour un particulier), 利息 (paiement d'intérêts — généralement de petits montants, pertinents sur le plan fiscal), 引落 (prélèvement automatique — loyer, services publics, assurance), 手数料 (frais bancaires — généralement 110 à 550 ¥, déductibles pour les comptes professionnels), et カード (transaction par carte — peut être un paiement par carte de débit ou un règlement de carte de crédit).
Une ligne de livret indiquant « 振込 50 000 » pourrait être un paiement de freelance d'un client ou un remboursement de dîner par un ami. Le livret ne fait pas la distinction — c'est la catégorisation du logiciel comptable qui le fait. L'extraction doit capturer le code fidèlement, et la logique de catégorisation intervient en aval.
Certains livrets contiennent également des annotations manuscrites dans les marges — une note comme 家賃 (loyer) ou 仕入 (achat de stock) écrite au stylo à bille à côté d'une transaction imprimée. Ces annotations sont cruciales pour la catégorisation comptable, mais présentent un défi supplémentaire : elles sont écrites avec une qualité d'écriture manuscrite variable, dans différentes couleurs d'encre, traversant parfois les lignes de la grille imprimée. Si votre outil d'extraction prend en charge la reconnaissance d'écriture manuscrite — comme le fait l'extraction basée sur un modèle de vision — ces notes marginales deviennent partie intégrante des données extraites, plutôt qu'une étape de recherche manuelle distincte.
Transférer les données vers Yayoi, freee ou MoneyForward
Le tableur Excel extrait n'est pas la destination — c'est le pont entre votre livret bancaire et votre logiciel comptable. Le marché japonais des logiciels comptables est dominé par trois plateformes qui couvrent ensemble la grande majorité des travailleurs indépendants et des petites entreprises :
Yayoi Accounting (弥生会計). Leader du marché, notamment auprès des experts-comptables. Prend en charge l'importation CSV des données de transaction via la fonction Smart Transaction Import (スマート取引取込) : ouvrez le journal, sélectionnez l'importation, choisissez le fichier CSV et mappez les colonnes vers les champs comptables de Yayoi. Yayoi attend une date au format aaaa-mm-jj — la conversion ère-grégorien de l'étape d'extraction doit donc avoir lieu avant l'exportation, et non après.
freee Accounting (freee会計). Natif du cloud avec une intégration API solide. Importez les données de transaction du livret soit via le chemin d'importation CSV manuel (choisissez le format « ご自身で作成したCSV » et mappez les colonnes), soit via l'API bancaire pour les transactions en cours. Pour les données historiques du livret antérieures à l'accès API, l'importation CSV est la seule voie — et les règles de catégorisation automatique de freee (自動登録ルール) peuvent être configurées pour reconnaître les codes de description du livret et attribuer les intitulés de compte corrects.
MoneyForward Cloud Accounting (マネーフォワード クラウド会計). Importez via la fonction « 他社ソフトデータの移行 » (migration de données d'un autre logiciel), en sélectionnant le format compatible Yayoi comme format CSV intermédiaire. La force de MoneyForward réside dans son tableau de bord unifié qui combine les données du livret, les relevés de carte de crédit et les scans de reçus — les lignes extraites du livret deviennent partie intégrante d'une image financière complète, plutôt qu'un tableur isolé.
Les autres plateformes comptables compatibles avec ce même import CSV incluent MJS Accounting (会計大将), TKC (séries FX2/MX), OBC (勘定奉行), Sorimachi (会計王), EPSON (財務応援R4) et PCA (PCA会計). Le résultat de l'extraction — un CSV propre à cinq colonnes — fonctionne avec toutes, car le format du livret bancaire est standardisé d'une banque à l'autre. Le format de date, les colonnes de montants et le champ de description sont identiques, quel que soit le logiciel comptable qui les reçoit.
Une colonne calculée utile à ajouter avant l'import : Définissez une colonne de vérification — « Vérification du solde (solde précédent + dépôt − retrait = solde actuel ? 'OK' : 'REVIEW') » — et exécutez-la lors de l'extraction. Un seul indicateur REVIEW au milieu d'une série de OK vous indique exactement quelle ligne mérite un second regard. Sans cela, l'erreur n'apparaît qu'une fois les données dans le logiciel comptable, lorsque la balance de vérification ne correspond pas au relevé bancaire — un problème bien plus difficile à retracer.
Cette étape de vérification fait du format de livret bancaire, semblable à un grand livre, un avantage par rapport aux autres documents bancaires. Un relevé bancaire britannique ou un récapitulatif de paie australien ne contient pas de solde courant — vous devez vérifier chaque ligne par rapport à une source externe. Un livret bancaire porte sa propre vérification en lui-même. Les calculs concordent sur chaque ligne, ou l'extraction a mal interprété quelque chose. Il n'y a pas de juste milieu, et la colonne calculée révèle l'écart avant qu'il n'entre dans vos livres comptables.
Contrairement aux documents de paie d'autres pays — où la même logique d'extraction s'applique malgré des codes fiscaux différents, comme on le voit dans le flux de travail PAYG australien, le traitement du P60 britannique ou l'extraction du feuillet T4 canadien — la structure auto-vérifiante du livret bancaire signifie que le rapprochement a lieu au moment de l'extraction, et non comme une étape comptable distincte. La qualité des données est assurée avant même que le CSV ne quitte l'outil d'extraction.
Questions fréquentes
L'extraction par IA peut-elle traiter des livrets bancaires de différentes banques dans un même lot ?
Oui — et c'est l'argument le plus fort en faveur de l'extraction sémantique par rapport à l'OCR basée sur des modèles. Un livret de la MUFG imprime les transactions sur une seule ligne, avec la date à gauche. Un livret de la Japan Post Bank (ゆうちょ銀行) utilise souvent un format sur deux lignes où la description se poursuit. Un livret d'une caisse régionale de crédit (信用金庫) peut être imprimé dans une taille de police légèrement différente. Comme l'extraction sémantique lit ce que chaque valeur signifie — et non où elle se trouve — les trois formats peuvent être téléchargés dans le même lot et produiront un tableur unifié avec des colonnes cohérentes. Un outil basé sur des modèles configuré pour la mise en page de la MUFG échouera sur celle de la Japan Post Bank, et reconfiguré pour une banque, il perdra l'autre.
Que faire si le livret bancaire contient des annotations manuscrites dans les marges ?
L'extraction basée sur un modèle de vision peut lire les annotations manuscrites en même temps que le texte imprimé — ainsi une note en marge comme 家賃 (loyer) ou 仕入 (achats) écrite à côté d'une ligne de transaction est capturée comme contexte supplémentaire. Cependant, la qualité de l'écriture manuscrite varie considérablement : une annotation au stylo à bille en kanji clair est généralement lisible ; une note au crayon à papier effacée, écrite en biais et traversant les lignes de la grille imprimée, l'est moins. Pour les livrets où les notes manuscrites contiennent des informations comptables critiques, le tableur extrait doit être vérifié avec le livret physique ouvert — mais l'IA traite la majorité des annotations lisibles, réduisant la vérification à la gestion des exceptions plutôt qu'à une vérification ligne par ligne.
Comment fonctionne la conversion des dates d'ère (和暦) et que se passe-t-il si l'en-tête d'année se trouve sur une page différente ?
L'IA lit l'en-tête d'année d'ère de chaque page — généralement imprimé en haut sous la forme 令和6年 ou R6 — et l'applique à toutes les transactions de cette page. Pour les pages sans en-tête d'année (pages de continuation), l'IA reporte le contexte d'ère de la page précédente. Lorsqu'un changement d'année se produit en milieu de page (31 décembre → 1er janvier), l'année d'ère est incrémentée. Pour les livrets couvrant plusieurs ères — un livret 2018–2024 qui passe de 平成30 à 令和6 — l'IA détecte le changement d'ère à la page où l'en-tête bascule. Les données extraites utilisent les dates grégoriennes (aaaa-mm-jj) pour une compatibilité directe avec les logiciels comptables.
Puis-je extraire uniquement une plage de dates spécifique d'un livret pluriannuel ?
Oui. Vous pouvez soit ne télécharger que les pages couvrant la période souhaitée, soit télécharger l'intégralité du livret et filtrer les résultats par plage de dates dans Excel après extraction. Cette dernière option est souvent plus rapide en pratique : numérisez tout le livret en une fois, obtenez toutes les transactions dans un seul tableur, puis filtrez par date. Pour un livret de trois ans avec environ 300 transactions, tout extraire et filtrer dans Excel prend moins de temps que d'identifier et de numériser uniquement les pages d'une fenêtre de 12 mois spécifique — d'autant que les en-têtes de date ne sont pas toujours visibles lorsqu'on feuillette rapidement.
Que se passe-t-il si la vérification du solde courant échoue sur une ligne ?
Un échec de vérification du solde — où solde précédent + dépôt − retrait n'est pas égal au solde actuel — est généralement causé par l'une des trois choses suivantes : (1) une virgule mal lue dans le montant (30 000 ¥ lu comme 3 000 ¥), (2) un montant de dépôt placé par erreur dans la colonne de retrait ou vice versa (le problème classique de l'OCR 列ずれ), ou (3) une ligne de transaction sautée (l'OCR a complètement manqué une ligne). Si vous utilisez une colonne calculée pour signaler les écarts lors de l'extraction, vous pouvez corriger les lignes spécifiques avant l'importation dans votre logiciel comptable. Sans l'étape de vérification, une seule erreur de lecture sur la ligne 47 sur 300 rend tous les soldes suivants erronés — et l'erreur est invisible jusqu'à ce qu'une balance de vérification échoue, moment où vous devez remonter 253 lignes en arrière pour trouver la source.
Dois-je encore conserver le livret physique après l'extraction ?
En vertu de la Loi sur la comptabilité électronique (電子帳簿保存法) au Japon, les copies numérisées de documents financiers peuvent servir de preuves légalement recevables si elles répondent à des exigences spécifiques de résolution et d'horodatage (l'amendement de 2022 a considérablement assoupli ces exigences). Cependant, le livret physique reste l'original définitif — et l'Agence nationale des impôts (国税庁) peut demander les originaux lors d'un contrôle fiscal. Meilleure pratique pour les déclarants en « déclaration bleue » : extrayez le livret vers Excel pour votre flux de travail comptable, mais conservez le livret physique pendant la période légale de conservation de sept ans. L'extraction remplace l'étape de saisie manuelle des données — elle ne remplace pas le document légal.
Faire de la saison des impôts une routine, pas un marathon de saisie
La date limite de déclaration d'impôts au Japon — le 15 mars pour l'impôt sur le revenu des particuliers (所得税の確定申告) — ne bouge pas. Chaque année, les travailleurs indépendants, freelances et petits entrepreneurs du pays répètent le même scénario : rassembler les livrets bancaires, les étaler sur un bureau, et recopier ligne après ligne les opérations dans un tableur ou directement dans un logiciel de comptabilité. Le format à cinq colonnes du livret est d'une simplicité élégante, ce qui donne l'impression que la saisie manuelle est simple — jusqu'à la page 27, où un seul chiffre mal placé dans une virgule décimale fausse silencieusement le reste de la colonne des soldes, et l'étape de rapprochement qui devrait prendre cinq minutes en prend deux heures.
Le processus d'extraction décrit ici inverse complètement cette logique. Au lieu de passer janvier et février à ressaisir, vous consacrez un après-midi à numériser les pages du livret, quelques minutes à définir les colonnes, et le reste de la période précédant la date limite à faire ce pour quoi la déduction « déclaration bleue » (青色申告) a été conçue : analyser la performance financière de votre entreprise, plutôt que de la reconstituer à partir de papier.
Le même schéma de colonnes fonctionnera l'année prochaine. Le format du livret — défini par l'Association des banquiers japonais, imprimé par les distributeurs automatiques des banques, standardisé dans toutes les institutions financières du pays — ne changera pas. Ce qui change chaque année, c'est le volume de pages et la proximité de l'échéance du 15 mars. Supprimer l'étape de ressaisie signifie que la pression se reporte sur la vérification — et la vérification, pour un document qui porte sa propre piste d'audit mathématique dans chaque ligne, est la partie qui mérite qu'on y consacre du temps.