5 erreurs de saisie de données P60 qui mettent en péril
le rapprochement de la paie

Le point aveugle de la transcription dans la saisie des données P60

Le secteur de la paie a passé des années à discuter des erreurs P60 — mais presque toujours du côté logiciel. Code d'imposition incorrect appliqué au cours de l'année. Lettre de catégorie NI incorrecte dans le système de paie. Soumission RTI signalée par HMRC. Ce sont des erreurs de traitement : le logiciel de paie a généré un certificat erroné parce que les données qui lui ont été fournies étaient incorrectes, ou qu'un paramètre de configuration était défectueux. La correction se fait dans le système de paie.

Mais il existe une deuxième catégorie d'erreurs P60 que les blogs spécialisés en paie, les guides des cabinets comptables et les pages de conseils de HMRC mentionnent à peine : les erreurs introduites après la génération correcte du P60, au moment où une personne lit le certificat et saisit ses données dans un tableur de rapprochement. Un bureau de paie qui vérifie les totaux FPS de fin d'année par rapport aux sorties P60 ne corrige pas un logiciel — il vérifie que la sortie du logiciel correspond aux soumissions HMRC. Le document source est le P60. La cible de transcription est un tableur. Chaque champ transcrit est une opportunité d'erreur qu'aucune piste d'audit du logiciel de paie ne détectera, car le système de paie n'a jamais été impliqué dans la transcription.

Ces erreurs sont structurellement différentes des erreurs de traitement. Une erreur de traitement est détectée lorsque le système de paie signale une règle de validation — un format NI invalide, un code d'imposition qui ne correspond pas aux registres HMRC. Une erreur de transcription est détectée lorsque quelqu'un compare manuellement la cellule du tableur au PDF du P60. Si personne n'effectue cette comparaison, l'erreur reste dans le tableur, alimente le rapport de rapprochement et refait surface des mois plus tard lorsqu'un employé constate que son code d'imposition est erroné — ou qu'un prêteur hypothécaire rejette une demande parce que le montant du salaire sur le P60 ne correspond pas à la vérification de l'employeur.

Les cinq erreurs ci-dessous sont celles qui survivent à la validation de format, passent les contrôles de fin de mois et refont surface des mois plus tard. Ce ne sont pas des problèmes de « vérifiez votre travail plus attentivement » — ce sont des symptômes d'un flux de travail où l'étape de transcription elle-même est la cause racine.

Erreur n°1 : Inversion du N° de Sécurité Sociale — L'erreur qui identifie le mauvais employé

Le format du numéro de Sécurité Sociale britannique — deux lettres préfixes, six chiffres, une lettre suffixe — semble conçu pour détecter automatiquement les inversions. Tout logiciel de paie, toute formule de validation Excel, toute déclaration RTI rejettera une chaîne ne correspondant pas au modèle. Mais voici ce que la vérification de format détecte réellement : les entrées de mauvaise longueur, des caractères là où il faut des chiffres, des lettres préfixes invalides (D, F, I, Q, U, V en première position ; D, F, I, O, Q, U, V en seconde).

Ce qu'elle ne détecte pas, c'est une inversion dans le bloc de six chiffres. QQ 12 34 56 C saisi comme QQ 12 43 56 C passe toutes les validations de format existantes — neuf caractères, deux lettres préfixes valides, six chiffres, une lettre suffixe valide. Le logiciel de paie l'accepte. Le système RTI de HMRC l'accepte. Et il achemine les données fiscales et de cotisations de l'employé vers le mauvais dossier HMRC — un dossier qui peut appartenir à une personne totalement différente, ou à personne jusqu'à ce que l'algorithme de rapprochement de HMRC signale finalement l'incohérence.

Une seule inversion dans le bloc de six chiffres crée un numéro de Sécurité Sociale valide appartenant à un autre individu — ou crée une combinaison qui ne correspond à aucun numéro émis mais passe la validation de format. Dans les deux cas, le dommage en aval n'est pas une déclaration rejetée — c'est une déclaration acceptée silencieusement avec une identité erronée. Les données du P60 de l'employé atterrissent sur le dossier de cotisations de quelqu'un d'autre. Le calcul de la pension d'État de cet autre intègre les revenus d'un tiers. La pré-remplissage de sa déclaration de revenus affiche un salaire d'un employeur pour lequel il n'a jamais travaillé.

La lettre suffixe est une autre couche de complexité cachée. Les quatre lettres valides — A, B, C, D — correspondent au trimestre civil d'émission du numéro. Les gestionnaires de paie d'avant RTI le savent car les cartes de Sécurité Sociale arrivaient trimestriellement, le suffixe indiquant le trimestre. Un professionnel entré en fonction en 2020 n'a peut-être jamais entendu parler de ce système. Ainsi, lorsqu'il recopie un P60 et voit QQ 12 34 56 C, il ignore que C signifie « émis au 4e trimestre » — et ne signalerait pas un suffixe erroné car la validation de format vérifie seulement que le suffixe est A/B/C/D ou un espace, pas qu'il correspond au trimestre d'émission.

Le cabinet comptable qui a repris un client et découvert que le numéro de Sécurité Sociale était erroné « depuis quelques années » — documenté sur AccountingWEB — n'est pas un cas isolé. C'est ce qui arrive quand une erreur d'inversion entre dans le système et que la validation de format dit « ça m'a l'air bon. »

Erreur n°2 : Saisie erronée du code fiscal — l’erreur qui coûte de l’argent aux salariés

Un code fiscal sur un P60 n’est pas qu’une simple chaîne comme 1257L. Il représente l’état final du calcul du PAYE du salarié pour l’année fiscale et contient deux informations essentielles : le numéro du code, qui détermine l’abattement fiscal, et un indicateur de base facultatif — W1 ou M1 — qui indique au HMRC si le code a été appliqué de manière cumulative ou d’urgence (non cumulative).

L’erreur de transcription la plus fréquente avec les codes fiscaux n’est pas de taper 1257L au lieu de 1258L. C’est d’omettre l’indicateur de base lorsque le P60 indique 1257L W1. Si la colonne du tableur ne capture que le code et supprime le suffixe W1/M1, le rapport de rapprochement perd l’information que ce salarié était en régime d’urgence en fin d’année. Le prochain employeur qui reçoit ces données — ou le comptable qui prépare la déclaration de revenus — voit un code cumulatif standard et l’applique comme s’il n’y avait pas de problème W1/M1. L’impôt du salarié est alors calculé de manière incorrecte pour l’année suivante, sur la base d’un code qui n’aurait jamais dû être reporté.

L’impact concret n’est pas théorique. Le dossier de corrections de P60 d’Audit Consulting Group inclut une salariée nommée Emma à Manchester dont le P60 affichait un mauvais code fiscal — le résultat a été un trop-perçu de 890 £ qui a nécessité un P60 corrigé et une procédure de remboursement auprès du HMRC. Cela représente 890 £ de l’argent d’un salarié bloqués par le HMRC pendant des mois, à cause d’un code erroné sur un certificat. Lorsque l’erreur est une transcription plutôt qu’un problème de système de paie — le système de paie a généré le bon code, mais la personne qui a transcrit le P60 a tapé le mauvais code dans le tableur — le chemin vers la résolution est plus long. L’employeur peut se référer au P60 correct. La transcription est l’erreur, pas le document source. Mais l’opérateur de paie qui a mal transcrit il y a six mois n’est peut-être pas celui qui répond à l’appel du salarié en septembre.

La saisie erronée du code fiscal a également des répercussions sur la chaîne de la déclaration de revenus. Si un cabinet comptable utilise les données du P60 — transcrites à partir des documents clients — pour remplir les pages Emploi de la déclaration SA100, un code erroné sur la déclaration crée une discordance avec les données RTI du HMRC. Le HMRC peut signaler la déclaration pour enquête, et la prochaine communication du comptable avec le client commence par expliquer pourquoi une erreur de saisie en mai a déclenché une lettre du HMRC en novembre.

Erreur n°3 : Salaire total et impôt retenu — un échange de colonnes qui casse tout

Un P60 pour un employé ayant occupé deux emplois au cours de la même année fiscale présente deux séries de chiffres faciles à confondre sous pression. « Pay in This Employment » correspond au salaire brut versé par cet employeur précis. « Total Pay for Year » inclut les salaires des emplois précédents, reportés depuis le P45. « Tax Deducted » dans cet emploi correspond à l'impôt PAYE retenu par cet employeur. « Total Tax for Year » agrège l'impôt de tous les emplois.

Sur un P60 imprimé via Sage, ces quatre chiffres peuvent apparaître dans deux colonnes adjacentes. Sur un P60 imprimé via Xero, ils peuvent apparaître en pile verticale. Sur un P60 papier apporté par un employé d'un précédent employeur il y a cinq ans, ils peuvent apparaître dans une disposition complètement différente. Un opérateur de paie qui saisit 80 P60 par jour, en passant d'un format de disposition à un autre tous les quelques certificats, tape « Pay in This Employment » dans la colonne « Tax Deducted » une seule fois. Une ligne. Un échange. Et cette ligne affiche désormais 31 200 £ d'impôt sur 4 870 £ de salaire — ou l'inverse, 4 870 £ d'impôt sur 31 200 £ de salaire.

Le premier chiffre déclenche un contrôle automatisé — le ratio impôt/salaire. Toute personne regardant une ligne de feuille de calcul avec 31 200 £ d'impôt sur 4 870 £ de salaire le remarquera. Mais l'inverse — 4 870 £ d'impôt sur 31 200 £ de salaire — représente un taux d'imposition effectif plausible de 15,6 %. Il passe le contrôle de proportionnalité. Il passe le contrôle de format. Il alimente le rapport de rapprochement comme ligne valide, et le rapprochement des totaux avec les données FPS est légèrement décalé — assez proche pour être attribué à un arrondi ou à une petite différence de calendrier RTI, pas assez pour déclencher une ré-audit complète de chaque ligne.

Cette erreur spécifique a un parallèle documenté dans le logiciel même de HMRC. Au cours d'une année fiscale, le logiciel Basic PAYE Tools (BPT) de HMRC a produit des PDF P60 où les tranches de revenus NI étaient inversées — le PDF affichait des chiffres erronés ne correspondant pas à la soumission RTI. Les administrateurs de paie en discutant sur AccountingWEB ont décrit avoir passé un « temps non facturable » à diagnostiquer une erreur qui n'était pas la leur. La réponse de HMRC était que l'erreur n'apparaissait que sur le PDF, pas dans les données de l'agence de cotisation — ce qui signifie que le PDF que l'opérateur de paie lit et à partir duquel il saisit peut contenir des erreurs de disposition que même le fournisseur du logiciel n'a pas détectées.

Lorsqu'une erreur humaine de transposition se combine à une disposition de document source qui est elle-même ambiguë — deux colonnes avec des valeurs numériques similaires, sans séparateur visuel — l'erreur devient pratiquement indétectable jusqu'à ce que quelqu'un rapproche la ligne individuelle du PDF P60 original. À 80 lignes par jour, personne ne rapproche chaque ligne du PDF original.

Erreur n°4 : Incohérence de date de départ — Quand le P45 et le P60 racontent deux histoires différentes

Cette erreur ne se produit pas sur un seul document. Elle apparaît dans l'écart entre deux documents qui concernent le même salarié. Un salarié qui a quitté l'employeur A en mars et a commencé chez l'employeur B en avril figure sur deux jeux de données P60. Le P60 de l'employeur A indique la rémunération jusqu'à une date de départ en mars. Le P60 de l'employeur B indique la rémunération à partir de la date d'embauche en avril. Les deux certificats sont individuellement corrects. Mais la somme des deux — lorsqu'elle est retranscrite dans une ligne de tableur pour le salarié — doit respecter une contrainte que personne ne vérifie : la date de départ sur le P45 doit précéder la date de début de l'emploi suivant, et la rémunération totale des deux P60 doit correspondre aux chiffres annuels.

Lorsque la date de départ sur le P45 est mal retranscrite — par exemple, 31/03 au lieu de 28/02 — le nouvel employeur applique un mauvais code d'imposition, car le P45 est le document que le nouvel employeur utilise pour déterminer la situation fiscale cumulée du salarié. Si le P45 indique une date de départ deux semaines plus tard que la réalité, le logiciel de paie du nouvel employeur applique un code cumulé qui suppose deux semaines supplémentaires d'abattement fiscal de l'emploi précédent — un abattement que le salarié a déjà utilisé. Le salarié se retrouve sous-imposé pour le reste de l'année et reçoit une lettre de Simple Assessment du HMRC l'automne suivant exigeant le paiement du manque.

Les directives du HMRC sur la correction d'une date de départ erronée indiquent : mettez à jour vos registres de paie avec la date correcte et ne signalez pas la modification dans votre prochain FPS — car cela pourrait créer un doublon de dossier d'emploi. Mais ces directives s'appliquent à l'employeur qui a soumis le FPS original. Si l'erreur de retranscription se produit dans le tableur de rapprochement d'un bureau de paie — la date de départ a été mal saisie lors de la saisie des données, pas lors du FPS original — le bureau n'a aucun FPS à modifier. L'erreur n'existe que dans le tableur. Et le tableur alimente le rapport de rapprochement du bureau, qui alimente la validation de l'employeur, ce qui peut amener l'employeur à émettre un P60 corrigé qui résout un problème qui n'existait pas dans le P60 original — créant une boucle de correction qui fait perdre du temps à tout le monde.

Le vide structurel est la validation inter-documents. Les logiciels de paie valident au sein d'un seul document — format NI sur le P60, format de code d'imposition sur le P45. Aucun système ne valide entre les documents — c'est-à-dire qu'aucun système ne vérifie que la date de départ du P45 et le montant « Rémunération dans cet emploi » du P60 sont cohérents avec la trajectoire salariale totale du salarié. Cette vérification inter-documents est ce que l'opérateur de paie est censé faire manuellement lors de la retranscription. Et c'est la première vérification abandonnée lorsque le volume dépasse le temps disponible.

Erreur n° 5 : Confusion sur le plan de prêt étudiant — Plan 1, 2, 4, 5 ou postgraduate ?

Parmi les cinq erreurs de cet article, c'est celle où les administrateurs de paie sont le moins en faute — et celle qui génère le plus de réclamations d'employés des mois après l'émission du P60. Le système britannique de remboursement des prêts étudiants comprend désormais cinq types de plans, chacun avec un seuil de remboursement différent, et le plan d'un employé est déterminé par le lieu d'études, l'année d'obtention du diplôme et le type de cursus suivi.

La matrice se présente comme suit :

Les directives de l'HMRC aux employeurs indiquent : si votre employé ne connaît pas son plan, utilisez le Plan 5 dans votre logiciel de paie jusqu'à réception d'un avis de début de prêt étudiant (SL1). Opter par défaut pour le Plan 5 est un repli administratif judicieux — mais cela signifie que chaque employé réellement inscrit aux Plans 1, 2 ou 4 qui n'en a pas informé son employeur subit des retenues calculées sur un mauvais seuil. Un emprunteur du Plan 1 (seuil £26 900) traité comme Plan 5 (seuil £25 000) commence à rembourser sur £1 900 de revenus plus tôt que prévu — ce qui, à 9 %, représente environ £171 de retenues excessives par an. Un emprunteur du Plan 4 (seuil £33 795) traité comme Plan 5 (£25 000) paie en trop sur £8 795 de revenus — environ £792 par an.

La dimension de transcription de cette erreur est plus subtile. Lorsqu'un opérateur de paie transcrit les données du P60 dans un tableur de rapprochement, le P60 affiche un montant de retenue de prêt étudiant — un chiffre unique en livres entières. Il n'indique pas quel plan a généré cette retenue. L'opérateur saisit £1 200 dans la colonne du tableur intitulée « Retenues de prêt étudiant ». Le montant est correct. Le plan est invisible. Deux employés ayant le même salaire et la même retenue de £1 200 peuvent être sur des plans différents — l'un Plan 1, l'autre Plan 2 — et le tableur les traite de manière identique. Le rapport de rapprochement qui compare le total des retenues P60 aux totaux FPS correspondra, car les montants des retenues sont corrects. L'erreur ne réside pas dans le montant — elle réside dans le type de plan enregistré dans le système de paie, que le P60 résume sans le nommer.

Lorsque HMRC croise finalement les types de plans des employés — ce qu’ils font, et qui peut prendre des mois car les données SLC transitent par HMRC vers les employeurs de manière asynchrone — l’employeur reçoit une notification indiquant qu’un employé était sur le mauvais plan. L’employeur doit alors corriger les déductions passées, ce qui peut amener l’employé à demander un remboursement à SLC. Martin Lewis de MoneySavingExpert a documenté le gel du seuil de remboursement du Plan 2 et le problème plus large des trop-perçus : employés aux revenus variables, employés ayant commencé à rembourser trop tôt, et employés par défaut sur le mauvais plan. Le processus de remboursement passe par SLC, pas par la paie — mais l’erreur initiale réside dans le dossier de paie que résume le P60, et le tableur de rapprochement qui ne capture pas le type de plan amplifie l’invisibilité de l’erreur.

Pourquoi l’extraction par IA modifie le profil d’erreur — pas seulement la vitesse

Chaque erreur décrite ci-dessus partage une cause profonde que la formation, les listes de contrôle et les doubles vérifications ne traitent qu’en surface. Cette cause profonde est l’étape de transcription elle-même — le moment où une personne lit un PDF et saisit ses données dans une cellule. Supprimer cette étape élimine toute une catégorie d’erreurs qu’aucune formule de validation ne détecte.

Lorsque les données du P60 sont extraites par IA plutôt que saisies manuellement, le profil d’erreur change. Le numéro NI est lu directement depuis le certificat — aucune possibilité de transposition entre la page et la cellule. Le code fiscal arrive complet avec son indicateur W1/M1 car l’extraction préserve la chaîne complète, pas ce qu’une personne se souvient de taper. Les montants de salaire et d’impôt sont mappés à leurs colonnes correctes par sens sémantique — « Salaire dans cet emploi » vs « Salaire total de l’année » — plutôt que par la navigation spatiale de l’opérateur sur une mise en page qu’il voit pour la première fois depuis dix secondes. La déduction pour prêt étudiant est extraite comme la valeur imprimée, et la question du type de plan devient un problème de configuration du système de paie plutôt qu’un problème de transcription.

Cela ne signifie pas que l’extraction élimine toutes les erreurs. Elle change les erreurs qui subsistent. Au lieu d’erreurs de transposition — mauvais chiffre, mauvaise colonne, suffixe omis — les erreurs restantes sont des erreurs de vérification : l’IA a-t-elle mal lu un caractère mal imprimé ? A-t-elle mappé la lettre de catégorie NI depuis la mauvaise ligne lorsqu’un employé a changé de catégorie en cours d’année ? Ces erreurs de vérification sont plus rapides à repérer car l’opérateur examine les données extraites par rapport au document source, plutôt que de saisir et vérifier simultanément. L’opérateur devient un réviseur, pas un transcripteur — et les réviseurs détectent les erreurs que les transcripteurs créent.

Pour le flux de travail complet — des PDF P60 au tableur prêt pour le rapprochement, y compris les définitions de colonnes qui fonctionnent avec Sage, Xero, BrightPay et toute mise en page P60 de fournisseur de paie — consultez notre guide pour extraire les données P60 britanniques dans Excel. Pour le problème plus large de la saisie manuelle des données P60 comme goulot d’étranglement structurel en fin d’année de paie, voir le coût caché de la saisie des données P60.