Plus de 100 P60 britanniques avant le 31 mai
Un seul tableur d'audit, zéro saisie manuelle

Pourquoi 100+ P60 est un problème fondamentalement différent d'un seul

Traiter un seul P60 est un problème résolu — extraire ses champs dans Excel demande de l'attention, pas des outils. Vous ouvrez le PDF, repérez les cases légales, tapez sept ou huit chiffres dans une ligne, et passez à la suite. Dès que le volume augmente — 100 employés, trois fournisseurs de paie, quelques partants d'entreprises acquises avec des certificats papier — le problème n'est plus la vitesse mais la structure.

Trois problèmes structurels apparaissent à l'échelle de 100+ documents, inexistants à l'échelle d'un seul document. Aucun n'est résolu en traitant les fichiers plus vite.

Chacun de ces problèmes a une solution qui n'implique pas d'embaucher plus de saisisseurs pour mai. Elle consiste à concevoir le flux par lots — de la préparation des fichiers au schéma de colonnes — comme si la sortie n'était pas un tableur mais un enregistrement d'audit qui sera lu six mois plus tard par quelqu'un n'ayant pas produit les données originales.

La réalité multi-format : Sage n'est pas BrightPay n'est pas un scan 150 DPI

HMRC n'impose pas une mise en page unique du P60. Il impose le contenu : selon la spécification RD1, un P60 de substitution doit afficher certaines cases — nom du salarié, numéro NI, référence PAYE, rémunération totale de l'année, total de l'impôt prélevé, prélèvements pour prêt étudiant, code fiscal final et coordonnées de l'employeur — mais la disposition visuelle est laissée à chaque éditeur de logiciel de paie. Il en résulte qu'un P60 de Sage 50cloud a une structure différente d'un P60 de BrightPay, lui-même différent d'un P60 de QuickBooks Online Payroll, qui diffère d'un P60 de Moorepay, qui diffère d'un P60 d'IRIS. Et ce, sans compter les copies papier scannées provenant de salariés ayant égaré leurs originaux.

L'extraction traditionnelle par modèle — où l'on dessine des rectangles autour des champs sur un P60 type — gère cela en exigeant un modèle distinct pour chaque logiciel de paie. Cinq logiciels, cinq modèles. Un logiciel met à jour la mise en page de son P60 pour le nouvel exercice fiscal — nouvelle directive HMRC, changement de marque, modification de format — et le modèle produit silencieusement des résultats décalés. L'administrateur paie ne s'en aperçoit que lorsque le rapprochement ne correspond pas aux totaux FPS.

L'extraction sémantique élimine le problème du modèle par logiciel en lisant le document pour son sens plutôt que pour sa position. Vous définissez les colonnes souhaitées une fois — « Numéro NI », « Rémunération totale de l'année (£) », « Impôt prélevé (£) », « Référence PAYE », « Code fiscal final » — et l'IA localise chaque valeur sur chaque P60 en comprenant ce que représentent les données, et non où elles se situent sur la page. Un P60 Sage 50cloud, un P60 BrightPay, un P60 QuickBooks et un P60 papier scanné de 2023 alimentent tous les mêmes définitions de colonnes. Pour une présentation détaillée des différents champs d'un P60 britannique et de leur comportement lors de l'extraction, commencez par le guide d'extraction d'un seul P60. Cet article reprend là où celui-ci s'arrête : ce qui se produit lorsque vous cessez de considérer les P60 un par un.

Ce qui rend cette approche particulièrement précieuse dans le contexte de la paie britannique, c'est que la référence PAYE — au format 123/AB456 — reste cohérente sur tous les P60 d'un même employeur, quel que soit le logiciel de paie utilisé. Une entreprise utilisant Sage pour ses salariés permanents et BrightPay pour ses contractants émettra des P60 portant la même référence PAYE mais dans deux formats visuellement différents. L'extraction sémantique lit la valeur, pas la mise en page. La colonne « Référence PAYE » de votre feuille de calcul de sortie se remplit à l'identique pour les deux logiciels, vous offrant une clé de regroupement naturelle pour les lots multi-logiciels.

Nommer les fichiers à grande échelle : rendre chaque ligne traçable jusqu'à sa source

La décision la plus stratégique dans un traitement par lots de P60 intervient avant même le premier fichier : le nom des documents sources. Quand votre tableur contient 100 lignes et qu'un inspecteur HMRC vous demande trois mois plus tard de voir « le P60 correspondant à la ligne 47 », la réponse ne peut pas être « je dois recouper le tableur avec mon dossier Téléchargements ». Il faut un nom de fichier que vous retrouvez instantanément.

Une convention de nommage qui garantit la traçabilité d'audit comprend trois éléments :

Le modèle de nom de fichier obtenu — AB123456C_2025-26_sage.pdf — intègre la piste d'audit dans le nom lui-même. Lorsque votre outil d'extraction conserve les noms de fichiers dans la sortie (ImageToTable.ai inclut une colonne « Nom du fichier » par défaut dans les exportations par lots), chaque ligne de votre tableur porte sa propre provenance. Aucun recoupement externe nécessaire.

Pour les équipes paie gérant des employés dans plusieurs régimes PAYE — une société d'intérim gérant la paie de 20 entités clientes, ou une structure de groupe où chaque filiale a son propre code PAYE — le format de référence PAYE 123/AB456 devient la clé naturelle de regroupement par lot. Traitez tous les P60 portant 123/AB456 en un lot, tous ceux portant 456/CD789 dans un autre. La colonne de référence PAYE dans la sortie de chaque lot sert de point de pivot lorsque vous fusionnez les deux tableurs plus tard. Vous n'avez jamais à deviner à quel employeur appartient une ligne.

Départs, anciens salariés et qui a légalement besoin d'un P60

La règle du HMRC est claire : tout salarié présent dans la paie au 5 avril de l'année fiscale doit recevoir un P60 avant le 31 mai. Cela inclut les salariés partis en cours d'année — à condition qu'ils soient encore employés au 5 avril. Un salarié démissionnaire le 30 mars et effectuant son préavis jusqu'au 4 avril reçoit un P60. Un salarié parti le 31 mars n'en reçoit pas. Cette distinction est cruciale : une erreur dans un sens ou dans l'autre crée un risque d'audit.

Dans un lot de 100 P60, les cas particuliers de départs se répartissent en quatre catégories — chacune modifiant ce que vous incluez dans le lot et ce que vous vérifiez ensuite :

Le piège d'audit n'est pas d'omettre un P60. C'est d'inclure un P60 pour quelqu'un qui ne devrait pas en avoir, ou d'exclure un P60 pour quelqu'un qui devrait en avoir. L'une ou l'autre erreur se propage dans votre rapprochement FPS, et un contrôle de conformité du HMRC au titre du Manuel de conformité CH40000 fera apparaître l'écart plus rapidement que votre logiciel de paie.

La sauvegarde pratique consiste à ajouter une colonne déduite — « Statut P60 » — où l'IA classe chaque document en fonction de son contenu. Des valeurs comme « Actif au 5 avril », « Départ après le 5 avril », « Duplicata année antérieure » et « Pas un P60 » vous permettent de trier le résultat avant le rapprochement, en signalant les lignes à vérifier ou à exclure. Une colonne dans l'extraction économise l'heure de recoupement manuel qui suivrait autrement.

Concevoir des colonnes prêtes pour l'audit dans un tableur de 100 lignes

Les noms de colonnes que vous définissez avant d'importer un lot sont la décision la plus importante de tout le processus. Un schéma de colonnes conçu pour un lot test de cinq employés échoue souvent à 100 lignes, car il ne tient pas compte des cas particuliers liés au volume — numéros NI en double dans différents régimes PAYE, codes fiscaux modifiés en cours d'année, déductions de prêt étudiant réparties entre plusieurs plans.

Un schéma de colonnes qui résiste à un audit de 100 lignes repose sur trois types de colonnes, chacune remplissant une fonction distincte dans le résultat :

Pour les équipes de paie qui gèrent les P60 de plusieurs employeurs, une colonne « Référence PAYE » sert à la fois de clé de regroupement par lot et de pivot de rapprochement. Filtrez le résultat par référence PAYE, additionnez les colonnes Salaire total et Impôt total déduit, et comparez avec les totaux du P35 (Déclaration annuelle de l'employeur) de chaque employeur. L'IA n'a pas besoin de comprendre le format d'une référence PAYE — elle lit la chaîne telle qu'elle apparaît, et comme les références PAYE britanniques utilisent un modèle cohérent NNN/XXNNNNN (PAYE20005), le résultat est naturellement triable et filtrable.

La gestion des codes fiscaux mérite une attention particulière à l'échelle d'un lot. Le code cumulatif standard pour 2025-26 est 1257L — reflétant l'abattement personnel de 12 570 £ — mais le traitement par lot révèle combien d'écarts existent parmi 100 employés. Un employé avec un code K (déductions totales supérieures aux abattements) a un traitement fiscal fondamentalement différent de celui sous 1257L. Un employé dont le P60 affiche un code BR (taux de base) a probablement été imposé sur une seconde source de revenus. Un employé sous NT (aucun impôt) peut avoir soumis un formulaire P85 à HMRC confirmant sa non-résidence. Cinq employés sous 1257L avec le suffixe « X » ont été placés en base non cumulative (mois 1) — ce qui signifie que leurs chiffres cumulés annuels peuvent ne pas représenter un calcul sur l'année complète. Une colonne nommée « Code fiscal final » révèle tout cela. Une seconde colonne calculée nommée « Type de code fiscal » — où l'IA classe chaque code comme « Cumulatif », « Non cumulatif », « BR/D0/D1 » ou « Code K » — transforme un tableur de codes en un tableur de situations fiscales, filtrable en un clic.

Fusionner les données P60 entre plusieurs employeurs et années fiscales

L'extraction par lot produit un tableur par lot. Une équipe paie gérant des P60 sur trois régimes PAYE — chacun avec sa propre référence de type 123/AB456 — se retrouve avec trois tableurs. L'étape de fusion est celle où la conception structurelle de vos colonnes d'extraction porte ses fruits ou s'effondre.

Si chaque lot utilise les mêmes noms de colonnes — « N° NI », « Nom de l'employé », « Référence PAYE », « Année fiscale », « Rémunération annuelle totale (£) », « Impôt total déduit (£) » — les trois tableurs s'empilent verticalement sans remappage de colonnes. La colonne « Référence PAYE » dans chaque feuille identifie à quel employeur chaque ligne appartient, de sorte que le tableur fusionné peut être pivoté par référence PAYE pour produire des totaux par employeur. C'est l'objectif même de la standardisation des noms de colonnes entre lots : la fusion devient une opération d'ajout, et non un exercice de remappage de colonnes.

Pour la question plus large du flux de travail — organiser les fichiers, choisir une approche par lot et structurer la sortie pour une utilisation en aval — le guide complet du flux de travail OCR par lot couvre la préparation des fichiers, la sélection des outils et la structuration de la sortie pour plusieurs types de documents. Le schéma de colonnes spécifique au P60 décrit ici s'intègre dans ce cadre général.

Un cas particulier lié à la fusion : un employé apparaissant dans deux lots avec le même N° NI mais des références PAYE différentes. Ce n'est pas une erreur — c'est un employé qui a occupé deux emplois la même année fiscale. Le P60 de l'employeur A montre les revenus et l'impôt d'un emploi ; le P60 de l'employeur B montre ceux de l'autre. Fusionnés dans un seul tableur, ces deux lignes ne doivent pas être agrégées. La colonne « Référence PAYE » empêche de totaliser deux P60 représentant des emplois distincts. Sans elle, une simple SOMME de « Impôt total déduit (£) » produit un chiffre qui ne correspond au P35 d'aucun employeur — et un rapprochement HMRC qui ne sera pas équilibré.

FAQ : Traitement par lots des P60 britanniques