Más de 100 P60 del Reino Unido antes del 31 de mayo
Una hoja de cálculo de auditoría, sin entrada manual
Según la Regulación 67 del Reglamento del Impuesto sobre la Renta (Pago a medida que se gana) de 2003 (SI 2003/2682), todo empleador del Reino Unido debe proporcionar un P60 a cada empleado en nómina a partir del 5 de abril — y la fecha límite del 31 de mayo está establecida por ley, no en el software de nóminas. El P60 en sí no es el cuello de botella. Sage 50cloud, BrightPay, QuickBooks Online, Moorepay e IRIS generan certificados conformes en segundos. El cuello de botella es lo que sucede después: alguien tiene que consolidar más de 100 de esos PDF — más copias en papel escaneadas de empleados que perdieron las suyas, más capturas de pantalla del portal de HMRC — en una sola hoja de cálculo que se concilie con las Full Payment Submissions del año antes de fin de mes. A dos minutos por certificado para el flujo de trabajo manual — abrir PDF, localizar las casillas 1 a 6, transcribir a una fila de la hoja de cálculo — una empresa de 150 empleados dedica cinco horas de la ventana de nóminas de mayo a puro copiar y pegar. Y eso suponiendo que nadie haya cambiado de software de nóminas a mitad de año, que ningún empleado se haya ido en marzo y que ningún P60 escaneado haya llegado impreso a 150 DPI.
Conclusiones clave
- Según la ley del Reino Unido, todo empleador debe emitir un P60 a cada empleado antes del 31 de mayo — y para una empresa de 150 empleados que utiliza varios proveedores de nóminas, "solo abra los PDF y cópielos en Excel" significa cinco horas de pura transcripción en el mes más ocupado del calendario de nóminas.
- El verdadero cuello de botella a escala de 100 documentos no es la velocidad de procesamiento de archivos — es el diseño de columnas: un conjunto de columnas de identidad (NI Number + referencia PAYE), un conjunto de columnas financieras (pago, impuestos, NIC) y un conjunto de columnas de verificación (tipo de código fiscal, verificación de categoría NI) que juntas hacen que cada fila sea auditable y que cada fusión de hoja de cálculo sea una simple adición.
- Defina ese esquema de columnas una vez, aplique los mismos nombres a cada lote independientemente del proveedor de nóminas o del año fiscal, y fusionar 100 filas de Sage con 50 de BrightPay se convierte en una operación apilable verticalmente — sin reasignación de columnas, sin plantillas por proveedor, sin conjeturas sobre qué fila pertenece a qué empleador.
Por qué 100+ P60s es un problema fundamentalmente distinto a uno solo
Procesar un único P60 es un problema resuelto: extraer sus campos a Excel requiere atención, no herramientas. Usted abre el PDF, localiza las casillas reglamentarias, escribe siete u ocho números en una fila y continúa. En el momento en que introduce volumen —100 empleados, tres proveedores de nóminas, un puñado de exempleados de empresas adquiridas con certificados en papel—, el problema deja de ser la velocidad y pasa a ser la estructura.
Para el caso de un solo certificado, una ejecución de P60 a Excel puntual es suficiente; los problemas que se indican a continuación solo aparecen cuando la carpeta es lo bastante grande como para que nadie pueda revisar las filas visualmente.
Aparecen tres problemas estructurales a escala de 100+ que no existen a escala de un solo documento. Ninguno se resuelve procesando los archivos más rápido.
1. Divergencia de diseño entre proveedores
Un P60 de Sage 50cloud presenta los datos del empleado alineados a la izquierda, con la referencia PAYE en negrita debajo del nombre del empleador. Un P60 de BrightPay separa la sección de certificados reglamentarios con un recuadro con borde. Un P60 de QuickBooks Online imprime el NI number encima del bloque de dirección del empleado, en lugar de junto al nombre. Para un administrador de nóminas que transcribe manualmente, cada diseño requiere un nuevo escaneo visual: localizar dónde está cada casilla en la representación de ese proveedor concreto antes de escribir nada. En 100 P60s repartidos entre tres proveedores, solo ese coste de reescaneo visual —unos 10 segundos por documento para reorientarse— consume 15 minutos de tiempo muerto antes de una sola pulsación de tecla de transcripción.
2. Procedencia de filas a escala de auditoría
Cuando usted extrae 100 P60s en 100 filas de hoja de cálculo, cada fila debe poder rastrearse hasta exactamente un documento de origen y exactamente un año fiscal. Si la hoja de cálculo de salida tiene una columna para "Total Pay" con £38.450, pero ninguna columna que identifique el P60 de qué empleado produjo esa cifra, la hoja de cálculo es un pasivo de auditoría, no un activo. En las comprobaciones de cumplimiento de HMRC, un inspector puede solicitar el P60 subyacente a cualquier cifra de su conciliación. Sin trazabilidad de origen por fila integrada en la propia extracción, usted está cotejando celdas de hoja de cálculo contra PDFs manualmente, lo que tarda más que la extracción original.
3. Gestión de excepciones a gran volumen
En un lote de 100 P60s, de tres a cinco serán casos especiales. Un empleado con un código fiscal Week 1 / Month 1 porque empezó a mitad de año sin un P45. Un exempleado que trabajó de enero a marzo —empleado el 5 de abril y, por tanto, con derecho a un P60— pero cuyo certificado fue generado por un proveedor de nóminas que la empresa ya no utiliza. Un P60 en papel escaneado de una adquisición de 2023 en el que la referencia PAYE pertenece a la entidad adquirida, no a la empresa actual. En un flujo de trabajo manual, usted detecta estos casos uno a uno. En un flujo por lotes, cada excepción no detectada se convierte en una cifra incorrecta en una hoja de conciliación que HMRC puede auditar.
Cada uno de estos problemas tiene una solución que no implica contratar más personal de captura de datos para mayo. Implican diseñar el flujo de trabajo por lotes — desde la preparación de archivos hasta el esquema de columnas — como si la salida no fuera una hoja de cálculo sino un registro de auditoría que alguien leerá dentro de seis meses y que no produjo los datos originales.
La realidad de múltiples formatos: Sage no es BrightPay no es un escaneo de 150 DPI
HMRC no exige un único diseño de P60. Exige el contenido: según la especificación RD1, un P60 sustituto debe mostrar ciertos recuadros — nombre del empleado, NI number, referencia PAYE, pago total del año, impuesto total deducido, deducciones por préstamo estudiantil, código fiscal final y datos del empleador — pero la disposición visual queda a criterio de cada proveedor de software de nóminas. El resultado es que un P60 de Sage 50cloud se ve estructuralmente diferente de uno de BrightPay, que se ve diferente de un P60 de QuickBooks Online Payroll, que se ve diferente de un P60 de Moorepay, que se ve diferente de un P60 de IRIS. Y eso es antes de que introduzca copias en papel escaneadas de empleados que extraviaron sus originales.
La extracción tradicional basada en plantillas — donde dibuja rectángulos alrededor de los campos en un P60 de muestra — maneja esto requiriendo una plantilla separada para cada proveedor de nóminas. Mantenga cinco proveedores, mantenga cinco plantillas. Un proveedor actualiza el diseño de su P60 para el nuevo año fiscal — nuevas directrices de HMRC, un cambio de marca, un cambio de formato — y la plantilla produce silenciosamente una salida desalineada. El administrador de nóminas solo lo descubre cuando la conciliación no cuadra con los totales de FPS.
La extracción semántica elimina el problema de una plantilla por proveedor al leer el documento por significado en lugar de por posición. Usted define las columnas que desea una vez — "NI Number", "Total Pay for Year (£)", "Tax Deducted (£)", "PAYE Reference", "Final Tax Code" — y la IA localiza cada valor en cada P60 al comprender qué representan los datos, no dónde se ubica en la página. Un P60 de Sage 50cloud, un P60 de BrightPay, un P60 de QuickBooks y un P60 en papel escaneado de 2023 alimentan las mismas definiciones de columna. Para un recorrido más detallado de los campos individuales de un P60 del Reino Unido y cómo se comporta cada uno durante la extracción, comience con la guía de extracción de un solo P60. Este artículo continúa donde termina ese: qué sucede cuando deja de pensar en los P60 de uno en uno.
Lo que hace que esto sea particularmente valioso en un contexto de nóminas del Reino Unido es que la referencia PAYE — en el formato 123/AB456 — se mantiene consistente en todos los P60 del mismo empleador, independientemente del software de nóminas que los haya producido. Una empresa que usa Sage para personal permanente y BrightPay para contratistas emitirá P60 con la misma referencia PAYE pero en dos formatos visualmente diferentes. La extracción semántica lee el valor, no el diseño. La columna "PAYE Reference" en su hoja de cálculo de salida se completa de manera idéntica en ambos proveedores, lo que le da una clave de agrupación natural para lotes de múltiples proveedores.
Nomenclatura de archivos a escala: haciendo que cada fila sea trazable hasta su origen
La decisión de mayor impacto en un flujo de trabajo de P60 por lotes se toma antes de subir un solo archivo: cómo nombra los documentos de origen. Cuando su hoja de cálculo de salida tiene 100 filas y tres meses después un oficial de cumplimiento de HMRC pide ver "el P60 subyacente a la fila 47", la respuesta no puede ser "necesito cruzar la hoja de cálculo con mi carpeta de Descargas". Debe ser un nombre de archivo que pueda localizar al instante.
Una convención de nomenclatura que sirva a la trazabilidad de auditoría incluye tres componentes:
Identificador del empleado
El NI number es la clave primaria natural para los registros de nóminas del Reino Unido: es único, permanente y aparece en cada P60. Usarlo como prefijo del nombre de archivo le proporciona una clave de búsqueda instantánea: AB123456C se asigna directamente a los registros de HMRC. Cuando no se puedan usar NI numbers (política de protección de datos), use el ID de nómina del empleado, pero añada una tabla de asignación.
Año fiscal
Un P60 cubre el año fiscal del 6 de abril al 5 de abril. El nombre de archivo debe codificar qué año: 2025-26 o FY2526. Esto evita el desastre de reorganización por lotes más común: mezclar P60 de 2024-25 y 2025-26 en la misma carpeta porque alguien los guardó en el mismo directorio con seis meses de diferencia. Cuando procesa por lotes archivos de varios años fiscales en hojas de cálculo separadas, el año en el nombre de archivo es lo único que evita la contaminación cruzada.
Etiqueta de proveedor u origen
No es esencial para la hoja de cálculo en sí, pero es invaluable durante la conciliación. Un sufijo en el nombre de archivo como _sage o _bp le indica, tres semanas después de mayo, cuando alguien pregunta por qué la cifra de la casilla 5 de la fila 23 contradice los datos del FPS, que la fila 23 proviene de BrightPay, que puede tener una diferencia de redondeo de exportación conocida. Una etiqueta de proveedor convierte una anomalía inexplicable en un patrón de comportamiento conocido.
El patrón de nombre de archivo resultante — AB123456C_2025-26_sage.pdf — incorpora la pista de auditoría al propio nombre de archivo. Cuando su herramienta de extracción conserva los nombres de archivo en la salida (ImageToTable.ai incluye una columna "File Name" de forma predeterminada en las exportaciones por lotes), cada fila de su hoja de cálculo lleva su propia procedencia. Sin necesidad de referencias cruzadas externas.
Para equipos de nóminas que gestionan empleados en múltiples esquemas de PAYE — una empresa de gestión que gestiona nóminas para 20 entidades cliente, o una estructura de grupo donde cada subsidiaria tiene su propia referencia de PAYE — el formato de referencia de PAYE 123/AB456 se convierte en la clave natural de agrupación por lotes. Procese todos los P60 que lleven 123/AB456 en un lote, y todos los P60 que lleven 456/CD789 en otro. La columna de referencia de PAYE en la salida de cada lote sirve como punto de pivote cuando combine las dos hojas de cálculo más adelante. Nunca tendrá que adivinar a qué empleador pertenece una fila.
Salidas, exempleados y quién necesita legalmente un P60
La norma de HMRC es clara: todo empleado en nómina al 5 de abril del año fiscal debe recibir un P60 antes del 31 de mayo. Esto incluye a quienes se fueron durante el año fiscal, siempre que siguieran empleados el 5 de abril. Un empleado que renunció el 30 de marzo y trabajó su preaviso hasta el 4 de abril recibe un P60. Un empleado que se fue el 31 de marzo no. La diferencia importa porque equivocarse en cualquier dirección genera exposición a una auditoría.
En un lote de 100 P60, los casos límite de salidas se dividen en cuatro categorías, y cada una cambia lo que incluyes en el lote y lo que verificas después:
Empleado el 5 de abril — salida posterior
Recibe un P60. Su certificado cubre todo el año fiscal y debe incluirse en el lote. El campo "Código Fiscal Final" mostrará el código vigente al cierre del año, incluso si el empleado se fue en junio.
Salida antes del 5 de abril — sin P60
Recibe un P45, no un P60. Si su registro de nómina aún aparece en el lote por una exportación desactualizada del sistema de RR. HH., debe excluirse antes de la conciliación; sus datos pertenecen a otra obligación de reporte.
Exempleado que solicita un duplicado
HMRC exige que los empleadores proporcionen P60 duplicados si se solicitan. Un exempleado que necesite su P60 de 2023-24 para una hipoteca se pondrá en contacto con usted, y su certificado se emitió hace dos años, quizás desde un proveedor de nóminas que ya no usa. El P60 sigue teniendo la misma información legal, pero puede existir solo como PDF escaneado o copia de seguridad de Sage archivada.
Empleados de empresa adquirida
Cuando la Empresa A adquiere la Empresa B en octubre, los empleados de B que estaban en nómina al 5 de abril anterior aún necesitan un P60, emitido por A como empleador sucesor, pero posiblemente referenciando el esquema PAYE de B para los meses previos a la adquisición. El P60 emitido puede llevar la referencia PAYE antigua, la nueva o ambas, según cómo se estructuró la transferencia TUPE. Incluir estos P60 en su lote con una columna dedicada "Ref. PAYE Anterior" captura la complejidad en una sola fila.
La trampa de auditoría no es omitir un P60. Es incluir un P60 para alguien que no debería tenerlo, o excluir uno para quien sí debería. Cualquier error se propaga a su conciliación FPS, y una verificación de cumplimiento de HMRC según el Manual de Cumplimiento CH40000 detectará la discrepancia más rápido que su software de nóminas.
La salvaguarda práctica es añadir una columna inferida — "Estado P60" — donde la IA clasifique cada documento según su contenido. Valores como "Activo 5 Abril", "Salida Posterior al 5 Abril", "Duplicado Año Anterior" y "No es un P60" le permiten ordenar el resultado antes de la conciliación, marcando filas que requieren revisión o exclusión. Una columna en la extracción ahorra la hora de verificación manual que de otro modo seguiría.
Diseño de columnas preparadas para auditoría en una hoja de cálculo de 100 filas
Los nombres de columna que defines antes de cargar un lote son la decisión más importante de todo el flujo de trabajo. Un esquema de columnas diseñado para un lote de prueba de cinco empleados suele fallar con 100 filas porque no contempla los casos extremos que surgen con el volumen: números de NI duplicados entre esquemas PAYE, códigos fiscales que cambiaron a mitad de año, deducciones de préstamos estudiantiles divididas entre planes.
Un esquema de columnas que sobrevive a una auditoría de 100 filas se construye en torno a tres tipos de columna, cada uno con una función distinta en el resultado:
1. Columnas de identidad: la clave compuesta que hace única cada fila
Número de NI, Nombre del empleado, Referencia PAYE y Año fiscal. Juntos, estos cuatro campos forman una clave compuesta: no debe haber dos filas en tu hoja de cálculo que compartan la misma combinación. El número de NI por sí solo no es suficiente: un empleado que trabajó para dos esquemas PAYE en el mismo año fiscal (algo común en estructuras de grupo) tendrá dos P60 con el mismo número de NI pero diferentes referencias PAYE. Incluir la referencia PAYE en el bloque de identidad evita que esas filas colisionen.
2. Columnas financieras: las cifras que concilian con el FPS
Pago total del año (£), Impuesto total deducido (£), NIC del empleado (£), NIC del empleador (£), Deducciones de préstamos estudiantiles (£), Pagos estatutarios (£). Cada una debe coincidir con la línea equivalente en tu Full Payment Submission del año fiscal. El fallo de conciliación más común en la extracción de P60 por lotes es un desajuste entre la Casilla 2 (Impuesto total deducido) de un P60 y la cifra de impuesto YTD del FPS final, generalmente porque el P60 incluye un ajuste manual del código fiscal aplicado después de presentar el FPS final.
3. Columnas de verificación: comprobaciones calculadas que señalan anomalías antes de la conciliación
Son columnas que no aparecen en el P60 pero se calculan durante la extracción para detectar discrepancias. Una columna "Verificación de código fiscal" que señale códigos no estándar (cualquier cosa que no sean códigos acumulativos como 1257L, BR, D0, D1) te indica al instante qué filas necesitan revisión manual. Una columna "Verificación de categoría NI" que señale cualquier cosa que no sea Categoría A (la categoría estándar para empleados no acogidos a esquemas externalizados) muestra empleados en Categoría B, C, J o Z, cada una con diferentes tipos de cotización que pueden indicar un régimen salarial especial. Estas columnas de verificación no añaden trabajo de transcripción porque la IA las completa durante la misma pasada de extracción que lee las cifras financieras.
Para los equipos de nóminas que gestionan P60 de múltiples empleadores, una columna "Referencia PAYE" funciona como clave de agrupación de lotes y pivote de conciliación. Filtra el resultado por referencia PAYE, suma las columnas de Pago total e Impuesto total deducido, y compara con los totales del P35 (Declaración anual del empleador) de cada empleador. La IA no necesita entender el formato de una referencia PAYE: lee la cadena tal como aparece y, como las referencias PAYE del Reino Unido usan un patrón NNN/XXNNNNN consistente (PAYE20005), el resultado se puede ordenar y filtrar de forma natural.
El manejo de los códigos de impuesto merece una atención particular a escala de lote. El código de impuesto acumulativo estándar para 2025-26 es 1257L — que refleja la desgravación personal de £12,570 — pero el procesamiento por lotes revela cuántas desviaciones del estándar existen entre 100 empleados. Un empleado con un código K (las deducciones totales superan las desgravaciones) tiene un tratamiento fiscal fundamentalmente diferente al de uno con 1257L. Un empleado cuyo P60 muestra un código BR (tasa básica) probablemente fue gravado por una segunda fuente de ingresos. Un empleado con NT (sin impuesto) puede haber presentado un P85 ante HMRC confirmando su no residencia. Cinco empleados con 1257L y un sufijo "X" fueron colocados en una base no acumulativa (Mes 1), lo que significa que sus cifras acumuladas del año pueden no representar un cálculo de año completo. Una columna llamada "Final Tax Code" saca a la superficie todo esto. Una segunda columna calculada llamada "Tax Code Type" — donde la IA clasifica cada código como "Cumulative," "Non-Cumulative," "BR/D0/D1," o "K Code" — convierte una hoja de cálculo de códigos en una hoja de cálculo de situaciones fiscales, filtrable con un clic.
Fusión de datos P60 de varios empleadores y años fiscales
La extracción por lotes produce una hoja de cálculo por lote. Un equipo de nóminas que gestiona P60 de tres esquemas PAYE — cada uno con su propia referencia de estilo 123/AB456 — termina con tres hojas de cálculo. El paso de fusión es donde el diseño estructural de sus columnas de extracción da sus frutos o se derrumba.
Si cada lote usara los mismos nombres de columna — "NI Number," "Employee Name," "PAYE Reference," "Tax Year," "Total Pay for Year (£)," "Total Tax Deducted (£)" — las tres hojas de cálculo se apilan verticalmente sin necesidad de reasignar columnas. La columna "PAYE Reference" en cada hoja identifica a qué empleador pertenece cada fila, por lo que la hoja fusionada puede pivotarse por referencia PAYE para producir totales por empleador. Este es el propósito completo de estandarizar los nombres de columna entre lotes: la fusión se convierte en una operación de anexado, no en un ejercicio de mapeo de columnas.
Para la pregunta más amplia del flujo de trabajo — organizar archivos, elegir un enfoque de lote y estructurar la salida para uso posterior — la guía completa del flujo de trabajo de OCR por lotes cubre la preparación de archivos, la selección de herramientas y la estructuración de la salida en múltiples tipos de documento. El esquema de columnas específico para P60 descrito aquí se integra en ese marco general.
Un caso límite específico de fusión: un empleado que aparece en dos lotes con el mismo NI number pero diferentes referencias PAYE. Esto no es un error — es un empleado que tuvo dos trabajos en el mismo año fiscal. El P60 del empleador A muestra ingresos e impuestos de un empleo; el P60 del empleador B muestra ingresos e impuestos del otro. Al fusionarse en una sola hoja de cálculo, estas dos filas no deben agregarse. La columna "PAYE Reference" es lo que evita que sume dos P60 que representan empleos separados. Sin ella, una SUMA ingenua de "Total Tax Deducted (£)" produce una cifra que no coincide con el P35 de ninguno de los dos empleadores — y una conciliación con HMRC que no cuadrará.
Preguntas frecuentes: Procesamiento por lotes de P60 del Reino Unido
¿La extracción por lotes funciona con P60 escaneados en papel?
Sí: la extracción semántica lee el contenido textual del documento, no sus metadatos digitales. Un escaneo a 150 DPI de un P60 en papel de 2022 produce la misma salida estructurada que un PDF generado digitalmente por Sage de 2026, siempre que el texto sea legible. La calidad de la extracción depende de la nitidez del escaneo, no de que el documento sea nativo digital. Los escaneos muy torcidos, las fotocopias de baja resolución y los P60 con anotaciones manuscritas pueden dar menor precisión; en esos casos, las columnas de verificación (Comprobación de código fiscal, Comprobación de categoría NI) marcarán las filas que necesiten revisión manual.
¿Qué ocurre con los P60 que incluyen deducciones de préstamos estudiantiles?
Los P60 del Reino Unido incluyen una sección específica para deducciones de préstamos estudiantiles y de posgrado (Plan 1, Plan 2, Plan 4 y Préstamo de Posgrado). El formato estándar de P60 de HMRC separa estas por tipo de plan. Defina una columna por plan — "Préstamo Estudiantil Plan 1 (£)", "Préstamo Estudiantil Plan 2 (£)", "Préstamo de Posgrado (£)" — en lugar de una sola columna "Préstamo Estudiantil (£)". Un empleado que reembolsa préstamos del Plan 1 y Plan 2 tendrá dos campos distintos de cero, y una columna combinada única imposibilita distinguir a qué plan corresponde cada deducción durante la conciliación con los avisos de inicio y fin SL1/SL2 que emite HMRC.
¿Puedo procesar P60 de varios años fiscales en un solo lote?
Técnicamente sí: la IA extraerá datos de cualquier P60 independientemente del año fiscal, pero es mejor práctica agrupar por año fiscal. Una hoja de cálculo combinada que contenga P60 de 2024-25 y 2025-26 requiere que la columna "Año Fiscal" sea 100 % precisa antes de comenzar cualquier conciliación por año. Procesar cada año fiscal como un lote separado —con el año fiscal codificado en una columna a nivel de lote en lugar de depender de la detección por documento— reduce el riesgo de contaminación entre años. Si debe procesar años mixtos, incluya una columna de verificación calculada que marque cualquier fila donde la fecha de fin de año no coincida con el 5 de abril esperado del año fiscal.
¿Cómo maneja la extracción por lotes a empleados con el mismo nombre?
El nombre del empleado no se usa como identificador único; el número de la Seguridad Social (NI) sí. Dos empleados llamados "Juan Pérez" que comparten el mismo empleador pero tienen diferentes números NI generarán dos filas distintas con el mismo nombre pero diferentes números NI y diferentes cifras financieras. El procesador por lotes trata cada documento de forma independiente. El riesgo está en el paso de combinación: si combina dos lotes y ordena por nombre, las dos filas de Juan Pérez aparecerán adyacentes, y la persona que revise la hoja de cálculo podría pasar por alto que tienen diferentes números NI. Incluir el número NI como primera columna en su salida —antes del nombre del empleado— lo convierte en la clave visual de ordenación y evita confusiones basadas en el nombre.
¿Qué pasa si un P60 no muestra claramente la referencia PAYE?
HMRC exige que todo P60 muestre la referencia PAYE del empleador; es un campo obligatorio según RD1. Sin embargo, algunos programas de nómina imprimen la referencia en tamaño pequeño, oculta en la sección de datos del empleador o junto al logotipo de HMRC en lugar del cuerpo principal del certificado. Si el diseño de un proveedor específico oculta sistemáticamente la referencia PAYE, puede agregar una columna de valor fijo y establecer la referencia PAYE manualmente para ese lote en lugar de depender de la extracción por IA. Como la referencia PAYE es la misma para todos los P60 de un lote de un solo empleador, una columna configurada manualmente cubre todo el lote. La columna "Nombre de archivo" en el resultado sigue proporcionando la procedencia de cada fila, incluso cuando una columna se establece por lote en lugar de extraerse individualmente.
La fecha límite del 31 de mayo para los P60 no va a desaparecer — y tampoco la brecha entre lo que genera el software de nóminas y lo que exige la conciliación de nóminas. Las cinco horas entre "los P60 están emitidos" y "la hoja de cálculo concilia con el FPS" es un problema estructural que la velocidad del teclado no resuelve. Es un problema de diseño de columnas. Defina sus columnas una vez. Suba el lote. Deje que la hoja de cálculo se complete sola.
Pruébelo con sus P60