El problema de mayo en la nómina del Reino Unido
El costo oculto de la entrada de datos del P60

El problema de mayo que nadie presupuesta

El P60 no es opcional. Según el Reglamento 67 del Income Tax (PAYE) Regulations 2003, todo empleador debe entregar un P60 a cada empleado en nómina al 5 de abril. El plazo vence el 31 de mayo. Si no se cumple, HMRC puede imponer una multa inicial de £300, más £60 por cada día adicional que el P60 esté pendiente. Para un departamento de nóminas que ya sobrevivió el sprint de cierre de año — FPS final, EPS final, conciliación del P32 — mayo no es un mes de recuperación. Es un segundo plazo.

Para una empresa con 100 empleados, la emisión del P60 toma minutos en un software de nóminas moderno. Haga clic en "generar P60". Descargue. Distribuya. Listo. El costo laboral aparece cuando alguien necesita usar los datos del P60 para algo que el software de nóminas nunca fue diseñado para hacer: compilar un informe de compensación anual para la junta, conciliar los totales salariales con el libro mayor, preparar datos para una auditoría, o — y aquí es donde el volumen explota — consolidar información de P60 de empleados que trajeron certificados de empleadores anteriores.

Una oficina de nóminas mediana que gestiona 30 clientes PYME con un promedio de 15 empleados cada uno maneja 450 P60 cada mayo. Un contador que procesa declaraciones de autoliquidación para 80 clientes necesita las cifras del P60 de cada uno. Un departamento de RRHH que planifica un estudio salarial necesita los totales salariales de fin de año de toda la plantilla — incluidos los empleados que se incorporaron a mitad de año y cuyo P60 muestra solo la parte ganada con el empleador actual, no el total que ganaron en dos trabajos en el mismo año fiscal. En cada uno de estos escenarios, el P60 existe. Los datos están en la página. Pero llevarlos a una hoja de cálculo — fila por fila, campo por campo, empleador por empleador — sigue siendo una operación manual.

De dónde viene el P60

Si todos los P60 llegaran como exportaciones de datos limpias y legibles por máquina del mismo sistema de nóminas, el problema de la entrada manual no existiría. También sería otro país. En el Reino Unido, el panorama del P60 está fragmentado por factores estructurales que ningún proveedor de software de nóminas tiene incentivos para solucionar.

Los empleadores anteriores siguen emitiendo papel. Un empleado que cambió de trabajo durante el año fiscal 2025/26 dejó a su antiguo empleador con un P45, pero el 5 de abril, el antiguo empleador sigue emitiendo un P60 por la parte del año que el empleado trabajó allí. Según las normas de HMRC, cada empleo genera su propio P60. Si el empleador anterior utiliza presentación en papel o está exento de la presentación electrónica — empleadores de cuidados y apoyo, algunas organizaciones religiosas y aquellos con exenciones por circunstancias excepcionales — ese P60 llega como documento físico. El empleado lo entrega a su nuevo departamento de nóminas. Alguien teclea las cifras.

Varios trabajos implican varios P60. Un empleado con dos trabajos PAYE — un puesto a tiempo completo y uno de fin de semana, o un trabajo principal y un salario de director de un negocio secundario — recibe dos P60 separados. Cada uno muestra solo los ingresos de ese empleo específico. Para compilar los ingresos anuales totales del empleado — necesarios para una solicitud de hipoteca, reclamación de crédito fiscal o declaración de autoliquidación — alguien debe sumar las dos cifras y luego ingresar los datos combinados donde sea necesario. El sistema de nóminas del Trabajo A no puede ver el P60 del Trabajo B. El sistema de nóminas del Trabajo B no puede ver el Trabajo A. El puente es una calculadora y un teclado.

Las adquisiciones dejan las nóminas en sistemas diferentes. Una empresa que adquirió una filial en 2024 puede seguir usando dos proveedores de nóminas: Sage para la matriz, BrightPay para la entidad adquirida. Ambos proveedores generan P60. Ambos los generan en su propio formato, con sus propias etiquetas de campo, estructurados para sus propios paneles de informes. Un director financiero que necesita una vista consolidada única de los costes totales de personal en toda la entidad combinada abre una hoja de cálculo y comienza a fusionar datos de dos exportaciones incompatibles — o, más comúnmente, de los propios PDF de los P60, porque los formatos de exportación difieren lo suficiente como para que la conciliación automatizada requiera un proyecto de TI que nadie tiene tiempo de encargar en mayo.

Los clientes de las gestorías traen archivos en cualquier formato. Las gestorías de nóminas y los despachos de contabilidad se encuentran en la intersección de todas estas fuerzas de fragmentación. Una sola gestoría puede procesar nóminas para 40 clientes usando cuatro sistemas de nóminas diferentes. Cuando un cliente trae datos de P60 de un proveedor de nóminas anterior del que se cambiaron a mitad de año — o cuando un empleado de un cliente de la gestoría necesita cifras de P60 de años anteriores para una declaración de impuestos — la gestoría recibe PDF, copias en papel escaneadas, capturas de pantalla de la Cuenta Fiscal Personal de HMRC y, ocasionalmente, una fotografía de un P60 que el cónyuge de alguien encontró en un archivador y envió por mensaje de texto. El trabajo de la gestoría es convertir todo eso en números precisos. La herramienta de la gestoría, en la mayoría de los casos, es un administrativo de entrada de datos.

Cómo es realmente la introducción manual de datos del P60: campo por campo, minuto a minuto

La «introducción manual de datos» es una abstracción que el marketing del software de nóminas ha desgastado. No dice nada sobre lo que una persona hace realmente en su escritorio durante el apuro de mayo. Esta es la secuencia real.

Un administrador de nóminas de una empresa de 120 empleados se sienta el 6 de mayo a elaborar el informe retributivo de fin de año. El sistema de nóminas —por ejemplo, Sage 50 Payroll— ya ha generado los P60 de todos los empleados actuales. El administrador descarga el paquete PDF. Pero el informe que quiere el director financiero no son los P60 en sí. Es una hoja de cálculo con las siguientes columnas: nombre del empleado, número de NI, código fiscal, retribución bruta total, impuesto total deducido, cotizaciones del empleado al NI, cotizaciones del empleador al NI. Algunos de estos campos están en el P60. El NI del empleador no —está en el informe P32 del sistema de nóminas—. Las cotizaciones del empleado a pensiones tampoco están en el P60 —están en la nómina final—. Así que el administrador tiene ahora tres documentos fuente que contrastar para cada empleado.

Por cada uno de los 120 empleados, el administrador debe: localizar al empleado en el paquete PDF, leer la cifra de retribución bruta y verificarla contra el informe interno del sistema de nóminas, escribirla en la hoja de cálculo, leer el impuesto deducido y escribirlo, leer las cotizaciones al NI y escribirlas, luego pasar al informe P32 para el NI del empleador, y pasar al PDF de la nómina para las cotizaciones a pensiones. Cada campo tarda aproximadamente de 6 a 8 segundos: encontrar el número en pantalla, confirmar que es el número correcto, escribirlo, volver a mirar para verificar. Con 120 empleados y 7 campos por empleado, son 840 campos. A 7 segundos cada uno: 98 minutos de transcripción pura. En la práctica, se acerca más a tres horas si se tiene en cuenta al empleado que tiene dos P60 (uno de un empleador anterior), el PDF que no se deja buscar correctamente porque se generó a partir de una plantilla escaneada, y la interrupción del director general preguntando si el informe estará listo para la reunión del consejo de las 2 p.m.

Para una gestoría de nóminas, la escala hace que las cifras sean más crudas. Con 450 empleados en 30 clientes, asumiendo los mismos 7 campos por empleado y el mismo ritmo, la transcripción bruta consume aproximadamente 6 horas —más de un día laborable completo de mecanografía ininterrumpida—. Pero las gestorías no disponen de bloques ininterrumpidos. Procesan los archivos de los clientes por lotes a medida que llegan, entre llamadas de clientes que tienen preguntas sobre sus P60, P32, P11D y el nuevo pago obligatorio de beneficios en especie que entró en vigor el 6 de abril de 2026. Repartidas a lo largo de una semana de atención fragmentada, 6 horas de introducción de datos se convierten en dos días completos de trabajo entrecortado —y la tasa de error aumenta con cada cambio de contexto—.

La investigación sobre las tasas de error en la introducción manual de datos converge en un rango del 1% al 4% para operadores entrenados. En el contexto de nóminas del Reino Unido, encuestas del sector han encontrado que aproximadamente el 20% de las nóminas contienen al menos un error —no el 20% de los campos de datos, sino el 20% de las ejecuciones completas de nómina—. Para la gestoría de 450 empleados, una tasa de error a nivel de campo del 1% significa 4 o 5 cifras mal tecleadas por temporada de P60. Cada una es una semilla.

La cascada de errores en el contexto de nóminas del Reino Unido

Una cifra mal escrita en un P60 no se queda en la hoja de cálculo. Viaja.

La ruta más corta llega hasta la declaración de autoliquidación del impuesto sobre la renta del empleado. Si un contable introduce el total de ingresos incorrecto de un P60 en el SA100 de un cliente, el cálculo del impuesto es erróneo. Los sistemas de HMRC comparan la declaración presentada con los datos de RTI que el empleador registró. Una discrepancia activa una verificación de cumplimiento. El contable debe localizar el P60 original, identificar el error de transcripción, corregir la declaración y explicar la rectificación al cliente. Cada paso es tiempo no facturable.

La siguiente ruta llega hasta el propio mecanismo de cumplimiento de HMRC. Según los requisitos de conservación de registros de HMRC, los empleadores deben conservar los registros de nómina durante al menos tres años desde el final del año fiscal al que corresponden. Si HMRC inspecciona esos registros y encuentra discrepancias entre las cifras de los P60 emitidos a los empleados y los registros internos utilizados para la declaración, el empleador se enfrenta a una sanción de hasta £3,000 por registros inadecuados, además de la obligación de reconstruir las cifras correctas, lo que, en una hoja de cálculo con entrada manual y sin rastro de auditoría, implica volver a introducir todo desde los documentos originales. La sanción no se debe a haber calculado mal. Se debe a no poder demostrar que el cálculo era correcto. Una hoja de cálculo con una pulsación de tecla errónea no es una prueba.

Luego está la cascada que afecta directamente a los empleados. El P60 es el documento principal que los empleados del Reino Unido utilizan para justificar ingresos en solicitudes de hipoteca, reclamaciones de créditos fiscales y renovaciones de visado. Un empleado que recibe un P60 con una cifra incorrecta — o cuyo total de ingresos en dos P60 se calculó mal al sumar los dos números — descubre el error en el peor momento posible: cuando un prestamista o el Home Office solicita una aclaración. El departamento de nóminas que emitió el P60 está legalmente obligado a emitir una versión corregida, marcada como «duplicado». Cada P60 duplicado emitido por un error de entrada manual representa tiempo que el equipo de nóminas no había previsto, dedicado a una corrección que no debería haber sido necesaria.

La ventana de corrección agrava la situación. HMRC acepta modificaciones de nóminas que se remontan a seis años fiscales desde la presentación original. Una cifra mal escrita en un P60 del año fiscal 2020/21, introducida en mayo de 2021 y corregida en 2026, ha permanecido en los registros de la empresa durante cinco años, durante los cuales cada informe, cada auditoría y cada solicitud de hipoteca que dependía de esas cifras se basó en un número erróneo. El coste de un solo error se acumula con el tiempo, no desaparece.

Por qué el software de nóminas no resolvió este problema

Sage se fundó en 1981 y procesa las nóminas de aproximadamente la mitad de las empresas del Reino Unido. Xero cuenta con más de 5.200 clientes británicos en su plataforma de contabilidad, con nóminas integradas. BrightPay domina el mercado de las agencias. ADP gestiona las nóminas de multinacionales con operaciones en el Reino Unido. El sector del software de nóminas británico es maduro, está bien capitalizado y profundamente integrado con el sistema RTI de HMRC. Entonces, ¿por qué los profesionales de nóminas siguen reescribiendo a mano los datos del P60 en 2026?

Porque el software de nóminas está diseñado para generar P60, no para consumirlos. Sage Payroll produce un P60 con el diseño reglamentario correcto, rellena los campos — paga total, impuesto deducido, contribuciones al Seguro Nacional (NI), código fiscal — desde su propia base de datos y distribuye el certificado. Lo hace de forma fiable. Lo que no hace — lo que ninguna plataforma de nóminas fue diseñada para hacer — es ingerir datos de P60 procedentes de fuera del sistema y estructurarlos para su uso posterior. Cuando un profesional de nóminas necesita incorporar datos de P60 de otro empleador, de otro proveedor de nóminas o de un certificado en papel a su propio entorno de informes, el software de nóminas no tiene nada que ofrecer. Los datos están en un PDF o en un papel. El sistema no puede leerlos. La brecha entre «los datos existen» y «los datos están en mi hoja de cálculo» sigue siendo una persona frente a un teclado.

Este es el mismo problema estructural que afecta al procesamiento de recibos de nómina en otros mercados — el equivalente estadounidense, explorado en nuestro artículo sobre extracción de W-2 y 1099 para despachos contables, sigue el mismo patrón: formularios estandarizados, sistemas incompatibles, reescritura manual. La diferencia en el contexto británico es que la estandarización del P60 hace que la entrada manual parezca más razonable — los campos son siempre los mismos, el diseño está prescrito, así que teclearlos parece una tarea pequeña. Solo cuando se multiplica esa pequeña tarea por el número de empleados, por el número de sistemas de origen, por las consecuencias posteriores de hacerlo mal, la magnitud del problema se hace visible.

Aquí es donde una categoría diferente de herramienta — diseñada para la extracción en lugar de la generación — cambia la ecuación. En lugar de exigir que cada P60 llegue a través del canal de entrada de un sistema de nóminas, la extracción semántica de documentos lee lo que cada campo significa. Defina las columnas que necesita una sola vez: «Paga total», «Impuesto deducido», «Contribuciones al NI», «Código fiscal», «Referencia PAYE». La IA localiza cada valor en todos los P60 del lote — ya provengan de Sage, de Xero, de una plantilla en papel solicitada a HMRC y rellenada a mano, o de una copia escaneada de un certificado de 2019 que un empleado encontró en un cajón. Los nombres de columna que definió se mantienen iguales; el formato de origen no importa. Sin plantillas. Sin configuración por empleador. Suba los archivos, obtenga la hoja de cálculo. Para el flujo de trabajo paso a paso, consulte nuestra guía sobre extracción de datos de P60 del Reino Unido a Excel para la conciliación de nóminas, y para la referencia completa campo por campo de los flujos de fin de año, nuestra guía completa de extracción de datos de P60 del Reino Unido.

Si prefiere ejecutar la pasada en lugar de leer sobre ella, el conversor de P60 a Excel toma un certificado individual o una carpeta completa y devuelve el mismo conjunto de columnas descrito anteriormente.

El reloj de cumplimiento avanza

El apuro de mayo no es la única fecha límite en juego cuando los datos del P60 se introducen manualmente en una hoja de cálculo. La ventana de conservación de registros de tres años del HMRC significa que cada pulsación de tecla permanece en el registro de cumplimiento de la empresa hasta al menos abril de 2029. La ventana de corrección de seis años implica que un error descubierto en 2031 debe poder rastrearse hasta el P60 original. Una hoja de cálculo introducida manualmente sin una pista de auditoría de origen a celda no puede resistir ese nivel de escrutinio.

La estructura de sanciones es binaria e implacable. Si el HMRC solicita los registros y el empleador no puede presentarlos, el HMRC puede estimar la obligación tributaria — y el empleador debe entonces demostrar que la estimación es incorrecta, utilizando registros que ya ha admitido no tener. Si los registros existen pero contienen errores, el empleador se enfrenta a la sanción de £3,000 por registros inadecuados. Si los errores afectan los impuestos declarados al HMRC, se aplican sanciones adicionales por pago tardío — comenzando en el 1% del monto impago a los 30 días, aumentando al 5% a los 6 y 12 meses. Una sola cifra de pago total mal escrita en un P60, multiplicada por la base de clientes de una agencia y arrastrada a múltiples años fiscales, puede convertir un error de tecleo en una responsabilidad de cinco cifras.

Y sin embargo, para la mayoría de los equipos de nómina, ninguno de estos riesgos se tiene en cuenta al decidir teclear los datos del P60 manualmente — porque el riesgo nunca se ha medido. El costo de la entrada de datos en sí es invisible: enterrado dentro del "procesamiento de nómina", absorbido en un rol asalariado, nunca aparece como una partida en un presupuesto. El costo de las correcciones se absorbe de la misma manera. Solo cuando una auditoría expone la brecha — cuando el HMRC pregunta "demuestre esta cifra" y la prueba es una hoja de cálculo sin trazabilidad — el costo se vuelve real. En ese punto, es demasiado tarde para decidir que la entrada manual era una falsa economía.

Para las organizaciones que necesitan recopilar P60 de múltiples fuentes — empleados en diferentes sistemas de nómina, clientes de una agencia, certificados de años anteriores para declaraciones enmendadas — un Enlace de Recopilación puede centralizar la recepción de documentos antes de la extracción, eliminando por completo el paso de "perseguir a los empleados por copias en papel" del flujo de trabajo.

Preguntas frecuentes

¿Por qué no puedo simplemente obtener los datos del P60 desde la función de exportación de mi software de nómina?

Su software de nómina puede exportar datos del P60 de los empleados a los que paga. No puede exportar datos del P60 de empleados pagados por otro empleador, un proveedor de nómina anterior o un sistema en papel. E incluso dentro de su propia nómina, el formato de exportación rara vez coincide con la estructura que requieren sus informes posteriores: los nombres de los campos difieren, la disposición de las columnas no se alinea y la exportación puede no incluir las contribuciones del empleador al NI o a las pensiones que se encuentran en módulos separados. Exportar no es lo mismo que tener datos utilizables.

¿Cuál es la multa por emitir un P60 tarde?

HMRC puede cobrar una multa inicial de £300, más £60 por día por cada día que el P60 permanezca pendiente. La probabilidad de una multa depende del motivo del retraso y de la rapidez con que se subsane. Es menos probable que los errores genuinos corregidos rápidamente atraigan multas que las fallas sistemáticas o la emisión tardía repetida.

¿Por cuánto tiempo deben los empleadores conservar los registros del P60?

Tres años desde el final del año fiscal al que se refieren, según los requisitos de mantenimiento de registros de HMRC. Esto significa que un P60 para el año fiscal 2025/26 debe conservarse hasta al menos abril de 2029. HMRC también puede aceptar correcciones que se remonten a seis años fiscales, por lo que la ventana de retención práctica es más larga si existe alguna posibilidad de una enmienda.

¿Un P60 muestra las contribuciones a la pensión?

No. Los P60 muestran el pago total, el impuesto total deducido, las contribuciones al Seguro Nacional y el código fiscal final del empleado. Las contribuciones a la pensión aparecen en el recibo de nómina final del empleado del año fiscal, no en el P60. Esta es una de las razones estructurales por las que la entrada manual es frecuente: no existe un informe único que cubra todos los campos que un profesional de nómina realmente necesita; los datos están distribuidos entre el P60, el P32 y el recibo de nómina final.

Si un empleado tuvo dos trabajos en el mismo año fiscal, ¿recibe un P60 o dos?

Dos: uno de cada empleador. Cada P60 informa solo el pago y las deducciones de ese empleo específico. El empleado es responsable de combinar las cifras para la autoevaluación u otros fines. Para el profesional de nómina que procesa los datos del año en curso del empleado, esto significa que el P60 del empleador actual cubre solo parte del año, y la imagen completa requiere una consolidación manual con las cifras del P60 o P45 del empleador anterior.

¿Puede la IA manejar realmente la variedad de formatos de P60 de los distintos sistemas de nómina?

El P60 sigue un diseño prescrito por HMRC, lo que lo hace más estandarizado que la mayoría de los tipos de documento. La variación proviene de la representación del software de nómina — diferentes fuentes, posiciones de campos ligeramente distintas, presencia o ausencia de logotipos del empleador — más que de diferencias estructurales. La extracción moderna con IA lee las etiquetas de los campos de forma semántica: entiende que «Total Pay for the Year» en un P60 generado por Sage y «Pay for the Year» en un P60 generado por BrightPay se refieren al mismo dato. Dicho esto, las fotocopias muy degradadas, las correcciones manuscritas y las plantillas de papel no estándar pueden reducir la precisión. Para el lote típico de P60 — una mezcla de PDF digitales de software de nómina conocido y un puñado de copias en papel escaneadas — la precisión de la extracción elimina la mayor parte de la carga de trabajo de introducción manual, no todos los casos excepcionales.

El coste de no mirar

El sector de nóminas del Reino Unido ha construido una infraestructura sofisticada para calcular el PAYE, procesar las presentaciones RTI y generar los P60 a tiempo. Lo que no ha construido es un puente entre el P60 y la hoja de cálculo donde los datos realmente se utilizan — para análisis de compensación, preparación de auditorías, declaraciones de autoliquidación, solicitudes de hipoteca y cualquier otro proceso posterior que requiera cifras de pago de fin de año en un formato estructurado.

Esa brecha se cubre, cada mayo, con la introducción manual de los profesionales de nóminas. A 6 a 8 segundos por campo, la introducción en sí es lo bastante rápida como para que nadie la cuestione. Con tasas de error del 1% al 4%, los errores son lo bastante poco frecuentes como para que cada uno parezca un fallo aislado en lugar de un coste sistémico. La notificación — correcciones, enmiendas, P60 duplicados, certificados reemitidos — se absorbe en el «negocio como siempre». El coste acumulado, en 30 millones de P60 y miles de departamentos de nóminas, nunca se ha medido — porque medirlo exigiría admitir que la brecha existe.

El primer paso no es comprar software. Es contar las horas, contar los errores y poner un número al problema de mayo. Un administrador de nóminas. Tres días de introducción de datos fragmentada. Cinco correos de corrección de empleados con cifras erróneas. Dos P60 duplicados reemitidos. Una consulta a HMRC que lleva una tarde resolver. Súmelo una vez. Luego decide si el coste de la brecha es menor que el coste de cerrarla.