Six erreurs de saisie de P45
qui surimposent un nouveau venu — et ce qu'il en coûte de les corriger

Pourquoi une seule erreur de champ sur un P45 ne reste jamais une seule erreur

Une erreur sur un P45 s'aggrave parce que le PAYE est cumulatif par conception. Contrairement à un reçu ou une facture — où un chiffre mal saisi est erroné sur un seul document — un P45 alimente la position de départ d'un calcul continu 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 sont incorrects à la configuration, le logiciel n'applique pas cette erreur une seule fois ; il la reporte dans chaque Full Payment Submission (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'imposition d'urgence n'a pas été surimposé par un seul mauvais chiffre au premier mois — il a été surimposé au premier, deuxième, troisième et quatrième mois, parce que le mauvais point de départ continuait de générer de mauvaises retenues. Et comme HMRC ne rapproche la situation qu'une fois qu'il dispose de 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 le plus souvent sur les forums de paie et dans les guides de correction de HMRC. Chacune est suffisamment spécifique pour que vous sachiez si vous l'avez commise — et chacune a une cause racine qui n'est pas « soyez plus prudent ».

Erreur 1 : Inverser un chiffre dans le code fiscal

L'erreur de P45 la plus courante est un seul chiffre inversé dans le code fiscal — 1257L saisi comme 1275L, ou 1250L comme 1205L. Cela semble trivial car il s'agit d'un seul caractère, mais le nombre dans un code fiscal correspond à l'allocation exonérée de l'employé divisée par dix. 1257L accorde 12 570 £ de revenu exonéré ; 1275L en accorde 12 750 £ ; 1205L en accorde 12 050 £. Un mauvais code signifie que l'employé reçoit soit une allocation à laquelle il n'a pas droit (et devra la rembourser), soit se voit refuser une allocation à laquelle il a droit (et paie trop jusqu'à ce que ce soit corrigé).

La cause racine n'est pas la négligence — c'est que les codes fiscaux sont des chaînes de chiffres sans contrôle interne, lues sur une mise en page et saisies dans une autre sous pression de temps. Rien dans « 1275L » ne semble anormal. C'est un code au format valide ; il appartient simplement à une allocation différente. 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 exécution de paie.

La correction, une fois détectée, passe par HMRC plutôt que par 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 automatiquement la position cumulée depuis le début de l'année. S'il était sur une base Semaine 1/Mois 1, le trop-perçu ou le manque à percevoir reste non résolu jusqu'à la fin de l'année. Dans les deux cas, la correction est plus lente que l'erreur.

Erreur 2 : Saisir une date de départ incorrecte — ou vide

Une date de départ incorrecte fausse la position de l'employé dans la chronologie de l'année fiscale, et une date vide qui prend une valeur par défaut (certains systèmes de paie convertissent une date vide en 01/01/1900) peut créer un enregistrement PAYE en double auprès du HMRC. La date de départ sur le P45 indique à votre logiciel quelle semaine ou quel mois fiscal l'emploi précédent s'est terminé, ce qui détermine ensuite où le nouvel emploi reprend. Saisissez-la incorrectement et le calcul cumulatif est ancré au mauvais point de l'année.

Les conseils du HMRC sur la correction d'un FPS sont explicites sur la complexité du nettoyage en aval : si une date de paiement ou une date 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 « paye de la période » et « paye cumulée depuis le début de l'année », sinon vous créez un enregistrement en double pour l'employé — vous devez mettre 0,00 dans le champ de la paye 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, la date du dernier paiement et la date de réception du P45 sont trois choses différentes, et les formats de P45 ne rendent pas toujours la distinction évidente. Saisissez la date de paiement à la place de la date de départ et la chronologie se décale.

Erreur 3 : Confondre « Total Pay to Date » avec « Pay in This Employment »

Lorsqu'un employé a occupé plusieurs emplois, le P45 affiche deux montants de paie — « Total Pay to Date » (cumul sur tous les emplois de l'année fiscale) et « Pay in This Employment » (uniquement l'emploi quitté) — et saisir le mauvais dans le champ cumulé de votre logiciel fausse la déclaration des revenus cumulés de l'employé auprès du HMRC. Les deux chiffres sont différents à dessein, et un seul d'entre eux doit être saisi dans le champ qui alimente le calcul de l'impôt cumulé.

Mettez « Pay in This Employment » là où « Total Pay to Date » devrait aller, et vous sous-estimez les revenus de l'employé pour l'année. Le logiciel pense alors que l'employé a plus d'abattement personnel non utilisé qu'il n'en a réellement, sous-déduit l'impôt pendant plusieurs mois, et le manque à gagner ressort plus tard sous la forme d'une désagréable correction de code fiscal — le HMRC récupère l'impôt sous-payé en réduisant l'abattement dans le code, si bien que l'employé voit soudainement une déduction bien plus importante pour récupérer ce qui n'a jamais été prélevé.

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

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