Six erreurs de saisie P45
qui surtaxent un nouvel embauché — et ce qu'il en coûte pour les corriger

Pourquoi une seule erreur sur un P45 n'en reste jamais une

Une erreur sur un P45 s'aggrave car le PAYE est cumulatif par conception. Contrairement à un reçu ou une facture — où un chiffre mal saisi n'affecte qu'un seul document — un P45 alimente la position de départ d'un calcul récurrent que votre logiciel de paie répète chaque période de paie pour le reste de l'année fiscale. Si le code fiscal, le salaire cumulé ou la base Semaine 1/Mois 1 est erroné lors de la configuration, le logiciel n'applique pas l'erreur une seule fois ; il la reporte dans chaque déclaration de paie (FPS) ultérieure jusqu'à ce que quelqu'un la détecte et corrige la base.

C'est la différence entre une erreur de P45 et la plupart des autres erreurs de saisie. L'employé sur le fil d'urgence fiscale n'a pas été surtaxé par un seul mauvais chiffre au premier mois — il a été surtaxé au premier, deuxième, troisième et quatrième mois, car le mauvais point de départ a généré des déductions erronées à chaque fois. Et comme HMRC ne rapproche les comptes qu'avec des données de revenus complètes, le remboursement n'arrive souvent qu'après correction du code fiscal en cours d'année ou, pire, après la fin de l'année fiscale. La conséquence d'une faute de frappe de deux secondes se mesure en mois de trésorerie pour l'employé.

Les six erreurs ci-dessous sont celles qui reviennent sur les forums de paie et dans les guides de correction d'HMRC. Chacune est assez spécifique pour que vous sachiez si vous l'avez commise — et chacune a une cause profonde qui n'est pas « être plus attentif ».

Erreur 1 : Inverser un chiffre dans le code fiscal

L'erreur la plus courante sur un P45 est l'inversion d'un seul chiffre dans le code fiscal — 1257L saisi comme 1275L, ou 1250L comme 1205L. Cela semble anodin car c'est un seul caractère, mais le nombre dans un code fiscal correspond à l'abattement fiscal de l'employé divisé par dix. 1257L accorde 12 570 £ de revenu non imposable ; 1275L accorde 12 750 £ ; 1205L accorde 12 050 £. Un mauvais code signifie que l'employé reçoit un abattement auquel il n'a pas droit (et devra le rembourser) ou se voit refuser un abattement auquel il a droit (et paie trop jusqu'à correction).

La cause profonde n'est pas la négligence — c'est que les codes fiscaux sont des chaînes de chiffres sans contrôle interne, lues sur un document et saisies sur un autre sous pression. Rien dans « 1275L » ne semble erroné. C'est un code valide ; il correspond simplement à un abattement différent. Et comme le logiciel de paie accepte tout code bien formé sans vérifier s'il correspond au P45, l'erreur passe silencieusement dans la première paie.

La correction, une fois en place, passe par HMRC plutôt qu'une simple modification : HMRC émet un code révisé via un avis P6 ou P9, et votre logiciel l'applique à l'avenir. Si le code était cumulatif, le bulletin suivant corrige généralement la position cumulée. S'il était en base Semaine 1/Mois 1, le trop-perçu ou le moins-perçu reste en suspens jusqu'à la fin de l'année. Dans les deux cas, la correction est plus lente que l'erreur.

Erreur n°2 : Saisir une date de départ erronée — ou vide

Une date de départ erronée fausse la position du salarié dans la chronologie de l'année fiscale, et une date vide qui prend une valeur par défaut (les systèmes de paie transforment parfois une date vide en 01/01/1900) peut créer un doublon de fiche PAYE auprès du HMRC. La date de départ sur le P45 indique à votre logiciel la semaine ou le mois fiscal au cours duquel l'emploi précédent s'est terminé, ce qui détermine le point de départ du nouvel emploi. Si vous la saisissez mal, le calcul cumulatif s'ancre au mauvais endroit dans l'année.

Le guide du HMRC sur la correction d'un FPS est explicite quant à la complexité du nettoyage en aval : si une date de paiement ou de départ est mal déclarée et qu'un indicateur de « paiement après départ » est impliqué, vous ne devez pas saisir les mêmes montants dans les champs « paie de la période » et « paie cumulée depuis le début de l'année », sinon vous créez un doublon pour le salarié — vous devez mettre 0,00 dans le champ « paie de la période » et réaligner la paie sur la bonne période fiscale. C'est un rapprochement en plusieurs étapes déclenché par une seule date mal saisie.

La cause profonde est que les dates de départ sont faciles à confondre : la date de fin d'emploi du salarié, la date de son dernier paiement et la date de réception du P45 sont trois choses différentes, et la présentation du P45 ne rend pas toujours la distinction évidente. Saisissez la date de paiement là où devrait figurer la date de départ, et la chronologie se décale.

Erreur n°3 : Confondre « Total des gains depuis le début de l'année » et « Gains dans cet emploi »

Lorsqu'un salarié a occupé plusieurs emplois, le P45 affiche deux montants de paie — « Total des gains depuis le début de l'année » (cumul sur tous les emplois de l'année fiscale) et « Gains dans cet emploi » (uniquement l'emploi quitté) — et saisir le mauvais dans le champ « cumul depuis le début de l'année » de votre logiciel déclare des revenus cumulés erronés au HMRC. Les deux chiffres sont délibérément différents, et un seul d'entre eux doit figurer dans le champ qui alimente le calcul de l'impôt cumulé.

Mettez « Gains dans cet emploi » là où devrait aller « Total des gains depuis le début de l'année », et vous sous-estimez les revenus du salarié pour l'année. Le logiciel pense alors que le salarié dispose d'un abattement personnel inutilisé plus important qu'en réalité, sous-déduit l'impôt pendant plusieurs mois, et le déficit se manifeste plus tard par une correction brutale du code fiscal — le HMRC récupère l'impôt sous-payé en réduisant l'abattement dans le code, de sorte que le salarié voit soudain une retenue bien plus élevée pour récupérer ce qui n'a jamais été prélevé.

Cette erreur piège les administrateurs expérimentés, pas seulement les débutants, car sur un P45 pour un seul emploi, les deux chiffres sont identiques — l'habitude de « prendre le montant de paie » fonctionne jusqu'à ce qu'elle échoue silencieusement sur un départ multi-emplois. La cause profonde est que la distinction n'a d'importance que parfois, ce qui est précisément le moment où une copie mécanique échoue. La ventilation champ par champ de la signification de chaque case du P45 vaut la peine d'être conservée à portée de main, justement pour ces cas à deux chiffres.

Erreur n°4 : Traiter un code Semaine 1/Mois 1 comme cumulatif

Un code fiscal portant le suffixe « W1 » ou « M1 » — par exemple, 1257L M1 — est non cumulatif. Ignorer ce suffixe (en saisissant le code comme un simple 1257L) indique à votre logiciel de répartir l'abattement de manière cumulative, ce qu'il ne doit pas faire. Semaine 1/Mois 1 signifie que chaque période de paie est imposée isolément, en utilisant uniquement le salaire de cette période et en ignorant tout ce qui précède dans l'année. Supprimez le suffixe et la base de calcul bascule.

La conséquence va dans le sens où la base ignorée l'a poussée. Si l'employé doit réellement être en M1 (le HMRC l'applique souvent lorsque ses dossiers de l'année précédente étaient incomplets) et que vous saisissez un code cumulatif, le logiciel peut restituer un abattement que l'employé a déjà utilisé ailleurs, entraînant une sous-déduction maintenant et une facture plus tard. L'erreur inverse — laisser un code d'urgence M1 actif alors que le HMRC a depuis émis un code cumulatif — maintient l'employé surimposé car l'abattement ne s'accumule jamais sur les périodes.

La cause profonde est que le drapeau W1/M1 est un suffixe de deux caractères qui semble anodin mais qui modifie tout le calcul. Il est facile de traiter « 1257L M1 » et « 1257L » comme le même code avec une étiquette superflue. Ce ne sont pas les mêmes codes. Un détail intentionnel : un véritable code W1/M1 sur un P45 est une instruction officielle du HMRC à saisir tel quel — pas une erreur à « nettoyer » en rendant les chiffres cumulatifs.

Erreur n°5 : Saisir erronément le numéro de Sécurité sociale

Un mauvais numéro de Sécurité sociale empêche le HMRC de faire correspondre le nouveau salarié à son dossier existant, ce qui peut entraîner le rejet du premier FPS ou, pire, l'affectation au compte d'une autre personne. Le NINO est la clé d'identité que le HMRC utilise pour rapprocher un individu de tous ses emplois passés. Son format est rigide — deux lettres, six chiffres, une lettre suffixe (ex. QQ 12 34 56 C) — mais un format rigide n'empêche pas une inversion de chiffres, et un NINO bien formé mais erroné semble parfaitement valide.

Lorsque le numéro ne correspond pas, les cotisations de Sécurité sociale et le PAYE que vous déclarez peuvent être crédités au mauvais dossier. Pour l'employé, cela peut signifier des lacunes dans son historique de cotisations — le genre qui affecte plus tard les années de validation pour la retraite d'État ou les droits aux prestations basées sur les cotisations — et le problème reste invisible jusqu'à ce qu'il consulte un relevé des années plus tard. Certains préfixes ne sont jamais attribués (les lettres D, F, I, Q, U et V ne sont jamais utilisées comme première lettre ; O n'est jamais la seconde), ce qui signale une erreur évidente, mais un numéro erroné plausible passe inaperçu.

La cause profonde est qu'un NINO est un identifiant de neuf caractères sans signification permettant une vérification de cohérence — on ne peut pas le regarder et dire qu'il est faux comme on pourrait remettre en question un salaire invraisemblable. Soit il correspond au dossier du HMRC, soit non, et on le découvre en aval.

Erreur n°6 : Ne pas cocher la case « prêt étudiant » — ou deviner le plan

Le P45 signale un prêt étudiant par un simple « Y » dans la case 5, sans autre précision — il n'indique pas le plan concerné. Ainsi, omettre la coche ou deviner le plan entraîne des retenues mensuelles erronées. Selon le Chartered Institute of Payroll Professionals (CIPP), lorsqu'un P45 mentionne « Y » dans la case prêt étudiant, les retenues doivent débuter dès le prochain jour de paie. Mais comme le formulaire ne distingue pas les plans 1, 2, 4 ou 5, c'est au salarié de vous indiquer lequel s'applique.

Deux erreurs distinctes se cachent ici. La première consiste à ignorer complètement l'indicateur — la case à cocher est petite, et si elle passe inaperçue, les remboursements du salarié s'arrêtent dès son changement d'emploi, accumulant silencieusement un arriéré que le Student Loans Company réclamera plus tard. La seconde est de deviner le plan. Les directives de l'HMRC pour les employeurs précisent que si le salarié ne peut pas indiquer son plan, vous devez par défaut utiliser le plan 5 dans votre logiciel de paie jusqu'à réception d'un avis de début SL1 — vous n'inventez pas un plan et ne déduisez pas d'arriérés pour la période précédant la réception du P45. Choisir le mauvais plan fausse le seuil, donc le pourcentage est appliqué à la mauvaise tranche de salaire chaque mois jusqu'à ce qu'un SL1 corrige la situation.

La cause profonde est une lacune structurelle que le CIPP a ouvertement sondée auprès de ses membres : le P45 ne comporte tout simplement pas le type de plan, donc le formulaire lui-même ne peut pas fournir assez d'informations pour effectuer la retenue correcte. Cela en fait moins une erreur de transcription qu'un angle mort connu — que l'on comble en capturant précisément l'indicateur, puis en confirmant le plan avec le salarié ou via l'avis SL1, sans présumer.

Ce qu'il faut réellement pour corriger une erreur de P45 après la paie

Corriger une erreur de P45 n'est jamais aussi rapide que l'erreur qui l'a causée, et dans certaines circonstances, cela expose l'employeur à une pénalité. La première chose à savoir est que vous ne pouvez pas simplement réémettre un P45 corrigé — l'HMRC interdit de le modifier ou de le régénérer, car un second P45 créerait des enregistrements PAYE en double. Toute correction doit passer par le système Real Time Information.

Le logiciel de paie rend les opérations mécaniques possibles, mais pas indolores. BrightPay, par exemple, exige de rouvrir les fiches de paie concernées avant de pouvoir les modifier, et propose un sélecteur dédié aux prêts étudiants pour cette correction spécifique ; IRIS Staffology expose une fonction « Earlier Year FPS » par employé pour les corrections d’exercices clos. Ces outils existent précisément parce que ces corrections sont courantes — mais chacune est un rapprochement manuel, pas un annulé en un clic.

Le risque le plus sérieux, c’est la pénalité. Les erreurs sur les déclarations RTI relèvent de l’Annexe 24 de la Loi de finances 2007, et comme le CIPP le résume, lorsqu’une déclaration inexacte sous-estime l’impôt dû, le HMRC peut facturer 30 % du manque à gagner potentiel pour une inexactitude par négligence, 70 % pour une inexactitude délibérée, et jusqu’à 100 % si elle est délibérée et dissimulée. Un chiffre mal saisi sur un P45 ne sera probablement pas jugé délibéré — mais « négligence » est exactement la catégorie dans laquelle tombe une erreur de transcription, et la défense consiste à prouver que vous avez fait preuve de diligence raisonnable. Le HMRC n’inflige une pénalité « que si vous n’avez pas fait preuve de diligence raisonnable ou si vous l’avez fait délibérément », ce qui fait de la présence ou non d’un processus de saisie contrôlé et vérifiable la différence entre une correction et une amende.

D’où viennent ces erreurs — et la solution qui supprime l’étape de transcription

Chacune de ces six erreurs partage une cause unique : un humain lit une valeur sur un document et la retape dans un autre, sans couche de correction d’erreur entre les deux. Le code fiscal n’est pas faux sur le P45 ; il devient faux lors de la retranscription. La solution n’est donc pas « vérifier plus attentivement » — c’est supprimer la retranscription.

C’est plus difficile qu’il n’y paraît avec les P45, car il n’existe pas de mise en page standard. Le HMRC impose quelles données un P45 doit contenir, mais pas leur apparence ; ainsi, un P45 produit par Sage 50 Payroll place le code fiscal à un endroit différent de celui de BrightPay, Xero ou QuickBooks UK. La reconnaissance optique basée sur des modèles — qui dépend de la connaissance de l’emplacement de chaque champ sur la page — échoue dès qu’un P45 provient d’un fournisseur de paie dont la mise en page n’est pas prévue. C’est pourquoi le « dénominateur commun » a toujours été une personne lisant le PDF.

ImageToTable.ai supprime la retranscription sans nécessiter de modèle pour chaque fournisseur. Il utilise l’Extraction de colonnes personnalisées : au lieu d’indiquer à l’outil où se trouve le code fiscal sur chaque mise en page, vous saisissez les noms de champs dont votre configuration de paie a besoin — « Tax Code at Leaving », « Total Pay to Date », « Pay in This Employment », « Leaving Date », « NINO », « Student Loan Indicator », « Week1/Month1 Basis » — et l’IA lit chaque P45 en comprenant ce que ces champs étiquetés signifient, où qu’ils apparaissent, sur n’importe quelle mise en page de fournisseur. La définition de colonne est écrite une fois et réutilisée pour chaque nouveau collaborateur tout au long de l’exercice fiscal. Comme l’outil capture à la fois « Total Pay to Date » et « Pay in This Employment » comme colonnes distinctes, et préserve le suffixe W1/M1 tel qu’imprimé, les deux erreurs qui dépendent de la confusion entre champs (Erreurs 3 et 4) ne surviennent pas lors de l’étape d’extraction.

L'extraction ne garantit pas une exactitude parfaite : elle élimine le mode de défaillance spécifique à l'origine de ces six erreurs. Vous devez toujours valider la paie : un rapide contrôle dans Excel qui signale un NINO qui ne fait pas neuf caractères, un code fiscal qui ne se termine pas par une lettre valide, ou un montant d'impôt qui n'est pas une proportion plausible du salaire. Mais vous vérifiez quelques lignes signalées par rapport à la source, sans retranscrire manuellement chaque champ de chaque P45 en espérant ne pas inverser un chiffre. Pour les équipes qui souhaitent un contexte plus large — gestion par lots, formules de validation et jeu de champs complet — le guide complet d'extraction des P45 britanniques et la répartition des coûts du traitement manuel des P45 reprennent là où cet article s'arrête.

FAQ