La avalancha de P45 en enero
Guía de supervivencia para nóminas en 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 bidireccional: salidas y entradas, la misma semana

El P45 es el único documento de nómina en el Reino Unido que un empleador produce y consume en el mismo flujo de trabajo. Cuando un empleado se va, el empleador emite un P45 (formalmente "Detalles del empleado que deja el trabajo") según el Reglamento 36 del Reglamento del Impuesto sobre la Renta (PAYE) de 2003. El software genera el certificado de cuatro partes: la Parte 1 va a HMRC a través de RTI en el último envío de pago completo, mientras que las Partes 1A, 2 y 3 van al empleado. La emisión está en gran medida automatizada: Sage Payroll, BrightPay, Xero Payroll, Iris y Moorepay manejan la generación del P45 como función estándar, calculando las cifras acumuladas desde el inicio del año fiscal (6 de abril) hasta la fecha de salida, aplicando la base del código tributario correcto y completando el certificado.

El lado receptor 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ómina completamente diferente — alguien tiene que abrir ese documento, localizar cinco campos y escribirlos en el sistema de nómina del nuevo empleador. Esos cinco campos son: fecha de salida, pago total hasta la fecha e impuesto total hasta la fecha para el año fiscal actual, código tributario al salir, número de seguro nacional y estado de deducción del préstamo estudiantil. Si alguno se ingresa incorrectamente, el primer recibo de sueldo del nuevo empleado será incorrecto — y la corrección recae en el equipo de nóminas, no en el proveedor del software. HMRC exige que los registros de nómina se conserven durante al menos tres años y advierte que los registros inadecuados pueden generar una factura de impuestos estimada y una multa de hasta 3.000 £.

En enero, el lado receptor de esta ecuación se multiplica. Un administrador de nóminas que normalmente maneja dos o tres P45 de nuevos empleados por semana puede enfrentarse a quince en la segunda semana de enero — los que se fueron en diciembre y ahora son los nuevos empleados de enero de otra empresa. Cada uno toma de dos a tres minutos para transcribir y verificar. Con un salario medio de administrador de nóminas en el Reino Unido de aproximadamente 29.750 £ brutos — lo que se traduce en un costo patronal cercano a 21 £ por hora una vez que se incluyen el seguro nacional de Clase 1 del empleador al 15% por encima del umbral secundario de 5.000 £ y las contribuciones al plan de pensiones de inscripción automática — eso equivale a unos 70 peniques de mano de obra por P45. El costo es lo suficientemente pequeño como para que nadie lo presupueste, razón por la cual la entrada de datos del P45 nunca se ha calculado adecuadamente en la mayoría de las organizaciones. Pero con quince P45 por semana durante un enero que se extiende por cuatro o cinco períodos de pago, el tiempo corre para una tarea que no tiene capa de automatización entre el PDF en la pantalla y el registro de nómina en el sistema.

Los cinco campos que mantienen los P45 en modo manual

El RTI digitalizó en 2013 el tramo empleador-HMRC del P45. Todo software de nóminas envía ahora los datos de salida directamente a HMRC mediante el Full Payment Submission; la Parte 1 del P45 es prácticamente redundante. Pero el 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 lectura humana. Nunca se diseñaron para lectura automática. Y como HMRC especifica qué datos debe contener un P45, pero no cómo deben distribuirse, cada proveedor de software de nóminas diseña su propio formato de P45.

Un P45 generado por Sage 50 Payroll sitúa el código tributario 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 salida, pagado hasta la fecha, impuestos hasta la fecha, código tributario, número de la Seguridad Social — aparecen en todos los certificados, pero sus coordenadas, tamaños de fuente, 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 que fija el empleador. Una oficina de nóminas que recibe P45 de treinta empresas clientas distintas puede encontrarse con treinta diseños diferentes, y el único denominador común garantizado 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 cuando el resto de la nómina se ha pasado al software. El OCR tradicional necesita saber dónde está 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 distinta para cada variante de diseño, lo que añade una carga administrativa que rivaliza con el tecleo que se suponía que iban a sustituir. 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 a merced del mercado de software.

Lo que cambia la ecuación es la extracción semántica: leer un documento entendiendo lo que cada campo significa en lugar de dónde está. En lugar de programar una herramienta para encontrar "Código tributario" en la columna A, fila 7 de una plantilla concreta de P45, un extractor semántico identifica el campo por su etiqueta — "Código tributario al salir", "Tax code", "Código tributario (a fecha de salida)" — y extrae el valor adyacente independientemente de su posición. Este enfoque, que ImageToTable.ai llama 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 distintos, sin estandarización. Usted escribe los nombres de las columnas que desea — Fecha de salida, Pagado hasta la fecha, Código tributario, Número de la Seguridad Social, Estado del préstamo estudiantil — y la IA localiza cada valor en cualquier parte de la página entendiendo lo que significa la etiqueta, no dónde aparece.

Lo que realmente cuesta un código fiscal mal escrito

Un código fiscal 1257L significa que el empleado tiene derecho al subsidio personal completo de £12,570 para el año fiscal 2025/26 — el código estándar para la mayoría de empleados con un solo empleo y sin ajustes. El sufijo 'L' indica el subsidio personal libre de impuestos estándar, y el número 1257 es el subsidio dividido 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 un subsidio personal de £12,750, y el empleado recibe £180 de más en su subsidio libre de impuestos durante el año. El sistema de HMRC eventualmente detectará el desajuste y emitirá un código corregido, pero para entonces el empleado puede haber estado pagando menos impuestos durante meses. El pago insuficiente se recupera mediante un código fiscal futuro ajustado, que aparece en el recibo de nómina del empleado sin previo aviso — y el empleado llama al departamento de nóminas preguntando por qué bajó su salario neto.

Esto no es hipotético. Los foros de AccountingWEB contienen casos reales de errores de ingreso de datos P45 que se propagan a través de múltiples períodos de pago. Una oficina de nóminas reportó haber ingresado cifras de año hasta la fecha de un 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 para 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 tenga al menos un error. Con quince P45 por semana durante enero, eso es una certeza estadística de al menos un error por mes — y el error que aterriza en el campo del código fiscal no se anunciará hasta que un recibo de nómina esté mal. El empleado que nota el error llama a nóminas. Nóminas verifica el P45 original, encuentra el error de transcripción e inicia una corrección. HMRC se involucra. Los dos minutos de ingreso de datos que costaron 70 peniques ahora han consumido tres escritorios, múltiples correos electrónicos y potencialmente semanas de seguimiento — nada de ello presupuestado, nada de ello visible en un informe de centro de costos, 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 nómina 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ómina, escribir cinco campos y repetir treinta veces, un administrador de nóminas con herramientas de extracción puede reestructurar la carga de trabajo de enero en tres bloques:

La aritmética de 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 errores descubiertos después. Con extracción por lotes, los mismos treinta P45 se cargan, extraen y compilan en una 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 apretujarlo entre sesiones de escritura.

Para el lado de los que se van, el mismo flujo de extracción sirve para otro propósito: verificar que las cifras de los P45 generados sean correctas antes de que lleguen al empleado y a HMRC. Una extracción por lotes de los PDF de P45 de salida contra los propios registros del sistema de nómina crea una verificación cruzada automatizada: ¿coincide la fecha de baja del P45 con el sistema? ¿Concuerdan las cifras de pago e impuesto acumulados? Ejecutar esta comprobación antes del envío de RTI cierra el círculo entre lo que dice el software de nómina y lo que muestra el certificado, detectando discrepancias antes de que lleguen al procesamiento FPS de HMRC. La guía paso a paso para extraer datos de P45 de salida a Excel detalla este flujo de trabajo, incluyendo los mapeos de campo específicos y casos 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.