15 départs ce mois-ci, 15 P45
Créez une base de données des départs sans double saisie
En vertu de l'article 36 du règlement de 2003 sur l'impôt sur le revenu (Pay As You Earn) (SI 2003/2682), chaque employeur britannique doit émettre un P45 lorsqu'un salarié cesse de travailler pour lui — rempli le jour de la fin de l'emploi « ou sans retard injustifié ». Le règlement ne fait pas de distinction entre une entreprise qui perd un salarié en mars et une entreprise qui en perd quinze lors d'une restructuration. Dans les deux cas, quinze formulaires P45 doivent être générés, quinze parties 1 soumises à HMRC via RTI, et quinze ensembles de parties 1A, 2 et 3 remis aux salariés partants — pendant que les RH suivent les motifs de départ, que les managers confirment les dates de fin, et que l'informatique récupère le matériel. Le P45 en lui-même n'est pas le goulot d'étranglement : Sage 50cloud, BrightPay, QuickBooks Online Payroll, Moorepay et IRIS génèrent chacun un P45 conforme en quelques secondes pour un seul départ. Le goulot d'étranglement est le fossé structurel entre un logiciel de paie qui raisonne salarié par salarié, et une opération RH qui doit suivre quinze départs en un mois, vérifier que les parties 2 et 3 ont bien été remises à chaque partant, et alimenter les analyses de turnover avec ces données de départ — sans ressaisir manuellement le même NI Number, la date de départ, le total des salaires et l'impôt payé dans un tableur séparé.
Points clés à retenir
- Chaque P45 généré par votre logiciel de paie contient déjà les champs nécessaires pour votre base de données des départs — mais quelqu'un les ressaisit tous dans un tableur que la paie ne voit jamais, pendant que les données d'origine restent inexploitées dans des archives PDF.
- Dès que vous remettez le P45 au salarié, ses données de salaire et d'impôt deviennent mortes — vous ne pouvez pas agréger qui est parti, ce qu'ils ont gagné, ou si leurs codes fiscaux suivent un schéma, car les données ont été générées mais jamais capturées.
- Téléversez les P45 des départs du mois en un seul lot après chaque cycle de paie avec un schéma de colonnes fixe — la même extraction alimente la vérification de conformité HMRC et les analyses RH des départs, et six lots mensuels empilés deviennent une base de données des départs interrogeable que personne n'a eu à saisir.
Les départs mensuels sont un problème différent d'un P45 unique
L'exercice annuel du P60 n'a lieu qu'une fois. Chaque employé présent dans la paie au 5 avril en reçoit un. L'équipe paie peut réserver une semaine en mai, exécuter le lot et rapprocher les données avec les déclarations de paiement intégrales (Full Payment Submissions). Le processus des départs mensuels — en revanche — est un élément permanent du calendrier de paie. Chaque mois, entre deux et vingt employés quittent l'entreprise : démissions, licenciements, fins de contrat à durée déterminée, départs à la retraite. Chaque départ génère un P45. Et chaque P45 n'est pas seulement une obligation de conformité envoyée à HMRC et remise au salarié partant — c'est aussi un point de données dont les RH ont besoin pour un tout autre objectif : savoir qui est parti, pourquoi, ce qui lui a été versé, et si son départ s'inscrit dans une tendance.
Traiter un P45 unique est simple. Extraire ses champs dans un tableur demande de l'attention, pas des outils spécialisés. Dès que vous traitez les départs au rythme mensuel auquel la plupart des entreprises fonctionnent réellement, trois problèmes structurels apparaissent qui n'existent pas à l'échelle d'un départ unique.
1. Les informations arrivent de trois directions, à trois moments différents
Les RH reçoivent la lettre de démission et connaissent la date de départ en premier — et cette lettre est aussi une donnée structurée, donc convertir une lettre de licenciement en Excel enregistre le dernier jour travaillé, le motif de séparation et le préavis avant même que le P45 ne soit généré. La paie peut ne pas recevoir la notification officielle pendant des jours — surtout si le manager retarde l'approbation. Au moment où le P45 est généré via Sage ou BrightPay, les RH ont déjà enregistré le départ dans le SIRH. Le P45 contient désormais des données — NI number, salaire total, impôt payé, code fiscal final — que le tableur de suivi des départs des RH ne possède pas. Quelqu'un copie manuellement ces champs. Pour quinze départs, cela représente quinze opérations de copier-coller entre systèmes chaque mois, chacune étant un écart potentiel entre ce que les RH ont enregistré et ce que la paie a réellement traité.
2. Le P45 en quatre parties crée sa propre piste d'audit — mais seulement si vous la préservez
La partie 1 est envoyée à HMRC via RTI lors de la soumission du Full Payment Submission. Les parties 1A, 2 et 3 vont à l'employé. L'employé conserve la partie 1A et remet les parties 2 et 3 à son nouvel employeur. Du point de vue de l'employeur émetteur, une fois le P45 généré et remis, les données sous-jacentes vivent dans les archives du logiciel de paie — pas dans un format que les RH peuvent interroger. Si trois mois plus tard quelqu'un demande « combien de départs au T1 avaient un salaire total supérieur à £30,000 », la réponse se trouve dans les dossiers individuels des employés de Sage, pas dans un rapport. Les données ont été générées. Elles n'ont simplement jamais été capturées.
3. Les cas particuliers se multiplient avec le volume
Une entreprise traitant trois départs par mois peut rencontrer un cas particulier. Une entreprise qui en traite quinze en rencontrera trois ou quatre chaque mois : le départ dont le dernier salaire inclut une grosse prime qui pousse le total cumulé au-dessus d'un seuil fiscal ; le départ à revenu nul (présent sur la paie avec un code fiscal mais jamais réellement payé) qui nécessite quand même un P45 en vertu du règlement 36 ; l'employé qui a donné son préavis en mars mais dont le dernier jour travaillé tombe le 7 avril — franchissant une limite d'année fiscale et modifiant les totaux cumulés de l'année qui apparaissent sur le P45. Chaque cas particulier interrompt un flux de travail manuel : vous arrêtez la transcription, examinez l'exception, la résolvez, puis reprenez. À l'échelle des lots, ces interruptions sont le flux de travail.
Le lot mensuel de départs n'est pas une version réduite de l'exercice annuel du P60. C'est un problème différent — où le P45 est à la fois un document de conformité que vous devez émettre, un enregistrement de paie que vous devez archiver, et un point de données de départ dont votre équipe RH a besoin pour une raison totalement indépendante. Le même PDF de P45 peut servir ces trois objectifs — si vous cessez de le traiter comme un formulaire à imprimer et commencez à le traiter comme une source de données structurée.
Le P45 en 4 parties à grande échelle : où va chaque partie et ce qui peut mal tourner
Le P45 se compose de quatre parties. Cette distinction est cruciale dans un flux de traitement par lots, car une erreur d'acheminement à grande échelle crée une cascade de corrections que le traitement manuel, un par un, masque.
Partie 1 — à HMRC (via RTI)
Envoyée automatiquement lorsque votre logiciel de paie transmet la Full Payment Submission signalant le départ du salarié. Vous n'envoyez pas physiquement la Partie 1 — le logiciel de paie génère les données P45 et les transmet dans le cadre de la déclaration RTI.
Partie 1A — dossier personnel du salarié
Le salarié la conserve. Elle contient les mêmes données que les Parties 2 et 3 — salaire total, impôt total, code d'imposition, date de départ — mais est destinée aux dossiers fiscaux personnels du salarié. Aucun nouvel employeur ne la voit.
Partie 2 — nouvel employeur (dossier fiscal)
Le nouvel employeur l'utilise pour configurer le dossier de paie du salarié avec le bon code d'imposition et les montants cumulés depuis le début de l'année. Sans la Partie 2, le nouvel employeur doit utiliser une Starter Checklist — ce qui aboutit souvent à un code d'imposition d'urgence jusqu'à ce que HMRC le corrige.
Partie 3 — nouvel employeur (confirmation)
Le nouvel employeur complète la Partie 3 avec sa propre référence PAYE, la date de début et le code d'imposition qu'il utilisera — puis envoie la Partie 3 à HMRC. Cela confirme la transition d'emploi et permet à HMRC de rapprocher le dossier fiscal du salarié sur la période entre deux emplois.
Dans un flux avec un seul départ, l'acheminement des quatre parties est une simple case à cocher : Partie 1 déclarée, Parties 1A/2/3 remises. Dans un lot de quinze, l'acheminement devient un problème de suivi. Quels départs ont été signalés comme tels sur la FPS ? Toutes les Parties 2 et 3 sont-elles correctement associées au bon salarié — ou quelqu'un a-t-il remis le P45 de John Smith à l'autre John Smith ? Si un salarié sortant perd son P45, vous ne pouvez pas en délivrer un duplicata (HMRC l'interdit explicitement) — vous ne pouvez fournir qu'une attestation de revenus. Cela signifie que le PDF P45 unique que vous avez généré est le seul document officiel. Le perdre — ou le mal acheminer — est une erreur irréparable.
La protection pratique à l'échelle des lots consiste à capturer les données de chaque P45 dans une feuille de calcul au moment de la génération — avant que les Parties 1A/2/3 ne quittent vos mains. La feuille de calcul devient votre registre d'audit interne : preuve du contenu de chaque P45, de sa date d'émission et du salarié concerné. Si un ancien salarié vous contacte six mois plus tard en affirmant que son P45 affichait un mauvais code d'imposition, vous disposez d'une ligne vérifiable — pas d'un accès au système de paie et d'un souvenir de ce que vous pensez avoir imprimé.
Du P45 PDF à la base de données des départs : des colonnes au service de HMRC et des RH
Les noms de colonnes que vous définissez avant d'importer un lot de P45 sont la décision la plus déterminante du processus. Un schéma de colonnes conçu uniquement pour la conformité de la paie capture les champs obligatoires — salaire total, impôt total, code d'imposition, date de départ — et s'arrête là. Cela suffit pour vérifier le P45 par rapport au FPS. Cela ne suffit pas pour alimenter les analyses de départs des RH, où les questions sont différentes : quels services perdent des collaborateurs, quels sont les schémas de codes d'imposition courants parmi les départs, les départs mieux rémunérés partent-ils pour des raisons différentes de ceux moins bien rémunérés.
Un schéma de colonnes qui sert les deux objectifs repose sur trois niveaux. Le premier niveau assure la conformité. Le deuxième fournit aux RH des données réellement exploitables. Le troisième fait remonter les anomalies avant qu'elles ne deviennent des demandes de HMRC.
1. Colonnes d'identité — la clé composite du départ
NI Number, nom du collaborateur, date de départ et référence PAYE. Le NI Number est la clé primaire naturelle — il est unique, permanent et figure sur chaque P45. La référence PAYE (format NNN/XXNNNNN selon PAYE20005) identifie le régime employeur auquel ce P45 appartient — essentiel si votre entreprise gère plusieurs régimes PAYE ou a acquis une autre entité. Inclure la date de départ dans le bloc d'identité permet de distinguer un collaborateur parti, revenu, puis reparti.
2. Colonnes financières et fiscales — le noyau statutaire
Salaire total à ce jour (£), impôt total à ce jour (£), code d'imposition à la date de départ, indicateur Semaine 1 / Mois 1 (capturer le suffixe « X »), déductions de prêt étudiant (Plan 1, Plan 2, Plan 4, Postgraduate — les séparer en colonnes individuelles est essentiel : une seule colonne « Prêt étudiant (£) » rend impossible la distinction du plan auquel chaque déduction se rapporte, et les avis d'arrêt SL1/SL2 de HMRC sont spécifiques à chaque plan).
3. Colonnes d'analyse RH — transformer les données de conformité en intelligence sur les départs
Ce sont des colonnes qui n'apparaissent pas sur le P45 mais qui sont renseignées à partir des données du P45 lors de l'extraction. Une colonne inférée « Catégorie de départ » — où l'IA classe le départ en fonction du contexte que vous fournissez (options : Démission / Licenciement / Départ volontaire / Retraite / Fin de contrat à durée déterminée). Une colonne calculée « Type de code d'imposition » qui classe chaque code comme « Cumulatif / Non cumulatif (M1/W1) / BR-D0-D1 / Code K / NT » — un départ avec un code K (les déductions dépassent les abattements) raconte une histoire différente sur la main-d'œuvre qu'un départ avec un code 1257L. Une colonne « Trimestre de départ » dérivée de la date de départ pour une segmentation instantanée en tableau croisé dynamique. Aucune de ces colonnes n'augmente le travail de saisie — l'IA les renseigne lors de la même passe d'extraction qui lit les champs statutaires.
Pour un exemple concret d'extraction des champs obligatoires d'un seul P45 — le NI number, le code fiscal, les montants du salaire total et de l'impôt — le guide d'extraction d'un P45 unique détaille chaque champ. Cet article reprend là où celui-ci s'arrête : ce qui change lorsque vous intégrez quinze P45 dans le même schéma de colonnes chaque mois, et la base de données à long terme que vous construisez ainsi.
Le schéma est ce qui rend une configuration P45 vers Excel réutilisable mois après mois — définissez les colonnes une fois et chaque départ ultérieur arrive comme une nouvelle ligne sous les mêmes en-têtes, sans re-mappage entre les lots.
Coordination multi-départements : combler l'écart entre la notification RH et l'émission du P45
La réglementation P45 stipule « le jour où l'emploi prend fin ou sans retard déraisonnable ». En pratique, cette déclaration masque une chaîne de coordination. Les RH reçoivent la démission. Le responsable hiérarchique confirme la date de fin de travail — parfois plusieurs jours plus tard. La paie reçoit la notification officielle de départ — parfois après la confirmation du responsable, parfois avant, selon que le processus de l'entreprise est piloté par les RH ou par la paie. La paie traite ensuite le salaire final, marque l'employé comme sortant dans Sage ou BrightPay, génère le P45 et soumet le FPS. Ce n'est qu'à ce moment-là que le P45 existe. Le temps entre « le salarié démissionne » et « le P45 est généré » peut aller du jour même à deux semaines — et pendant cet intervalle, les RH ont déjà enregistré le départ dans un tableur qui ne contient pas encore les données du P45.
C'est le coût caché d'une base de données de sorties manuelle : une saisie de données en double, effectuée dans deux systèmes différents à deux moments différents. Les RH saisissent le nom du sortant, le département, le motif de départ et la date finale lorsque la démission est confirmée. La paie saisit le même nom, le NI number, le salaire total, l'impôt total et le code fiscal lorsque le P45 est généré — une semaine plus tard. Les deux ensembles de données se rencontrent rarement dans le même tableur. Le résultat est un suivi des sorties RH qui sait pourquoi les gens sont partis mais pas ce qu'ils ont gagné, et une archive de paie qui sait ce que les gens ont gagné mais pas pourquoi ils sont partis.
Le flux de travail par lots élimine cet écart non pas en modifiant le processus de chacun, mais en modifiant le moment de la capture des données. Au lieu que la paie génère les P45 et que les RH tiennent séparément un suivi des sorties, les PDF des P45 deviennent la source unique pour les deux. Téléversez le lot de P45 du mois après le cycle de paie — lorsque tous les sortants ont été traités et tous les P45 générés — et extrayez-les dans un tableur qui inclut à la fois les champs de paie obligatoires (issus du P45 lui-même) et les champs de contexte RH (issus des colonnes inférées). Une seule passe d'extraction. Les deux équipes obtiennent leurs données. L'équipe RH ajoute la colonne du motif de départ en se basant sur les lettres de démission qu'elle possède déjà ; l'équipe de paie vérifie les chiffres fiscaux par rapport au FPS. Les deux travaillent à partir du même NI number, de la même date de départ, de la même ligne.
Pour les entreprises qui gèrent déjà les P60 en fin d'année avec une approche similaire, le flux de travail mensuel des P45 suit le même modèle : standardiser les noms de colonnes, traiter par lot mensuel, vérifier par rapport au FPS. Le flux de travail d'audit par lots des P60 couvre en détail la dénomination des fichiers, la conception des colonnes et la fusion multi-employeurs — le schéma de colonnes est spécifique au document, mais l'approche par lots est identique.
Réalité multi-éditeurs : Sage, BrightPay, QuickBooks et le départant qui a changé de service en cours d'année
HMRC n'impose pas de format unique pour le P45. Selon les spécifications RTI d'HMRC, le logiciel de paie doit inclure les champs obligatoires — référence PAYE de l'employeur, numéro NI du salarié, nom, date de départ, code fiscal, rémunération totale, impôt total — mais la disposition visuelle est laissée à chaque éditeur. Résultat : un P45 de Sage 50cloud Payroll diffère d'un P45 de BrightPay, qui diffère d'un P45 de QuickBooks Online Payroll, qui diffère d'un P45 de Moorepay. Le numéro NI peut figurer en haut à droite sur l'un et sous le nom du salarié sur un autre. Le code fiscal peut être imprimé à côté de la référence PAYE sur l'un et dans un encadré séparé sur un autre.
Cette variation de mise en page engendre un coût subtil mais significatif lors du traitement manuel par lots. Chaque fois que l'administrateur paie passe d'un P45 Sage à un P45 BrightPay, il doit visuellement re-scanner pour localiser chaque champ. Sur quinze P45 répartis entre trois fournisseurs de paie — ce qui arrive naturellement lorsqu'une entreprise en acquiert une autre et hérite de son logiciel de paie pour une période de transition — ce re-scan visuel ajoute environ dix secondes par document. Sur un mois de départs, cela représente des minutes de lecture morte avant la moindre frappe de transcription.
L'extraction sémantique élimine ce re-scan spécifique à chaque éditeur en lisant le document pour son sens plutôt que pour sa position. Vous définissez la colonne souhaitée — « Numéro NI » — une fois. L'IA localise le numéro NI sur un P45 Sage en comprenant à quoi ressemble un numéro d'assurance nationale (deux lettres, six chiffres, une lettre : AB123456C), et non en sachant que Sage l'imprime aux coordonnées (x=72mm, y=38mm). Un P45 BrightPay, un P45 QuickBooks, un P45 Moorepay et un P45 papier scanné d'un employé qui a perdu le sien alimentent tous la même définition de colonne. La colonne de sortie se remplit à l'identique quel que soit le fournisseur.
Ce comportement indépendant du fournisseur est particulièrement utile dans le scénario courant où un employé parti en cours d'année était sur un système de paie différent du système actuel. Une entreprise passée de Sage à BrightPay en septembre aura des partants dont les P45 ont été générés par Sage (départs avant septembre) et des partants dont les P45 ont été générés par BrightPay (départs après septembre). Dans un flux manuel, l'administrateur paie traite chaque lot séparément car les deux mises en page de P45 exigent des approches visuelles différentes. Un lot d'extraction sémantique peut traiter les deux dans le même téléchargement — l'IA lit les valeurs, pas la mise en page. La colonne « Référence PAYE » se remplit à l'identique pour tous les partants du même employeur, quel que soit le logiciel ayant généré le P45.
Transformer les fichiers P45 mensuels en un flux d'analyse des départs
La plupart des entreprises suivent les départs dans un tableur que les RH mettent à jour manuellement — nom, service, date de départ, motif. Cela répond à la question « qui est parti ce mois-ci ». Cela ne répond pas à « quel est le salaire total moyen des départs du service ingénierie par rapport à ceux qui restent », « les départs avec des codes fiscaux non cumulatifs partent-ils à un taux plus élevé », ou « les départs du T3 avaient-ils une répartition de codes fiscaux différente de ceux du T2 ». Pour répondre à ces questions, il faut les données P45 — les montants de salaire et d'impôt que seule la paie détient — jointes aux données RH — les champs service et motif que seuls les RH détiennent.
Une extraction mensuelle des fichiers P45 produit exactement cet ensemble de données joint. Chaque mois, vous extrayez le fichier P45 dans un tableur avec le même schéma de colonnes. Au bout de six mois, vous avez six tableurs. Comme les noms de colonnes sont identiques d'un mois à l'autre, les empiler pour former un ensemble de données annuel est une simple opération d'ajout — pas de remappage de colonnes, pas d'alignement de champs. Ajoutez une colonne « Mois » à chaque fichier comme valeur fixe, et soudain vous avez six mois de données de départs avec salaire, impôt, code fiscal, numéro NI et date de départ — interrogeables par mois, par type de code fiscal, par tranche de salaire total.
Les données de paie seules vous révèlent des choses que les comptes rendus d'entretien de départ ne peuvent pas. Un groupe de départs avec des codes BR (taux de base) — indiquant qu'ils avaient probablement un second emploi — suggère un ensemble de salariés qui étaient peut-être déjà économiquement désengagés de l'organisation avant de démissionner. Un groupe de départs avec des codes K — où les déductions totales dépassent les abattements — peut indiquer des salariés ayant des affaires fiscales complexes (voiture de fonction, avantages en nature) dont les décisions de départ sont corrélées aux structures d'avantages plutôt qu'à l'insatisfaction salariale. Rien de tout cela n'est visible dans un entretien de départ. C'est visible dans les données P45 — si vous les capturez.
Le rythme mensuel des fichiers révèle également des schémas temporels que les analyses annuelles rétrospectives manquent. Y a-t-il un pic de départs en janvier (départs post-prime) ? En avril (post-fin d'année fiscale, les salariés attendent leur P60 puis partent) ? En septembre (post-été, les nouvelles promotions de diplômés poussent les employés existants) ? Un instantané d'un seul mois ne peut pas répondre à cela. Six mois de fichiers empilés le peuvent. Le schéma émerge non pas de l'analyse d'un seul tableur, mais du fait d'avoir construit la base de données mois après mois.
FAQ : Traitement par lots des formulaires de départ P45 UK
Puis-je traiter des P45 de plusieurs années fiscales en un seul lot ?
Techniquement oui — l'IA extrait les données de tout P45, quelle que soit l'année fiscale — mais il est préférable de les regrouper par année. Un salarié dont le dernier jour travaillé est le 31 mars 2026 aura son P45 dans l'année fiscale 2025-26. Un autre dont le dernier jour est le 7 avril 2026 aura son P45 dans l'année 2026-27, même s'il a donné son préavis en mars. Ces deux P45 se ressemblent mais correspondent à des années différentes. Si vous les regroupez, la colonne « Total des salaires versés (£) » contiendra des montants de périodes cumulées différentes, les rendant incomparables. Regroupez par année fiscale et ajoutez une colonne fixe « Année fiscale » pour que l'année soit explicite dans chaque ligne.
Qu'en est-il du P45 à revenu nul — un employé inscrit mais jamais payé ?
Selon les directives du HMRC, si un code fiscal a été attribué et que l'employé a été déclaré sur un FPS — même avec un salaire nul — vous devez émettre un P45 à son départ. Le P45 indiquera 0,00 £ de salaire total et 0,00 £ d'impôt total. Dans un lot manuel, l'administrateur pourrait sauter ce P45 car « il n'y a aucune donnée à saisir ». Dans un lot d'extraction, incluez-le — les valeurs nulles sont des données. Un départ à revenu nul, resté trois mois sur la paie sans être payé, est un signal RH important : cela peut indiquer une personne ajoutée à la paie avant sa date d'embauche mais qui n'a jamais commencé, ou une période de congé légal sans rémunération. Ce signal compte dans l'analyse des départs.
Que faire si le code fiscal d'un P45 comporte l'indicateur « X » Semaine 1 / Mois 1 ?
Le marqueur « X » — appliqué lorsque le code fiscal est utilisé en mode non cumulatif (Semaine 1 / Mois 1) — signifie que les montants cumulés annuels sur le P45 peuvent ne pas représenter un calcul cumulatif complet. Cela importe pour l'analyse des départs : un salarié quittant avec le code 1257L M1 et 25 000 £ de salaire cumulé n'est pas directement comparable à un autre avec le code 1257L et le même salaire — l'impôt du premier a été calculé période par période, sans référence aux revenus antérieurs, donc son impôt total peut différer de l'équivalent cumulatif. Capturez l'indicateur « X » dans une colonne dédiée (ne l'ajoutez pas à la colonne du code fiscal sous forme de texte — « 1257L X » perturbe le tri). Une colonne séparée « Indicateur M1/W1 » vous permet de filtrer les départs non cumulatifs des comparaisons d'impôt agrégées.
Puis-je inclure la date d'émission des parties 2/3 du P45 comme colonne ?
Le P45 lui-même n'indique pas la date à laquelle les parties 2 et 3 ont été remises à l'employé — il indique la date de départ. La date d'émission dépend du moment où la paie a été traitée, ce n'est pas un champ du formulaire. Si votre lot de P45 de fin de mois est généré le lendemain du cycle de paie, la date d'émission est la même pour tous les P45 du lot — ajoutez-la comme colonne fixe. Si les P45 sont émis à des dates différentes (certains départs traités lors du premier cycle de paie du mois, d'autres lors du second), créez des lots séparés par cycle de paie et utilisez la date du lot comme date d'émission. La colonne « Nom du fichier » dans le résultat — qu'ImageToTable.ai inclut par défaut — assure la traçabilité par document, quoi qu'il arrive.
Que deviennent les déductions de prêt étudiant sur un P45 — faut-il des colonnes séparées par plan ?
Oui. Les P45 britanniques incluent les informations de déduction des prêts étudiants et de troisième cycle par type de plan (Plan 1, Plan 2, Plan 4, Prêt de troisième cycle). La spécification HMRC exige qu'ils soient déclarés séparément. Définissez une colonne par plan — « Prêt étudiant Plan 1 (£) », « Prêt étudiant Plan 2 (£) », « Prêt de troisième cycle (£) » — plutôt qu'une colonne combinée « Prêt étudiant (£) ». Un salarié remboursant à la fois le Plan 1 et le Plan 2 aura deux champs non nuls sur le P45. Une colonne unique qui les additionne rend impossible la réponse à un avis d'arrêt SL1/SL2 spécifique à un plan émis par HMRC — vous ne sauriez pas quel plan arrêter. À grande échelle, des colonnes séparées par plan permettent également d'analyser quels groupes de sortants portent quel type de prêt étudiant — une donnée que l'analyse RH peut recouper par service, tranche de salaire et motif de départ.
Comment l'extraction par lots gère-t-elle les P45 dont le numéro NI est illisible ou partiellement masqué ?
Le numéro NI est le champ le plus important d'un P45 pour l'audit et l'analyse — c'est l'identifiant unique qui relie ce P45 à tous les autres enregistrements de paie du même salarié. Si un P45 scanné rend le numéro NI illisible (scan de faible résolution, dommage physique sur la copie papier), l'IA l'extraira de manière incorrecte ou le laissera vide. Dans un flux de travail par lots, un numéro NI manquant brise l'analyse en aval car la ligne ne peut être jointe à aucun autre jeu de données. La sauvegarde pratique est une colonne de vérification calculée — « Vérification du format du numéro NI » — qui signale tout numéro NI ne correspondant pas au modèle standard AA######. Les lignes signalées par cette vérification doivent être vérifiées manuellement dans le système de paie avant que le tableur ne soit utilisé pour l'audit ou l'analyse. Pour les P45 générés numériquement depuis Sage, BrightPay ou QuickBooks, la précision de l'extraction du numéro NI est constamment élevée car le texte est imprimé par machine à une position standard.
Chaque P45 généré par votre logiciel de paie contient les mêmes données que celles que vous saisiriez manuellement dans une base de sortie. La réglementation vous impose de l'émettre. Elle ne vous impose pas de perdre les données en cours de route. Définissez vos colonnes une fois. Importez le lot de départs du mois. Laissez le tableur se remplir tout seul — et dans six mois, vous aurez non seulement un enregistrement de conformité, mais aussi un jeu de données capable de répondre à des questions que vos entretiens de départ n'ont jamais posées.
Essayez-le sur vos P45