15 bajas este mes, 15 P45
Crea una base de datos de bajas sin doble entrada
Según el Reglamento 36 del Reglamento del Impuesto sobre la Renta (Pago según Gana) de 2003 (SI 2003/2682), todo empleador del Reino Unido debe emitir un P45 cuando un empleado deja de trabajar para él, cumplimentado el día en que finaliza la relación laboral "o sin demora injustificada". El reglamento no distingue entre una empresa que pierde un empleado en marzo y otra que pierde quince en una reestructuración. En cualquier caso, deben generarse quince formularios P45, presentarse quince Partes 1 a HMRC vía RTI y entregarse quince juegos de Partes 1A, 2 y 3 a los empleados salientes, todo mientras RR. HH. registra los motivos de la baja, los jefes directos confirman las fechas finales y el departamento de TI recupera los equipos. El P45 en sí no es el cuello de botella: Sage 50cloud, BrightPay, QuickBooks Online Payroll, Moorepay e IRIS generan un P45 conforme en segundos para una sola baja. El cuello de botella es la brecha estructural entre un software de nóminas que procesa un empleado a la vez y una operación de RR. HH. que necesita gestionar quince bajas en un mes, verificar que las Partes 2 y 3 se emitieron correctamente a cada saliente e incorporar esos datos de baja al análisis de rotación, sin tener que introducir a mano el mismo número de la Seguridad Social, fecha de salida, pago total e impuestos pagados en una hoja de cálculo aparte.
Conclusiones clave
- Cada P45 que genera tu software de nóminas ya contiene los campos de base de datos de bajas que necesitas, pero alguien los vuelve a escribir todos en una hoja de cálculo que nóminas nunca ve, mientras los datos originales permanecen sin consultar en un archivo PDF.
- En el momento en que entregas el P45 al empleado, sus datos de pago e impuestos quedan inactivos: no puedes agregar quién se fue, cuánto ganó o si sus códigos fiscales siguen un patrón, porque los datos se generaron pero nunca se capturaron.
- Sube los P45 de las bajas del mes en un solo lote después de cada ciclo de nómina con un esquema de columnas fijo: la misma extracción alimenta la verificación de cumplimiento de HMRC y el análisis de rotación de RR. HH., y seis lotes mensuales apilados se convierten en una base de datos de bajas consultable que nadie tuvo que teclear.
Las bajas mensuales son un problema distinto a un solo P45
El proceso anual del P60 ocurre una vez. Todo empleado en nómina al 5 de abril recibe uno. El equipo de nóminas puede reservar una semana en mayo, ejecutar el lote y conciliarlo con las declaraciones de pago completo. El proceso de bajas mensuales, en cambio, es una tarea permanente en el calendario de nóminas. Cada mes, entre dos y veinte empleados causan baja: renuncias, despidos, fin de contratos temporales, jubilaciones. Cada baja genera un P45. Y cada P45 no solo es una obligación fiscal enviada a HMRC y entregada al empleado — es un dato que RR. HH. necesita para un propósito completamente distinto: saber quién se fue, por qué, qué se le pagó y si su salida sigue un patrón.
Procesar un solo P45 es sencillo. Extraer sus campos a una hoja de cálculo requiere atención, no herramientas especializadas. En cuanto procesas bajas con la cadencia mensual que manejan la mayoría de las empresas, aparecen tres problemas estructurales que no existen a escala de una sola baja.
1. La información llega de tres fuentes, en tres momentos distintos
RR. HH. recibe la carta de renuncia y conoce la fecha de baja primero. Nóminas puede no recibir la notificación formal hasta días después — sobre todo si el jefe directo retrasa la aprobación. Cuando el P45 se genera a través de Sage o BrightPay, RR. HH. ya ha registrado la baja en el HRIS. El P45 contiene datos — número de la Seguridad Social, pago total, impuestos pagados, código fiscal final — que la hoja de seguimiento de bajas de RR. HH. no tiene. Alguien copia esos campos manualmente. Para quince bajas, son quince operaciones de copiar y pegar entre sistemas cada mes, cada una con posible desajuste entre lo que RR. HH. registró y lo que nóminas procesó realmente.
2. El P45 de cuatro partes genera su propio rastro de auditoría — pero solo si lo conservas
La Parte 1 se envía a HMRC mediante RTI al presentar la declaración de pago completo. Las Partes 1A, 2 y 3 van al empleado. El empleado conserva la Parte 1A y entrega las Partes 2 y 3 a su nuevo empleador. Desde la perspectiva del empleador emisor, una vez generado y entregado el P45, los datos subyacentes quedan en los archivos del software de nóminas — no en un formato que RR. HH. pueda consultar. Si tres meses después alguien pregunta "cuántas bajas en el primer trimestre tuvieron un pago total superior a 30 000 £", la respuesta está en los registros individuales de Sage, no en un informe. Los datos se generaron. Simplemente nunca se capturaron.
3. Los casos excepcionales se multiplican con el volumen
Una empresa que procesa tres bajas al mes puede encontrarse con un caso excepcional. Una que procesa quince tendrá tres o cuatro cada mes: la baja cuyo pago final incluye un bono grande que eleva su total acumulado anual por encima de un umbral fiscal; la baja con ingresos cero (en nómina con código fiscal pero sin cobrar nunca) que igual requiere un P45 según el Reglamento 36; el empleado que avisó en marzo pero cuyo último día laborable cae el 7 de abril — cruzando el límite del año fiscal y cambiando qué totales acumulados del año aparecen en el P45. Cada caso excepcional interrumpe un flujo manual: dejas de transcribir, investigas la excepción, la resuelves y luego reanudas. A escala de lote, esas interrupciones son el flujo de trabajo.
El lote mensual de bajas no es una versión reducida del proceso anual del P60. Es un problema distinto: el P45 es a la vez un documento de cumplimiento que debes emitir, un registro de nómina que debes archivar y un dato de salida que tu equipo de RR. HH. necesita para un fin completamente diferente. El mismo PDF del P45 puede cumplir los tres propósitos si dejas de tratarlo como un formulario para imprimir y empiezas a tratarlo como una fuente de datos estructurada.
El P45 en 4 partes a escala: qué va dónde y qué sale mal
El P45 consta de cuatro partes. La distinción importa en un flujo por lotes porque, a escala, un error en el enrutamiento genera una cascada de correcciones que el procesamiento manual uno a uno oculta.
Parte 1 — para HMRC (vía RTI)
Se envía automáticamente cuando tu software de nómina presenta el FPS marcando al empleado como baja. No envías físicamente la Parte 1: el software genera los datos del P45 y los transmite como parte de la declaración RTI.
Parte 1A — registro del empleado
El empleado la conserva. Muestra los mismos datos que las Partes 2 y 3 (pago total, impuesto total, código fiscal, fecha de baja), pero es para sus registros fiscales personales. Ningún nuevo empleador la ve.
Parte 2 — nuevo empleador (registro fiscal)
El nuevo empleador la usa para configurar la nómina del empleado con el código fiscal y las cifras acumuladas correctas. Sin la Parte 2, el nuevo empleador debe usar un formulario de inicio, lo que a menudo resulta en un código fiscal de emergencia hasta que HMRC lo corrija.
Parte 3 — nuevo empleador (confirmación)
El nuevo empleador completa la Parte 3 con su propia referencia PAYE, la fecha de inicio y el código fiscal que usará, y luego la envía a HMRC. Esto confirma la transición laboral y permite a HMRC conciliar el registro fiscal del empleado durante el periodo entre trabajos.
En un flujo de una sola baja, el enrutamiento de las cuatro partes es una casilla de verificación: Parte 1 presentada, Partes 1A/2/3 entregadas. En un lote de quince, el enrutamiento se convierte en un problema de seguimiento. ¿Qué bajas se han marcado como tales en el FPS? ¿Están todas las Partes 2 y 3 correctamente asignadas al empleado adecuado, o alguien le dio el P45 de Juan Pérez al otro Juan Pérez? Si una baja pierde su P45, no puedes emitir un duplicado (HMRC lo prohíbe explícitamente); solo puedes proporcionar un certificado de ingresos. Eso significa que el único PDF del P45 que generaste es el único registro oficial. Perderlo o mal dirigirlo es un error irreparable.
La salvaguarda práctica a escala de lotes es capturar los datos de cada P45 en una hoja de cálculo en el momento de la generación, antes de que las Partes 1A/2/3 salgan de tus manos. La hoja de cálculo se convierte en tu registro de auditoría interno: prueba de lo que contenía cada P45, en qué fecha se emitió y para qué baja. Si un exempleado se pone en contacto seis meses después alegando que su P45 mostraba el código fiscal incorrecto, tienes una fila verificable, no un inicio de sesión en el sistema de nóminas y un recuerdo de lo que crees que imprimiste.
Del P45 en PDF a la base de datos de salidas: columnas que sirven tanto a HMRC como a RR. HH.
Los nombres de columna que defines antes de cargar un lote de P45 son la decisión más importante del flujo de trabajo. Un esquema de columnas diseñado solo para el cumplimiento de nóminas captura los campos obligatorios: pago total, impuesto total, código fiscal, fecha de baja, y se detiene ahí. Eso basta para verificar el P45 contra el FPS. No basta para alimentar los análisis de salidas de RR. HH., donde las preguntas son diferentes: qué departamentos están perdiendo personal, cuáles son los patrones comunes de código fiscal entre los que se van, si los empleados con salarios más altos se van por razones distintas a los de salarios más bajos.
Un esquema de columnas que sirva a ambos propósitos se construye en tres niveles. El primer nivel te garantiza el cumplimiento. El segundo nivel proporciona a RR. HH. datos que realmente pueden usar. El tercer nivel detecta anomalías antes de que se conviertan en consultas de HMRC.
1. Columnas de identidad: la clave compuesta del empleado saliente
N.º de NI, Nombre del empleado, Fecha de baja y Referencia PAYE. El N.º de NI es la clave primaria natural: es único, permanente y aparece en cada P45. La Referencia PAYE (formato NNN/XXNNNNN según PAYE20005) identifica a qué esquema patronal pertenece este P45, algo fundamental si tu empresa gestiona múltiples esquemas PAYE o ha adquirido otra entidad. Incluir la fecha de baja en el bloque de identidad distingue a un empleado que se fue, regresó y se fue de nuevo.
2. Columnas financieras y fiscales: el núcleo obligatorio
Pago total hasta la fecha (£), Impuesto total hasta la fecha (£), Código fiscal en la fecha de baja, Indicador de Semana 1 / Mes 1 (captura el sufijo 'X'), Deducciones por préstamo estudiantil (Plan 1, Plan 2, Plan 4, Posgrado: separarlos en columnas individuales es esencial; una sola columna "Préstamo estudiantil (£)" impide distinguir a qué plan corresponde cada deducción, y las notificaciones de suspensión SL1/SL2 de HMRC son específicas de cada plan).
3. Columnas de análisis de RR. HH.: convertir datos de cumplimiento en inteligencia de salidas
Son columnas que no aparecen en el P45 pero se completan a partir de los datos del P45 durante la extracción. Una columna inferida de "Categoría de baja", donde la IA clasifica al empleado según el contexto que proporciones (opciones: Renuncia / Despido / Despido disciplinario / Jubilación / Fin de contrato fijo). Una columna calculada de "Tipo de código fiscal" que clasifica cada código como "Acumulativo / No acumulativo (M1/W1) / BR-D0-D1 / Código K / NT": un empleado con código K (deducciones superan las exenciones) cuenta una historia laboral diferente a un empleado con código 1257L. Una columna de "Trimestre de baja" derivada de la fecha de baja para segmentación instantánea en tablas dinámicas. Ninguna de estas columnas aumenta el trabajo de transcripción: la IA las completa en la misma pasada de extracción que lee los campos obligatorios.
Para ver un ejemplo concreto de cómo extraer los campos obligatorios de un solo P45 (el N.º de NI, el código fiscal, las cifras de pago total e impuesto total), consulta la guía de extracción de un solo P45, que cubre cada campo en detalle. Este artículo retoma donde termina esa guía: qué cambia cuando introduces quince P45 en el mismo esquema de columnas cada mes, y la base de datos a largo plazo que construyes al hacerlo.
Coordinación multidepartamental: Cerrar la brecha entre la notificación de RR. HH. y la emisión del P45
La normativa del P45 dice "el día en que finaliza el empleo o sin demora injustificada". En la práctica, esa afirmación oculta una cadena de coordinación. RR. HH. recibe la renuncia. El jefe directo confirma la fecha de finalización del trabajo, a veces días después. Nóminas recibe la notificación formal de baja, a veces después de la confirmación del jefe directo, a veces antes, dependiendo de si el proceso de la empresa está liderado por RR. HH. o por nóminas. Nóminas procesa el pago final, marca al empleado como baja en Sage o BrightPay, genera el P45 y envía el FPS. Solo entonces existe el P45. El tiempo entre "el empleado renuncia" y "se genera el P45" puede ser desde el mismo día hasta dos semanas, y en ese lapso, RR. HH. ya ha registrado la baja en una hoja de cálculo que aún no tiene los datos del P45.
Este es el costo oculto de una base de datos de salidas manual: la entrada duplicada de datos que ocurre en dos sistemas diferentes en dos momentos diferentes. RR. HH. ingresa el nombre del empleado que se va, departamento, motivo de salida y fecha final cuando se confirma la renuncia. Nóminas ingresa el mismo nombre, número de la Seguridad Social, pago total, impuesto total y código fiscal cuando se genera el P45, una semana después. Los dos conjuntos de datos rara vez se encuentran en la misma hoja de cálculo. El resultado es un registro de salidas de RR. HH. que sabe por qué se fueron las personas pero no cuánto ganaron, y un archivo de nóminas que sabe cuánto ganaron las personas pero no por qué se fueron.
El flujo de trabajo por lotes elimina esta brecha no cambiando el proceso de nadie, sino cambiando cuándo ocurre la captura de datos. En lugar de que nóminas genere P45 y RR. HH. mantenga por separado un registro de salidas, los PDF de los P45 se convierten en la fuente única para ambos. Cargue el lote de P45 del mes después del ciclo de nóminas, cuando todos los empleados que se van hayan sido procesados y todos los P45 generados, y extraiga a una hoja de cálculo que incluya tanto los campos obligatorios de nóminas (del propio P45) como los campos de contexto de RR. HH. (de columnas inferidas). Una sola extracción. Ambos equipos obtienen sus datos. El equipo de RR. HH. añade la columna de motivo de salida basándose en las cartas de renuncia que ya tienen; el equipo de nóminas verifica las cifras fiscales con el FPS. Ambos trabajan con el mismo número de la Seguridad Social, la misma fecha de baja, la misma fila.
Para las empresas que ya manejan P60 a fin de año con un enfoque similar, el flujo de trabajo mensual de P45 sigue el mismo patrón: estandarizar nombres de columnas, agrupar por mes, verificar contra el FPS. El flujo de trabajo de auditoría por lotes de P60 cubre el nombramiento de archivos, el diseño de columnas y la fusión de múltiples empleadores en detalle; el esquema de columnas es específico del documento, pero el enfoque por lotes es idéntico.
Realidad entre proveedores: Sage, BrightPay, QuickBooks y el empleado que se fue cambiando de departamento a mitad de año
HMRC no exige un diseño único de P45. Según las especificaciones RTI de HMRC, el software de nóminas debe incluir los campos obligatorios (referencia PAYE del empleador, número NI del empleado, nombre, fecha de salida, código fiscal, pago total, impuesto total), pero la disposición visual queda a criterio de cada proveedor. El resultado es que un P45 de Sage 50cloud Payroll se ve diferente de uno de BrightPay, que a su vez se ve diferente de uno de QuickBooks Online Payroll, y este de uno de Moorepay. El número NI del empleado puede estar en el recuadro superior derecho en uno y debajo del nombre en otro. El código fiscal puede imprimirse junto a la referencia PAYE en uno y en un recuadro separado con borde en otro.
Esta variación de diseño genera un costo sutil pero significativo en el procesamiento manual. Cada vez que el administrador de nóminas pasa de leer un P45 de Sage a uno de BrightPay, debe reescanear visualmente para localizar cada campo. Con quince P45 de tres proveedores distintos —algo habitual cuando una empresa adquiere otra entidad y hereda su software de nóminas durante un período de transición— ese reescaneo visual añade unos diez segundos por documento. En un mes de salidas, eso suma minutos de escaneo muerto antes de una sola pulsación de tecla para transcribir.
La extracción semántica elimina el reescaneo específico de cada proveedor al leer el documento por su significado, no por su posición. Usted define la columna que desea —"Número NI"— una sola vez. La IA localiza el número NI en un P45 de Sage al entender cómo es un número de Seguro Social (dos letras, seis dígitos, una letra: AB123456C), no al saber que Sage lo imprime en la coordenada (x=72mm, y=38mm). Un P45 de BrightPay, uno de QuickBooks, uno de Moorepay y un P45 escaneado en papel de un empleado que perdió el suyo se alimentan de la misma definición de columna. La columna de salida se completa de forma idéntica entre proveedores.
Este comportamiento independiente del proveedor es especialmente valioso en el caso común de un empleado que se fue a mitad de año y estaba en un sistema de nóminas diferente al actual. Una empresa que cambió de Sage a BrightPay en septiembre tendrá empleados salientes cuyos P45 fueron generados por Sage (salidas anteriores a septiembre) y otros por BrightPay (salidas posteriores a septiembre). En un flujo manual, el administrador procesa cada lote por separado porque los dos diseños de P45 exigen enfoques visuales distintos. Un lote de extracción semántica puede manejar ambos en la misma carga: la IA lee los valores, no el diseño. La columna "Referencia PAYE" se completa de forma idéntica para todos los empleados salientes del mismo empleador, independientemente del software que generó el P45.
Convirtiendo lotes mensuales de P45 en un feed de análisis de salidas
La mayoría de las empresas registran las bajas en una hoja de cálculo que RR.HH. actualiza manualmente: nombre, departamento, fecha de salida, motivo. Responde a la pregunta "quién se fue este mes". No responde a "cuál es el salario total promedio de los que se van del departamento de ingeniería frente a los que se quedan", "si los que se van con códigos fiscales no acumulativos lo hacen a un ritmo mayor" o "si los que se fueron en el tercer trimestre tenían una combinación de códigos fiscales diferente a la del segundo trimestre". Responder a esas preguntas requiere los datos del P45 — las cifras de salario e impuestos que solo tiene nóminas — unidos a los datos de RR.HH. — los campos de departamento y motivo que solo tiene RR.HH.
Una extracción mensual de lotes de P45 produce exactamente ese conjunto de datos unificado. Cada mes, extraes el lote de P45 en una hoja de cálculo con el mismo esquema de columnas. En seis meses, tienes seis hojas de cálculo. Como los nombres de las columnas son idénticos entre meses, apilarlos en un conjunto de datos anual es una operación de anexado — sin reasignación de columnas, sin alineación de campos. Añade una columna "Mes" a cada lote como valor fijo, y de repente tienes seis meses de datos de salidas con salario, impuestos, código fiscal, número de la Seguridad Social y fecha de salida — consultables por mes, por tipo de código fiscal, por tramo salarial total.
Los datos de nóminas por sí solos revelan cosas que las transcripciones de entrevistas de salida no pueden. Un grupo de salidas con códigos BR (tipo básico) — que indica que probablemente tenían un segundo empleo — sugiere un conjunto de empleados que ya podrían estar económicamente desvinculados de la organización antes de renunciar. Un grupo de salidas con códigos K — donde las deducciones totales superan las exenciones — puede indicar empleados con asuntos fiscales complejos (coche de empresa, retribuciones en especie) cuyas decisiones de salida se correlacionan con las estructuras de beneficios más que con la insatisfacción salarial. Nada de esto es visible en una entrevista de salida. Es visible en los datos del P45 — si los capturas.
La cadencia mensual de lotes también revela patrones temporales que las revisiones anuales pasan por alto. ¿Hay un pico de salidas en enero (salidas post-bono)? ¿En abril (post-cierre del año fiscal, los empleados esperan su P60 y luego se van)? ¿En septiembre (post-verano, las nuevas incorporaciones de graduados desplazan al personal existente)? Una instantánea de un solo mes no puede responder a eso. Seis meses de lotes apilados sí pueden. El patrón surge no de analizar una hoja de cálculo, sino de haber construido la base de datos mes a mes.
Preguntas frecuentes: Procesamiento por lotes de formularios P45 de salida del Reino Unido
¿Puedo procesar P45 de varios años fiscales en un solo lote?
Técnicamente sí: la IA extraerá datos de cualquier P45 independientemente del año fiscal, pero debería agruparlos por año fiscal. Un empleado cuya última jornada laboral sea el 31 de marzo de 2026 tendrá su P45 en el año fiscal 2025-26. Otro cuya última jornada sea el 7 de abril de 2026 lo tendrá en el año fiscal 2026-27, aunque haya presentado su renuncia en marzo. Ambos P45 son idénticos visualmente, pero representan años fiscales distintos. Si los agrupa, la columna "Total de remuneración hasta la fecha (£)" contendrá cifras de períodos acumulativos diferentes, lo que las hará incomparables. Agrupe por año fiscal y añada una columna de valor fijo "Año fiscal" para que el año quede explícito en cada fila.
¿Qué pasa con el P45 de ingresos cero: un empleado en nómina que nunca cobró?
Según las directrices de HMRC, si se asignó un código tributario y el empleado se declaró en un FPS, incluso con pago cero, debe emitir un P45 al causar baja. El P45 mostrará £0.00 de pago total y £0.00 de impuesto total. En un lote manual, el administrador de nóminas podría omitir este P45 porque "no hay datos que introducir". En un lote de extracción, inclúyalo: los valores cero son datos. Un empleado con ingresos cero que estuvo en nómina tres meses sin cobrar es una señal de RR. HH. significativa: puede indicar a alguien añadido a la nómina antes de una fecha de inicio que nunca llegó a empezar, o un período de permiso legal sin derecho a paga. Esa señal es importante en el análisis de salidas.
¿Qué pasa si el código tributario del P45 de un empleado tiene el indicador 'X' de Semana 1 / Mes 1?
El marcador 'X' — aplicado cuando el código tributario se opera de forma no acumulativa (Semana 1 / Mes 1) — significa que las cifras acumuladas del año en el P45 pueden no representar un cálculo acumulativo completo. Esto es relevante para el análisis de salidas porque un empleado con 1257L M1 que gana £25,000 acumulados no es directamente comparable con uno con 1257L (acumulativo) que gana £25,000: los impuestos del empleado con M1 se calcularon por período sin referencia a ingresos anteriores, por lo que su cifra total de impuestos puede diferir del equivalente acumulativo. Capture el indicador 'X' en una columna dedicada (no lo añada como texto a la columna del código tributario — "1257L X" rompe la ordenación). Una columna separada "Indicador M1/W1" le permite filtrar a los empleados no acumulativos de las comparaciones de impuestos agregados.
¿Puedo incluir la fecha de emisión de la Parte 2/3 del P45 como columna?
El propio P45 no muestra la fecha en que se entregaron las Partes 2 y 3 al empleado; muestra la fecha de baja. La fecha de emisión depende de cuándo se ejecutó la nómina, no es un campo del formulario. Si su lote de P45 de fin de mes se genera al día siguiente de la ejecución de la nómina, la fecha de emisión es la misma para todos los P45 del lote: agréguela como columna de valor fijo. Si los P45 se emiten en fechas diferentes (algunas bajas procesadas en la primera ejecución de nómina del mes, otras en la segunda), cree lotes separados por ejecución de nómina y use la fecha del lote como fecha de emisión. La columna "Nombre de archivo" en el resultado — que ImageToTable.ai incluye por defecto — proporciona la procedencia de cada documento independientemente.
¿Qué sucede con las deducciones de préstamos estudiantiles en un P45? ¿Necesito columnas separadas por plan?
Sí. Los P45 del Reino Unido incluyen información de deducciones de préstamos estudiantiles y de posgrado por tipo de plan (Plan 1, Plan 2, Plan 4, Préstamo de Posgrado). La especificación de HMRC exige que se informen por separado. Defina una columna por plan — "Préstamo Estudiantil Plan 1 (£)", "Préstamo Estudiantil Plan 2 (£)", "Préstamo de Posgrado (£)" — en lugar de una columna combinada "Préstamo Estudiantil (£)". Un empleado que reembolsa tanto el Plan 1 como el Plan 2 tendrá dos campos distintos de cero en el P45. Una sola columna que los suma imposibilita responder a un aviso de suspensión SL1/SL2 específico de un plan de HMRC — no sabría qué plan suspender. A escala de lote, las columnas separadas por plan también permiten analizar qué grupos de salida tienen qué tipo de préstamo estudiantil, un dato que RRHH puede cruzar con departamento, banda salarial y motivo de salida.
¿Cómo maneja la extracción por lotes los P45 donde el número de NI es ilegible o está parcialmente oculto?
El número de NI es el campo más importante de un P45 para auditoría y análisis — es el identificador único que vincula este P45 con todos los demás registros de nómina del mismo empleado. Si un P45 escaneado muestra el número de NI ilegible (escaneo de baja resolución, daño físico en la copia en papel), la IA lo extraerá incorrectamente o lo dejará en blanco. En un flujo de trabajo por lotes, la falta del número de NI rompe el análisis posterior porque la fila no se puede vincular con ningún otro conjunto de datos. La salvaguarda práctica es una columna de verificación calculada — "Verificación de formato de número NI" — que marque cualquier número NI que no coincida con el patrón estándar AA######. Las filas marcadas por esta verificación deben revisarse manualmente contra el sistema de nómina antes de usar la hoja de cálculo para auditoría o análisis. Para P45 generados digitalmente desde Sage, BrightPay o QuickBooks, la precisión de extracción del número NI es consistentemente alta porque el texto está impreso mecánicamente en una posición estándar.
Cada P45 que genera tu software de nómina contiene los mismos datos que escribirías a mano en una base de salidas. La normativa exige emitirlo, no perder los datos en el proceso. Define tus columnas una vez. Sube el lote de bajas del mes. Deja que la hoja de cálculo se complete sola. En seis meses, no solo tendrás un registro de cumplimiento, sino un conjunto de datos que responderá preguntas que tus entrevistas de salida nunca hicieron.
Pruébalo con tus P45