Le guide complet de l'extraction des données P60 au Royaume-Uni
pour les équipes de paie

Ce qu'est réellement l'extraction de données P60

L'extraction de données P60 est le processus de lecture des champs statutaires d'un certificat de fin d'année — NINO de l'employé, référence PAYE de l'employeur, rémunération dans cet emploi, impôt retenu, cotisations d'assurance nationale, code fiscal final — et de leur conversion en colonnes structurées dans un tableur, une ligne par employé et par année fiscale. Le certificat lui-même est régi par la spécification HMRC RD1, qui prescrit chaque champ qu'un P60 de substitution doit comporter, tout en laissant la disposition visuelle entièrement à la discrétion du fournisseur de logiciel de paie.

Cette distinction — données obligatoires, mise en page libre — est la raison pour laquelle l'extraction existe en tant que catégorie à part entière. Si tous les P60 étaient identiques, tout outil OCR basé sur des modèles pourrait lire les cases 1 à 6 à partir de coordonnées fixes. Mais Sage 50cloud peut imprimer le NINO en haut à droite et la référence PAYE en bas à gauche en gras sous le nom de l'employeur. BrightPay peut les placer côte à côte dans une section encadrée. IRIS Staffology peut tout empiler verticalement. Ces trois certificats sont tous également conformes à HMRC. Ils contiennent tous les trois les mêmes champs statutaires. Et ils déjouent tous les trois un modèle conçu pour l'un d'entre eux.

Extraction de colonnes personnalisées — où vous définissez les colonnes de sortie dont votre tableur a besoin (“NINO,” “Rémunération dans cet emploi,” “Impôt retenu,” “Lettre de catégorie NI”) et où l'IA localise chaque valeur sur chaque P60 en comprenant ce que signifie le libellé du champ plutôt que sa position — est ce qui permet à l'extraction de fonctionner avec tous les fournisseurs de paie sans configuration spécifique. La même définition de colonne lit un P60 Sage, un P60 Xero, un P60 BrightPay et un P60 papier scanné provenant d'un employeur placé en administration judiciaire en 2023. L'IA lit par le sens, pas par modèle.

Pourquoi extraire les données du P60 est important

En vertu du Règlement 67 du Income Tax Regulations 2003, tout employeur britannique doit fournir un P60 à chaque salarié inscrit au 5 avril. La date limite légale est le 31 mai. Pour le logiciel de paie qui a généré le certificat, le processus s'arrête là. Pour l'équipe paie, c'est là que commencent trois flux de travail en aval — et aucun n'est pris en charge par la fonction de génération de P60 du logiciel.

Rapprochement de fin d'année entre P60 et FPS

Un cabinet de paie gérant la fin d'année pour plusieurs clients employeurs doit vérifier que les chiffres de chaque P60 correspondent aux totaux annuels de la déclaration FPS (Full Payment Submission) envoyée à HMRC via le système RTI (Real Time Information). Le rapprochement se fait employeur par employeur : extraire tous les P60 de l'Employeur A dans un tableur, comparer les totaux de salaire et d'impôt avec l'extrait FPS du cabinet, et enquêter sur toute ligne où les deux montants ne concordent pas à la livre près. Pour 150 salariés répartis sur cinq clients employeurs, cela représente 750 comparaisons P60/FPS — et une seule erreur de transcription dans une ligne crée un écart qu'un contrôle de conformité HMRC peut signaler des mois plus tard. Pour un guide détaillé de ce processus, voir comment extraire les données P60 britanniques dans Excel pour le rapprochement de paie.

Préparation de la déclaration de revenus (échéance janvier, collecte mai)

Un cabinet comptable servant des clients particuliers reçoit les P60 en même temps que les relevés bancaires, les coupons de dividendes et les formulaires P11D avant l'échéance du 31 janvier pour la déclaration de revenus (Self Assessment). Un client avec deux emplois simultanés dans la même année fiscale produit deux lignes de P60 — chacune avec son propre code employeur PAYE et son montant « Salaire dans cet emploi ». Ces données correspondent directement aux pages Emploi du formulaire SA100, et une erreur de transcription où le salaire de l'Employeur A atterrit sur la ligne de l'Employeur B est l'une des causes les plus fréquentes d'une demande d'explication SA302. Le problème de mai pour la paie britannique est que ce travail de transcription atteint son pic dans une période où les comptables sont déjà débordés par la documentation de fin d'année de chaque client.

Vérification des revenus à grande échelle

Les prêteurs hypothécaires, agences de location, cabinets de vérification d'emploi et conseillers en immigration demandent régulièrement les P60 comme justificatif des revenus de l'année précédente. Le processus de vérification est à haut volume et à champ restreint : nom, NINO, référence PAYE de l'employeur, rémunération totale annuelle. Comme les P60 proviennent du logiciel de paie utilisé par l'employeur du demandeur — que le vérificateur ne maîtrise pas — la capacité de l'outil d'extraction à traiter toute mise en page sans préconfiguration détermine si la chaîne de vérification peut être automatisée ou si quelqu'un doit ouvrir chaque PDF et saisir les chiffres manuellement.

Les défis uniques de l'extraction des P60

Les P60 partagent certains défis d'extraction avec les fiches de paie et les formulaires fiscaux — diversité des formats, étiquetage incohérent, qualité numérisée ou numérique — mais présentent aussi trois problèmes structurels que presque aucun autre type de document ne génère. Comprendre ces points avant de configurer un flux d'extraction évite de devoir reprendre manuellement le tableur en juin.

Multiples formats de logiciels de paie, un seul cahier des charges légal

La spécification RD1 de l'HMRC autorise explicitement des « variations de format et de mise en page » pour les P60 de substitution. Sage imprime la section des certificats légaux en blocs alignés à gauche, avec la référence PAYE en gras sous le nom de l'employeur. BrightPay sépare les détails NI dans un tableau encadré. Xero place le NINO au-dessus du bloc d'adresse de l'employé. QuickBooks Online affiche le code fiscal et la lettre de catégorie NI dans une bande horizontale en haut du quart de page. Moorepay utilise une grille à trois colonnes. Les six mises en page sont conformes. Aucune ne partage un modèle.

Ce n'est pas un défaut de la spécification — elle existe parce que les employeurs britanniques utilisent différents logiciels de paie depuis des décennies, chacun avec son propre moteur d'impression, et la position réglementaire de l'HMRC est d'imposer le contenu des données, pas la disposition visuelle. La conséquence pratique pour l'extraction est qu'une approche basée sur des modèles qui fonctionne sur les P60 générés par Sage produit des résultats inexploitables sur les P60 de BrightPay. Une approche d'extraction sémantique — lisant par signification du champ plutôt que par coordonnée de pixel — traite tous les fournisseurs avec une seule définition de colonne, car elle comprend que « Rémunération dans cet emploi » signifie la même chose, peu importe où cela apparaît sur la page.

P60 des sortants : le cas particulier caché dans chaque fin d’exercice fiscal

Un salarié ayant démissionné en février 2026 était encore inscrit dans les effectifs au 5 avril de cette année — son ancien employeur doit donc lui délivrer un P60 pour la partie de l’année fiscale travaillée, même s’il est parti avant la clôture. Si l’employeur utilise Sage mais que l’entreprise d’accueil utilise Xero, le nouveau service paie se retrouve avec un P60 dans une présentation que son équipe rencontre rarement. Pire, si l’ancien employeur émet encore des certificats papier — autorisé par les règles HMRC pour les employeurs du secteur des soins et certaines entités exonérées — le P60 arrive en format physique. Quelqu’un le photographie avec son téléphone et l’envoie par email à la paie. Cette photo devient alors une donnée d’extraction au même titre que les P60 numériques propres issus de leur propre système de paie.

Les P60 des sortants posent aussi des problèmes inter-exercices. Un salarié ayant travaillé pour l’employeur A d’avril 2025 à février 2026, puis pour l’employeur B de février à avril 2026, détient deux P60 couvrant la même année fiscale. Son revenu imposable total pour l’année est la somme des deux montants « Rémunération dans cet emploi » — mais aucun des deux P60 n’affiche cette somme. Le calcul se fait dans le tableur, après extraction, et dépend de l’extraction correcte des deux P60 dans le même classeur. Une seule erreur de saisie sur l’une ou l’autre ligne produit un total erroné que la déclaration de revenus finira par révéler.

Données inter-exercices : le problème de la lettre de catégorie NI

Lorsque la lettre de catégorie d’assurance nationale d’un salarié change en cours d’année — le plus souvent de A à C à l’âge de la retraite d’État — le P60 affiche deux lignes NI distinctes sous deux lettres de catégorie différentes. Chaque ligne comporte ses propres tranches de revenus (au LEL, entre LEL et PT, entre PT et UEL, au-dessus de UEL) et ses propres cotisations salariales dues. Sage les imprime en deux lignes adjacentes avec les lettres comme étiquettes à gauche. Xero les imprime en sections de tableau séparées avec la lettre comme en-tête de section. Un système d’extraction qui fusionne les deux lignes en un seul montant « total NI » — courant dans les outils conçus pour les fiches de paie et adaptés aux P60 — perd la ventilation par lettre de catégorie dont dépend le rapprochement employeur avec les déclarations RTI.

L’ensemble des lettres de catégorie NI est limité : A, B, C, F, H, I, J, L, M, S, V, X, Z. Toute valeur en dehors de cet ensemble dans un tableur extrait est soit une erreur de transcription, soit un échec d’extraction — et comme la plupart des P60 utilisent la lettre A (taux standard), un « D » ou « K » aberrant dans la colonne de catégorie NI est détectable par une simple règle de validation Excel. Mais cette détection ne fonctionne que si l’extraction a conservé la lettre dans une colonne dédiée — pas si elle a fusionné les deux lignes NI en une seule ligne avec les cotisations additionnées.

Méthodes traditionnelles vs extraction P60 par IA

Trois approches existent pour intégrer les données P60 dans une feuille de calcul, et le choix entre elles détermine si la période de paie de mai est un marathon de saisie ou une séquence de téléversement de fichier et d'exportation.

L'OCR par modèle — l'approche utilisée par les outils de traitement documentaire hérités — fonctionne en définissant des zones rectangulaires sur une image de document et en exécutant l'OCR dans chaque zone. Pour un P60 Sage où le NINO de l'employé se trouve aux coordonnées (530, 280, 700, 300) sur une page A4, le modèle lit le texte qui apparaît dans ce rectangle. Un P60 BrightPay où le NINO se trouve aux coordonnées (400, 190, 600, 210) produit une cellule vide ou une valeur de champ erronée. Étant donné que les fournisseurs de paie britanniques utilisent des mises en page P60 fondamentalement différentes, un système à modèles nécessite un modèle par fournisseur, plus une solution de repli pour les P60 papier scannés qui ne correspondent à aucune mise en page numérique — et chaque fois que le fournisseur met à jour son format d'impression, le modèle casse silencieusement.

L'extraction sémantique par IA inverse cette logique. Au lieu de définir où se trouvent les données sur la page, vous définissez quelles données vous voulez — en saisissant les noms de colonnes dont votre feuille de calcul a besoin. L'IA lit l'intégralité du document, identifie chaque champ par son rôle sémantique dans une structure de certificat fiscal, et remplit la colonne correspondante indépendamment de la position des pixels. Un P60 de Sage, un P60 de BrightPay et une photo prise au téléphone d'un P60 papier d'un ancien employeur produisent tous des lignes remplies dans la même feuille de calcul, car l'IA fait correspondre par le sens plutôt que par les coordonnées. C'est le changement fondamental entre l'extraction basée sur la position et l'extraction basée sur la sémantique.

La différence d'efficacité se creuse avec le volume. À deux minutes par P60 pour la saisie manuelle, 150 employés représentent cinq heures de transcription concentrée — dans une fenêtre de mai où l'équipe paie gère également l'EPS final, rapproche le P32 et prépare les rapports attendus par le conseil avant la fin du mois. L'extraction par IA traite les mêmes 150 P60 en environ 15 à 25 minutes de temps de traitement total. Pour une comparaison plus approfondie de l'approche manuelle, voir le coût caché de la saisie des données P60.

Champs clés du P60 à extraire

Le P60 contient plus de champs que la plupart des flux d'extraction n'en nécessitent. Les champs à extraire dépendent de ce que le tableur doit alimenter — mais les champs eux-mêmes sont définis par la spécification RD1 de HMRC, et comprendre l'utilité de chacun détermine si votre résultat résout la tâche en aval ou crée un nouveau problème de rapprochement.

La conséquence pour le tableur est qu'une extraction complète des P60 pour 150 employés produit environ 150 lignes et 20 à 25 colonnes lorsque vous incluez toutes les ventilations des tranches de NI. La définition des colonnes est réutilisable d'une année fiscale à l'autre — le jeu de champs statutaire du HMRC ne change que lorsque la législation change, et lorsqu'elle change (comme avec l'ajout du Statutory Neonatal Care Pay dans la spécification 2025-26), vous ajoutez la nouvelle colonne sans reconstruire le reste. Si vous passez de la transcription manuelle à l'extraction, les cinq erreurs de saisie de données P60 qui mettent en péril le rapprochement de la paie valent la peine d'être lues avant de définir vos colonnes — chacune correspond à un contrôle au niveau de la colonne que vous pouvez intégrer au résultat de l'extraction.

Traitement par lots des P60 à grande échelle

Traiter un seul P60 n'est pas le problème. Extraire les champs d'un P60 dans Excel demande de l'attention, pas de l'automatisation. Le problème apparaît à grande échelle — 100 employés, trois fournisseurs de paie, quelques P60 papier scannés de départs d'entreprises acquises — et à cette échelle, les défis structurels passent de « puis-je lire ce champ » à « chaque ligne de ce tableur peut-elle être retracée jusqu'à exactement un document source et exactement une année fiscale ».

Le traitement par lots réduit le flux de travail multi-fichiers à une séquence unique de téléversement et d'export : déposez tous les PDF P60 — imprimés Sage, imprimés Xero, papier scanné, photos de téléphone — dans un seul lot, définissez vos noms de colonnes une fois, et recevez un tableur unifié où chaque ligne correspond à un P60. Traiter par lots plus de 100 P60 avant la date limite du 31 mai est ce qui transforme l'extraction d'une commodité par document en un flux de travail pour l'équipe de paie.

Trois préoccupations spécifiques au traitement par lots méritent d'être abordées avant de traiter 150 P60 d'un coup :

Exportation et utilisation des données P60 extraites

Les résultats de l'extraction doivent atterrir là où se trouve le flux de travail en aval. Les données P60 ont trois destinations principales, chacune avec des exigences de format différentes :

• Excel (XLSX) — Le format par défaut pour le rapprochement de la paie. Les données extraites arrivent avec des en-têtes de colonnes appropriés, des formats de date standardisés (l'année fiscale exprimée sous la forme “2025-26”) et des champs numériques formatés en tant que nombres — ce qui signifie que vous pouvez immédiatement appliquer les formules de validation couvertes dans le guide pratique d'extraction P60 sans avoir à reformater les valeurs monétaires stockées sous forme de texte ou les NINO répartis sur des cellules fusionnées.
• CSV — Pour l'import en masse dans un logiciel de paie, des systèmes comptables ou les outils de rapprochement du bureau. La plupart des plateformes de paie acceptent les importations CSV pour les données de rémunération, et un CSV propre issu de l'extraction permet d'éviter l'étape intermédiaire de formatage manuel d'un tableur avant l'import.
• JSON — Pour les intégrations personnalisées, les pipelines de vérification pilotés par API ou la recoupement automatisé avec les extraits de données de soumission RTI.

Pour les équipes qui effectuent leur rapprochement dans Google Sheets, un module complémentaire de barre latérale Google Sheets écrit les champs P60 extraits directement dans la feuille active sans la boucle d'exportation et de réimport. Téléchargez les PDF P60 depuis Sheets, définissez vos noms de colonnes, et les données atterrissent dans la prochaine ligne disponible.

Choisir une approche d'extraction de données P60

Les fonctionnalités qui comptent pour l'extraction P60 ne sont pas celles qui comptent pour l'extraction de factures ou la numérisation de reçus. Un outil qui traite 10 000 factures par mois peut être totalement inadapté pour 150 P60 — car la structure du P60 (champs légaux, répartitions des lettres de catégorie NI, cas particuliers de sortie, données interannuelles) crée des exigences que les outils d'extraction génériques n'ont pas été conçus pour gérer. Voici les dimensions à évaluer :

Ces dimensions sont spécifiques à l'extraction des P60. Un outil performant pour la facturation peut échouer au test de la lettre de catégorie NI. Un outil qui gère bien les fiches de paie peut avoir du mal avec les cas particuliers des P60 de départ. Tester avec vos documents réels — y compris les moins nets — avant de vous engager dans un flux de production est le seul moyen de confirmer que l'outil gère le flux P60 que votre équipe reçoit réellement, et non sa version idéale.

Questions fréquentes