La avalancha de P45 de enero
Una guía de supervivencia para nóminas en el Reino Unido

El pico de enero que nadie programó

La rotación de personal en el Reino Unido ronda aproximadamente el 34 % anual, según el análisis del CIPD de la Encuesta Anual de Población — alrededor del 27,4 % de los trabajadores cambia a un nuevo empleador y el 6,6 % abandona el mercado laboral cada año. Con aproximadamente 33 millones de personas en PAYE, eso supone unos 9 millones de P45 generados anualmente solo para quienes cambian de trabajo. Pero la rotación no es uniforme a lo largo del calendario. Todo profesional de nóminas sabe que se concentra, y enero es el mes de mayor concentración del año.

El momento no es aleatorio. La mayoría de los empleadores del Reino Unido tienen un período de preaviso de un mes, a veces tres meses para puestos directivos. Quien decide irse durante las vacaciones de Navidad — después de la fiesta de la empresa, después de que llegue el bono, después de quince días en familia que aclararon lo que realmente quiere de su vida laboral — entrega su preaviso en la primera semana de enero. Ese preaviso se extiende durante enero, y su paga final y la fecha del P45 caen a finales de enero o principios de febrero. Mientras tanto, los nuevos empleados que llegan para reemplazarlos traen P45 de sus anteriores empleadores — documentos generados por diferentes softwares de nóminas, con diferentes diseños y diferentes posiciones de campos — y cada uno de esos P45 debe ser leído, transcrito al sistema de nóminas del nuevo empleador y verificado antes de la primera ejecución de nómina. Una empresa de construcción con 400 trabajadores en obra y un 35 % de rotación anual procesará aproximadamente 140 P45 en un año, y una cantidad desproporcionada de ellos llegan en el primer trimestre. Una gestoría de nóminas que atiende a 30 clientes PYME con un total de 450 empleados se enfrentará a una versión condensada del mismo patrón en múltiples sectores, múltiples exportaciones de software de nóminas, múltiples formatos de P45 — ninguno de ellos estandarizado.

El volumen por sí solo no es el problema; los equipos de nóminas manejan volumen durante todo el año. Lo que hace diferente a enero es que el volumen choca con el trabajo atrasado de la ventana de procesamiento comprimida de diciembre. Los datos del CIPP muestran que el mes más corto de diciembre obliga a los departamentos de nóminas a adelantar tareas y aplazar otras. "La renovación de los años de beneficios en enero también añade significativamente a la carga de trabajo de diciembre", señaló el CIPP en su informe de nóminas de diciembre. Las renovaciones de años de beneficios, el procesamiento de P11D y las actualizaciones de códigos fiscales se acumulan sobre la ejecución de nómina estándar de enero. La oleada de bajas por P45 llega en medio de un mes que ya iba a ser ajustado — y llega en dos direcciones a la vez.

El problema de doble dirección: bajas y altas, la misma semana

El P45 es el único documento de nóminas que un empleador del Reino Unido produce y consume en el mismo flujo de trabajo. Cuando un empleado causa baja, el empleador emite un P45 (formalmente «Detalles del empleado que causa baja laboral») conforme a la Regulación 36 del Reglamento del Impuesto sobre la Renta (PAYE) de 2003. El software genera el certificado de cuatro partes: la Parte 1 se envía a HMRC mediante RTI en la última Full Payment Submission, mientras que las Partes 1A, 2 y 3 se entregan al empleado. El lado de la emisión está en gran medida automatizado: Sage Payroll, BrightPay, Xero Payroll, Iris y Moorepay gestionan la generación del P45 como una función estándar, calculando las cifras acumuladas desde el inicio del año fiscal (6 de abril) hasta la fecha de baja, aplicando la base del código tributario correcto y completando el certificado.

El lado de la recepción es donde termina la automatización. Cuando un nuevo empleado llega con un P45 de su empleador anterior — o envía por correo electrónico un PDF generado por un software de nóminas completamente distinto — alguien tiene que abrir ese documento, localizar cinco campos y teclearlos en el sistema de nóminas del nuevo empleador. Esos cinco campos son: fecha de baja, pago total hasta la fecha e impuesto total hasta la fecha para el año fiscal en curso, código tributario en el momento de la baja, número de National Insurance y estado de deducción del préstamo estudiantil. Si cualquiera de ellos se introduce incorrectamente, la primera nómina del nuevo empleado será errónea — y la corrección recae en el equipo de nóminas, no en el proveedor del software. HMRC exige que los registros de nóminas se conserven durante al menos tres años y advierte de que unos registros inadecuados pueden dar lugar a una factura fiscal estimada y a una penalización de hasta £3.000.

En enero, el lado de la recepción de esta ecuación se multiplica. Un administrador de nóminas que normalmente gestiona dos o tres P45 de nuevas altas a la semana puede enfrentarse a quince en la segunda semana de enero — las bajas de diciembre que ahora son las altas de enero de otra empresa. Cada uno tarda de dos a tres minutos en transcribirse y verificarse. Con la mediana salarial del administrador de nóminas del Reino Unido en aproximadamente £29.750 brutas — lo que se traduce en un coste empresarial cargado de cerca de £21 por hora una vez que se tienen en cuenta la Clase 1 de National Insurance del empleador al 15% por encima del umbral secundario de £5.000 y las contribuciones de pensión de inscripción automática — eso supone unos 70 peniques de mano de obra por P45. El coste es lo bastante pequeño como para que nadie presupueste para ello, que es precisamente la razón por la que la introducción de datos del P45 nunca se ha costeado adecuadamente en la mayoría de las organizaciones. Pero con quince P45 a la semana a lo largo de un enero que se extiende durante cuatro o cinco períodos de pago, el reloj corre sobre una tarea que no tiene capa de automatización entre el PDF en la pantalla y el registro de nóminas en el sistema.

Los cinco campos que mantienen los P45 en modo manual

RTI digitalizó el tramo empleador-HMRC del P45 en 2013. Todos los programas de nóminas transmiten ahora los datos de los empleados que causan baja directamente a HMRC a través del Full Payment Submission — la Parte 1 del P45 es efectivamente redundante. Pero RTI no hizo nada por el tramo empleador-empleador. Las Partes 2 y 3, que llevan los mismos datos al nuevo empleador, siguen siendo documentos físicos o PDF diseñados para la lectura humana. Nunca fueron diseñados para la lectura automática. Y como HMRC especifica qué datos debe contener un P45, pero no cómo deben disponerse, cada proveedor de software de nóminas diseña su propio formato de P45.

Un P45 generado por Sage 50 Payroll coloca el código fiscal en una posición distinta que uno de BrightPay. El PDF del P45 de Xero se ve diferente al de Iris. El diseño de Moorepay difiere del de FreeAgent. Los cinco campos que importan — fecha de baja, total pagado hasta la fecha, total de impuestos hasta la fecha, código fiscal, número de NI — aparecen en todos los certificados, pero sus coordenadas, tamaños de fuente, redacción de etiquetas y proximidad a otros campos varían con cada proveedor de software, cada actualización de versión y, a veces, cada preferencia de plantilla configurada por el empleador. Una oficina de nóminas que recibe P45 de treinta empresas clientes distintas puede encontrarse con treinta diseños diferentes — y el único denominador común garantizado entre todos ellos es que una persona tiene que localizar los campos y teclearlos.

Esta variabilidad de diseño es la razón por la que el procesamiento de P45 ha resistido la automatización incluso mientras todas las demás partes de las nóminas han migrado al software. El OCR tradicional necesita saber dónde se sitúa cada campo en la página — un enfoque basado en la posición que falla en cuanto llega un P45 de otro proveedor de nóminas. Las herramientas de extracción basadas en plantillas requieren crear y mantener una regla de análisis separada para cada variante de diseño, lo que añade una carga administrativa que rivaliza con el tecleo que se suponía que debía reemplazar. El cuello de botella es estructural: los datos del P45 están estandarizados a nivel de campo — HMRC define los campos — pero no a nivel de diseño, que queda en manos del mercado de software.

Lo que cambia la ecuación es la extracción semántica: leer un documento comprendiendo lo que cada campo significa en lugar de dónde se sitúa. En lugar de programar una herramienta para encontrar «Código fiscal» en la columna A, fila 7 de una plantilla específica de P45, un extractor semántico identifica el campo por su etiqueta — «Código fiscal al momento de la baja», «Tax code», «Código fiscal (en la fecha de baja)» — y extrae el valor adyacente independientemente de su posición. Este enfoque, que ImageToTable.ai denomina Extracción de Columnas Personalizadas, es el primer método de extracción que se ajusta a cómo funcionan realmente los P45 en el ecosistema de nóminas del Reino Unido: mismos datos, diseños diferentes, sin estandarización. Usted escribe los nombres de las columnas que desea — Fecha de baja, Total pagado hasta la fecha, Código fiscal, Número de NI, Estado del préstamo estudiantil — y la IA localiza cada valor en cualquier parte de la página comprendiendo lo que significa la etiqueta, no dónde aparece.

Lo que realmente cuesta un código de impuesto mal escrito

Un código de impuesto 1257L significa que el empleado tiene derecho a la desgravación personal completa de £12,570 para el año fiscal 2025/26 — el código estándar para la mayoría de los empleados con un solo empleo y sin ajustes. El sufijo «L» indica la desgravación personal estándar exenta de impuestos, y el número 1257 es la desgravación dividida entre 10. Si un administrador de nóminas escribe 1275L en su lugar — dos dígitos transpuestos — el software de nóminas interpreta esto como una desgravación personal de £12,750, y el empleado recibe £180 de más en su desgravación exenta de impuestos a lo largo del año. El sistema de HMRC eventualmente detectará la discrepancia y emitirá un código corregido, pero para entonces el empleado puede haber estado pagando menos impuestos durante meses. El pago insuficiente se recauda mediante un código de impuesto futuro ajustado, que aparece en el recibo de nómina del empleado sin previo aviso — y el empleado llama al departamento de nóminas queriendo saber por qué su salario neto ha bajado.

Esto no es hipotético. Los foros de AccountingWEB contienen casos reales de errores de entrada de datos P45 que se propagan a través de múltiples períodos de pago. Una oficina de nóminas informó haber introducido las cifras acumuladas del año del P45 de una exportación CSV de Sage de un empleador anterior en BrightPay para una transferencia a mitad de año — y descubrir meses después que el cliente había sido cobrado £2,390 por HMRC, exactamente el impuesto acumulado de las cifras del P45 que se habían contado dos veces. La respuesta de HMRC: presentar una disputa, que puede tardar «más de un año en resolverse». Los dos minutos de escritura que causaron el error ya habían ocurrido; la corrección tardó un año.

La tasa de error en la entrada manual de datos se sitúa entre el 1% y el 4% por campo, dependiendo de la calidad del documento, la presión de tiempo y la familiaridad del operador con el diseño. En cinco campos del P45, una tasa de error del 1% por campo da aproximadamente un 5% de probabilidad de que cualquier P45 dado contenga al menos un error. Con quince P45 por semana durante enero, eso es una casi certeza estadística de al menos un error por mes — y el error que aterriza en el campo del código de impuesto no se anunciará hasta que un recibo de nómina sea incorrecto. El empleado que nota el error llama a nóminas. Nóminas verifica el P45 de origen, encuentra el error de transcripción e inicia una corrección. HMRC se involucra. Los dos minutos de entrada de datos que costaron 70 peniques ahora han consumido tres puestos de trabajo, múltiples correos electrónicos y potencialmente semanas de seguimiento — nada de ello presupuestado, nada de ello visible en un informe de centro de costes, todo ello atribuible a un solo dígito mal escrito.

El coste total de la tramitación manual del P45 — mano de obra, corrección de errores, exposición al cumplimiento normativo y la multa de 3.000 libras por empleado por mantenimiento de registros — se ha desglosado en detalle. Para el equipo de nóminas de enero, la parte relevante de ese marco es el lado de la recepción: cada P45 que llega de un nuevo empleado es una tarea de transcripción manual, cada tarea de transcripción conlleva una probabilidad de error, y enero multiplica tanto el volumen como la presión de tiempo que aumenta la tasa de error.

Romper el ciclo de los P45 de enero

La solución estructural para el cúmulo de P45 de enero no es más personal ni más horas extra — los equipos de nóminas que ya están al límite en diciembre no tienen capacidad adicional para absorber un pico en enero trabajando más. La solución es eliminar por completo el paso de transcripción. Los datos de un P45 — fecha de baja, salario acumulado, impuestos acumulados, código fiscal, número de la Seguridad Social, estado del préstamo estudiantil — ya están impresos en el certificado. El papel del administrador de nóminas debe ser la verificación, no la creación. Mire los datos extraídos, confirme que coinciden con la fuente, impórtelos en el sistema de nóminas. Un paso en lugar de dos, y el paso que conlleva el riesgo de error — la escritura — se elimina.

Aquí es donde la extracción por IA sin plantillas cambia el flujo de trabajo para el procesamiento de P45. A diferencia del OCR basado en posición que necesita saber dónde se encuentra cada campo en un diseño de P45 específico, la extracción semántica lee el documento comprendiendo lo que significa cada etiqueta de campo. Un P45 generado por Sage coloca el código fiscal en un lugar; un P45 generado por BrightPay lo coloca en otro. Un lector humano navega por ambos de forma instintiva: busca "Código fiscal" o "Código fiscal al causar baja" y lee el valor adyacente. La extracción semántica hace lo mismo: localiza el campo por su significado en lugar de por sus coordenadas. Este es el mecanismo central que hace viable procesar por lotes P45 de múltiples fuentes en una sola operación — no está creando plantillas para el formato de salida de cada software de nóminas. Le está diciendo al sistema qué columnas quiere, y encuentra los datos coincidentes en cada documento independientemente del diseño.

La dimensión del procesamiento por lotes es crítica específicamente para enero. Con quince, veinte o treinta P45 llegando en una sola semana — una mezcla de empleados salientes cuyos formularios deben emitirse y empleados entrantes cuyos formularios deben registrarse — procesarlos uno por uno no resuelve el problema de la presión de tiempo. Extraerlos todos en una sola operación por lotes, con resultados fusionados en una hoja de cálculo donde cada fila es un registro de datos de P45 completo, convierte una semana de escritura distribuida en una tarde de revisión. El flujo de trabajo de procesamiento por lotes de P45 — construir una base de datos de salidas a partir de múltiples formularios simultáneamente — se aplica igualmente al lado de las entradas de nuevos empleados. La misma ejecución de extracción que completa una base de datos de salidas para empleados que se van puede completar una hoja de configuración de nuevos empleados para los que llegan, porque los cinco campos principales son idénticos en ambas direcciones.

Un flujo de trabajo de nóminas de enero que no depende de escribir a mano

En lugar de abrir cada PDF de P45 individualmente, leer cinco campos, cambiar al software de nóminas, escribir cinco campos y repetir treinta veces, un administrador de nóminas con herramientas de extracción puede reestructurar el trabajo de enero en tres bloques:

La aritmética del tiempo es sencilla. A dos minutos por P45 para entrada manual, treinta P45 de nuevos empleados consumen una hora de escritura — y eso antes de corregir cualquier error descubierto más tarde. Con la extracción por lotes, los mismos treinta P45 se cargan, extraen y compilan en una sola hoja de cálculo en minutos. La hora restante se convierte en verificación e importación — trabajo que siempre fue necesario y que el administrador de nóminas ahora puede hacer correctamente en lugar de apretarlo en los huecos entre sesiones de escritura.

Para el lado de las bajas salientes, el mismo flujo de extracción sirve a un propósito diferente: verificar que las cifras en los P45 generados sean correctas antes de que lleguen al empleado y a HMRC. Una extracción por lotes de los PDF de P45 salientes contra los propios registros del sistema de nóminas crea una verificación cruzada automatizada — ¿coincide la fecha de baja en el P45 con el sistema? ¿Cuadran las cifras de pago e impuestos acumulados en el año? Ejecutar esta comprobación antes del envío de RTI cierra el ciclo entre lo que dice el software de nóminas y lo que muestra el certificado, detectando discrepancias antes de que lleguen al procesamiento de FPS de HMRC. La guía paso a paso para extraer datos de P45 de bajas a Excel recorre este flujo de trabajo en detalle, incluyendo los mapeos de campos específicos y casos límite comunes como los indicadores de base Semana 1/Mes 1 y los tipos de plan de préstamo de estudios.

Por qué enero es el mes que revela el problema

Durante once meses al año, el procesamiento manual del P45 es una fricción administrativa menor: unos minutos aquí, unos formularios allá, algún error ocasional que se detecta antes de causar daños. En enero, deja de ser fricción y se convierte en un cuello de botella. El volumen se dispara, la presión de tiempo se intensifica, la tasa de error aumenta y la carga de corrección — correos a HMRC, envíos de FPS modificados, consultas de nómina de empleados — se extiende hasta febrero y marzo. El problema siempre fue estructural: los datos del P45 están estandarizados a nivel de campo, pero no a nivel de diseño, y la transferencia entre empleadores sigue siendo una cadena de transcripción humana en un ecosistema de nóminas por lo demás automatizado. Enero solo expone la fractura en el peor momento posible.

El problema más profundo es que los equipos de nóminas del Reino Unido aún procesan P45 a mano no porque carezcan de habilidades o herramientas para hacerlo de otra manera, sino porque las herramientas disponibles hasta hace poco — OCR basado en plantillas, extracción zonal — requerían un nivel de configuración por formato que hacía que la automatización fuera más lenta que el proceso manual que debía reemplazar. Cuando una oficina de nóminas recibe P45 de treinta empresas clientes diferentes que usan cinco paquetes de nóminas distintos, crear y mantener treinta plantillas de extracción es un trabajo de tiempo completo en sí mismo. La extracción semántica elimina esta barrera: una definición de columna, aplicada a cada P45 del lote, porque la IA entiende qué significa "Código Fiscal al Salir" independientemente del software que lo imprimió.

Para los equipos de nóminas que se preparan para el próximo enero, la pregunta no es si la entrada manual de datos del P45 es sostenible — los números de volumen ya lo han respondido. La pregunta es en qué punto el costo acumulado de errores de transcripción, ciclos de corrección y la carga administrativa de escribir los mismos cinco campos una y otra vez supera el costo de cambiar a un flujo de trabajo sin escritura. El marco de costos ya está disponible. Las herramientas existen. La única variable restante es la decisión de dejar de escribir y empezar a revisar — y enero, más que cualquier otro mes, justifica tomar esa decisión antes de que llegue la próxima ola de salidas.

Preguntas Frecuentes

¿Con qué rapidez debe un empleador del Reino Unido emitir un P45 tras la salida de un empleado?

Según el Reglamento 36 del Reglamento del Impuesto sobre la Renta (PAYE) de 2003, el P45 debe completarse el día en que finaliza el empleo o, si no es posible, sin demora injustificada. En la práctica, HMRC espera que el P45 se emita con el pago final del empleado o dentro del mismo ciclo de nómina. La mayoría del software de nóminas (Sage, BrightPay, Xero Payroll, Iris, Moorepay) genera el P45 automáticamente cuando el empleado se marca como saliente y se procesa la última nómina. La Parte 1 se envía a HMRC a través de la Presentación de Pago Completo (FPS) en o antes del último día de pago del empleado.

¿Puedo procesar por lotes P45 de diferentes softwares de nóminas?

Sí, con extracción semántica por IA en lugar de OCR basado en plantillas. Las herramientas basadas en plantillas requieren una regla de análisis separada para el diseño del P45 de cada software (Sage, BrightPay, Xero, Iris, Moorepay y FreeAgent producen certificados con formatos diferentes). La extracción semántica lee cada P45 comprendiendo el significado de las etiquetas de los campos (como "Código Fiscal al Salir" o "Pago Total Hasta la Fecha") en lugar de su posición en la página. Esto significa que puede cargar un lote mixto con P45 de múltiples proveedores de nóminas y extraerlos todos con un único conjunto de definiciones de columnas. El resultado es una hoja de cálculo con una fila por P45.

¿Qué información de un P45 debe ingresarse en el sistema de nóminas del nuevo empleador?

Cinco campos clave de las Partes 2 y 3 del P45: la fecha de salida del empleado de su empleo anterior, el pago total hasta la fecha y el impuesto total hasta la fecha para el año fiscal actual (del 6 de abril al 5 de abril), el código fiscal al salir (incluyendo cualquier indicador de base Semana 1/Mes 1), el número de la Seguridad Social y el estado de deducción del préstamo estudiantil. Si alguno de estos se ingresa incorrectamente, el nuevo empleado podría ser colocado en un código fiscal de emergencia y su primer recibo de nómina será incorrecto. Las cifras del año fiscal son acumulativas: son los totales corrientes que el nuevo empleador necesita para continuar la situación fiscal del empleado sin reiniciarla.

¿Cuál es la diferencia entre un P45 y un P60?

Ambos muestran lo que un empleado ha ganado y los impuestos pagados en un año fiscal, pero se activan por eventos distintos. El P45 se emite cuando un empleado deja un trabajo: cubre el período desde el inicio del año fiscal (6 de abril) hasta la fecha de salida. El P60 se emite al final de cada año fiscal para los empleados que aún trabajan para el empleador en ese momento: cubre los 12 meses completos hasta el 5 de abril. Los empleadores deben proporcionar los P60 a todos los empleados actuales antes del 31 de mayo de cada año. Para más información sobre el procesamiento de P60, consulte la guía sobre extracción de datos P60 del Reino Unido a Excel para conciliación de nóminas.

¿Qué sucede si se ingresa incorrectamente un código fiscal del P45?

Un código fiscal incorrecto modifica de inmediato el cálculo de la asignación libre de impuestos del empleado. Por ejemplo, ingresar 1275L en lugar de 1257L otorga una asignación de £12,750 en lugar de £12,570; el empleado paga £180 menos de impuestos durante el año. HMRC normalmente detecta la discrepancia mediante la comparación de datos RTI y emite un código fiscal corregido. El impuesto no pagado se recupera mediante un ajuste futuro del código fiscal, lo que reduce el salario neto del empleado en un mes posterior. El empleado a menudo contacta a nóminas para preguntar por qué cambió su pago, y nóminas debe rastrear hasta la entrada original del P45 para explicar la corrección. Si el error no se detecta, puede persistir entre años fiscales y acumularse en un impago mayor que HMRC persigue directamente.

¿Se pueden procesar formularios P45 en papel con la misma herramienta de extracción?

Sí. Una imagen escaneada o una foto de un P45 en papel funciona igual que un PDF: la IA lee el documento visualmente, no a partir de capas de texto incrustadas. Esto es especialmente útil para los P45 en papel que aún circulan en pequeñas empresas, o para P45 que llegan como archivos adjuntos en formatos que no se pueden analizar directamente (PDF escaneados, fotos JPEG, capturas de pantalla de un portal de nóminas). La herramienta de extracción admite entradas en PDF, JPG, PNG, WebP y AVIF.

¿La extracción por lotes de P45 funciona para gestorías que administran varias empresas clientes?

Sí — las gestorías son el caso de uso más sólido porque enfrentan la máxima diversidad de formatos. Una gestoría que administra nóminas de treinta pymes en cinco paquetes de software distintos recibe P45 en docenas de formatos diferentes cada mes. Con la extracción semántica, la gestoría define un conjunto de nombres de columna y lo aplica a cada P45 del lote, independientemente del software que lo haya generado. El resultado es una hoja de cálculo consolidada por cliente o por proceso. La guía de procesamiento por lotes de P45 cubre en detalle los flujos de trabajo para gestorías con múltiples clientes.