15 Bajas Este Mes, 15 P45
Cree una Base de Datos de Bajas Sin Doble Entrada
Según el Reglamento 36 del Income Tax (Pay As You Earn) Regulations 2003 (SI 2003/2682), todo empleador del Reino Unido debe emitir un P45 cuando un empleado deja de trabajar para ellos, completado 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 una que pierde quince en una reestructuración. En cualquier caso, se deben generar quince Formularios P45, enviar quince Partes 1 a HMRC vía RTI, y entregar quince juegos de Partes 1A, 2 y 3 a los empleados que se marchan, todo mientras RRHH registra los motivos de salida, los jefes de línea confirman las fechas finales y TI recupera el equipo. El P45 en sí no es el cuello de botella: Sage 50cloud, BrightPay, QuickBooks Online Payroll, Moorepay e IRIS generan cada uno un P45 conforme en segundos para una sola baja. El cuello de botella es la brecha estructural entre un software de nóminas que piensa en un empleado a la vez y una operación de RRHH que necesita gestionar quince bajas en un mes, verificar que las Partes 2 y 3 se emitieron correctamente a cada empleado y alimentar esos datos de salida a los análisis de rotación, sin introducir manualmente el mismo NI Number, la fecha de salida, el salario total y los impuestos pagados en una hoja de cálculo aparte.
Conclusiones Clave
- Cada P45 que genera su software de nóminas ya contiene los campos de la base de datos de salidas que necesita, pero alguien los vuelve a escribir 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 entrega el P45 al empleado, sus datos de pago e impuestos quedan obsoletos: no puede 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 los análisis de salidas de RRHH, 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 al de un solo P45
El ejercicio anual del P60 ocurre una sola vez. Cada 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 conciliar contra las Full Payment Submissions. El proceso de bajas mensuales — en cambio — es una constante en el calendario de nóminas. Cada mes, entre dos y veinte empleados causan baja: renuncias, despidos, fin de contratos de duración determinada, jubilaciones. Cada salida genera un P45. Y cada P45 no es solo una obligación de cumplimiento enviada a HMRC y entregada al empleado que se va — es un dato que RRHH necesita para un propósito completamente distinto: saber quién se fue, por qué se fue, cuánto 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 el momento en que procesas bajas con la cadencia mensual con la que operan la mayoría de las empresas, aparecen tres problemas estructurales que no existen a escala de una sola baja.
1. La información llega desde tres direcciones, en tres momentos distintos
RRHH recibe la carta de renuncia y conoce la fecha de salida primero — y esa carta también es datos estructurados, por lo que convertir una carta de despido a Excel registra el último día laborable, el motivo de la separación y el período de preaviso antes incluso de que se genere el P45. Es posible que nóminas no reciba la notificación formal durante días, especialmente si el mánager retrasa la aprobación. Cuando el P45 se genera a través de Sage o BrightPay, RRHH ya ha registrado la baja en el HRIS. El P45 contiene ahora datos — NI number, paga total, impuestos pagados, código fiscal final — que la hoja de seguimiento de bajas de RRHH no tiene. Alguien copia manualmente esos campos. Para quince bajas, eso supone quince operaciones de copiar y pegar entre sistemas cada mes, cada una con un posible desajuste entre lo que RRHH registró y lo que nóminas procesó realmente.
2. El P45 de cuatro partes crea su propio rastro de auditoría, pero solo si lo conserva
La Parte 1 se envía a HMRC a través de RTI cuando presenta la Full Payment Submission. Las Partes 1A, 2 y 3 van para el empleado. El empleado conserva la Parte 1A y entrega las Partes 2 y 3 a su nuevo empleador. Desde la perspectiva del empleador que lo emite, una vez que el P45 se genera y se entrega, los datos subyacentes quedan en los archivos del software de nóminas, no en un formato que RRHH pueda consultar. Si tres meses después alguien pregunta "¿cuántas bajas hubo en el Q1 con paga total superior a £30,000?", la respuesta está en los registros individuales de empleados de Sage, no en un informe. Los datos se generaron, pero nunca se capturaron.
3. Los casos límite se multiplican con el volumen
Una empresa que procesa tres bajas al mes puede encontrarse con un caso límite. Una que procesa quince se topará con tres o cuatro cada mes: la baja cuya paga final incluye una bonificación grande que eleva su total acumulado anual por encima de un umbral fiscal; la baja sin ingresos (en nómina con código fiscal pero sin paga real) que aun así requiere un P45 según la Regulación 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 límite interrumpe el flujo manual: usted deja de transcribir, investiga la excepción, la resuelve y luego retoma. A escala de lote, esas interrupciones son el flujo de trabajo.
El lote mensual de bajas no es una versión reducida del ejercicio anual del P60. Es un problema distinto — uno en el que el P45 es simultáneamente un documento de cumplimiento que debe emitir, un registro de nóminas que debe archivar y un punto de datos de salida que su equipo de RRHH necesita con un propósito completamente ajeno. El mismo PDF del P45 puede servir para los tres fines — si deja de tratarlo como un formulario para imprimir y empieza a tratarlo como una fuente de datos estructurados.
El P45 de 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 de trabajo por lotes porque equivocarse en el enrutamiento a escala crea una cascada de correcciones que el procesamiento manual, uno a uno, enmascara.
Parte 1 — al HMRC (vía RTI)
Se envía automáticamente cuando su software de nóminas envía la Declaración de Pago Completa que marca al empleado como saliente. Usted no envía físicamente la Parte 1 — el software de nóminas genera los datos del P45 y los transmite como parte de la declaración RTI.
Parte 1A — registro del propio empleado
El empleado la conserva. Muestra los mismos datos que las Partes 2 y 3 — pago total, impuesto total, código fiscal, fecha de salida — pero es para los registros fiscales personales del empleado. Ningún nuevo empleador la ve.
Parte 2 — nuevo empleador (registro fiscal)
El nuevo empleador la usa para configurar el registro de nóminas del empleado con el código fiscal y las cifras acumuladas del año correctos. Sin la Parte 2, el nuevo empleador debe usar una Lista de Verificación de Inicio — lo que a menudo resulta en un código fiscal de emergencia hasta que el HMRC lo corrija.
Parte 3 — nuevo empleador (confirmación)
El nuevo empleador completa la Parte 3 con su propia referencia PAYE, fecha de inicio y el código fiscal que usará — y luego envía la Parte 3 al HMRC. Esto confirma la transición laboral y permite al HMRC conciliar el registro fiscal del empleado durante el período entre empleos.
En un flujo de trabajo de un solo empleado saliente, 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é salientes han sido marcados como tales en el FPS? ¿Están todas las Partes 2 y 3 correctamente emparejadas con el empleado adecuado — o alguien le entregó el P45 de John Smith al otro John Smith? Si un empleado saliente pierde su P45, usted no puede emitir un reemplazo (el HMRC lo prohíbe explícitamente) — solo puede proporcionar un estado de ingresos. Eso significa que el único PDF del P45 que generó es el único registro oficial. Perderlo — o enrutarlo mal — 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 sus manos. La hoja de cálculo se convierte en su registro de auditoría interno: prueba de qué contenía cada P45, en qué fecha se emitió y para qué empleado saliente. Si un ex empleado lo contacta seis meses después alegando que su P45 mostraba el código fiscal incorrecto, usted tiene una fila verificable — no un inicio de sesión en el sistema de nóminas y un recuerdo de lo que cree que imprimió.
Del P45 en PDF a la base de datos de salidas: columnas que sirven tanto a HMRC como a RRHH
Los nombres de las columnas que defina antes de cargar un lote de P45 son la decisión más trascendental de todo el flujo de trabajo. Un esquema de columnas diseñado únicamente para el cumplimiento de nóminas captura los campos obligatorios — pago total, impuesto total, código fiscal, fecha de salida — y se detiene ahí. Eso es suficiente para verificar el P45 contra el FPS. No es suficiente para alimentar los análisis de salidas de RRHH, donde las preguntas son diferentes: qué departamentos están perdiendo personal, cuáles son los patrones comunes de códigos fiscales entre los que se marchan, si los empleados con salarios más altos se van por razones distintas que los de salarios más bajos.
Un esquema de columnas que sirva para ambos propósitos se construye sobre tres niveles. El primer nivel le garantiza el cumplimiento. El segundo le da a RRHH datos que realmente pueden utilizar. El tercer nivel saca a la luz las anomalías antes de que se conviertan en consultas de HMRC.
1. Columnas de identidad: la clave compuesta del empleado que se marcha
NI Number, nombre del empleado, fecha de salida y referencia PAYE. El NI Number es la clave principal natural: es único, permanente y aparece en todos los P45. La referencia PAYE (formato NNN/XXNNNNN según PAYE20005) identifica a qué esquema de empleador pertenece este P45, algo fundamental si su empresa gestiona varios esquemas PAYE o ha adquirido otra entidad. Incluir la fecha de salida en el bloque de identidad permite distinguir a un empleado que se marchó, regresó y volvió a marcharse.
2. Columnas financieras y fiscales: el núcleo normativo
Pago total hasta la fecha (£), impuesto total hasta la fecha (£), código fiscal en la fecha de salida, indicador de semana 1 / mes 1 (capturar el sufijo 'X'), deducciones de préstamos estudiantiles (Plan 1, Plan 2, Plan 4, posgrado — separar estos en columnas individuales es esencial: una sola columna de "Préstamo estudiantil (£)" hace imposible distinguir a qué plan corresponde cada deducción, y los avisos de suspensión SL1/SL2 de HMRC son específicos de cada plan).
3. Columnas de análisis de RRHH: convertir los datos de cumplimiento en inteligencia de salidas
Son columnas que no aparecen en el P45 pero que se completan a partir de los datos del P45 durante la extracción. Una columna inferida de "categoría del empleado que se marcha", donde la IA clasifica al empleado según el contexto que usted proporcione (opciones: renuncia / despido / despido improcedente / jubilación / fin de contrato temporal). 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 (las deducciones superan las exenciones) cuenta una historia laboral distinta que uno con código 1257L. Una columna de "trimestre de salida" derivada de la fecha de salida para segmentar al instante 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 práctico de cómo extraer los campos obligatorios de un solo P45 — el NI Number, el código de impuestos, las cifras de pago total e impuestos totales — la guía de extracción de un solo P45 cubre cada campo en detalle. Este artículo continúa 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 se construye al hacerlo.
El esquema es lo que hace que una configuración de P45 a Excel sea reutilizable mes tras mes: define las columnas una vez y cada baja posterior llega como otra fila bajo los mismos encabezados, sin necesidad de reasignar entre lotes.
Coordinación entre departamentos: cómo cerrar la brecha entre la notificación de RRHH y la emisión del P45
La normativa del P45 dice «el día en que finaliza la relación laboral o sin demora injustificada». En la práctica, esta afirmación oculta una cadena de coordinación. RRHH recibe la renuncia. El responsable de línea confirma la fecha final de 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 responsable de línea, a veces antes, dependiendo de si el proceso de la empresa está liderado por RRHH o por nóminas. Nóminas procesa entonces 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 ir desde el mismo día hasta dos semanas — y en ese intervalo, RRHH ya ha registrado la baja en una hoja de cálculo que aún no contiene los datos del P45.
Este es el coste oculto de una base de datos de bajas manual: la introducción duplicada de datos que ocurre en dos sistemas diferentes en dos momentos diferentes. RRHH introduce el nombre del empleado que se marcha, el departamento, el motivo de la baja y la fecha final cuando se confirma la renuncia. Nóminas introduce el mismo nombre, el NI Number, el pago total, los impuestos totales y el código de impuestos cuando se genera el P45 — una semana después. Los dos conjuntos de datos rara vez coinciden en la misma hoja de cálculo. El resultado es un seguimiento de bajas de RRHH 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 el momento en que se capturan los datos. En lugar de que nóminas genere los P45 y RRHH mantenga por separado un seguimiento de bajas, los PDF de los P45 se convierten en la única fuente para ambos. Sube el lote de P45 del mes después de la ejecución de nóminas — cuando todas las bajas se han procesado y todos los P45 se han generado — y extrae a una hoja de cálculo que incluya tanto los campos obligatorios de nóminas (del propio P45) como los campos de contexto de RRHH (de columnas inferidas). Una sola pasada de extracción. Ambos equipos obtienen sus datos. El equipo de RRHH añade la columna de motivo de baja basándose en las cartas de renuncia que ya tienen; el equipo de nóminas verifica las cifras de impuestos contra el FPS. Ambos trabajan con el mismo NI Number, la misma fecha de baja y la misma fila.
Para las empresas que ya gestionan P60 a fin de año con un enfoque similar, el flujo de trabajo mensual de P45 sigue el mismo patrón: estandariza los nombres de las columnas, agrupa por mes y verifica contra el FPS. El flujo de trabajo de auditoría de lotes de P60 cubre el nombrado de archivos, el diseño de columnas y la fusión multiempleador 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 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 su software de nóminas contiene los mismos datos que usted teclearía manualmente en una base de datos de salidas. La normativa le exige emitirlo. No le exige perder los datos en el proceso. Defina sus columnas una vez. Suba el lote de bajas del mes. Deje que la hoja de cálculo se complete sola — y dentro de seis meses tendrá no solo un registro de cumplimiento, sino un conjunto de datos capaz de responder preguntas que sus entrevistas de salida nunca formularon.
Pruébelo con sus P45