Erreurs de saisie de livret japonais
qui compromettent votre Kakeibo

Ce qui suit concerne cinq erreurs de saisie de données spécifiques aux livrets bancaires. Elles existent à cause du format, pas parce que la personne qui saisit a fait une faute de frappe. Si vous en reconnaissez une, vous n'êtes pas négligent. Vous travaillez avec un document conçu pour une imprimante, pas pour un tableur.

Le piège de l'écriture de consolidation (合計記帳) : quand une ligne de synthèse bancaire crée des doublons fantômes

À quoi cela ressemble. Vous saisissez les lignes de transactions d'une page de livret. La ligne 27 affiche un retrait de ¥48 200 avec le code de description Écriture de consolidation, ou Total des transactions non enregistrées (未記帳分合算) 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 reste trop longtemps sans être mis à jour à un distributeur automatique, des transactions non imprimées s'accumulent. La politique de la MUFG Bank déclenche une écriture de consolidation lorsque les écritures non imprimées dépassent un seuil à des dates précises (mai et novembre de chaque année). La Hiroshima Bank utilise un seuil de 48 écritures. La Japan Post Bank (ゆうちょ銀行) consolide à 30 écritures non imprimées, en imprimant « total consolidé » (合算) et un total combiné unique. La banque imprime une ligne de synthèse représentant la somme de toutes les transactions ignorées, puis imprime également les transactions individuelles. La ligne de synthèse n'est pas une transaction supplémentaire. C'est une étiquette.

Saisissez les deux, et vous avez compté le même argent deux fois : une fois en agrégat, une fois individuellement. L'arithmétique est précise. Si votre écart après la saisie d'une page correspond exactement au montant d'un retrait ou d'un dépôt d'une seule ligne, vérifiez si cette ligne est une écriture de consolidation, un total de transactions non enregistrées ou un total consolidé.

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 une date d'ère écrite Reiwa 6, 15 juillet (令和6年7月15日) sur une ligne de livret bancaire. Vous la convertissez en 2025/07/15 dans votre feuille de calcul. Votre comptable vous appelle en février et vous demande 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 d'années d'ère japonais 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'existe pas de Reiwa 0. Donc Reiwa 6 = 6 − 1 + 2019 = 2024, et non 2025. L'erreur la plus courante consiste à ajouter l'année d'ère à l'année où l'ère a commencé plutôt qu'à l'année précédente (2018), ce qui décale le résultat d'un an. La même erreur déplace chaque date ultérieure : Reiwa 7 (令和7年) atterrit en 2026 dans votre feuille de calcul alors qu'elle devrait être en 2025.

La formule correcte pour chaque ère en usage actif sur les livrets bancaires japonais :

Le problème s'aggrave lorsqu'une seule page de livret couvre une frontière d'ère. Une ligne datée Heisei 31 (平成31年4月20日) se trouve directement au-dessus d'une ligne datée Reiwa 1 (令和元年5月10日). Heisei 31 est Reiwa 1 : le 30 avril 2019 était le dernier jour de Heisei, et 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 de frontière d'ère.

Mauvaise interprétation du code de description (摘要) : quand le salaire et le virement de salaire racontent des histoires différentes

À quoi cela ressemble. Vous voyez Salaire (給与) dans la colonne du code de description et vous le classez comme revenu salarial. La catégorie est correcte pour un kakeibo personnel, mais totalement erronée pour une comptabilité d'entreprise où Virement de salaire (給与振替) représente un transfert interne entre comptes, et non un revenu.

Ce qui s'est réellement passé. Les codes de description des livrets bancaires japonais sont télégraphiques : des chaînes compressées de kanji et de katakana qui regroupent un type de transaction, un identifiant de contrepartie et parfois un code d'agence dans un seul champ d'à peine 10 caractères. Le même mot racine peut signifier des choses différentes selon le suffixe et le contexte :

Changez de banque et le même type de transaction peut utiliser des codes entièrement différents. SMBC (三井住友銀行) abrège là où MUFG (三菱UFJ銀行) écrit en toutes lettres. Mizuho (みずほ銀行) utilise des caractères pleine largeur là où Resona (りそな銀行) utilise des caractères demi-largeur. Un outil OCR basé sur des modèles entraîné sur des échantillons de livrets 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 courant : un chiffre erroné à la page 3, 280 lignes de dérive

À quoi cela ressemble. Vous saisissez les données du livret depuis trois heures. Le registre des dépenses pour 2025 semble complet : 340 lignes, chaque écriture comptabilisée, un solde final de ¥2 847 610. Vous ouvrez votre logiciel comptable, saisissez le solde bancaire du 31 décembre à partir du livret réel : ¥2 835 940. La différence est de ¥11 670. Vous ne le 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. 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, le solde courant (差引残高), est calculé en ajoutant le dépôt ou en soustrayant le retrait du solde de la ligne précédente. Un seul chiffre mal saisi à la ligne 47 d'un livret MUFG (¥88 170 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, soit un écart de ¥10 330, mais en regardant une ligne isolément, ¥88 170 semble parfaitement plausible. Cela pourrait être le bon solde. Ce n'est que 280 lignes plus tard, lorsque le solde imprimé de la page courante devrait correspondre au solde courant de votre feuille de calcul, que la dérive devient visible, et à ce moment-là, vous avez 280 écritures à revérifier.

La partie difficile est la vérification, pas la saisie. 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 consiste à saisir l'intégralité du livret et à comparer le solde final, moment auquel toute erreur nécessite de tout ressaisir.

Sur Zeiri4 (税理士ドットコム), un propriétaire d'entreprise en troisième année de déclaration en 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 courante pour correspondre au livret, passer l'écart accumulé en 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 l'a corrigée mais pas la feuille de calcul

À quoi cela ressemble. Vous transcrivez une page de livret. La ligne 53 affiche un retrait imprimé de ¥52,000. À côté, au stylo à bille, un guichetier de banque a écrit ¥25,000 et l'a tamponné avec le sceau de correction de l'agence (訂正印). Vous saisissez ¥52,000, le nombre imprimé. Six mois plus tard, votre solde bancaire diffère de vos livres de ¥27,000.

Ce qui s'est réellement passé. Les corrections de guichetier sur les livrets magnétiques (磁気通帳) sont rares mais réelles. Lorsqu'un distributeur automatique imprime mal (un problème connu avec les anciennes têtes d'impression matricielles proches du remplacement, ou avec une piste magnétique usée (磁気ストライプ) qui fait lire la mauvaise page au distributeur), un guichetier au comptoir écrit la correction à la main, la tamponne avec le sceau de correction officiel de la banque et y appose ses initiales. L'entrée manuscrite fait autorité. L'entrée imprimée est l'erreur.

C'est l'erreur la plus difficile à détecter car elle va à l'encontre du modèle mental que les utilisateurs apportent à la saisie de données : « lire ce qui est imprimé, saisir ce qui est imprimé ». La correction est manuscrite, ce que le cerveau classe naturellement comme annotation plutôt que comme donnée. Et le tampon 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 shinkin banks (信用金庫), où les cycles de maintenance des distributeurs sont plus longs et les corrections de guichetier plus fréquentes. Si un livret est mis à jour au guichet plutôt qu'au distributeur (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 racine : le livret a été conçu pour une imprimante qui imprime une chaîne unifiée de transactions, et toute transcription manuelle brise cette chaîne à plusieurs points : la saisie, la vérification, la conversion d'ère, l'interprétation des descriptions 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 comme un document structuré dont l'intégrité dépend de la lecture correcte de chaque maillon de la chaîne.

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

Pour quiconque traite des données de livret à 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 d'écritures de consolidation comme des lignes non transactionnelles, convertir les dates d'ère à l'aide de la formule correcte, classer les codes de description par leur signification plutôt que par correspondance de caractères, et tracer chaque valeur extraite jusqu'à la ligne dont elle provient. Dans l'écran de révision, survolez une cellule du tableau de résultats et la ligne correspondante sur la page du livret se surligne, de sorte qu'une valeur qui ne correspond pas à sa source est visible pendant l'extraction au lieu d'après l'échec du rapprochement du solde. Activez l'auto-annotation et ce mappage est généré dès que le traitement se termine. 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. Est-ce une erreur de livret ou 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'une lacune de suivi des dépenses : retraits non enregistrés au konbini, frais de guichet automatique, ou les petits paiements d'intérêts de ¥1 à ¥3 (利子) que les banques impriment. Comparez d'abord le solde saisi de votre livret avec le solde imprimé. S'ils correspondent, l'écart vient de vos relevés de dépenses, pas de la transcription du livret. Si vous n'avez pas saisi les petites lignes d'intérêts — faciles à ignorer car elles ressemblent à du bruit — ces dépôts de ¥1 à ¥3 totalisent ¥12 à ¥36 par an, pas ¥6,000 à ¥24,000. Un écart plus important indique un retrait manquant.

Comment distinguer une ligne de consolidation (合計記帳) d'une ligne de retrait normale ?

Trois indices visuels : (1) Le code de description indique une écriture de consolidation, un total de transactions non comptabilisées ou un total consolidé, jamais un code de transaction normal comme un virement entrant (振込) ou un salaire (給与). (2) La ligne apparaît au début d'une nouvelle page ou immédiatement 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 qui correspond au total des plusieurs transactions individuelles suivantes. Fiez-vous au code de description : une ligne indiquant Total (合計) n'est pas une transaction.

Mon livret comporte Heisei 31 et Reiwa 1 sur la même page. Comment gérer le chevauchement d'ères ?

Heisei 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 Heisei 31, 20 avril (平成31年4月20日) se convertit en 2019/04/20, et une ligne datée Reiwa 1, 10 mai (令和元年5月10日) se convertit en 2019/05/10. Même année civile, étiquettes d'ère différentes. Si votre livret comporte les deux sur une même page, traitez-les comme la même année mais utilisez le mois comme critère de tri. Cela est le plus courant sur les livrets imprimés à la mi-2019 qui couvrent la transition, en particulier à Japan Post Bank, où les livrets magnétiques (磁気通帳) imprimés avant la transition comportaient des pages pré-transition à côté de mises à jour post-transition.

Les différentes banques utilisent-elles des codes de description 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 consulter une feuille de référence pour interpréter. C'est pourquoi l'approche d'extraction est importante : l'interprétation sémantique du code de description (s'agit-il d'un dépôt de salaire, d'un virement ou d'un retrait au guichet automatique ?) est plus précieuse que la chaîne de caractères brute. Si votre logiciel de comptabilité prend en charge l'importation CSV avec mappage de catégories, faire correspondre le type de transaction extrait au bon code de compte est préférable à faire correspondre le texte de description brut à une liste fixe de codes.

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

Une correction légitime d'un guichetier 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 est é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 sceau, 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 contrôle manuel. En cas de doute, l'agence bancaire ayant 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 des données où chaque ligne comporte la date correcte (calendrier occidental), le montant, le type de transaction et, surtout, un solde courant vérifié. La plupart des échecs d'importation CSV dans les logiciels comptables 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 solde courant imprimé du livret (差引残高) pour cette date, l'importation réussira. L'approche de saisie manuelle (saisir chaque ligne en espérant que le solde s'équilibre) est ce qui crée l'écart d'importation en premier lieu.

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

Cinq types d'erreurs ne sont pas le vrai problème. 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 ne se révèle que plus tard, lors d'un rapprochement que la plupart des gens font une fois par an, s'ils le font du tout.

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 aucune référence croisée 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.

C'est cette boucle autonome 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 la lecture machine par un distributeur automatique. Les erreurs se produisent dans l'écart entre la page imprimée et la feuille de calcul, et c'est cet écart que l'extraction élimine.