Guía completa para la extracción de datos del P60
del Reino Unido para equipos de nóminas

Qué es realmente la extracción de datos del P60

La extracción de datos del P60 es el proceso de leer los campos obligatorios de un Certificado de Fin de Año — NINO del empleado, referencia PAYE del empleador, salario en este empleo, impuesto deducido, contribuciones al Seguro Nacional, código fiscal final — y convertirlos en columnas estructuradas en una hoja de cálculo, una fila por empleado por año fiscal. El certificado en sí está regulado por la especificación RD1 de HMRC, que prescribe todos los campos que debe contener un P60 sustituto, dejando el diseño visual a discreción del proveedor de software de nóminas.

Esta distinción — datos obligatorios, diseño libre — es la razón por la que la extracción existe como categoría. Si todos los P60 fueran idénticos, cualquier herramienta OCR basada en plantillas podría leer las Casillas 1 a 6 desde coordenadas fijas. Pero Sage 50cloud puede imprimir el NINO arriba a la derecha y la referencia PAYE abajo a la izquierda en negrita debajo del nombre del empleador. BrightPay puede colocarlos uno al lado del otro en una sección con bordes. IRIS Staffology puede apilar todo verticalmente. Los tres certificados cumplen igualmente con HMRC. Los tres contienen los mismos campos obligatorios. Y los tres derrotan a una plantilla diseñada para cualquiera de ellos.

Extracción de Columnas Personalizadas — donde defines las columnas de salida que necesita tu hoja de cálculo («NINO», «Salario en este Empleo», «Impuesto Deducido», «Letra de Categoría NI») y la IA localiza cada valor en cada P60 entendiendo qué significa la etiqueta del campo en lugar de dónde está — es lo que hace que la extracción funcione en todos los proveedores de nóminas sin configuración por proveedor. La misma definición de columna lee un P60 de Sage, un P60 de Xero, un P60 de BrightPay y un P60 en papel escaneado de un empleador que entró en concurso de acreedores en 2023. La IA lee por significado, no por plantilla.

Por qué es importante extraer los datos del P60

Según la Regulación 67 del Reglamento del Impuesto sobre la Renta (PAYE) de 2003, todo empleador del Reino Unido debe entregar un P60 a cada empleado en nómina al 5 de abril. El plazo legal es el 31 de mayo. Para el software de nóminas que generó el certificado, ahí termina el flujo de trabajo. Para el equipo de nóminas, ahí comienzan tres flujos de trabajo posteriores, y ninguno de ellos es cubierto por la función de generación de P60 del software de nóminas.

Conciliación de nóminas de fin de año frente al FPS

Una gestoría de nóminas que cierra el año para múltiples clientes empleadores debe confirmar que las cifras del P60 de cada empleado coinciden con los totales del Full Payment Submission (FPS) de fin de año enviados a HMRC a través del sistema Real Time Information (RTI). La conciliación se realiza empleador por empleador: extraer todos los P60 del Empleador A a una hoja de cálculo, comparar los totales de salario e impuestos con el extracto FPS propio de la gestoría, e investigar cualquier fila donde ambas cifras no coincidan al céntimo. Con 150 empleados en cinco clientes empleadores, esto son 750 comparaciones P60 vs. FPS, y un solo error de transcripción en cualquier fila genera una discrepancia que una revisión de cumplimiento de HMRC puede detectar meses después. Para un recorrido detallado de este flujo de trabajo, consulte cómo extraer datos del P60 del Reino Unido a Excel para conciliación de nóminas.

Preparación de la Autoliquidación (plazo de enero, ventana de recogida en mayo)

Un despacho contable que atiende a clientes particulares recibe P60 junto con extractos bancarios, cupones de dividendos y formularios P11D antes del plazo de presentación de la Autoliquidación del 31 de enero. Un cliente con dos empleos simultáneos en el mismo año fiscal genera dos filas de P60, cada una con su propia referencia PAYE del empleador y la cifra de "Salario en este Empleo". Estos datos se asignan directamente a las páginas de Empleo de la declaración SA100, y un error de transcripción donde la cifra de salario del Empleador A termina en la línea del Empleador B es uno de los desencadenantes más comunes de una investigación SA302. El problema de mayo de las nóminas del Reino Unido es que este trabajo de transcripción alcanza su punto máximo en una ventana donde los contables ya están al límite con la documentación de cierre de año de cada cliente.

Verificación de ingresos a gran escala

Entidades hipotecarias, agencias de alquiler, empresas de verificación laboral y asesores de inmigración solicitan habitualmente los P60 como comprobante de ingresos del año anterior. El flujo de verificación es de alto volumen y campos reducidos: Nombre, NINO, Referencia PAYE del empleador, Remuneración total anual. Dado que los P60 provienen del proveedor de nóminas que use el empleador del solicitante — algo que el verificador no controla — la capacidad de la herramienta de extracción para procesar cualquier diseño sin configuración previa determina si el proceso de verificación puede automatizarse o si alguien debe abrir cada PDF y teclear los datos manualmente.

Los desafíos únicos de la extracción de P60

Los P60 comparten algunos retos de extracción con nóminas y formularios fiscales — diversidad de formatos, etiquetado inconsistente, calidad escaneada versus digital — pero también presentan tres problemas estructurales que casi ningún otro tipo de documento genera. Comprenderlos antes de configurar un flujo de extracción es lo que evita que la hoja de cálculo necesite una segunda ronda de correcciones manuales en junio.

Múltiples formatos de proveedores de nóminas, una misma especificación legal

La especificación RD1 de HMRC permite explícitamente “variaciones en formato y diseño” para los P60 sustitutivos. Sage imprime la sección de certificados legales como bloques alineados a la izquierda con la referencia PAYE en negrita debajo del nombre del empleador. BrightPay separa los detalles del NI con una tabla con bordes. Xero coloca el NINO sobre el bloque de dirección del empleado. QuickBooks Online imprime el código fiscal y la letra de categoría del NI en una franja horizontal en el cuarto superior. Moorepay usa una cuadrícula de tres columnas. Los seis diseños cumplen la normativa. Ninguno comparte plantilla.

Esto no es un defecto de la especificación — existe porque los empleadores del Reino Unido han usado diferentes programas de nóminas durante décadas, cada uno con su propio motor de impresión, y la postura regulatoria de HMRC es exigir el contenido de los datos, no el diseño visual. La consecuencia práctica para la extracción es que un enfoque basado en plantillas que funciona con P60 generados por Sage produce basura con P60 de BrightPay. Un enfoque de extracción semántica — que lee por el significado del campo en lugar de por coordenadas de píxel — maneja todos los proveedores con una sola definición de columna porque entiende que “Remuneración en este empleo” significa lo mismo independientemente de dónde aparezca en la página.

P60 de salida: el caso límite oculto en cada cierre de ejercicio fiscal

Un empleado que renunció en febrero de 2026 seguía en nómina al 5 de abril de ese año; por tanto, su antiguo empleador debe emitir un P60 por el periodo trabajado en ese ejercicio fiscal, aunque se haya ido antes del cierre. Si el empleador usa Sage pero la empresa a la que se unió usa Xero, el nuevo departamento de nóminas recibe un P60 con un formato que su equipo rara vez ve. Peor aún, si el empleador anterior sigue emitiendo certificados en papel —permitido por las normas de HMRC para empleadores de cuidados y ciertas entidades exentas— el P60 llega en físico. Alguien lo fotografía con su móvil y lo envía por correo a nóminas. Esa foto se convierte en un insumo de extracción junto con los P60 digitales limpios de su propio sistema de nóminas.

Los P60 de salida también implican consecuencias entre ejercicios. Un empleado que trabajó para el Empleador A de abril de 2025 a febrero de 2026, y luego para el Empleador B de febrero a abril de 2026, tiene dos P60 que cubren el mismo ejercicio fiscal. Sus ingresos imponibles totales del año son la suma de ambas cifras de “Remuneración en este empleo” — pero ningún P60 muestra esa suma. El cálculo se hace en la hoja de cálculo, tras la extracción, y depende de que ambos P60 se extraigan con precisión en el mismo libro. Un solo dígito mal tecleado en cualquiera de las filas genera un total erróneo que la declaración de autoliquidación acabará sacando a la luz.

Datos entre ejercicios: el problema de la letra de categoría NI

Cuando la letra de categoría del Seguro Nacional de un empleado cambia a mitad de año —lo más común de A a C al alcanzar la edad de pensión estatal— el P60 muestra dos filas separadas de NI bajo dos letras de categoría distintas. Cada fila tiene sus propios tramos de ingresos (en el LEL, entre LEL y PT, entre PT y UEL, por encima de UEL) y sus propias cotizaciones del empleado. Sage las imprime como dos filas adyacentes con las letras a la izquierda. Xero las imprime como secciones de tabla separadas con la letra como encabezado de sección. Un sistema de extracción que colapsa ambas filas en una sola cifra de “NI total” —común en herramientas diseñadas para nóminas y adaptadas para P60— pierde el desglose por letra de categoría del que depende la conciliación del empleador con las declaraciones RTI.

El conjunto de letras de categoría NI es limitado: A, B, C, F, H, I, J, L, M, S, V, X, Z. Cualquier valor fuera de este conjunto en una hoja de cálculo extraída es un error de transcripción o un fallo de extracción; y como la mayoría de los P60 usan la letra A (tarifa estándar), una “D” o “K” extraviada en la columna de categoría NI se detecta con una simple regla de validación en Excel. Pero la detección solo funciona si la extracción conservó la letra en una columna dedicada —no si fusionó ambas filas de NI en una sola fila con las cotizaciones sumadas.

Métodos tradicionales vs. extracción de P60 con IA

Existen tres formas de llevar los datos del P60 a una hoja de cálculo, y la elección entre ellas define si la ventana de nómina de mayo es una maratón de escritura o una secuencia de subida y exportación de archivos.

El OCR basado en plantillas — el enfoque utilizado por las herramientas heredadas de procesamiento de documentos — funciona definiendo zonas rectangulares en la imagen de un documento y ejecutando OCR dentro de cada zona. Para un P60 de Sage donde el NINO del empleado está en las coordenadas (530, 280, 700, 300) en una página A4, la plantilla lee el texto que aparezca en ese rectángulo. Un P60 de BrightPay donde el NINO está en las coordenadas (400, 190, 600, 210) produce una celda vacía o el valor del campo incorrecto. Debido a que los proveedores de nómina del Reino Unido utilizan diseños de P60 fundamentalmente diferentes, un sistema de plantillas necesita una plantilla por proveedor, más una alternativa para los P60 en papel escaneados que no coinciden con ningún diseño digital — y cada vez que el proveedor actualiza su formato de impresión, la plantilla se rompe silenciosamente.

La extracción semántica con IA invierte esta lógica. En lugar de definir dónde están los datos en la página, defines qué datos quieres — escribiendo los nombres de las columnas que necesita tu hoja de cálculo. La IA lee el documento completo, identifica cada campo por su función semántica dentro de la estructura de un certificado fiscal y rellena la columna correspondiente independientemente de la posición de los píxeles. Un P60 de Sage, un P60 de BrightPay y una foto de móvil de un P60 en papel de un empleado saliente de su anterior empresa producen filas rellenas en la misma hoja de cálculo porque la IA empareja por significado, no por coordenadas. Este es el cambio fundamental de la extracción basada en posición a la extracción basada en semántica.

La diferencia de eficiencia se multiplica con el volumen. A dos minutos por P60 para entrada manual, 150 empleados consumen cinco horas de trabajo de transcripción concentrado — en una ventana de mayo donde el equipo de nómina también está gestionando el EPS final, conciliando el P32 y preparando informes que el consejo espera para fin de mes. La extracción con IA procesa los mismos 150 P60 en aproximadamente 15 a 25 minutos de tiempo total de procesamiento. Para una comparación más detallada del enfoque manual, consulta el coste oculto de la introducción de datos del P60.

Campos clave del P60 a extraer

El P60 contiene más campos de los que la mayoría de los flujos de extracción necesitan. Qué campos extraer depende de lo que alimentará la hoja de cálculo, pero los campos en sí están definidos por la especificación RD1 de HMRC, y entender para qué sirve cada uno determina si tu salida resuelve la tarea posterior o crea un nuevo problema de conciliación.

La consecuencia en la hoja de cálculo es que una extracción completa de P60 para 150 empleados genera aproximadamente 150 filas y entre 20 y 25 columnas si se incluyen todos los desgloses de bandas NI. La definición de columnas es reutilizable entre años fiscales: el conjunto de campos estatutarios de HMRC solo cambia cuando cambia la legislación, y cuando esto ocurre (como con la adición del Pago Estatutario por Cuidado Neonatal en la especificación 2025-26), se añade la nueva columna sin necesidad de reconstruir el resto.

Procesamiento por lotes de P60 a escala

Procesar un solo P60 no es el problema. Extraer los campos de un P60 a Excel requiere atención, no automatización. El problema surge con el volumen: 100 empleados, tres proveedores de nómina, un puñado de P60 en papel escaneados de exempleados de empresas adquiridas. A esa escala, los desafíos estructurales pasan de «¿puedo leer este campo?» a «¿puede cada fila de esta hoja de cálculo rastrearse hasta un único documento fuente y un único año fiscal?».

El procesamiento por lotes reduce el flujo de trabajo de múltiples archivos a una sola secuencia de carga y exportación: coloque todos los PDF de P60 —impresos desde Sage, Xero, papel escaneado, fotos de móvil— en un lote, defina los nombres de las columnas una vez y reciba una hoja de cálculo unificada donde cada fila es un P60. Procesar por lotes más de 100 P60 antes del plazo del 31 de mayo es lo que convierte la extracción de una conveniencia por documento en un flujo de trabajo para el equipo de nóminas.

Tres aspectos específicos del procesamiento por lotes que conviene abordar antes de procesar 150 P60 de una vez:

Exportación y uso de los datos extraídos del P60

El resultado de la extracción debe llegar al lugar donde opera el flujo de trabajo posterior. Los datos del P60 tienen tres destinos principales, cada uno con requisitos de formato distintos:

• Excel (XLSX) — El formato predeterminado para la conciliación de nóminas. Los datos extraídos llegan con encabezados de columna adecuados, formatos de fecha estandarizados (el año fiscal expresado como “2025-26”) y campos numéricos formateados como números, lo que permite aplicar de inmediato las fórmulas de validación que se explican en la guía práctica de extracción de P60 sin tener que reformatear valores de moneda almacenados como texto o NINOs divididos en celdas combinadas.
• CSV — Para importación masiva en software de nóminas, sistemas contables o las herramientas de conciliación internas de la gestoría. La mayoría de las plataformas de nóminas aceptan importaciones CSV para datos de compensación, y un CSV limpio procedente de la extracción evita el paso intermedio de formatear manualmente una hoja de cálculo antes de la importación.
• JSON — Para integraciones personalizadas, procesos de verificación basados en API o cotejo automatizado con extractos de datos de envíos RTI.

Para los equipos que realizan su conciliación en Google Sheets, un complemento lateral de Google Sheets escribe los campos extraídos del P60 directamente en la hoja activa, sin necesidad de exportar y reimportar. Suba los PDF del P60 desde Sheets, defina los nombres de sus columnas y los datos se colocarán en la siguiente fila disponible.

Cómo elegir un enfoque de extracción de datos del P60

Las funciones que importan para la extracción del P60 no son las mismas que importan para la extracción de facturas o el escaneo de recibos. Una herramienta que procesa 10 000 facturas al mes puede ser completamente inadecuada para 150 P60, porque la estructura del P60 (campos obligatorios, desgloses de letras de categoría NI, casos excepcionales de bajas, datos entre ejercicios) genera exigencias para las que las herramientas de extracción genéricas no fueron diseñadas. Estas son las dimensiones a evaluar:

Estas dimensiones son específicas de la extracción de P60. Una herramienta excelente para procesar facturas puede fallar en la prueba de la letra de categoría NI. Una que maneje bien los recibos de nómina puede tener problemas con los casos atípicos de P60 de exempleados. Probar con tus documentos reales —incluidos los desordenados— antes de comprometerte con un flujo de producción es la única forma de confirmar que la herramienta maneja el flujo de P60 que tu equipo realmente recibe, no la versión ideal del mismo.

Preguntas Frecuentes