Extraction de livret bancaire japonais (通帳) :
Guide complet pour la comptabilité et la déclaration fiscale
Le système de livret bancaire japonais est unique parmi les économies développées : un carnet physique imprimé en temps réel par les DAB à l'aide de têtes d'impression matricielle ou thermique, contenant chaque transaction sous forme de grand livre à cinq colonnes avec un solde courant — et, pour les 4,6 millions de travailleurs indépendants et de petites entreprises qui l'utilisent comme document financier principal, la source définitive pour la déclaration fiscale. En 2024, l'Association japonaise des banquiers (全国銀行協会) a indiqué que les DAB des grandes banques traitent encore plus de 300 millions de mises à jour de livrets par an — même si l'adoption de la banque numérique augmente. Pour le problème de l'extraction, ce volume signifie une chose précise : le livret n'est pas un format ancien en voie de disparition. C'est le format auquel le flux de travail comptable doit s'adapter, et comprendre sa structure est le prérequis pour automatiser la saisie de données qui, actuellement, consomme des heures de transcription manuelle à chaque saison fiscale.
Points clés à retenir
- Un livret japonais n'est pas un relevé bancaire — c'est un grand livre courant où un seul chiffre mal lu sur la ligne 47 corrompt tous les soldes suivants sur les 153 lignes qui suivent.
- La réforme fiscale de 2027 réduit la déduction pour déclaration bleue sur papier de 550 000 ¥ à 100 000 ¥ — une pénalité de 450 000 ¥ pour avoir continué la même transcription manuelle de livret que vous avez toujours faite.
- Le même schéma d'extraction à cinq colonnes lit les livrets de MUFG, de la Banque postale du Japon et des coopératives de crédit régionales en un seul lot — car l'IA lit ce que chaque valeur signifie plutôt que l'endroit où elle se trouve sur la page.
Ce qui fait du livret bancaire japonais une cible d'extraction unique
Dans la plupart des pays, un relevé bancaire est un résumé mensuel — un PDF ou un rapport papier couvrant une période définie, avec un solde d'ouverture, un solde de clôture et les transactions intermédiaires. Chaque relevé est autonome. Une erreur de lecture sur le relevé de mars n'affecte pas celui d'avril.
Un livret bancaire japonais (通帳, tsūchō) n'est pas un relevé. C'est un grand livre continu imprimé par un distributeur automatique — un registre physique permanent que l'on met à jour en insérant le livret dans une machine qui imprime de nouvelles lignes de transaction directement sur la page à l'aide d'une tête d'impression matricielle ou thermique. Chaque ligne comporte cinq champs : date (月日), description (摘要, tekiyō), montant du retrait (お支払金額), montant du dépôt (お預り金額) et solde reporté (差引残高). Chaque nouvelle ligne prolonge la chaîne. Le solde de la ligne 47 dépend de l'exactitude des lignes 1 à 46. Une seule erreur de lecture corrompt tous les soldes suivants — un mode de défaillance appelé dérive du solde (残高ずれ) qui n'a pas d'équivalent dans les systèmes bancaires basés sur des relevés.
Ce mécanisme d'impression crée un problème d'extraction de second ordre que la plupart des outils OCR génériques n'ont jamais été conçus pour gérer. Les pages de livret ne sont pas des documents typographiés avec une densité d'encre et un alignement constants. Ce sont des sorties d'imprimante — et la qualité d'impression varie selon le modèle de distributeur, l'âge du ruban encreur et la propreté de la tête d'impression. Deux livrets de la même banque, mis à jour à des distributeurs différents à six mois d'intervalle, peuvent présenter des différences notables de noirceur des caractères, d'alignement et de lisibilité. Une tête d'impression matricielle en fin de cycle produit des caractères plus fins avec plus d'espaces entre les points — le même code 振込 (virement) qu'un distributeur propre imprime en traits nets et continus devient une constellation de points déconnectés sur une tête usée.
Le format du livret est régi par l'Association japonaise des banquiers (全国銀行協会), qui établit des normes pour l'échange de données interbancaires, l'interopérabilité des distributeurs et la bande magnétique (磁気ストライプ) au dos qui stocke les informations du compte. Le distributeur lit cette bande pour identifier le compte, puis imprime les lignes de transaction — ce qui signifie que le livret que vous tenez est une sortie d'imprimante, pas un document conçu. Le format est suffisamment standardisé pour que la disposition à cinq colonnes soit cohérente dans toutes les banques du Japon. La qualité d'impression, elle, ne l'est pas. Cette tension — format standard, exécution variable — définit le défi de l'extraction.
La différence structurelle qui compte pour l'extraction : une déclaration de revenus SA100 britannique ou un relevé BAS australien est un instantané — extrayez-le une fois, vérifiez-le par rapport à une source externe, terminé. Un livret japonais est une chaîne — l'extraction est une opération de continuité où l'exactitude de chaque ligne dépend de toutes les lignes précédentes. Le traiter comme un document basé sur un relevé et traiter les pages indépendamment est la source la plus courante d'échec d'extraction dans les workflows comptables japonais.
Le paysage bancaire japonais et son impact sur l'extraction des livrets
Le Japon compte plus de 100 banques émettant des livrets physiques, et bien que la disposition à cinq colonnes soit standard, les détails de formatage — taille de police, interlignage, présence ou absence d'une colonne agence (取抜店), et le fait qu'une transaction occupe une seule ligne ou s'étende sur deux — varient selon l'établissement. Comprendre quelle banque a émis un livret n'est pas une question théorique. Cela détermine les défis d'extraction à anticiper.
| Banque | Style de livret | Considérations d'extraction | Rôle sur le marché |
|---|---|---|---|
| MUFG Bank (三菱UFJ銀行) | Saisie sur une ligne, date à gauche, colonne du code agence (取抜店) incluse. Mise en page moderne et claire. | Le plus simple à extraire — alignement matriciel cohérent, en-tête d'ère clairement imprimé en haut de page. La colonne du code agence est une donnée supplémentaire à extraire ou ignorer selon les besoins comptables. | La plus grande banque du Japon — 7,93 % des entreprises en font leur banque principale (selon Tokyo Shoko Research). |
| SMBC (三井住友銀行) | Format similaire sur une ligne à MUFG. Peut abréger l'année d'ère (R6 vs 令和6年). | Les années d'ère abrégées nécessitent une attention particulière au mappage des abréviations lors de la conversion des dates. Sinon, difficulté comparable à MUFG. | 6,34 % de part de banque principale. Solide base d'entreprises. |
| Mizuho Bank (みずほ銀行) | Similaire à MUFG/SMBC. Format d'impression traditionnel ; les années d'ère sont souvent en caractères pleine largeur. | Les caractères d'année d'ère en pleine largeur peuvent être lus comme des caractères séparés par l'OCR au niveau des caractères. L'extraction sémantique par IA évite ce problème en lisant le champ de date dans son ensemble. | 5,04 % de part de banque principale. La plus traditionnelle des trois mégabanques. |
| Japan Post Bank (ゆうちょ銀行) | Format à deux lignes par transaction — le champ de description passe à une deuxième ligne. Impression compacte. Le code agence est affiché uniquement sous forme de chiffres. | Le format standard le plus difficile — le passage à la ligne sur deux lignes signifie qu'un OCR basé sur un modèle entraîné sur des formats à une ligne manquera les détails de la description. L'extraction sémantique gère cela en lisant les deux lignes comme une seule unité sémantique. Propose également un « livret numérique » (デジタル通帳) pour les titulaires de compte Yucho Direct+. | Réseau national — plus de 24 000 DAB. Banque par défaut pour de nombreux comptes personnels. |
| Resona Bank (りそな銀行) | Format sur une ligne. Forte orientation vers les PME et les clients particuliers ; les livrets incluent souvent des messages de service bancaire supplémentaires après les lignes de transaction. | Les messages de service supplémentaires imprimés entre les lots de transactions peuvent être interprétés à tort comme des lignes de données par les outils qui ne distinguent pas les lignes de transaction du texte informatif. | Membre du groupe Resona — solide base de PME. Orientation bancaire régionale. |
| Banques régionales & coopératives de crédit (地方銀行・信用金庫) | Varié — la plupart suivent la disposition standard à cinq colonnes, mais avec des conventions d'impression localisées, du matériel ATM plus ancien et des formats de date d'ère ancienne (y compris les dates de l'ère Shōwa pour les comptes de longue durée). | Le matériel ATM plus ancien entraîne une plus grande variance de la qualité d'impression. Les livrets ouverts dans les années 1980 peuvent contenir des dates de l'ère Shōwa (昭和) nécessitant une conversion Shōwa + 1925. Cette grande variance est l'argument le plus fort en faveur de l'extraction sémantique — il est impossible de créer un modèle pour plus de 100 conventions d'impression régionales. | Collectivement, elles desservent une plus grande part de PME que les trois mégabanques réunies. |
L'implication pratique pour l'extraction est qu'un schéma à colonne unique — Date, Description (摘要), Retrait, Dépôt, Solde — fonctionne pour toutes ces banques. L'IA localise chaque valeur en lisant ce qu'elle signifie, et non en faisant correspondre les coordonnées de pixels d'un modèle. Un livret de MUFG avec une impression propre sur une seule ligne et un livret Yucho avec un retour à la ligne sur deux lignes produisent le même tableur à cinq colonnes dans le même lot, car le moteur d'extraction lit la sémantique des champs, et non leurs positions. Pour une présentation détaillée de cette approche par colonnes, consultez le guide étape par étape de l'extraction des livrets japonais.
L'architecture à cinq colonnes du livret — et pourquoi l'OCR générique échoue sur chacune
La disposition à cinq colonnes du livret est d'une simplicité élégante en surface et structurellement hostile à l'OCR conventionnelle en profondeur. Chaque colonne présente un mode de défaillance distinct :
月日 (Date) — le problème du calendrier 和暦 (Wareki)
Les dates des livrets utilisent le calendrier impérial japonais : 令和 (Reiwa, depuis mai 2019), 平成 (Heisei, 1989–2019), 昭和 (Showa, 1926–1989). Une date imprimée R6.7.15 correspond au 15 juillet 2024 (année Reiwa 6 + 2018). H30.3.31 correspond au 31 mars 2018 (année Heisei 30 + 1988). L'en-tête de l'année de l'ère n'est imprimé qu'une fois en haut d'une page — les lignes suivantes sur la même page et les pages suivantes n'indiquent que le mois et le jour. Un outil OCR générique qui lit « 7.15 » de manière isolée obtient une date sans année, avec un en-tête d'année situé trois pages en arrière qu'il n'a jamais vu. La formule de conversion est déterministe — Reiwa n = n + 2018, Heisei n = n + 1988, Showa n = n + 1925 — mais identifier quelle formule appliquer à quelle ligne nécessite de lire la relation entre l'en-tête de page et ses lignes de contenu, et non de lire des cellules individuelles.
摘要 (Description) — le fossé de classification des codes
La colonne de description utilise des codes compacts qu'un lecteur japonais catégorise immédiatement : 振込 (virement bancaire), ATM (transaction ATM), 給与 (dépôt de salaire), 引落 (prélèvement automatique), 手数料 (frais bancaires, généralement ¥110–¥550), 利息 (intérêts), カード (transaction par carte). Une extraction brute qui reproduit fidèlement ces codes produit une liste de transactions. Une extraction qui les classifie pendant le traitement produit un grand livre pré-catégorisé. La logique de classification peut être définie une fois comme une colonne calculée : if Description contains "給与" then "Salary Income"; if contains "引落" then "Direct Debit"; if contains "手数料" then "Bank Fee"; if contains "利息" then "Interest Income". Le code le plus ambigu est 振込 — un virement de ¥500 000 d'une entreprise cliente connue est un revenu professionnel ; un virement de ¥15 000 d'un particulier est probablement personnel. Une colonne calculée peut combiner la description avec le montant pour lever l'ambiguïté : if Description="振込" and Amount > 100000 then "Business Income"; else "Personal Transfer".
お支払金額 / お預り金額 (Retrait / Dépôt) — le piège de l'exclusion mutuelle
Une transaction donnée a une entrée soit dans la colonne des retraits, soit dans celle des dépôts — jamais les deux. Cette exclusivité mutuelle est la base structurelle de la vérification du solde, mais elle crée aussi une défaillance OCR courante : un dépôt de ¥30 000 placé dans la colonne des retraits par une lecture mal alignée. Le calcul du solde échouera sur cette ligne, et toutes les lignes suivantes échoueront également, car solde précédent + 0 (aucun dépôt lu) − ¥30 000 (mauvaise colonne) ne peut pas égaler le solde courant imprimé. Ce n'est pas une erreur aléatoire — c'est une erreur structurée, caractéristique des formats basés sur des colonnes avec une logique d'exclusion mutuelle, et l'OCR basé sur un modèle qui lit les cellules par position y est particulièrement vulnérable.
差引残高 (Solde reporté) — le moteur d'auto-vérification
Le solde reporté est à la fois le plus grand avantage de l'extraction d'un livret et son mode de défaillance le plus dangereux. C'est un avantage car la colonne du solde porte sa propre vérification en elle-même : solde précédent + dépôt − retrait doit être égal au solde actuel. Définissez une colonne calculée qui vérifie cela sur chaque ligne lors de l'extraction — Vérification solde (solde précédent + Dépôt − Retrait = solde actuel ? 'OK' : 'À VÉRIFIER') — et vous saurez quelles lignes examiner avant que les données n'entrent dans votre logiciel comptable. C'est dangereux car une seule erreur de lecture — une virgule manquante transformant 30 000 ¥ en 3 000 ¥ — corrompt le solde de cette ligne, ce qui corrompt la vérification de la ligne suivante, et de toutes les lignes suivantes. Un livret de 280 transactions avec une erreur de lecture à la ligne 47 produit 233 indicateurs « À VÉRIFIER » — mais la cause racine est la première ligne signalée. Corrigez la ligne 47, et les lignes 48 à 280 se recalculeront correctement. Cet effet de cascade est le sujet du guide des erreurs courantes de saisie de livret, qui couvre en détail la prévention de la dérive du solde.
Bande magnétique (磁気ストライプ) — la dépendance matérielle
La bande magnétique au dos de la couverture stocke le numéro de compte, le code de l'agence et le type de compte. Lorsqu'un livret est inséré dans un distributeur, la machine lit la bande, identifie le compte, récupère les transactions non imprimées et les imprime. La bande est un composant lu par la machine — les détails du compte qu'elle contient ne sont pas imprimés sous forme de texte sur la page du livret elle-même (la couverture avant indique généralement le nom du titulaire du compte en katakana, pas le numéro de compte). Pour l'extraction, le numéro de compte et les informations de l'agence sont des données qui doivent provenir soit de la carte de retrait (キャッシュカード), des informations de la couverture avant (si présentes), soit d'une saisie manuelle — les pages du livret elles-mêmes ne portent pas ces données sous une forme imprimée lisible par machine. Une bande magnétique endommagée sur un vieux livret signifie que le distributeur ne peut pas la lire pour les mises à jour d'impression, mais cela n'empêche pas l'extraction des pages imprimées existantes — les données de transaction imprimées sont indépendantes de la bande.
Le flux d'extraction : du livret papier au tableur prêt pour la comptabilité
L'extraction des données d'un livret bancaire japonais suit une architecture en trois étapes, identique que vous traitiez un livret ou dix, une année ou cinq. La phase de configuration est effectuée une fois et réutilisée indéfiniment. La phase de traitement est celle où le moteur d'extraction opère. La phase de vérification vous permet de confirmer que le résultat est correct — et la colonne de solde auto-vérifiante du livret rend cette étape infiniment plus rapide qu'un rapprochement manuel.
Définition du schéma de sortie. Vous spécifiez cinq noms de colonnes — Date, Description (摘要), Retrait (お支払金額), Dépôt (お預り金額), Solde (差引残高) — et vous pouvez ajouter des colonnes calculées pour la pré-classification et la vérification. Il s'agit de l'Extraction de colonnes personnalisées : vous définissez la sortie, et l'IA fait correspondre les champs imprimés de chaque livret à vos colonnes en lisant la signification de chaque valeur. Le même schéma de colonnes fonctionne pour toutes les banques — MUFG, SMBC, Mizuho, Banque postale du Japon, coopératives de crédit régionales — car l'IA lit la sémantique des champs, et non leurs coordonnées en pixels. Un modèle configuré pour la disposition sur une seule ligne de MUFG échouerait sur la disposition sur deux lignes de la Banque postale du Japon ; un schéma sémantique gère les deux formats dans le même lot car il lit la signification de chaque champ, et non sa position.
Téléchargement et traitement. Numérisez ou photographiez les pages du livret — y compris la couverture avant indiquant le nom du titulaire du compte, la couverture arrière pour référence, et chaque page de transactions — et téléchargez toutes les images en un seul lot. Chaque page est traitée indépendamment avec le même schéma de colonnes. Les dates en ère (和暦) sont converties en dates grégoriennes (aaaa-mm-jj) au niveau de la sortie, en appliquant le contexte d'ère correct par page. Les codes de description sont capturés tels quels et éventuellement classés en catégories de dépenses via les colonnes calculées. Le solde courant de chaque ligne est vérifié par rapport au solde de la ligne précédente pendant l'extraction, signalant les écarts.
Exportation et vérification. Le résultat est un fichier Excel avec une ligne par transaction et chaque champ dans sa propre colonne. La colonne de vérification du solde indique OK sur chaque ligne où le calcul est correct, et REVIEW sur les lignes présentant des écarts. Un livret de trois ans avec environ 280 transactions génère généralement un ou deux drapeaux REVIEW — virgules mal lues, chiffres maculés sur des pages vieillissantes, ou une correction manuscrite ayant perturbé le lecteur d'impression. Corrigez ces lignes, et les 278 restantes sont vérifiées. Le tableur s'importe directement dans tout logiciel de comptabilité japonais acceptant les données de transaction au format CSV.
Les fichiers sont traités de manière sécurisée et ne sont pas conservés.
Pour une démonstration pratique de ce flux de travail — incluant la configuration des colonnes, les stratégies de numérisation des pages et la gestion des erreurs courantes — le guide d'extraction d'un livret unique couvre chaque étape en détail. Pour la stratégie de traitement par lots qui gère plusieurs livrets sur plusieurs années, le guide de traitement par lots aborde la fusion multi-livrets, le report des dates d'ère entre les pages et la vérification du solde à l'échelle du lot. Pour une analyse des raisons pour lesquelles la saisie manuelle persiste malgré les outils numériques disponibles, consultez l'analyse approfondie du problème de la saisie manuelle des livrets japonais.
Traitement par lots : quand un livret devient une décennie de données
Un livret unique contient environ 8 à 10 transactions par page et 50 à 100 pages, ce qui lui confère une durée de vie utile typique d'un à trois ans selon l'activité du compte. Un entrepreneur individuel déposant une déclaration bleue (青色申告) qui tient des livrets séparés pour les opérations courantes (MUFG), les réserves fiscales (Banque postale du Japon) et la paie (coopérative de crédit régionale) doit extraire trois livrets — environ 36 pages de transactions imprimées, 280 lignes, selon trois conventions d'impression.
L'extraction par lots traite ceci comme une opération unique. Les trois livrets sont chargés en une seule fois avec le même schéma de cinq colonnes. Les dates d'ère sont converties par page avec le contexte d'ère correct — le livret MUFG utilisant des années d'ère abrégées (R6), le livret de la Banque postale du Japon utilisant des noms d'ère complets (令和6年), et le livret de la coopérative de crédit contenant des transactions de la fin de l'ère Shōwa provenant de comptes ouverts dans les années 1980 — toutes étant converties en dates grégoriennes dans le résultat. Le même lot traite les annotations manuscrites en marge (家賃 pour loyer, 仕入 pour achats de stock) comme une colonne Notes supplémentaire, et les colonnes calculées pré-classifient les transactions en catégories de dépenses et signalent les écarts de solde.
L'alternative — l'extraction page par page avec fusion manuelle — oblige l'utilisateur à consolider 36 fichiers de feuilles de calcul séparés, à recouper les dates d'ère entre les pages où l'en-tête d'année apparaît à la page 1 et disparaît pour les sept pages de continuation suivantes, et à vérifier manuellement la continuité du solde entre les livrets. Pour trois années de données provenant de trois banques, la seule étape de fusion manuelle prend environ deux à trois heures. L'approche par lots l'élimine complètement — un seul chargement, une seule feuille de calcul, une seule vérification. Pour l'architecture complète du flux de traitement par lots, consultez le guide de traitement par lots des pages de livret vers un grand livre de dépenses annuel. Pour une analyse chiffrée de ce que la saisie manuelle des données coûte réellement aux petites entreprises japonaises, l'analyse des coûts traduit le temps et les taux d'erreur en chiffres concrets.
Traitement par lots de livrets vs. autres scénarios de lots du marché : un cabinet britannique traitant par lots 80 déclarations d'impôt SA100 gère des documents indépendants — chaque déclaration est un ensemble de données autonome, et une erreur de lecture sur la déclaration 47 n'affecte que la déclaration 47. Un lot de livrets traite des pages interdépendantes — le solde courant se répercute d'une page à l'autre, et une erreur de lecture à la page 3 corrompt silencieusement la vérification de toutes les pages suivantes. Le lot doit tenir compte de la structure de continuité du type de document, et non traiter chaque page comme une île. C'est pourquoi la vérification par colonne calculée au moment de l'extraction — et non après — fait la différence technique entre un lot qui produit un résultat vérifié et un lot qui produit des données que vous devez entièrement revérifier dans votre logiciel comptable.
Dans l'écosystème comptable japonais : Yayoi, freee, MoneyForward et au-delà
Le tableur extrait n'est qu'un pont — la destination, c'est le logiciel comptable japonais. Les trois plateformes qui dominent le marché des indépendants et des petites entreprises — Yayoi Accounting (弥生会計), freee Accounting (freee会計) et MoneyForward Cloud Accounting (マネーフォワード クラウド会計) — couvrent ensemble la grande majorité des déclarants bleus. Chacune a son propre chemin d'importation, et le résultat de l'extraction doit correspondre aux attentes de la plateforme cible.
Yayoi Accounting (弥生会計). Le leader du marché, notamment auprès des experts-comptables fiscalistes (税理士). L'importation se fait par CSV via la fonction Smart Transaction Import (スマート取引取込). Yayoi exige les dates au format aaaa-mm-jj — la conversion ère-vers-grégorien de l'étape d'extraction doit être terminée avant l'exportation. Yayoi utilise un format d'importation propriétaire (弥生インポート形式) pour le CSV, donc le résultat de l'extraction doit être mappé au schéma de champs Yayoi : date, compte débiteur (借方勘定科目), montant débiteur, compte créditeur (貸方勘定科目), montant créditeur, description (摘要).
freee Accounting (freee会計). Natif du cloud avec plus de 270 points d'accès API et le support MCP (Model Context Protocol) — le plus riche en API des trois. Importation par téléchargement manuel de CSV (取引 CSV インポート) en utilisant le modèle d'importation freee, ou via l'API freee pour une ingestion automatisée. Les règles de catégorisation automatique de freee (自動登録ルール) peuvent être configurées pour reconnaître les codes de description du livret et attribuer des comptes comptables (勘定科目) — ce qui signifie que l'étape d'extraction peut se concentrer sur la capture fidèle du code, et que la logique de classification réside dans le moteur de règles du logiciel comptable.
MoneyForward Cloud Accounting (マネーフォワード クラウド会計). Importation via la fonction de migration de données (他社ソフトデータの移行), en sélectionnant le format compatible Yayoi comme format CSV intermédiaire. La force de MoneyForward est le 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 pour obtenir une image financière complète. Si le résultat de l'extraction utilise le format de date et de colonne compatible Yayoi, il s'importe dans MoneyForward avec le même mappage de colonnes.
Les autres plateformes prises en charge qui acceptent la même importation CSV incluent : MJS Accounting (会計大将), TKC (série FX2/MX), OBC Kanjo Bugyo (勘定奉行), Sorimachi Accounting King (会計王), EPSON Financial Support (財務応援R4) et PCA Accounting (PCA会計). Le format à cinq colonnes du livret est standardisé dans toutes les banques japonaises, donc le même résultat d'extraction fonctionne avec n'importe quelle plateforme comptable qui importe des données de transactions CSV — le format de date, les colonnes de montant et le champ de description sont les mêmes, quel que soit le logiciel récepteur.
La distinction clé entre les trois principales plateformes pour la planification de l'extraction : Yayoi est uniquement CSV et nécessite que l'extraction produise un fichier compatible avec le format d'importation Yayoi. freee prend en charge à la fois le CSV et l'API — la voie API permet des pipelines automatisés du livret à la comptabilité sans transfert manuel de fichiers. MoneyForward utilise le CSV au format Yayoi comme format intermédiaire, donc le résultat de l'extraction formaté pour Yayoi fonctionne pour les deux plateformes. Pour la plupart des petites entreprises sans intégration API configurée, cibler le format d'importation Yayoi comme standard de sortie de l'extraction offre la plus large compatibilité.
Le lien avec la 青色申告 : pourquoi l'extraction de livret devient cruciale avec la réforme fiscale de 2027
Le projet de réforme fiscale japonaise (令和8年度税制改正の大綱), publié par la coalition au pouvoir le 19 décembre 2025, restructure la déduction spéciale pour déclaration bleue (青色申告特別控除) — l'incitation fiscale qui rend la comptabilité en partie double rentable pour les travailleurs indépendants depuis son introduction. Les changements prennent effet pour l'année fiscale 2027 (déclarée en 2028) et modifient directement l'économie de la numérisation des livrets bancaires.
Dans le système actuel (2026), un déclarant bleu tenant une comptabilité en partie double et déposant par voie électronique bénéficie d'une déduction de 650 000 ¥ sur le revenu imposable. Les déclarants sur papier avec comptabilité en partie double reçoivent 550 000 ¥. La réforme de 2027 réduit la déduction papier à 100 000 ¥ — une baisse de 450 000 ¥ — et introduit un niveau supérieur de 750 000 ¥ pour les déclarants qui utilisent la déclaration électronique e-Tax ET tiennent des livres électroniques qualifiés (優良な電子帳簿) ou utilisent un système de calcul électronique spécifié avec liaison automatique des données (デジタルシームレス). La structure à trois niveaux devient :
| Mode de déclaration | Comptabilité | Déduction (2026) | Déduction (2027+) | Variation |
|---|---|---|---|---|
| e-Tax + Livres électroniques qualifiés ou liaison automatique | Partie double | — | 750 000 ¥ | Nouveau niveau |
| Déclaration électronique e-Tax | Partie double | 650 000 ¥ | 650 000 ¥ | Aucun changement |
| Déclaration papier | Partie double | 550 000 ¥ | 100 000 ¥ | −450 000 ¥ |
| Comptabilité simplifiée | Partie simple | 100 000 ¥ | 100 000 ¥ (recettes ≤ 10 M¥) 0 ¥ (recettes > 10 M¥) | Restriction de recettes ajoutée |
La connexion pour l'extraction du livret est directe. Un entrepreneur individuel déposant une déclaration papier en 2026 avec une comptabilité en partie double et une transcription manuelle du livret a obtenu 550 000 ¥. Ce même déclarant, poursuivant la même approche manuelle en 2027, obtient 100 000 ¥ — une réduction de déduction de 450 000 ¥, équivalant à environ 90 000 à 180 000 ¥ d'impôt supplémentaire selon le taux marginal. La réforme rend obligatoire la déclaration électronique via e-Tax pour la tranche des 650 000 ¥ — ce qui signifie que l'ensemble du pipeline comptable, de la saisie des données du livret au dépôt final de la déclaration, doit être numérique. L'extraction du livret n'est pas une simple amélioration de confort. C'est le premier maillon d'une chaîne qui détermine désormais votre niveau de déduction fiscale.
En vertu de la Loi sur la conservation des livres électroniques (電子帳簿保存法), les copies numérisées des documents financiers peuvent servir de documents légalement recevables si elles respectent les exigences de résolution (200 dpi) et de couleur. L'amendement de 2024 a assoupli l'exigence d'horodatage — les documents numérisés stockés dans un système doté d'un historique des modifications/suppressions (訂正・削除履歴) n'ont plus besoin d'un horodatage séparé. Pour l'extraction du livret, cela signifie que les pages numérisées du livret utilisées comme entrée d'extraction peuvent également servir de copie légale du document, à condition que la résolution de numérisation réponde à l'exigence de 200 dpi en couleur et que les fichiers numérisés soient stockés dans un système conforme. Le livret physique doit toujours être conservé pendant la période légale de sept ans — l'extraction remplace l'étape de saisie manuelle des données, pas le document légal.
Cas particuliers et dépannage
La plupart des extractions de livret produisent un résultat propre avec une ou deux lignes signalées. Les cas particuliers ci-dessous couvrent les scénarios où les résultats d'extraction nécessitent une vérification humaine — savoir à quoi ils ressemblent avant qu'ils ne se produisent transforme une session de dépannage frustrante en une correction de deux minutes.
Corrections manuscrites (手書き通帳修正)
Les utilisateurs de livrets corrigent parfois les entrées imprimées à la main — un guichetier écrit une correction à côté d'un montant mal imprimé, ou le titulaire du compte annote la colonne de description avec une note comme 家賃 (loyer) ou 仕入 (achat de stock). Ces annotations font légalement partie du document et contiennent des informations essentielles à la comptabilité. L'extraction basée sur un modèle de vision peut lire les annotations manuscrites en même temps que le texte imprimé — mais la qualité de l'écriture manuscrite varie : une annotation claire au stylo à bille en kanji est généralement lisible ; une note au crayon à papier fanée et inclinée traversant les lignes de la grille imprimée est moins fiable. Pour les livrets où les notes manuscrites sont la seule trace de la catégorisation des transactions, le tableur extrait doit être vérifié avec le livret physique ouvert pour les lignes où l'écriture manuscrite était ambiguë. L'IA traite la majorité lisible ; la vérification est une gestion d'exceptions, pas une relecture ligne par ligne.
Ambiguïté du code de description (摘要あいまい性)
Un 振込 (virement) de 500 000 ¥ provenant d'une entreprise cliente connue est un revenu professionnel. Un 振込 de 15 000 ¥ provenant d'un particulier est probablement personnel. Le code de description du livret seul ne peut pas les distinguer — c'est l'attribution de catégorie du logiciel comptable qui le fait. L'extraction doit capturer le code fidèlement ; la logique de classification se trouve en aval, soit dans les règles de catégorisation automatique du logiciel comptable, soit dans une colonne calculée qui combine le code de description avec le seuil de montant. Une erreur courante consiste à écrire des règles de classification trop agressives — une règle qui classe tous les 振込 de plus de 100 000 ¥ comme « Revenus professionnels » classera à tort un don familial unique de 200 000 ¥. Les règles doivent être prudentes, en classant les cas évidents et en laissant les cas ambigus pour une vérification manuelle.
Pages de livret endommagées ou dégradées
Les livrets de cinq ans ou plus peuvent présenter des pages à l'impression délavée, des traces d'humidité, des bavures d'encre ou des plis traversant la zone des transactions. Pour une impression délavée, numériser à une résolution plus élevée (300 dpi ou plus) et ajuster le contraste avant l'extraction améliore la lisibilité. Pour les plis qui déforment les caractères matriciels, photographier la page sous lumière naturelle en biais peut réduire l'ombre du pli. Pour les pages où un dommage rend une ligne de transaction illisible — généralement 1 à 2 lignes dans un livret de 280 — marquez la ligne pour une saisie manuelle en vous référant au livret physique. L'extraction traite les 278 autres lignes. L'échec sur une ligne endommagée est visible dans la colonne de vérification : un indicateur REVIEW sur une ligne où le calcul du solde ne correspond pas, souvent causé par un chiffre de montant partiellement illisible.
Livrets numériques (デジタル通帳) vs. livrets physiques
Certaines banques — notamment la Banque postale du Japon via son service Yucho Direct+ — proposent des livrets numériques qui remplacent le livret physique par une vue des transactions en ligne et un export CSV téléchargeable. Cependant, le format d'exportation, la plage de dates et les colonnes disponibles diffèrent selon les banques et ne correspondent souvent pas au format attendu par le logiciel comptable. Un CSV de livret numérique de la Banque postale du Japon peut exporter les dates dans le calendrier grégorien, alors que le livret physique du même compte imprimé à un DAB utilise les dates d'ère — et le CSV peut ne couvrir que les 12 derniers mois tandis que le livret physique contient l'historique complet du compte. Pour les déclarants bleus dont le logiciel comptable attend un format CSV spécifique, la voie de l'extraction — numériser le livret physique ou capturer l'écran de la vue du livret numérique — fournit une sortie au format cohérent quelle que soit la source de données, avec la conversion ère-vers-grégorien gérée au niveau de la sortie, quel que soit le format d'entrée.
Livrets trans-ères et en-têtes d'année manquants
Un livret ouvert en 2018 et renouvelé en 2024 contient des transactions couvrant deux ères impériales : 平成 (Heisei) et 令和 (Reiwa). La frontière entre les ères — 平成31年 (janvier–avril 2019) passant à 令和元年 (mai–décembre 2019) — se situe au milieu du livret. L'extraction doit détecter le changement d'ère à la page où l'en-tête d'année passe de 平成 à 令和 et appliquer le décalage correct par transaction. De même, les pages de continuation dans le même livret qui ne réimpriment pas l'en-tête d'année s'appuient sur le contexte reporté de la page la plus récente avec un en-tête. Si la page 5 imprime 令和6年 et que les pages 6 à 8 n'impriment que le mois et le jour, l'extraction applique le contexte 令和6年 à toutes les transactions des pages 5 à 8 — et lorsque la page 9 imprime 令和7年 après le 1er janvier, le contexte est mis à jour. Un report manqué produit des transactions avec des dates flottantes (« 7.15 » sans année) qui ne peuvent pas être placées sur une chronologie et échoueront lors de l'importation dans le logiciel comptable.
Foire aux questions
L'extraction de livret peut-elle traiter toutes les banques japonaises dans le même lot ?
Oui — un livret MUFG à une ligne par opération, un livret de la Banque postale du Japon (ゆうちょ銀行) à deux lignes par opération, et un livret de caisse de crédit régionale (信用金庫) à impression compacte peuvent tous être téléchargés dans le même lot et produire un tableur unifié avec des colonnes cohérentes. L'extraction sémantique lit la signification de chaque valeur — une date reste une date, qu'elle soit imprimée R6.7.15 sur un livret ou 令和6年7月15日 sur un autre. Le même schéma à cinq colonnes fonctionne avec tous les formats. La conversion ère-vers-grégorien est appliquée page par page en fonction de l'en-tête d'ère détecté sur chaque page. Ainsi, un lot contenant des livrets de différentes ères — 平成 sur le livret MUFG, 令和 sur celui de la Banque postale du Japon, 昭和 sur un vieux livret de caisse de crédit — convertit toutes les dates au format aaaa-mm-jj dans le fichier de sortie.
Comment l'extraction gère-t-elle les dates en ère japonaise (和暦) couvrant plusieurs ères ?
L'extraction lit l'en-tête d'année d'ère de chaque page et applique la formule de conversion correcte : Reiwa n = n + 2018, Heisei n = n + 1988, Showa n = n + 1925. Pour les pages de continuation sans en-tête d'année, le contexte d'ère est reporté depuis la page la plus récente avec en-tête. Lorsqu'un changement d'ère survient en cours de livret — par exemple le passage de Heisei 31 à Reiwa 1 le 1er mai 2019 — le moteur détecte le changement d'ère à la page où l'en-tête bascule. Pour l'année charnière, les transactions sur les pages avec l'en-tête 平成 utilisent le décalage Heisei, et celles sur les pages avec l'en-tête 令和 utilisent le décalage Reiwa. Toutes les dates en sortie sont grégoriennes (aaaa-mm-jj) pour une compatibilité directe avec Yayoi, freee et MoneyForward.
Que se passe-t-il si la vérification du solde reporté échoue sur plusieurs lignes ?
Plusieurs drapeaux REVIEW consécutifs remontent presque toujours à une cause unique — la première ligne signalée. Une erreur de lecture de virgule (¥30 000 → ¥3 000) sur la ligne 47 corrompt le solde de la ligne 47, ce qui corrompt la vérification de la ligne 48, et ainsi de suite jusqu'à la fin du livret. Corrigez la ligne 47 — rectifiez le montant mal lu — et les lignes 48 à 280 se recalculent correctement. L'approche par colonne calculée détecte le problème au point de défaillance ; l'utilisateur corrige la première ligne signalée, et le reste se résout. Sans cette étape de vérification, l'erreur apparaît dans le logiciel comptable lorsque la balance de vérification ne correspond pas au relevé bancaire — un rapprochement qui oblige à remonter chaque ligne pour trouver la seule erreur de lecture à l'origine de la cascade. Le signalement au moment de l'extraction représente deux minutes de correction. Le signalement au moment de la comptabilité représente une heure de travail d'enquête. Pour un traitement complet de ce problème et d'autres modes de défaillance courants de la saisie de livret, consultez le guide des erreurs courantes.
Comment l'extraction gère-t-elle les annotations manuscrites dans les marges des livrets ?
Définissez une colonne « Notes » dans votre schéma de sortie. Toute annotation manuscrite lisible près d'une ligne de transaction — une note comme 家賃 (loyer), 仕入 (achat de stock) ou un nom de client écrit à côté d'une écriture 振込 — est capturée comme contexte supplémentaire lors de l'extraction. La qualité de l'écriture manuscrite varie considérablement : une annotation claire au stylo à bille en kanji standard est généralement lisible ; une note au crayon à papier, écrite en biais et traversant les lignes imprimées du quadrillage, est moins fiable. Pour les livrets où les notes manuscrites sont la seule trace de la catégorisation des transactions, le fichier extrait doit être vérifié en ayant le livret physique ouvert pour les lignes où l'écriture était ambiguë. L'IA traite la majorité lisible — réduisant la vérification de chaque ligne à quelques-unes où la qualité de l'annotation était insuffisante.
Les données extraites du livret peuvent-elles être directement importées dans Yayoi Accounting pour la déclaration bleue ?
Oui — le résultat de l'extraction est un fichier Excel avec des dates au format aaaa-mm-jj, que Yayoi Accounting (弥生会計) accepte via la fonction Smart Transaction Import (スマート取引取込). Faites correspondre les colonnes extraites au schéma de Yayoi : date, compte débiteur (借方勘定科目), montant débiteur, compte créditeur (貸方勘定科目), montant créditeur et description (摘要). Si vous utilisez les colonnes calculées pour pré-classifier les transactions — en associant 給与 à « Revenus salariaux » et 引落 à « Services publics » — les champs d'intitulé de compte sont déjà renseignés avant l'importation. Si vous préférez laisser le logiciel comptable gérer la classification, extrayez les codes de description bruts et configurez les règles de catégorisation automatique de Yayoi ou freee pour les faire correspondre aux bons intitulés de compte. Les plus de 270 points d'API de freee permettent des pipelines automatisés d'extraction vers la comptabilité sans transfert manuel de fichiers ; Yayoi et MoneyForward utilisent l'import CSV avec le format compatible Yayoi comme format intermédiaire commun. Les autres plateformes prises en charge incluent MJS Accounting, TKC, OBC Kanjo Bugyo, Sorimachi, EPSON et PCA — toutes acceptent le même format CSV de transaction.
Ai-je encore besoin du livret physique après l'extraction ?
Selon la Loi sur la conservation des livres électroniques (電子帳簿保存法), les copies numérisées des documents financiers peuvent servir de pièces justificatives légalement recevables si elles respectent l'exigence de numérisation en couleur à 200 dpi et les règles de conservation. Cependant, le livret physique reste le document original faisant foi. L'Agence nationale des impôts (国税庁) peut demander les originaux lors d'un contrôle fiscal. Bonne pratique : extrayez le livret dans un tableur pour votre flux de travail comptable, conservez les pages numérisées comme copie électronique et gardez le livret physique pendant la période légale de conservation de sept ans. L'extraction remplace la saisie manuelle des données — elle ne remplace pas le document légal.
Vue d'ensemble : où se situe l'extraction de livret dans le flux comptable japonais
Le flux de travail de déclaration fiscale d'un entrepreneur individuel japonais a toujours été divisé en deux moitiés déconnectées. La première moitié — la saisie manuelle des données du livret — est manuelle : des pages étalées sur un bureau, des dates en ère converties mentalement, des montants saisis dans un tableur ou un logiciel comptable, ligne par ligne. La seconde moitié — la comptabilité et la déclaration — se déroule dans Yayoi, freee ou MoneyForward, où les données sont rapprochées, catégorisées et assemblées dans la déclaration bleue (青色申告決算書). Les deux moitiés sont reliées par une transcription manuelle, et la qualité de cette liaison détermine si la déclaration fiscale se rapproche du premier coup ou au cinquième.
L'extraction de livret remplace la liaison par transcription par une liaison automatisée. Les pages du livret deviennent des images ; les images deviennent un tableur avec des dates vérifiées, des transactions catégorisées et des écarts signalés ; le tableur s'importe dans le logiciel comptable, où le reste du flux reste inchangé. L'étape d'extraction ne modifie ni le logiciel comptable, ni le processus de déclaration fiscale, ni la structure de la déduction pour déclaration bleue — elle modifie le pipeline de données qui les alimente.
Avec la réforme fiscale de 2027, ce pipeline a une valeur de déduction qui lui est attachée. Un déclarant qui reste sur papier — transcription manuelle du livret, déclaration papier — reçoit 100 000 ¥. Un déclarant qui numérise le pipeline — données de livret extraites alimentant la déclaration électronique e-Tax — reçoit 650 000 ¥, ou 750 000 ¥ avec des livres électroniques qualifiés. L'écart de 450 000 ¥ à 650 000 ¥ n'est pas un crédit d'impôt pour l'utilisation d'un logiciel d'extraction. C'est le système fiscal qui fixe le prix du statu quo de la saisie manuelle des données de livret à son véritable coût — et qui incite à passer au numérique avant que la fenêtre de déduction ne se réduise.
Le guide pratique pour l'extraction d'un seul livret couvre la configuration en cinq colonnes et la première extraction. Le guide de traitement par lots traite de la consolidation multi-années et multi-banques. L'analyse des problèmes explique pourquoi le statu quo manuel persiste malgré les outils disponibles. L'analyse des coûts quantifie la perte financière liée à la poursuite de la saisie manuelle. Le guide des erreurs courantes couvre la dérive du solde et la stratégie de vérification. Cet article — le hub — les relie en une seule image pour comprendre pourquoi l'extraction de livret existe, comment elle fonctionne, où elle se situe dans la pile comptable, et pourquoi la réforme fiscale de 2027 en fait la voie par défaut pour tout entrepreneur individuel japonais qui dépose une déclaration bleue.