Saisie de données de livret bancaire japonais (通帳)
Erreurs qui ruinent votre Kakeibo

Ce qui suit sont cinq erreurs de saisie propres au livret bancaire — des erreurs qui existent parce que le livret est un livret, et non parce que la personne qui tape a fait une faute de frappe. Si vous en reconnaissez une, vous n'êtes pas négligent. Vous travaillez avec un format de document conçu pour une imprimante, pas pour un tableur.

Le piège 合計記帳 (Gōkei Kichō) : quand la ligne de consolidation bancaire crée des doublons fantômes

À quoi cela ressemble. Vous saisissez les lignes de transactions d'une page de livret. La ligne 27 indique un retrait de 48 200 ¥ avec le code description 合計記帳 (ou 未記帳分合算, selon la banque). Les lignes 28 à 31 affichent des transactions individuelles — 12 500 ¥, 8 700 ¥, 15 000 ¥, 12 000 ¥. Vous saisissez les cinq lignes. Votre solde est maintenant décalé de 48 200 ¥ — exactement le montant de la ligne 27.

Ce qui s'est réellement passé. Lorsqu'un livret n'est pas mis à jour à un distributeur automatique pendant trop longtemps, les transactions non imprimées s'accumulent. La politique de MUFG Bank déclenche 合計記帳 lorsque les écritures non imprimées dépassent un seuil à des dates spécifiques (mai et novembre de chaque année). Hiroshima Bank utilise un seuil de 48 écritures. Japan Post Bank (ゆうちょ銀行) consolide à 30 écritures non imprimées, en imprimant "合算" et un total combiné unique. La banque imprime une ligne récapitulative représentant la somme de toutes les transactions ignorées — puis imprime également les transactions individuelles. La ligne récapitulative n'est pas une transaction supplémentaire. C'est une étiquette.

Saisissez les deux, et vous avez compté deux fois le même argent : une fois en agrégat, une fois individuellement. L'arithmétique est précise — si votre écart après avoir saisi une page correspond exactement au montant de retrait ou de dépôt d'une ligne, vérifiez si cette ligne indique 合計記帳, 未記帳分合算 ou 合算.

Erreur de conversion de date d'ère : comment un décalage d'un an envoie des transactions dans la mauvaise année fiscale

À quoi cela ressemble. Vous lisez 令和6年7月15日 sur une ligne de livret bancaire. Vous le convertissez en 2025/07/15 dans votre tableur. Votre comptable vous appelle en février pour vous demander pourquoi 380 000 ¥ de revenus de décembre se retrouvent dans la mauvaise année fiscale.

Ce qui s'est réellement passé. Le système des années d'ère japonaise est arithmétique, mais l'arithmétique comporte un piège. Reiwa (令和) a commencé le 1er mai 2019. La formule de conversion est :

Reiwa 1 (令和元年) a commencé en mai 2019 — il n'y a pas de Reiwa 0. Donc Reiwa 6 = 6 − 1 + 2019 = 2024, et non 2025. L'erreur la plus courante consiste à ajouter directement l'année d'ère à 2018 (l'année précédant le début de l'ère) au lieu de tenir compte du fait que la première année d'une ère est l'année 1, et non l'année 0. Un utilisateur ajoute 6 + 2018 = 2024, ce qui est correct pour Reiwa 6 — mais applique ensuite la même logique à 令和7年 (qui devrait être 2025, et non 7 + 2018 = 2025) et obtient une réponse erronée différente pour une raison erronée différente.

La formule correcte pour chaque ère encore utilisée sur les livrets bancaires japonais :

Le problème s'aggrave lorsqu'une seule page de livret couvre une limite d'ère. Une ligne datée du 平成31年4月20日 se trouve directement au-dessus d'une ligne datée du 令和元年5月10日. Heisei 31 est Reiwa 1 — le 30 avril 2019 était le dernier jour de Heisei, le 1er mai 2019 était le premier jour de Reiwa. Si votre extraction traite les deux comme « année 1 moins une constante » de la même ère, l'une d'elles sera décalée de plusieurs années. Les livrets imprimés pendant la transition de 2019 — en particulier dans les banques régionales et à Japan Post (ゆうちょ銀行) — contiennent encore ces lignes à cheval sur les ères.

Erreur d'interprétation du code 摘要 : quand 給与 et 給与振替 racontent des histoires différentes

Ce à quoi cela ressemble. Vous voyez 給与 dans la colonne description (摘要, tekiyō) et classez l'opération comme un revenu salarial. Cette catégorie est correcte pour un kakeibo personnel, mais totalement erronée pour une comptabilité d'entreprise, où 給与振替 représente un virement interne entre comptes — pas un revenu du tout.

Ce qui s'est réellement passé. Les codes de description (摘要) des relevés bancaires japonais sont télégraphiques — des chaînes compressées de kanji et katakana qui intègrent un type de transaction, un identifiant de contrepartie et parfois un code d'agence dans un champ aussi court que 10 caractères. Un même mot racine peut signifier des choses différentes selon le suffixe et le contexte :

Passez d'une banque à une autre et le même type de transaction peut utiliser des codes totalement différents. SMBC (三井住友銀行) abrège là où MUFG (三菱UFJ銀行) écrit en toutes lettres. Mizuho (みずほ銀行) utilise des caractères pleine largeur là où Resona (りそな銀行) utilise la demi-largeur. Un outil OCR basé sur des modèles, entraîné sur des échantillons de relevés MUFG, lira mal les descriptions SMBC car il a appris des motifs de caractères qui n'existent pas sur la page SMBC.

La cascade du solde cumulé : une erreur de chiffre à la page 3, 280 lignes de dérive

À quoi ça ressemble. Vous saisissez des données de livret bancaire depuis trois heures. Le grand livre des dépenses pour 2025 semble complet — 340 lignes, chaque écriture comptabilisée, un solde qui se termine à 2 847 610 ¥. Vous ouvrez votre logiciel comptable, saisissez le solde bancaire au 31 décembre du livret réel : 2 835 940 ¥. La différence est de 11 670 ¥. Vous ne la trouvez pas.

Ce qui s'est réellement passé. C'est la vulnérabilité structurelle déterminante de la saisie de données de livret bancaire. Contrairement à un relevé bancaire britannique — où chaque page mensuelle est autonome avec son propre solde d'ouverture et de clôture — le livret japonais est une chaîne continue unique. Le solde de chaque ligne (差引残高) est calculé en ajoutant le dépôt ou en soustrayant le retrait du solde de la ligne précédente. Une seule erreur de frappe à la ligne 47 d'un livret MUFG — en tapant 98 500 ¥ au lieu de 98 500 ¥ — ne crée aucun écart visible sur cette ligne. Le solde après la ligne 47 est de 88 170 ¥ au lieu de 98 500 ¥ — un écart de 10 330 ¥ — mais en regardant une ligne isolément, 88 170 ¥ semble parfaitement plausible. Cela pourrait être le solde correct. Ce n'est qu'en arrivant à la ligne 47 + 280 lignes plus tard, lorsque le solde imprimé de la page en cours devrait correspondre au 差引残高 de votre feuille de calcul, que la dérive devient visible — et à ce moment-là, vous avez 280 écritures à revérifier.

Ce n'est pas un problème de faute de frappe. C'est un problème de vérification. Dans un système basé sur des relevés, vous vérifiez chaque mois indépendamment. Dans un livret, vous ne pouvez pas vérifier la ligne 50 sans vérifier les lignes 1 à 49 — ce qui signifie que la seule stratégie de vérification pratique est de saisir l'intégralité du livret et de comparer le solde final, auquel cas toute erreur nécessite de tout ressaisir.

Sur Zeiri4 (税理士ドットコム), un chef d'entreprise en troisième année de déclaration sur formulaire bleu (青色申告) a décrit le scénario exact : trois années de données de livret saisies, le solde jamais rapproché, l'écart désormais trop emmêlé pour être démêlé. La réponse du comptable était pragmatique : définir le solde d'ouverture de la période en cours pour correspondre au livret, passer l'écart accumulé en écriture d'ajustement, et repartir de zéro. Mais cet ajustement est de l'argent réel — 11 670 ¥, 48 000 ¥, parfois plus — qui disparaît des livres parce que la saisie des données n'a jamais été vérifiée à la source.

La correction manuscrite que personne n'a remarquée : quand le guichetier a corrigé, mais pas le tableur

À quoi ça ressemble. Vous retranscrivez une page de livret bancaire. La ligne 53 indique un retrait imprimé de 52 000 ¥. À côté, au stylo à bille, un guichetier a écrit 25 000 ¥ et apposé le cachet de correction (訂正印) de l'agence. Vous saisissez 52 000 ¥ — le chiffre imprimé. Six mois plus tard, votre solde bancaire diffère de vos comptes de 27 000 ¥.

Ce qui s'est réellement passé. Les corrections manuscrites sur les livrets magnétiques (磁気通帳) sont rares mais réelles. Lorsqu'un DAB imprime mal — un problème connu avec les anciennes têtes d'impression matricielles proches du remplacement, ou lorsque la piste magnétique (磁気ストライプ) du livret est usée et que le DAB lit la mauvaise page — un guichetier au comptoir écrit la correction à la main, appose le cachet officiel de correction de la banque et paraphe. L'écriture manuscrite fait foi. L'impression est l'erreur.

C'est l'erreur la plus difficile à détecter car elle va à l'encontre du modèle mental que les utilisateurs appliquent à la saisie de données : « lire ce qui est imprimé, taper ce qui est imprimé ». La correction est manuscrite, ce que le cerveau classe naturellement comme annotation plutôt que donnée. Et le cachet du guichetier est petit — un cercle de 10 mm à l'encre rouge, facilement négligé sur une page de texte matriciel noir.

Le risque est le plus élevé avec les anciens livrets des banques régionales (地方銀行) et des caisses de crédit mutuel (信用金庫), où les cycles de maintenance des DAB sont plus longs et les corrections par guichetier plus fréquentes. Si un livret a été mis à jour au guichet plutôt qu'au DAB — courant pendant les heures ouvrables lorsque le livret est déjà sorti pour un dépôt — le guichetier peut remarquer et corriger une erreur d'impression avant de le rendre.

Comment détecter ces erreurs avant la saison des impôts — et avant qu'elles n'atteignent le grand livre

Ces cinq erreurs partagent une cause commune : le livret a été conçu pour une imprimante qui imprime une chaîne unique et unifiée de transactions, et toute transcription manuelle brise cette chaîne à plusieurs endroits — la saisie, la vérification, la conversion d'ère, l'interprétation de la description et la gestion des corrections. La solution n'est pas d'être plus prudent. Elle consiste à confier l'extraction des données à un processus qui traite le livret pour ce qu'il est : un document structuré dont l'intégrité dépend de la lecture correcte de chaque maillon de la chaîne.

Trois mesures pratiques qui préviennent les cinq types d'erreurs :

Pour quiconque traite des données de livrets à grande échelle — trois ans de pages, plusieurs comptes bancaires, des grands livres de dépenses sur 12 mois — ces vérifications manuelles fonctionnent mais ne passent pas à l'échelle. L'alternative est une extraction qui lit la page du livret dans son ensemble : reconnaître les lignes 合計記帳 comme des lignes non-transaction, convertir les dates d'ère à l'aide de la formule correcte, classer les codes 摘要 par signification plutôt que par correspondance de caractères, et signaler les écarts de solde au moment de l'extraction plutôt qu'au moment du rapprochement. C'est la différence entre un flux de saisie manuelle qui coûte plus de 80 heures par année fiscale et une passe de vérification qui prend quelques minutes.

FAQ : Erreurs de saisie de données sur les livrets bancaires japonais

Mon solde kakeibo est décalé d'un petit montant chaque mois. S'agit-il d'une erreur de livret ou d'une erreur de suivi des dépenses ?

Si l'écart est faible et constant — disons 500 à 2 000 ¥ par mois — il s'agit probablement d'un écart de suivi des dépenses (retraits non enregistrés aux distributeurs, frais de guichet automatique ou les petits dépôts d'intérêts de 1 à 3 ¥ que les banques impriment sous le nom de 利子). Comparez d'abord le solde de votre livret saisi avec celui imprimé. S'ils correspondent, l'écart se trouve dans vos relevés de dépenses, pas dans la transcription du livret. Si vous n'avez pas saisi les minuscules lignes d'intérêts — faciles à sauter car elles ressemblent à du bruit — ces dépôts de 1 à 3 ¥ s'accumulent à 12-36 ¥ par an, pas à 6 000-24 000 ¥. L'écart plus important indique un retrait manquant.

Comment distinguer une ligne 合計記帳 d’une ligne de retrait normale ?

Trois indices visuels : (1) La colonne 摘要 indique 合計記帳, 未記帳分合算 ou 合算 — jamais un code de transaction normal comme 振込 ou 給与. (2) La ligne apparaît en début de nouvelle page ou juste après une ligne vide — jamais au milieu d’une séquence de transactions individuelles. (3) Le montant est généralement un nombre rond ou une somme égale au total des transactions individuelles suivantes. Fiez-vous à la colonne 摘要 : si elle indique 合計, il ne s’agit pas d’une transaction.

Mon livret affiche 平成31年 et 令和元年 sur la même page. Comment gérer le changement d’ère ?

Heisei 31 (平成31年) couvre du 1er janvier au 30 avril 2019. Reiwa 1 (令和元年) couvre du 1er mai au 31 décembre 2019. Les deux correspondent à l’année civile 2019 — mais le mois détermine le nom de l’ère affiché. Une ligne datée du 平成31年4月20日 = 2019/04/20. Une ligne datée du 令和元年5月10日 = 2019/05/10. Même année civile, étiquettes d’ère différentes. Si votre livret affiche les deux sur une même page, traitez-les comme la même année mais utilisez le mois comme critère de tri. C’est le plus fréquent sur les livrets imprimés mi-2019 qui couvrent la transition — notamment à la Japan Post Bank, où les livrets magnétiques (磁気通帳) imprimaient des pages pré-transition avec des mises à jour post-transition.

Différentes banques utilisent-elles des codes 摘要 différents pour le même type de transaction ?

Oui. Il n’existe pas de norme sectorielle pour les codes de description des livrets. Le code de MUFG pour un virement bancaire national peut différer de celui de Resona. Les banques régionales (地方銀行) et les shinkin banks (信用金庫) ont souvent leurs propres codes abrégés que même les comptables expérimentés doivent interpréter à l’aide d’une fiche de référence. C’est pourquoi l’approche d’extraction est importante : l’interprétation sémantique du champ 摘要 — « s’agit-il d’un dépôt de salaire, d’un virement ou d’un retrait au DAB ? » — est plus précieuse que la chaîne de caractères brute. Si votre logiciel de comptabilité prend en charge l’import CSV avec mappage de catégories, il est préférable de faire correspondre le type de transaction extrait au code de compte approprié plutôt que de faire correspondre le texte brut du 摘要 à une liste fixe de codes.

Comment vérifier si une correction manuscrite sur mon livret bancaire est légitime ?

Une correction légitime d'un guichetier bancaire comporte toujours un sceau de correction rouge (訂正印) — généralement un petit tampon circulaire contenant le nom de la banque ou le code de l'agence. Le montant manuscrit sera écrit clairement, souvent au stylo à bille bleu ou noir, contrastant avec le gris foncé de l'impression matricielle. S'il n'y a pas de tampon, ou si l'écriture ressemble à une note personnelle plutôt qu'à une correction officielle, considérez le montant imprimé comme faisant autorité et signalez la ligne pour un examen manuel. En cas de doute, l'agence bancaire qui a effectué la correction peut la vérifier — mais cela nécessite une visite physique avec le livret, ce que peu de gens font pour une seule ligne.

Puis-je importer directement les données corrigées du livret dans Yayoi ou freee ?

Oui. Yayoi (弥生) et freee prennent tous deux en charge l'importation CSV pour les données de transactions. La clé est d'obtenir les données dans un format où chaque ligne a la date correcte (calendrier occidental), le montant, le type de transaction et — surtout — un solde cumulé vérifié. La plupart des échecs d'importation CSV dans les logiciels de comptabilité japonais surviennent parce que le solde importé ne correspond pas au solde d'ouverture attendu. Si le solde de départ de vos données extraites correspond au 差引残高 imprimé sur le livret pour cette date, l'importation réussira. L'approche de saisie manuelle — taper chaque ligne en espérant que le solde fonctionne — est ce qui crée l'inadéquation d'importation en premier lieu.

L'erreur que vous ne voyez pas est celle qui vous coûte cher

Le problème de la saisie des données du livret bancaire n'est pas que cinq erreurs spécifiques existent. C'est que les erreurs sont invisibles sur le moment. Contrairement à un reçu où un montant erroné est immédiatement évident car le total ne correspond pas, une erreur de saisie dans un livret produit un solde qui semble correct — 88 170 ¥ se lit aussi plausiblement que 98 500 ¥ — et l'erreur n'apparaît que plus tard, lors d'un rapprochement que la plupart des gens font une fois par an, s'ils le font.

C'est pourquoi les mêmes erreurs de saisie de données au Royaume-Uni se manifestent différemment du cas du livret japonais. Les erreurs de paie P60 et les erreurs d'auto-évaluation SA100 sont détectées par le recoupement du HMRC — l'administration fiscale compare votre déclaration aux déclarations de l'employeur et signale l'écart. Le livret japonais n'a pas de recoupement externe. La seule autorité qui connaît votre solde correct est la banque, et la banque l'a imprimé sur la page du livret que vous transcrivez. La boucle de vérification est autonome : le document source est sa propre référence.

Cette boucle autonome est ce qui rend l'extraction de livret différente de tout autre type de document. Les données sont là, imprimées clairement, sur un document conçu pour une lecture automatique par un DAB. Les erreurs se produisent dans l'écart entre la page imprimée et le tableur — et cet écart est ce que l'extraction élimine.