Ajustement fiscal de fin d'année au Japon :
Pourquoi la saisie des données reste manuelle

Le problème que les logiciels de paie n'ont pas été conçus pour résoudre

Les plateformes de paie au Japon sont vraiment excellentes pour le calcul. Elles appliquent le barème progressif de retenue à la source de l'ANF — des taux allant de 5 % sur les premiers 1,95 million de yens de revenu imposable à 45 % sur les montants supérieurs à 40 millions de yens — prennent en compte la déduction pour revenus d'emploi (給与所得控除) qui suit une formule légale progressive, calculent les cotisations de sécurité sociale aux taux préfectoraux en vigueur, et rapprochent le total de l'impôt déjà retenu dans l'année de l'impôt annuel final. En décembre, le système connaît le salaire, les primes, les heures supplémentaires, la retenue à la source et les cotisations sociales de chaque employé jusqu'au dernier yen.

Le problème n'est pas le résultat. C'est l'écart entre l'endroit où les données brutes sont générées et celui où le système de paie les attend.

Le rajustement fiscal de fin d'année selon l'article 190 de la loi japonaise sur l'impôt sur le revenu (所得税法第190条) nécessite des données provenant de trois sources indépendantes, dont une seule se trouve dans la plateforme de paie :

Source 1 — Registres de paie. Salaire mensuel, primes, indemnités, heures supplémentaires, retenue à la source versée et cotisations sociales déduites. Ces données sont déjà numériques. Le système de paie les possède.

Source 2 — Déclarations des employés. La Déclaration de déduction pour personnes à charge (扶養控除等（異動）申告書) liste chaque personne à charge : revenu estimé du conjoint, âge et statut étudiant des enfants, situation de logement des parents âgés. La Déclaration de déduction pour primes d'assurance (保険料控除申告書) déclare les primes d'assurance-vie payées, les primes d'assurance contre les catastrophes naturelles et la sécurité sociale payée en dehors du système de l'employeur. La Déclaration de déduction de base (基礎控除申告書) estime le revenu annuel total de l'employé. Aucune de ces informations n'existe dans le système de paie avant que l'employé ne les fournisse.

Source 3 — Certificats de déduction tiers (控除証明書). Les compagnies d'assurance émettent des certificats de déduction pour primes d'assurance (保険料控除証明書). Les banques émettent des certificats de solde de prêt immobilier (住宅借入金等特別控除証明書) pour le crédit d'impôt pour prêt au logement. Chaque certificat contient des montants précis en yens, des numéros de police, des dates de contrat et des codes de classification du type d'assurance qui déterminent la formule de déduction applicable. Ces documents sont émis par des organismes externes. Le système de paie ne peut ni les générer, ni les prédire, et — surtout — ne peut pas les lire.

Les logiciels de paie automatisent entièrement la Source 1. Pour la Source 2, des plateformes comme SmartHR et freee HR & Payroll ont créé des portails en libre-service où les employés remplissent des questionnaires numériques qui alimentent directement le moteur de calcul. C'est un véritable progrès — cela élimine le formulaire papier pour les employés des entreprises qui utilisent ces plateformes.

Mais la Source 3 reste en dehors de la boucle fermée. Les certificats d'assurance sont toujours émis par les compagnies d'assurance, pas par les éditeurs de logiciels de paie. Et lorsque ces certificats arrivent sous forme de cartes postales papier ou de PDF imprimés par l'employé, quelqu'un doit lire les chiffres et les saisir. La plateforme de paie la plus sophistiquée du marché ne peut pas extraire des données d'un document qu'elle n'a pas généré.

Les déclarations papier qui refusent de disparaître

Les déclarations des employés sont numérisables — SmartHR et freee l'ont prouvé avec leurs interfaces basées sur des questionnaires. Mais les informations déclarables proviennent d'ailleurs. Un employé remplissant la Déclaration de déduction des primes d'assurance ne connaît pas ses montants de prime par cœur. Il recopie les chiffres des certificats d'assurance reçus par courrier. Le questionnaire numérique déplace la charge de la transcription des RH vers l'employé, mais ne l'élimine pas.

La Déclaration de déduction pour personne à charge (扶養控除等申告書) illustre une dépendance plus profonde au papier. Ce formulaire exige que l'employé déclare pour chaque personne à charge : nom, numéro My Number, date de naissance, lien de parenté avec l'employé, et revenu total estimé pour l'année. Pour les personnes à charge non-résidentes — fréquentes chez les employés étrangers soutenant leur famille à l'étranger — le formulaire exige également une preuve de transfert de fonds (送金関係書類) et une preuve de lien familial (親族関係書類). Ces documents justificatifs arrivent sous forme de reçus de virement bancaire, d'extraits de registre familial et de certificats traduits. Ce ne sont pas des formats de données standardisables. Ce sont des preuves, et la preuve dans la culture administrative japonaise se fait par défaut sur papier.

L'Agence nationale des impôts a construit une voie numérique. Le Logiciel de bilan annuel (年調ソフト), disponible gratuitement auprès de l'Agence, prend en charge l'importation électronique des certificats de déduction via le Portail Myna (マイナポータル). Suite à la réforme fiscale de 2020, les compagnies d'assurance peuvent délivrer des certificats de déduction électroniques (電子的控除証明書) que les employés téléchargent via le Portail Myna et importent directement dans le logiciel de l'Agence. En principe, cela boucle la boucle : assureur → Portail Myna → logiciel de l'Agence → calcul.

En pratique, la boucle est encore fragmentée. L'adoption des certificats de déduction électroniques reste incomplète. De nombreux assureurs envoient encore des cartes postales papier. De nombreux employés n'ont pas configuré de compte Portail Myna — l'adoption de la carte My Number au Japon n'atteignait qu'environ 74 % de la population fin 2024, et le taux d'activation des comptes Portail Myna est encore plus faible. Plus important encore, la voie d'importation électronique de l'Agence ne fonctionne qu'avec son propre logiciel. Elle ne fait pas le pont avec SmartHR, freee, Yayoi Payroll (弥生給与) ou MoneyForward Cloud Payroll. Un employé qui télécharge ses données d'assurance via le Portail Myna et les soumet à un employeur utilisant SmartHR a fait passer les données du papier au numérique — pour ensuite les voir ressaisies manuellement car les formats ne sont pas compatibles.

Les déclarations papier ne sont pas un échec de la technologie. Elles sont un artefact structurel d'un système où l'émetteur du document, le destinataire du document et le processeur du document sont trois entités différentes utilisant trois systèmes différents. Aucun effort de numérisation unique — aussi bien financé soit-il — ne peut résoudre les trois extrémités simultanément.

Le tapis roulant des certificats d'assurance : numérique à la source, papier à destination

Une analyse de 2024 par RSM Shiodome sur la numérisation de la régularisation de fin d'année cartographie l'écart précis : dans le flux de travail actuel, une compagnie d'assurance émet une carte postale physique prouvant les paiements de primes de l'employé (étape 1). L'employé transcrit le contenu de cette carte postale sur le formulaire de déclaration de déduction des primes d'assurance et calcule le montant de la déduction (étape 2). L'employé soumet le formulaire physique et la carte postale originale à son employeur (étape 3). L'employeur saisit manuellement ces données dans le système de paie, calcule l'impôt annuel et effectue le rapprochement (étape 4).

Dans la version numérisée de ce flux de travail, la compagnie d'assurance émet des données électroniques (étape 1). L'employé importe ces données dans un logiciel de régularisation de fin d'année qui remplit automatiquement le calcul de la déduction (étape 2). L'employé soumet les données électroniques à l'employeur (étape 3). L'employeur importe les données dans un système de paie qui calcule l'impôt automatiquement (étape 4).

Le goulot d'étranglement se situe entre les étapes 1 et 3. Même lorsque la compagnie d'assurance émet un certificat électronique, l'employé agit toujours comme coursier — recevant les données, puis les transmettant à l'employeur. Si l'employé imprime le PDF et soumet du papier, ou si le système de paie de l'employeur ne peut pas accepter le format électronique fourni par l'assureur, la chaîne numérique se rompt et revient à la saisie manuelle.

Multipliez cela par le nombre de relations d'assurance qu'un employé japonais typique détient. L'assurance vie générale (一般生命保険料), l'assurance pension personnelle (個人年金保険料) et l'assurance soins infirmiers/médicale (介護医療保険料) relèvent chacune de catégories de déduction distinctes avec des plafonds différents. L'assurance contre les tremblements de terre a son propre calcul de déduction avec un plafond distinct. Un seul employé pourrait soumettre des certificats de Nippon Life (日本生命), Dai-ichi Life (第一生命), Meiji Yasuda (明治安田) et d'un assureur régional contre les tremblements de terre — chaque certificat dans un format légèrement différent, chacun exigeant que son montant de prime atterrisse dans le champ correct du système de paie.

Pour une entreprise de 200 employés avec une moyenne de deux certificats d'assurance par employé, cela représente 400 certificats individuels contenant chacun des montants de primes, des numéros de police et des codes de classification qui doivent être transcrits avec précision. Le calcul de l'impôt prend quelques secondes par employé. L'assemblage des données prend des semaines.

La date limite du 31 janvier : comment la pression du temps favorise la saisie manuelle

En vertu de l'article 226 de la loi sur l'impôt sur le revenu, les employeurs doivent délivrer un certificat de retenue à la source (源泉徴収票, Gensen Choshu-hyo) à chaque employé avant le 31 janvier de l'année suivante. Le ajustement de fin d'année lui-même doit être terminé avant la fin décembre afin que tout remboursement ou retenue supplémentaire apparaisse sur la paie de décembre — le dernier cycle de paie de l'année civile.

Cela crée un schéma de compression qui se répète à l'identique dans chaque entreprise, chaque année :

Octobre–novembre : Les RH distribuent les formulaires de déclaration aux employés. Les échéances sont fixées en interne — généralement de la mi-novembre au début décembre.

Novembre–décembre : Les employés soumettent leurs déclarations complétées accompagnées des certificats d'assurance, des relevés de solde hypothécaire et des documents relatifs aux personnes à charge. Les soumissions arrivent par vagues. Certains employés soumettent dès le premier jour. D'autres nécessitent trois rappels. Les certificats se perdent, se retrouvent, sont redemandés aux assureurs.

Décembre : Les RH doivent vérifier les données soumises par chaque employé — recouper les primes d'assurance déclarées avec les certificats, confirmer l'éligibilité des personnes à charge par rapport aux seuils de revenus, vérifier les soldes de prêts immobiliers — puis saisir les données vérifiées dans le système de paie, exécuter le calcul de fin d'année et traiter la paie de décembre avec l'ajustement inclus.

Janvier : Délivrer les certificats de retenue à la source à tous les employés. Soumettre le récapitulatif de retenue à la source (法定調書合計表) au bureau des impôts. Déposer les déclarations de taxe de résidence municipale pour chaque employé auprès de leurs municipalités respectives.

Le cycle complet dure environ 10 à 12 semaines. La fenêtre de saisie des données — la période entre la réception des certificats et la nécessité de lancer le calcul de paie de décembre — est plus étroite, souvent de 3 à 4 semaines.

Lorsque l'échéance se resserre et qu'il reste encore 50 certificats d'assurance d'employés à saisir, le chemin le plus rapide est le manuel : ouvrir le PDF, lire le chiffre, le taper. Lorsqu'un certificat arrive sous forme de photo d'une carte postale prise sur le téléphone de l'employé, il n'existe aucun chemin d'importation par lots — seulement la transcription. Lorsque deux membres du personnel RH doivent traiter 200 employés en trois semaines, la structure d'incitation à court terme pousse vers le comportement qui consomme le plus de travail à long terme : la saisie manuelle des données, répétée chaque année.

La date limite ne cause pas la saisie manuelle des données. Elle la récompense structurellement. Chaque année, les équipes RH font face au même compromis : investir du temps à concevoir un flux de travail plus efficace pour les formats de cette année, ou simplement taper et respecter l'échéance. La pression de conformité — les pénalités de dépôt tardif commencent à 15 % pour un dépôt tardif autodéclaré, 20 % pour les corrections initiées par le NTA, avec des pénalités pour fraude atteignant 35 à 40 % — renforce l'instinct de terminer plutôt que d'optimiser. La bonne décision à long terme est rarement la bonne décision de décembre.

Là où ça se complique : les filiales étrangères et le multiplicateur linguistique

Pour les entreprises à capitaux étrangers (外資系, gaishikei) exploitant des filiales au Japon, le même processus entraîne une taxe opérationnelle supplémentaire.

Les formulaires sont entièrement en japonais. Les certificats d'assurance de Nippon Life, Dai-ichi Life, Meiji Yasuda et autres assureurs nationaux sont des documents en langue japonaise. Le logiciel de régularisation de fin d'année de l'ANT est par défaut en japonais. La plupart des plateformes de paie — même celles relativement internationalisées — présentent leurs interfaces de régularisation de fin d'année uniquement en japonais.

L'équipe RH d'une filiale étrangère typique se compose d'un responsable RH bilingue et de plusieurs employés de paie japonophones. Le responsable bilingue est le seul pont entre les données sources en japonais et les résultats en anglais exigés par le siège mondial. Lorsque le responsable RH régional à Singapour ou l'équipe mondiale de rémunération à New York demande le résumé annuel de rémunération — en anglais, dans Excel, avec des colonnes intitulées « Gross Salary », « Income Tax Withheld » et « Social Insurance Contributions » — chaque point de données que le système de paie exporte en japonais doit être traduit manuellement.

Cette couche linguistique aggrave toutes les autres charges manuelles. Un certificat de retenue à la source (源泉徴収票) contient 26 champs définis. Pour 200 employés, cela représente 5 200 points de données. Si chaque champ nécessite à la fois une transcription et une traduction — 支払金額 en « Gross Salary », 源泉徴収税額 en « Income Tax Withheld », 社会保険料等の金額 en « Social Insurance Contributions », 給与所得控除後の金額 en « Income After Statutory Deduction » — le temps de traitement par certificat augmente considérablement, car la personne qui le fait doit comprendre à la fois la terminologie fiscale japonaise et le format de rapport anglais exigé par la destination.

Il existe également un écart de familiarité avec les formulaires. Un employé de paie japonais qui traite les ajustements de fin d’année depuis dix ans peut jeter un œil à une attestation d’assurance et identifier immédiatement quel code va dans quel champ. Un coordinateur RH nouvellement embauché dans une filiale étrangère, qui traite son premier cycle d’ajustement de fin d’année (年末調整), fait face à une courbe d’apprentissage abrupte en plus de la charge de saisie manuelle des données. Les formulaires ne s’expliquent pas d’eux-mêmes. Les directives officielles de l’ANT et le guide de l’impôt sur le revenu en anglais couvrent les bases mais ne détaillent pas le mappage champ par champ requis pour la saisie des données de paie.

Comme exploré dans l’analyse des coûts du traitement manuel de fin d’année, le coût de main-d’œuvre par attestation est d’environ ¥1 167 pour une entreprise japonaise nationale. Pour une filiale étrangère, l’étape de traduction linguistique ajoute environ 30–40 % au temps par attestation, portant le coût de traitement entièrement chargé bien au-dessus de ¥1 500 par attestation. La barrière linguistique n’est pas un problème distinct de la saisie manuelle des données. C’est un multiplicateur appliqué à chaque inefficacité existante dans la pile.

Ce qui Change Réellement la Donne

Le nœud structurel décrit ci-dessus — trois sources de documents, certification par défaut sur papier, délai compressé, friction linguistique — ne sera pas dénoué par un seul changement réglementaire ou une mise à jour logicielle. Les émetteurs de documents (assureurs, banques), les destinataires de documents (employés) et les processeurs de documents (équipes RH/paie) fonctionnent sur des systèmes différents avec des incitations différentes. Une réforme coordonnée entre les trois est peu probable dans un avenir visible.

Ce qui peut changer, c’est l’interface entre le document papier et le système de paie. Si l’attestation d’assurance, la déclaration de personne à charge ou le relevé de solde hypothécaire peut être photographié ou scanné et ses données extraites directement dans un format structuré — sans qu’un humain ne lise et ne saisisse chaque champ — le goulot d’étranglement se réduit à la seule variable que l’équipe RH contrôle : le bouton de téléversement.

C’est ce que fait l’extraction par nom de colonne. Au lieu de dessiner des cadres autour des champs sur un modèle (l’approche utilisée par les outils OCR traditionnels, qui échoue lorsque chaque assureur formate ses attestations différemment), vous tapez les en-têtes de colonne souhaités — par exemple, “Nom de l’employé,” “Prime d’assurance-vie (一般生命保険料),” “Prime de pension personnelle (個人年金保険料)” — et l’IA lit chaque document pour localiser ces valeurs en comprenant ce qu’elles signifient, et non où elles se trouvent sur la page. Les mêmes définitions de colonnes fonctionnent sur les cartes postales, les PDF imprimés, les scans par e-mail et les photos de téléphone, car l’extraction est sémantique, et non basée sur les coordonnées.

Combiné au traitement par lots — téléverser plusieurs documents à la fois et recevoir un seul fichier de sortie fusionné, une ligne par document — le flux de travail passe de l’ouverture de chaque attestation individuellement au traitement de toutes les attestations en une seule opération. L’approche d’extraction par attestation unique élimine la saisie manuelle des données par document. L’approche par lots élimine la répétition d’ouverture et de fermeture de 400 fichiers.

Aucune de ces solutions ne supprime la complexité réglementaire. L'article 190 s'applique toujours. La date limite du 31 janvier s'applique toujours. Les trois sources documentaires fonctionnent toujours indépendamment. Ce qui change, c'est que les RH cessent d'être la couche de transcription entre elles. Les données passent directement du document à la feuille de calcul, et les employés qui consacraient auparavant 67 heures à saisir les primes d'assurance dans les champs de paie peuvent désormais consacrer ces heures à la vérification, à la communication avec les employés et au travail de conformité qui exige réellement un jugement humain.

Questions fréquentes

Les logiciels de paie peuvent-ils déjà gérer numériquement le ajustement de fin d'année ?

Partiellement. SmartHR, freee人事労務 (freee RH & Paie) et MoneyForward Cloud Payroll peuvent calculer l'ajustement fiscal une fois toutes les données saisies dans le système et générer les formulaires requis. Mais la saisie des données — obtenir les chiffres des certificats d'assurance et des déclarations de personnes à charge pour les intégrer au système — reste manuelle pour la plupart des entreprises, car ces documents proviennent de l'extérieur du logiciel de paie. La plateforme de paie peut calculer avec les données dont elle dispose. Elle ne peut pas extraire des données qu'elle n'a pas reçues.

L’NTA ne fournit-elle pas un logiciel gratuit de fin d’année ?

Si. Le logiciel de fin d’année (年調ソフト) de l’NTA est gratuit et prend en charge l’importation électronique des certificats de déduction via le portail Myna. Cependant, il exige que les employés disposent de comptes sur le portail Myna et que les assureurs émettent des certificats de déduction électroniques — deux conditions dont l’adoption reste incomplète. En 2025, les certificats papier restent le canal majoritaire pour la documentation des primes d’assurance. De plus, le parcours d’importation électronique du logiciel de l’NTA ne se connecte pas aux plateformes de paie tierces.

Quelle quantité de travail manuel la fin d’année consomme-t-elle réellement ?

Un cycle complet de traitement par employé — collecte des certificats, vérification des montants déclarés par rapport aux documents sources, saisie des données dans le système de paie et recoupement — prend environ 20 minutes pour un cas simple. Pour 200 employés, cela représente environ 67 heures de travail RH : près de deux semaines complètes de travail d’une seule personne. Les employés ayant plusieurs polices d’assurance, des déductions hypothécaires, des personnes à charge non résidentes ou des changements d’emploi en cours d’année nécessitent un temps de vérification supplémentaire. L’analyse du coût par certificat détaille ce point avec des données salariales RH japonaises.

L’extraction par IA peut-elle traiter de manière fiable les documents fiscaux en japonais ?

Oui. Les modèles modernes de vision-langage sont multilingues. Ils reconnaissent les caractères japonais (kanji, hiragana, katakana), les mises en page mixtes horizontales/verticales courantes dans les formulaires japonais, et les formats numériques spécifiques au Japon (¥1,234,567 avec des virgules comme séparateurs de milliers). La précision d’extraction sur du texte japonais imprimé dans des documents structurés est comparable à celle de l’anglais. Le défi ne réside pas dans la reconnaissance linguistique — c’est la variabilité du format des documents (carte postale vs. PDF vs. photo vs. scan) qui fait échouer l’extraction basée sur des modèles, ce qui explique précisément pourquoi l’extraction sémantique fonctionne sur tous les formats.

La déclaration de fin d’année au Japon deviendra-t-elle un jour entièrement numérique ?

Pas à court terme. La structure tripartite (assureur → employé → employeur) implique qu’une numérisation complète nécessite une action coordonnée entre les compagnies d’assurance, les agences gouvernementales, les éditeurs de logiciels de paie et le comportement individuel des employés. La réforme fiscale de 2020 autorisant les certificats de déduction électroniques a été un véritable pas en avant, mais son adoption reste incomplète. L’approche la plus pragmatique consiste à accepter que les documents papier et PDF persistent et à combler l’écart au niveau de l’extraction — le point où les documents rencontrent le système de paie — plutôt que d’attendre que les trois parties se standardisent simultanément.

Un seul mois de janvier suffit pour savoir

Les forces structurelles qui maintiennent la déclaration de fin d’année manuelle — collecte de données provenant de trois sources, certification par défaut sur papier, fenêtres de traitement compressées, friction linguistique pour les filiales étrangères — ne vont pas se résoudre d’elles-mêmes. Ce sont des caractéristiques de l’architecture réglementaire, pas des bugs en attente d’un correctif logiciel. L’article 190 de la loi sur l’impôt sur le revenu est en vigueur depuis des décennies. La transition du secteur de l’assurance vers les certificats électroniques se fera selon son propre calendrier, pas selon celui des RH. La date limite du 31 janvier continuera d’arriver chaque année.

Ce qui change, c’est de savoir si les données entrent dans votre système de paie via un clavier ou via l’extraction. Une année de traitement de votre cycle réel de déclaration de fin d’année par extraction — les certificats de vos propres employés, vos propres définitions de colonnes, vos propres exigences de déclaration — est le seul test qui compte. Essayez-le sur un échantillon cette année, avant la période chargée de novembre. La réponse à la question de savoir si un janvier de 67 heures devient un janvier de 4 heures ne se trouve pas dans l’étude de cas de quelqu’un d’autre.