Déclaration de fin d'année au Japon :Pourquoi la saisie est encore manuelle

Le marché japonais des logiciels de paie compte parmi les plateformes RH les plus sophistiquées d'Asie. SmartHR — la plus grande plateforme RH cloud du Japon avec environ 60 000 clients entreprises — numérise le questionnaire employé, génère les certificats de retenue et transmet les déclarations par voie électronique. freee HR & Payroll (freee人事労務) sert environ 380 000 entités. Yayoi Payroll (弥生給与) effectue des calculs de paie depuis des décennies. Ensemble, ces plateformes gèrent l'arithmétique de la déclaration de fin d'année (年末調整, Nenmatsu Chosei) au yen près — en appliquant les barèmes de retenue actualisés chaque année par l'Agence nationale des impôts, en calculant les cotisations sociales sur deux systèmes d'assurance parallèles, et en rapprochant douze mois de retenues avec l'impôt réel dû par chaque employé. Puis un employé remet aux RH une carte postale papier de son assureur-vie, et le fossé structurel entre ce que fait le logiciel de paie et ce qu'exige le processus devient impossible à ignorer.

Arrêtez la saisie manuelle — laissez l'IA lire vos documents
Image ou PDF — données structurées en 10 secondes
Essayer maintenant
Sans inscription · Sans carte bancaire · Résultat en 10 secondes
Formulaire fiscal japonais et certificats de déduction d'assurance illustrant le problème de saisie manuelle des données de déclaration de fin d'année pour les RH

Points clés

  1. Soixante-sept heures — c'est ce qu'une entreprise de 200 employés perd chaque décembre à taper les primes d'assurance depuis des cartes postales papier dans les champs de paie, non pas parce que le calcul est difficile (le logiciel de paie japonais le fait au yen près), mais parce que le logiciel n'a jamais été conçu pour lire des documents qu'il n'a pas générés.
  2. Le portail Myna du Japon (la passerelle nationale d'identité numérique) a été conçu pour recevoir des certificats d'assurance électroniques — mais les données butent sur un mur là où le format d'exportation du portail ne se connecte à rien, obligeant les employés à télécharger des données numériques que les RH doivent encore ressaisir manuellement dans SmartHR ou freee.
  3. ImageToTable.ai lit les certificats d'assurance par le sens plutôt que par la position — un seul lot traite les 400 documents de formats variés en un seul tableur, remplaçant 67 heures de saisie manuelle par une vérification.

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é.

L'idée clé : Le bilan annuel n'est pas un problème de traitement de données qu'un logiciel peut résoudre. C'est un problème de collecte de données qui nécessite de relier trois flux documentaires — un interne, deux externes — chacun contrôlé par une organisation différente, sans aucune incitation à normaliser les sorties pour un logiciel de paie.

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 à l'arrivée

Une analyse de 2024 par RSM Shiodome sur la numérisation du bilan de fin d'année cartographie précisément l'écart : dans le flux actuel, une compagnie d'assurance émet une carte postale physique attestant des primes payées par l'employé (étape 1). L'employé retranscrit 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 papier 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, la compagnie d'assurance émet des données électroniques (étape 1). L'employé importe ces données dans un logiciel de bilan de fin d'année qui remplit automatiquement le calcul de la déduction (étape 2). L'employé soumet les données électroniques à son 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 un coursier — il reçoit les données, puis les transmet à 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 brise et l'on revient à une saisie manuelle.

Multipliez cela par le nombre de relations d'assurance qu'un employé japonais typique entretient. L'assurance-vie générale (一般生命保険料), l'assurance pension personnelle (個人年金保険料) et l'assurance soins infirmiers/médicaux (介護医療保険料) relèvent chacune de catégories de déduction distinctes avec des plafonds différents. L'assurance tremblement de terre a son propre calcul de déduction avec un plafond séparé. Un seul employé peut 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 nécessitant 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 prime, des numéros de police et des codes de classification qui doivent être retranscrits 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 les saisies manuelles

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 réajustement de fin d'année doit lui-même être achevé d'ici fin décembre, afin que tout remboursement ou retenue supplémentaire apparaisse sur la fiche de paie de décembre — le dernier traitement 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 dates limites sont fixées en interne — généralement de mi-novembre à 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 justificatifs de personnes à charge. Les soumissions arrivent par vagues. Certains employés soumettent dès le premier jour. D'autres nécessitent trois relances. 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 le réajustement inclus.

Janvier : Délivrer les certificats de retenue à la source à tous les employés. Soumettre le récapitulatif des retenues à 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.

L'ensemble du cycle 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é d'effectuer le calcul de la paie de décembre — est plus étroite, souvent de 3 à 4 semaines.

Lorsque la date limite se rapproche et qu'il reste encore 50 certificats d'assurance d'employés à saisir, le chemin le plus rapide est manuel : ouvrir le PDF, lire le numéro, 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'y a pas de voie d'importation par lots — seulement de 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 provoque pas la saisie manuelle des données. Elle la récompense structurellement. Chaque année, les équipes RH sont confrontées au même compromis : investir du temps pour concevoir un flux de travail plus efficace pour les formats de cette année, ou simplement taper et respecter la date limite. La pression de conformité — les pénalités pour dépôt tardif commencent à 15 % pour un dépôt tardif auto-dé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 de rendre efficace. La bonne décision à long terme est rarement la bonne décision de décembre.

La boucle de rétroaction de la date limite : Pression temporelle → la saisie manuelle est la plus rapide cette année → aucune infrastructure n'est construite pour l'année prochaine → en décembre prochain, la saisie manuelle est à nouveau le chemin le plus rapide. Briser cette boucle nécessite une solution plus rapide que la saisie manuelle dès la première utilisation — et pas seulement après l'installation et la formation.

Arrêtez la saisie manuelle — laissez l'IA lire vos documents
Image ou PDF — données structurées en 10 secondes
Essayer maintenant
Sans inscription · Sans carte bancaire · Résultat en 10 secondes

Là où ça se complique : filiales étrangères et barrière linguistique

Pour les entreprises étrangères (外資系, gaishikei) ayant des filiales au Japon, le même processus entraîne une surcharge 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 japonais. Le logiciel de régularisation de fin d'année du NTA est par défaut en japonais. La plupart des plateformes de paie — même les plus internationalisées — présentent leur interface de régularisation uniquement en japonais.

L'équipe RH d'une filiale étrangère type 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 de rémunération mondiale à New York demande le résumé annuel des rémunérations — en anglais, dans Excel, avec des colonnes intitulées « Salaire brut », « Impôt sur le revenu retenu » et « Cotisations sociales » — chaque donnée exportée par le système de paie en japonais doit être traduite manuellement.

Cette couche linguistique aggrave toutes les autres tâches manuelles. Un certificat de retenue à la source (源泉徴収票) contient 26 champs définis. Pour 200 employés, cela représente 5 200 données. Si chaque champ nécessite à la fois une transcription et une traduction — 支払金額 en « Salaire brut », 源泉徴収税額 en « Impôt sur le revenu retenu », 社会保険料等の金額 en « Cotisations sociales », 給与所得控除後の金額 en « Revenu après déduction légale » — le temps de traitement par certificat augmente car la personne doit comprendre à la fois la terminologie fiscale japonaise et le format de rapport anglais requis par la destination.

Il existe également un écart de familiarité avec le format. Un employé de paie japonais qui traite des régularisations de fin d'année depuis dix ans peut jeter un coup d'œil à un certificat d'assurance et identifier immédiatement quel code va dans quel champ. Un coordinateur RH nouvellement embauché dans une filiale étrangère, traitant son premier cycle de régularisation 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. Le guide officiel du NTA et le guide de l'impôt sur le revenu en anglais couvrent les bases mais ne détaillent pas la correspondance champ par champ nécessaire à 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 certificat est d'environ 1 167 ¥ pour une entreprise japonaise nationale. Pour une filiale étrangère, l'étape de traduction ajoute environ 30 à 40 % au temps par certificat, portant le coût de traitement complet bien au-dessus de 1 500 ¥ par certificat. 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 chaîne.

Ce qui change vraiment la donne

Le nœud structurel décrit ci-dessus — trois sources de documents, certification papier par défaut, délais serrés, friction linguistique — ne sera pas dénoué par une simple modification réglementaire ou une mise à jour logicielle. Les émetteurs de documents (assureurs, banques), les destinataires (employés) et les processeurs (RH/paye) opèrent sur des systèmes différents avec des incitations différentes. Une réforme coordonnée des trois est peu probable à court terme.

Ce qui peut changer, c'est l'interface entre le document papier et le système de paie. Si le certificat 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 saisisse chaque champ — le goulot d'étranglement se réduit à la seule variable que l'équipe RH contrôle : le bouton d'import.

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 des outils OCR traditionnels, qui échoue quand chaque assureur formate ses certificats 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 leur sens, pas leur position sur la page. Les mêmes définitions de colonnes fonctionnent sur des cartes postales, des PDF imprimés, des scans par email et des photos de téléphone, car l'extraction est sémantique, pas basée sur les coordonnées.

Combinée au traitement par lots — importer 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 certificat individuellement au traitement de tous les certificats en une seule opération. L'approche d'extraction par certificat unique supprime la saisie manuelle des données par document. L'approche par lots supprime la répétition d'ouverture et de fermeture de 400 fichiers.

JPG/PNG/PDF Extraction IA

Les fichiers sont traités de manière sécurisée et non stockés.

Tout cela ne supprime pas la complexité réglementaire. L'article 190 s'applique toujours. La date limite du 31 janvier reste en vigueur. Les trois sources documentaires continuent de fonctionner 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 au tableur, et les collaborateurs qui passaient auparavant 67 heures à saisir les primes d'assurance dans les champs de paie peuvent consacrer ces heures à la vérification, à la communication avec les employés et au travail de conformité qui nécessite réellement un jugement humain.

Questions fréquentes

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

Partiellement. SmartHR, freee HR & Payroll (freee人事労務) et MoneyForward Cloud Payroll peuvent calculer l'ajustement fiscal une fois toutes les données dans le système et générer les formulaires requis. Mais la saisie des données — transférer les chiffres des certificats d'assurance et des déclarations de personnes à charge dans le 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 qu'elle possède. Elle ne peut pas extraire les données qu'elle n'a pas reçues.

L'ANF ne fournit-elle pas un logiciel gratuit de réajustement de fin d'année ?

Oui. Le Logiciel de réajustement de fin d'année (年調ソフト) de l'ANF est gratuit et prend en charge l'importation électronique des certificats de déduction via le portail Myna. Cependant, il nécessite que les employés aient un compte 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. Et le chemin d'importation électronique du logiciel de l'ANF ne se connecte pas aux plateformes de paie tierces.

Quelle quantité de travail manuel le réajustement de fin d'année consomme-t-il réellement ?

Un cycle de traitement complet 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 de travail complètes pour une seule personne. Les employés ayant plusieurs polices d'assurance, des déductions pour prêt immobilier, 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 cela avec les données salariales RH japonaises.

L'extraction par IA peut-elle traiter fiablement les documents fiscaux japonais ?

Oui. Les modèles modernes de vision-langage sont multilingues. Ils reconnaissent les caractères japonais (kanji, hiragana, katakana), les dispositions mixtes horizontales/verticales courantes dans les formulaires japonais, et les formats numériques propres au Japon (¥1 234 567 avec des espaces 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 n'est pas la reconnaissance linguistique — c'est la variabilité du format du document (carte postale vs PDF vs photo vs scan) qui fait échouer l'extraction basée sur des modèles, ce qui explique pourquoi l'extraction sémantique fonctionne sur tous les formats.

Le réajustement de fin d'année au Japon sera-t-il un jour entièrement numérique ?

Pas à court terme. La structure tripartite (assureur → employé → employeur) signifie 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 l'adoption reste incomplète. L'approche la plus pragmatique consiste à accepter que les documents papier et PDF persistent et à combler le fossé au niveau de la couche d'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 janvier suffit pour le savoir

Les forces structurelles qui maintiennent le réajustement fiscal de fin d'année manuel — collecte de données à trois sources, certification papier par défaut, 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 attendant 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 si les données entrent dans votre système de paie via un clavier ou via l'extraction. Une année d'exécution de votre cycle réel de réajustement de fin d'année via l'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 lot d'échantillons cette année, avant la rué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 dans l'étude de cas de personne d'autre.

📮 contact email: [email protected]