15 départs ce mois-ci, 15 P45
Construisez une base de données des départs sans double saisie
En vertu du Règlement 36 du Income Tax (Pay As You Earn) Regulations 2003 (SI 2003/2682), tout employeur britannique doit remettre un P45 lorsqu'un salarié cesse de travailler pour lui — établi le jour de la fin du contrat « ou sans retard injustifié ». Le règlement ne fait pas de distinction entre une entreprise qui perd un seul salarié en mars et une autre qui en perd quinze lors d'une restructuration. Dans les deux cas, quinze formulaires P45 doivent être générés, quinze Partie 1 soumises à HMRC via RTI, et quinze jeux de Parties 1A, 2 et 3 remis aux salariés partants — pendant que les RH enregistrent 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 vrai goulot, c'est le fossé structurel entre un logiciel de paie qui traite un salarié à la fois, et un service RH qui doit suivre quinze départs par mois, vérifier que les Parties 2 et 3 ont bien été remises à chaque partant, et alimenter les analyses de turnover — sans avoir à ressaisir manuellement le même NI number, la date de sortie, le total des rémunérations 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 à votre base de données des départs — mais quelqu'un les ressaisit tous dans un tableur que la paie ne voit jamais, tandis que les données originales restent inexploitables dans une archive PDF.
- Dès que vous remettez le P45 au salarié, ses données de paie 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.
- Importez 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 : un problème différent d'un simple P45
L'exercice annuel du P60 a lieu une fois par an. Tout salarié présent au 5 avril en reçoit un. L'équipe paie peut bloquer une semaine en mai, lancer le traitement par lots et le rapprocher des Déclarations de Paiement Intégral. Le processus de départ mensuel, en revanche, est un rendez-vous permanent du calendrier paie. Chaque mois, entre deux et vingt salariés quittent l'entreprise : démissions, licenciements, fins de CDD, 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 à l'administration fiscale et remise au salarié : c'est une donnée 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 seul P45 est simple. Extraire ses champs dans un tableur demande de l'attention, pas d'outils spécialisés. Dès que vous gérez les départs au rythme mensuel de la plupart des entreprises, trois problèmes structurels apparaissent, inexistants à l'échelle d'un départ unique.
1. Les informations arrivent de trois sources, à trois moments différents
Les RH reçoivent la lettre de démission et connaissent la date de départ en premier. La paie peut ne pas recevoir la notification officielle avant plusieurs 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 leur SIRH. Le P45 contient désormais des données — numéro de Sécurité sociale, total des rémunérations, impôt payé, code d'imposition final — que le tableur de suivi des départs des RH ne possède pas. Quelqu'un recopie manuellement ces champs. Pour quinze départs, ce sont quinze opérations de copier-coller entre systèmes chaque mois, chacune source potentielle d'écart entre ce que les RH ont saisi 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 conservez
La Partie 1 est envoyée à l'administration fiscale via le RTI lors de la soumission de la Déclaration de Paiement Intégral. Les Parties 1A, 2 et 3 vont au salarié. Le salarié 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 résident 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 total de rémunération supérieur à 30 000 £ », la réponse se trouve dans les dossiers individuels 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 salarié dont le dernier salaire inclut une grosse prime qui fait passer son cumul annuel au-dessus d'un seuil d'imposition ; le salarié sans revenu (présent dans la paie avec un code d'imposition mais jamais payé) qui nécessite tout de même un P45 selon le Règlement 36 ; le salarié 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 cumuls annuels apparaissant sur le P45. Chaque cas particulier interrompt un flux 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 fichier mensuel des départs n'est pas une version réduite de l'exercice annuel P60. C'est un problème différent — où le P45 est à la fois un document de conformité à émettre, un enregistrement de paie à archiver et une donnée de sortie dont les RH ont besoin pour un motif totalement distinct. Le même PDF P45 peut remplir ces trois rôles — si vous cessez de le traiter comme un formulaire à imprimer et commencez à le considérer comme une source de données structurée.
Le P45 en 4 parties à grande échelle : où va quoi et ce qui déraille
Le P45 comporte quatre parties. Cette distinction compte dans un traitement par lots, car une erreur d'aiguillage à grande échelle entraîne une cascade de corrections que le traitement manuel unitaire masque.
Partie 1 — à HMRC (via RTI)
Transmise automatiquement lorsque votre logiciel de paie envoie la déclaration de paiement intégrale signalant le départ du salarié. Vous n'envoyez pas physiquement la Partie 1 — le logiciel 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é conserve cette partie. Elle contient les mêmes données que les Parties 2 et 3 — total des salaires, total des impôts, code fiscal, date de départ — mais pour ses archives fiscales personnelles. Aucun nouvel employeur n'y a accès.
Partie 2 — nouvel employeur (registre fiscal)
Le nouvel employeur l'utilise pour configurer la fiche de paie du salarié avec le bon code fiscal et les cumuls annuels. Sans la Partie 2, le nouvel employeur doit utiliser une liste de contrôle de démarrage — ce qui aboutit souvent à un code fiscal d'urgence jusqu'à ce que HMRC le corrige.
Partie 3 — nouvel employeur (confirmation)
Le nouvel employeur remplit la Partie 3 avec son propre référence PAYE, la date de début et le code fiscal qu'il utilisera — puis l'envoie à HMRC. Cela confirme la transition d'emploi et permet à HMRC de rapprocher le dossier fiscal du salarié entre les deux emplois.
Dans un flux de départ unitaire, l'aiguillage des quatre parties est une simple case à cocher : Partie 1 déposée, Parties 1A/2/3 remises. Dans un lot de quinze, l'aiguillage 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 Jean Dupont à l'autre Jean Dupont ? Si un ancien salarié perd son P45, vous ne pouvez pas en délivrer un duplicata (HMRC l'interdit formellement) — vous ne pouvez fournir qu'un relevé de rémunération. Cela signifie que l'unique PDF P45 que vous avez généré est le seul document officiel. Le perdre — ou le mal aiguiller — est une erreur irrécupérable.
La sauvegarde pratique à grande échelle consiste à capturer les données de chaque P45 dans un tableur au moment de la génération — avant que les Parties 1A/2/3 ne quittent vos mains. Le tableur devient votre registre d'audit interne : la preuve du contenu de chaque P45, de sa date d'émission et du salarié concerné. Si un ancien employé vous contacte six mois plus tard en affirmant que son P45 affichait un mauvais code fiscal, vous disposez d'une ligne vérifiable — et non d'un accès au logiciel de paie et d'un vague souvenir de ce que vous pensez avoir imprimé.
Du P45 PDF à la base de données des départs : des colonnes qui servent à la fois HMRC et les RH
Les noms de colonnes que vous définissez avant d'importer un lot de P45 sont la décision la plus importante 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 fiscal, date de départ — et s'arrête là. Cela suffit pour vérifier le P45 par rapport au FPS. Mais pas pour alimenter l'analyse RH des départs, où les questions sont différentes : quels services perdent des employés, quels sont les schémas de codes fiscaux courants parmi les partants, les salariés mieux rémunérés partent-ils pour des raisons différentes de ceux moins bien payés.
Un schéma de colonnes qui sert les deux objectifs repose sur trois niveaux. Le premier assure la conformité. Le second fournit aux RH des données exploitables. Le troisième révèle les anomalies avant qu'elles ne deviennent des questions de HMRC.
1. Colonnes d'identité — la clé composite du partant
Numéro NI, Nom de l'employé, Date de départ et Référence PAYE. Le numéro NI 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 employé parti, revenu, puis reparti.
2. Colonnes financières et fiscales — le noyau obligatoire
Salaire total à ce jour (£), Impôt total à ce jour (£), Code fiscal à la date de départ, Indicateur Semaine 1 / Mois 1 (capturer le suffixe 'X'), Déductions pour 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 de chaque déduction, 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 des départs
Ces colonnes n'apparaissent pas sur le P45 mais sont renseignées à partir des données du P45 lors de l'extraction. Une colonne « Catégorie de départ » déduite — où l'IA classe le partant en fonction du contexte que vous fournissez (options : Démission/Licenciement économique/Licenciement/Départ à la retraite/Fin de CDD). Une colonne calculée « Type de code fiscal » qui classe chaque code comme « Cumulatif / Non cumulatif (M1/W1) / BR-D0-D1 / Code K / NT » — un partant avec un code K (déductions supérieures aux abattements) raconte une histoire différente de celle d'un partant 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 du même passage d'extraction qui lit les champs obligatoires.
Pour une démonstration concrète de l'extraction des champs obligatoires d'un seul P45 — le numéro NI, le code fiscal, les montants du salaire et de l'impôt totaux — le guide d'extraction d'un seul P45 détaille chaque champ. Cet article reprend là où celui-ci s'arrête : ce qui change quand vous alimentez quinze P45 dans le même schéma de colonnes chaque mois, et la base de données à long terme que vous construisez ainsi.
Coordination multi-service : combler le fossé entre la notification RH et l'émission du P45
La réglementation P45 stipule « le jour de la fin de l'emploi ou sans retard injustifié ». En pratique, cette phrase cache une chaîne de coordination. Les RH reçoivent la démission. Le responsable hiérarchique confirme la dernière date de travail — parfois plusieurs jours après. 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 la paie. La paie traite ensuite le dernier salaire, marque le salarié comme sortant dans Sage ou BrightPay, génère le P45 et soumet le FPS. Ce n'est qu'à ce moment que le P45 existe. Le délai entre « le salarié démissionne » et « le P45 est généré » peut aller du jour même à deux semaines — et dans 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 sorties manuelle : une double saisie de données dans deux systèmes différents à deux moments différents. Les RH saisissent le nom du sortant, son service, le motif de départ et la date de fin lorsque la démission est confirmée. La paie saisit le même nom, le numéro NI, 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échargez 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 (du P45 lui-même) et les champs de contexte RH (des colonnes déduites). Une seule extraction. Les deux équipes obtiennent leurs données. L'équipe RH ajoute la colonne motif de départ à partir des lettres de démission qu'elle possède déjà ; l'équipe paie vérifie les chiffres fiscaux par rapport au FPS. Les deux travaillent à partir du même numéro NI, 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 schéma : standardiser les noms de colonnes, regrouper par mois, 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 des 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 (cumulatif) 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 vous saisiriez manuellement dans une base de sortie. La réglementation vous impose de l'émettre, pas de perdre les données en chemin. Définissez vos colonnes une fois. Importez le lot de départs du mois. Laissez le tableaux se remplir seul — et dans six mois, vous aurez non seulement un dossier de conformité, mais un jeu de données capable de répondre à des questions que vos entretiens de départ n'ont jamais posées.
Essayez avec vos P45