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

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

Depuis des années, le secteur de la paie débat des erreurs de P60 — mais presque toujours du côté logiciel. Code fiscal erroné appliqué durant l'année. Catégorie de cotisation NI incorrecte dans le système de paie. Déclaration 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 saisies étaient fausses ou qu'un paramètre était mal configuré. La correction se fait dans le système de paie.

Mais il existe une deuxième catégorie d'erreurs P60 que les blogs paie, les guides des cabinets comptables et les pages d'avis 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 les sorties du logiciel correspondent aux déclarations HMRC. Le document source est le P60. La cible de la saisie est un tableur. Chaque champ saisi 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 participé à la saisie.

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 fiscal ne correspondant pas aux registres HMRC. Une erreur de saisie est détectée lorsque quelqu'un compare manuellement la cellule du tableur au PDF du P60. Si personne ne fait cette comparaison, l'erreur reste dans le tableur, alimente le rapport de rapprochement, et refait surface lorsqu'un employé remarque que son code fiscal est erroné — ou qu'un prêteur hypothécaire rejette une demande parce que le montant de 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 les symptômes d'un flux de travail où l'étape de saisie 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 prélevé — un échange de colonnes qui fait tout dérailler

Un P60 pour un salarié ayant occupé deux emplois au cours de la même année fiscale présente deux séries de chiffres faciles à confondre sous pression. « Salaire dans cet emploi » est le salaire brut de cet employeur spécifique. « Salaire total de l’année » inclut les salaires des emplois précédents, reportés du P45. « Impôt prélevé » dans cet emploi est le PAYE retenu par cet employeur. « Impôt total de l’année » agrège l’impôt de tous les emplois.

Sur un P60 imprimé par Sage, ces quatre chiffres peuvent apparaître dans deux colonnes adjacentes. Sur un P60 imprimé par Xero, ils peuvent être empilés verticalement. Sur un P60 papier apporté par un employé d’un ancien employeur il y a cinq ans, la disposition peut être totalement différente. Un opérateur de paie qui saisit 80 P60 par jour, en passant d’un format à l’autre toutes les quelques attestations, tape « Salaire dans cet emploi » dans la colonne « Impôt prélevé » une 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 nombre déclenche un contrôle automatisé — le ratio impôt/salaire. Quiconque voit une ligne de tableur 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 — donne un taux 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 une 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 à un petit écart de timing RTI, pas assez pour déclencher une nouvelle vérification complète de chaque ligne.

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

Quand une erreur humaine de transposition se combine à une mise en page de document source 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 entre les plans de prêt étudiant — Plan 1, 2, 4, 5 ou Postgraduate ?

Parmi les cinq erreurs de cet article, c'est celle dont les gestionnaires de paie sont le moins responsables — et celle qui génère le plus de réclamations de la part des employés, des mois après l'émission du P60. Le système de remboursement des prêts étudiants du Royaume-Uni compte désormais cinq types de plans, chacun avec un seuil de remboursement différent, et le plan d'un employé est déterminé par son lieu d'études, son année de diplôme et le type de cursus suivi.

La matrice se présente comme suit :

Les directives du HMRC pour les 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). Par défaut, le Plan 5 est un repli administratif judicieux — mais cela signifie que tout employé qui est en réalité sur le Plan 1, 2 ou 4 mais n'en a pas informé son employeur se voit appliquer des déductions calculées sur le mauvais seuil. Un emprunteur du Plan 1 (seuil 26 900 £) traité comme Plan 5 (seuil 25 000 £) commence à rembourser 1 900 £ de revenus plus tôt que prévu — ce qui, à 9 %, représente environ 171 £ de trop-perçu par an. Un emprunteur du Plan 4 (seuil 33 795 £) traité comme Plan 5 (25 000 £) paie en trop sur 8 795 £ de revenus — soit environ 792 £ par an.

La dimension de transcription de cette erreur est plus subtile. Lorsqu'un opérateur de paie retranscrit les données du P60 dans un tableur de rapprochement, le P60 affiche un montant de déduction pour prêt étudiant — un seul chiffre en livres entières. Il n'indique pas quel plan a généré cette déduction. L'opérateur saisit 1 200 £ dans la colonne du tableur intitulée « Déductions pour prêt étudiant ». Le chiffre est correct. Le plan est invisible. Deux employés avec le même salaire et la même déduction 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 déductions P60 aux totaux FPS correspondra, car les montants des déductions sont corrects. L'erreur ne porte pas sur le montant — elle porte sur 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.