5 errores de entrada de datos en el P60 que ponen
en riesgo la conciliación de nóminas

El punto ciego de la transcripción en la introducción de datos del P60

La industria de nóminas ha dedicado años a debatir los errores del P60, pero casi siempre desde el lado del software. Código de impuesto incorrecto aplicado durante el año. Letra de categoría NI incorrecta en el sistema de nóminas. Envío RTI marcado por HMRC. Estos son errores de procesamiento: el software de nóminas generó un certificado incorrecto porque los datos introducidos eran erróneos o una opción de configuración estaba desactivada. La solución está en el sistema de nóminas.

Pero existe una segunda categoría de errores del P60 que los blogs de nóminas, las guías de despachos contables y las páginas de asesoramiento de HMRC apenas mencionan: los errores introducidos después de que el P60 se haya generado correctamente, durante el momento en que una persona lee el certificado y teclea sus datos en una hoja de cálculo de conciliación. Una agencia de nóminas que verifica los totales FPS de fin de año contra la salida del P60 no está arreglando software — está verificando que la salida del software coincide con los envíos a HMRC. El documento fuente es el P60. El destino de la transcripción es una hoja de cálculo. Cada campo transcrito es una oportunidad para un error que ningún rastro de auditoría del software de nóminas detectará, porque el sistema de nóminas nunca participó en la transcripción.

Estos errores son estructuralmente diferentes de los errores de procesamiento. Un error de procesamiento se detecta cuando el sistema de nóminas marca una regla de validación — un formato NI no válido, un código de impuesto que no coincide con los registros de HMRC. Un error de transcripción se detecta cuando alguien compara manualmente la celda de la hoja de cálculo contra el PDF del P60. Si nadie hace esa comparación, el error permanece en la hoja de cálculo, se incorpora al informe de conciliación y finalmente sale a la luz cuando un empleado nota que su código de impuesto es incorrecto — o un prestamista hipotecario rechaza una solicitud porque la cifra salarial del P60 no coincide con la verificación del empleador.

Los cinco errores siguientes son los que sobreviven a la validación de formato, superan los controles de fin de mes y salen a la luz meses después. No son problemas de "revise su trabajo con más cuidado" — son síntomas de un flujo de trabajo donde el propio paso de transcripción es la causa raíz.

Error #1: Transposición del N.º de la SS — El error que localiza al empleado equivocado

El formato del número de la Seguridad Social (National Insurance, NI) — dos letras de prefijo, seis dígitos, una letra de sufijo — parece que debería detectar automáticamente los errores de transposición. Cualquier software de nóminas, cualquier fórmula de validación en Excel, cualquier envío RTI rechazará una cadena que no coincida con el patrón. Pero esto es lo que realmente detecta la comprobación de formato: entradas de longitud incorrecta, caracteres donde deben ir dígitos, letras de prefijo no válidas (D, F, I, Q, U, V como primer carácter; D, F, I, O, Q, U, V como segundo).

Lo que no detecta es una transposición dentro del segmento de seis dígitos. QQ 12 34 56 C escrito como QQ 12 43 56 C supera todas las validaciones de formato existentes: nueve caracteres, dos letras de prefijo válidas, seis dígitos, una letra de sufijo válida. El software de nóminas lo acepta. El sistema RTI de HMRC lo acepta. Y dirige los datos fiscales y de la SS del empleado al registro incorrecto de HMRC — un registro que podría pertenecer a una persona completamente diferente, o a nadie hasta que el algoritmo de coincidencia de HMRC marque finalmente la discrepancia.

Una sola transposición en el segmento de seis dígitos crea un número de la SS válido que pertenece a otra persona — o crea una combinación que no corresponde a ningún número de la SS emitido pero que supera la validación de formato. En cualquier caso, el daño posterior no es un envío rechazado, sino un envío aceptado silenciosamente con una vinculación de identidad incorrecta. Los datos del P60 del empleado terminan en el registro de la Seguridad Social de otra persona. El cálculo del derecho a la pensión estatal de esa otra persona incorpora los ingresos de otra persona. La autocumplimentación de la declaración de la renta de esa otra persona muestra ingresos de un empleador para el que nunca trabajó.

La letra de sufijo es otra capa de complejidad oculta. Las cuatro letras válidas — A, B, C, D — corresponden al trimestre natural en el que se emitió originalmente el número de la SS. Los administradores de nóminas que trabajaban antes de RTI lo saben porque las tarjetas de la SS solían llegar trimestralmente, y el sufijo era el marcador del trimestre. Alguien que entró en la profesión en 2020 puede que nunca haya oído hablar del sistema de sufijos trimestrales. Así que cuando transcriben un P60 y ven QQ 12 34 56 C, no saben que C significa "emitido en el trimestre de octubre a diciembre" — y no lo marcarían si el sufijo fuera incorrecto porque la validación de formato solo comprueba que el sufijo sea A/B/C/D o espacio, no que coincida con el trimestre de emisión del número de la SS.

La firma de contabilidad que asumió un nuevo cliente y descubrió que el número de la SS había sido incorrecto "durante unos años" — documentado en AccountingWEB — no es un caso atípico. Es lo que ocurre cuando un error de transposición entra en el sistema y la validación de formato dice "parece correcto".

Error #2: Error al introducir el código tributario: el fallo que cuesta dinero real a los empleados

Un código tributario en un P60 no es solo una cadena como 1257L. Es el estado final del cálculo PAYE del empleado para el año fiscal, y contiene dos datos críticos: el número del código en sí, que determina la desgravación fiscal, y un indicador de base opcional — W1 o M1 — que indica a HMRC si el código se aplicó de forma acumulativa o de emergencia (no acumulativa).

El error de transcripción más común con los códigos tributarios no es escribir 1257L como 1258L. Es omitir el indicador de base cuando el P60 muestra 1257L W1. Si la columna de la hoja de cálculo solo captura el código y omite el sufijo W1/M1, el informe de conciliación pierde la información de que este empleado estaba en régimen de emergencia al cierre del año. El siguiente empleador que recibe estos datos — o el contador que prepara la declaración de autoliquidación a partir de ellos — ve un código acumulativo estándar y lo aplica como si no hubiera problema con W1/M1. El impuesto del empleado se calcula incorrectamente para el siguiente año fiscal, basándose en un código que nunca debió trasladarse.

El impacto real no es hipotético. El archivo de casos de corrección de P60 de Audit Consulting Group incluye a una empleada llamada Emma en Mánchester cuyo P60 mostraba el código tributario incorrecto; el resultado fue un pago en exceso de £890 que requirió un P60 corregido y un proceso de reembolso con HMRC para resolverse. Es decir, £890 del dinero de una empleada retenidas por HMRC durante meses, porque un código en un certificado estaba mal. Cuando el error es de transcripción y no del sistema de nómina — el sistema generó el código correcto, pero la persona que transcribió el P60 lo escribió mal en la hoja de cálculo — el camino hacia la solución es más largo. El empleador puede señalar el P60 correcto. La transcripción es el error, no el documento original. Pero el operador de nómina que lo transcribió mal hace seis meses puede no ser quien atienda la llamada de la empleada en septiembre.

El error al introducir el código tributario también se propaga en el proceso de autoliquidación. Si un despacho contable utiliza datos del P60 — transcritos de documentos de clientes — para completar las páginas de Empleo de la declaración SA100, un código incorrecto en la declaración genera una discrepancia con los datos RTI de HMRC. HMRC puede marcar la declaración para investigación, y la siguiente comunicación del contador con el cliente comienza explicando por qué un error tipográfico de mayo provocó una carta de HMRC en noviembre.

Error n.º 3: Pago total e impuesto deducido: un intercambio de columnas que lo rompe todo

Un P60 de un empleado que tuvo dos trabajos en el mismo año fiscal muestra dos conjuntos de cifras que se confunden fácilmente bajo presión de tiempo. "Pay in This Employment" es el pago bruto de este empleador específico. "Total Pay for Year" incluye el pago de empleos anteriores, trasladado desde el P45. "Tax Deducted" en este empleo es el impuesto PAYE que este empleador dedujo. "Total Tax for Year" agrega el impuesto de todos los empleos.

En un P60 impreso con Sage, estas cuatro cifras pueden aparecer en dos columnas adyacentes. En un P60 impreso con Xero, pueden aparecer en una pila vertical. En un P60 en papel traído por un empleado de un empleador anterior hace cinco años, pueden aparecer en un formato completamente diferente. Un operador de nóminas que transcribe 80 P60 en un día, alternando entre diferentes formatos cada pocos certificados, escribe "Pay in This Employment" en la columna "Tax Deducted" una vez. Una fila. Un intercambio. Y esa fila ahora muestra £31 200 de impuesto sobre £4 870 de pago — o lo contrario, £4 870 de impuesto sobre £31 200 de pago.

El primer número activa una verificación automatizada: la proporción entre impuesto y pago. Cualquiera que vea una fila de hoja de cálculo con £31 200 de impuesto sobre £4 870 de pago lo notará. Pero lo contrario — £4 870 de impuesto sobre £31 200 de pago — es una tasa efectiva plausible del 15,6 %. Pasa la verificación de proporcionalidad. Pasa la verificación de formato. Se incorpora al informe de conciliación como una fila válida, y la conciliación de totales contra los datos del FPS sale ligeramente desviada — lo bastante cerca como para atribuirlo a redondeo o a una pequeña diferencia de sincronización del RTI, pero no lo bastante como para activar una reauditoría completa de cada fila.

Este error específico tiene un paralelo documentado en el propio software de HMRC. En un año fiscal, el software Basic PAYE Tools (BPT) de HMRC generó PDF de P60 donde las bandas de ganancias NI estaban transpuestas: el PDF mostraba cifras incorrectas que no coincidían con la presentación del RTI. Los administradores de nóminas que lo comentaron en AccountingWEB describieron haber dedicado "tiempo no facturable" a diagnosticar un error que no era suyo. La respuesta de HMRC fue que el error aparecía solo en el PDF, no en los datos de la agencia de contribuciones — lo que significa que el PDF que el operador de nóminas lee y del que transcribe puede contener errores de formato que ni siquiera el proveedor del software ha detectado.

Cuando un error humano de transposición se combina con un formato de documento fuente que es en sí mismo ambiguo — dos columnas con valores numéricos similares, sin separador visual — el error se vuelve prácticamente indetectable hasta que alguien concilia la fila individual contra el PDF original del P60. A 80 filas por día, nadie concilia cada fila contra el PDF original.

Error #4: Fecha de cese discrepante — cuando el P45 y el P60 cuentan historias distintas

Este error no ocurre en un solo documento. Ocurre en el espacio entre dos documentos que hacen referencia al mismo empleado. Un empleado que dejó el Empleador A en marzo y comenzó en el Empleador B en abril aparece en dos conjuntos de datos del P60. El P60 del Empleador A muestra el salario hasta la fecha de cese de marzo. El P60 del Empleador B muestra el salario desde la fecha de inicio de abril. Ambos certificados son correctos individualmente. Pero la suma de ambos — al transcribirse en una fila de hoja de cálculo para el empleado — debe respetar una restricción que nadie verifica: la fecha de cese en el P45 debe ser anterior a la fecha de inicio del siguiente empleo, y el salario total de ambos P60 debe corresponder a las cifras del año completo.

Cuando la fecha de cese en el P45 se transcribe incorrectamente — por ejemplo, tecleando 31/03 en lugar de 28/02 — el nuevo empleador aplica el código tributario equivocado porque el P45 es el documento que el nuevo empleador usa para determinar la situación fiscal acumulada del empleado. Si el P45 muestra una fecha de cese dos semanas después de la real, el software de nóminas del nuevo empleador aplica un código acumulativo que asume dos semanas adicionales de desgravación fiscal del empleo anterior — desgravación que el empleado ya usó. El empleado termina pagando menos impuestos durante el resto del año y recibe una carta de Liquidación Simplificada de HMRC el otoño siguiente exigiendo el pago del déficit.

La guía de HMRC sobre corregir una fecha de cese incorrecta dice: actualice sus registros de nóminas con la fecha correcta y no informe la modificación en su próximo FPS — porque hacerlo podría crear un registro de empleo duplicado. Pero esta guía aplica al empleador que realizó la presentación original del FPS. Si el error de transcripción ocurre en la hoja de cálculo de conciliación de una oficina de nóminas — la fecha de cese se tecleó mal durante la entrada de datos, no durante el FPS original — la oficina no tiene un FPS que modificar. El error solo existe en la hoja de cálculo. Y la hoja de cálculo alimenta el informe de conciliación de la oficina, que alimenta la aprobación del empleador, lo que puede resultar en que el empleador emita un P60 corregido que soluciona un problema que no existía en el P60 original — creando un bucle de corrección que pierde el tiempo de todos.

La brecha estructural es la validación entre documentos. El software de nóminas valida dentro de un solo documento — formato NI en el P60, formato de código tributario en el P45. Ningún sistema valida entre documentos — es decir, ningún sistema verifica que la fecha de cese del P45 y la cifra de "Salario en este Empleo" del P60 sean coherentes con la trayectoria salarial total del empleado. Esa verificación entre documentos es lo que se supone que el operador de nóminas debe hacer manualmente al transcribir. Y es la primera verificación que se omite cuando el volumen supera el tiempo disponible.

Error n.º 5: Confusión con el plan de préstamo estudiantil: ¿Plan 1, 2, 4, 5 o de posgrado?

De los cinco errores de este artículo, este es en el que los administradores de nóminas tienen menos culpa, y el que genera más quejas de los empleados meses después de emitirse el P60. El sistema de reembolso de préstamos estudiantiles del Reino Unido ahora tiene cinco tipos de plan, cada uno con un umbral de reembolso diferente, y el plan de un empleado se determina por dónde estudió, cuándo se graduó y qué tipo de curso realizó.

La matriz es la siguiente:

La guía del empleador de HMRC dice: si su empleado no sabe en qué plan está, use el Plan 5 en su software de nóminas hasta que reciba un Aviso de Inicio de Préstamo Estudiantil (SL1). Usar el Plan 5 por defecto es un respaldo administrativo sensato, pero significa que todo empleado que en realidad esté en el Plan 1, 2 o 4 pero no se lo haya dicho a su empleador tendrá las deducciones calculadas con el umbral incorrecto. Un prestatario del Plan 1 (umbral de £26,900) tratado como Plan 5 (umbral de £25,000) empieza a reembolsar £1,900 de ingresos antes de lo que debería, lo que, al 9%, supone unas £171 al año de deducciones en exceso. Un prestatario del Plan 4 (umbral de £33,795) tratado como Plan 5 (£25,000) paga de más sobre £8,795 de ingresos, unas £792 al año.

La dimensión de transcripción de este error es más sutil. Cuando un operador de nóminas transcribe los datos del P60 a una hoja de cálculo de conciliación, el P60 muestra una cifra de deducción del préstamo estudiantil: un único número en libras enteras. No muestra qué plan generó esa deducción. El operador escribe £1,200 en la columna de la hoja de cálculo etiquetada como "Deducciones por préstamo estudiantil". El número es correcto. El plan es invisible. Dos empleados con el mismo salario y la misma deducción de £1,200 pueden estar en planes diferentes — uno en el Plan 1, otro en el Plan 2 — y la hoja de cálculo los trata de forma idéntica. El informe de conciliación que compara las deducciones totales del P60 con los totales del FPS coincidirá, porque los importes de las deducciones son correctos. El error no está en el importe, sino en el tipo de plan registrado en el sistema de nóminas, que el P60 resume sin nombrarlo.

Cuando HMRC finalmente cruza los tipos de plan de los empleados — lo cual hacen, y puede llevar meses porque los datos de SLC fluyen a través de HMRC hacia los empleadores de forma asíncrona — el empleador recibe una notificación de que un empleado estaba en el plan incorrecto. El empleador debe entonces corregir las deducciones pasadas, lo que puede implicar que el empleado solicite un reembolso a SLC. Martin Lewis en MoneySavingExpert ha documentado la congelación del umbral de reembolso del Plan 2 y el problema más amplio de las deducciones excesivas: empleados con ingresos variables, empleados que comenzaron a reembolsar demasiado pronto y empleados en el plan incorrecto por defecto. El proceso de reembolso pasa por SLC, no por la nómina — pero el error original reside en el registro de nómina que resume el P60, y la hoja de conciliación que no captura el tipo de plan amplifica la invisibilidad del error.

Por qué la extracción con IA cambia el perfil de error — no solo la velocidad

Cada error descrito anteriormente comparte una causa raíz que la capacitación, las listas de verificación y las segundas revisiones solo abordan superficialmente. La causa raíz es el propio paso de transcripción — el momento en que una persona lee un PDF y escribe sus datos en una celda. Eliminar ese paso elimina toda una categoría de errores que ninguna fórmula de validación detecta.

Cuando los datos del P60 se extraen con IA en lugar de escribirse a mano, el perfil de error cambia. El número de NI se lee directamente del certificado — sin oportunidad de transposición entre página y celda. El código tributario llega completo con su indicador W1/M1 porque la extracción conserva la cadena completa, no lo que una persona recuerda escribir. Las cifras de salario e impuestos se asignan a sus columnas correctas por significado semántico — "Salario en este Empleo" vs "Salario Total del Año" — en lugar de por la navegación espacial del operador a través de un diseño que vieron por primera vez hace diez segundos. La deducción del préstamo estudiantil se extrae como el valor impreso, y la pregunta del tipo de plan se convierte en un problema de configuración del sistema de nómina, no en un problema de transcripción.

Esto no significa que la extracción elimine todos los errores. Cambia qué errores permanecen. En lugar de errores de transposición — dígito incorrecto, columna incorrecta, sufijo omitido — los errores restantes son errores de verificación: ¿la IA leyó mal un carácter mal impreso? ¿Asignó la letra de categoría de NI de la fila incorrecta cuando un empleado tuvo un cambio de categoría a mitad de año? Estos errores de verificación son más rápidos de detectar porque el operador revisa los datos extraídos contra el documento fuente, en lugar de escribir y revisar simultáneamente. El operador se convierte en un revisor, no en un transcriptor — y los revisores detectan errores que los transcriptores crean.

Para el flujo de trabajo completo — desde PDFs de P60 hasta una hoja de cálculo lista para conciliación, incluyendo definiciones de columnas que funcionan en Sage, Xero, BrightPay y cualquier diseño de P60 de proveedor de nómina — consulte nuestra guía para extraer datos de P60 del Reino Unido a Excel. Para el problema más amplio de la entrada manual de datos del P60 como un cuello de botella estructural en el cierre del año de nómina, consulte el costo oculto de la entrada de datos del P60.