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

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

La industria de nóminas lleva años debatiendo los errores del P60, pero casi siempre desde el lado del software. Código fiscal incorrecto aplicado durante el año. Letra de categoría NI incorrecta en el sistema de nóminas. Envío RTI marcado por HMRC. Son errores de proceso: el software de nóminas generó un certificado erróneo porque los datos introducidos eran incorrectos o una configuración estaba mal. La solución está en el sistema de nóminas.

Pero existe una segunda categoría de error del P60 que los blogs de nóminas, guías de despachos contables y páginas de asesoría de HMRC apenas mencionan: los errores introducidos después de que el P60 se haya generado correctamente, en el momento en que alguien lee el certificado y teclea sus datos en una hoja de cálculo de conciliación. Una gestoría de nóminas que verifica los totales FPS de fin de año contra la salida del P60 no está arreglando el software, está verificando que la salida del software coincida 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 ninguna traza 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 proceso. Un error de proceso se detecta cuando el sistema de nóminas activa una regla de validación — un formato NI inválido, un código fiscal 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 con el PDF del P60. Si nadie hace esa comparación, el error permanece en la hoja de cálculo, alimenta el informe de conciliación y finalmente sale a la luz cuando un empleado nota que su código fiscal 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, pasan los controles de fin de mes y afloran meses después. No son problemas de "revisa tu 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 #3: Pago total e impuesto deducido: un intercambio de columnas que lo rompe todo

Un P60 de un empleado con dos trabajos en el mismo año fiscal muestra dos conjuntos de cifras que se confunden fácilmente bajo presión de tiempo. "Pago en este empleo" es el salario bruto de este empleador específico. "Pago total del año" incluye pagos de empleos anteriores, transferidos del P45. "Impuesto deducido" en este empleo es el impuesto PAYE que este empleador dedujo. "Impuesto total del año" suma el impuesto de todos los empleos.

En un P60 impreso por Sage, estas cuatro cifras pueden aparecer en dos columnas adyacentes. En un P60 impreso por 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 diseño completamente diferente. Un operador de nóminas que transcribe 80 P60 al día, moviéndose entre diferentes formatos cada pocos certificados, escribe "Pago en este empleo" en la columna "Impuesto deducido" 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 automática: la relación impuesto-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 impositiva efectiva plausible del 15.6%. Pasa la verificación de proporcionalidad. Pasa la verificación de formato. Alimenta el informe de conciliación como una fila válida, y la conciliación total contra los datos FPS sale ligeramente desviada — lo suficientemente cerca para atribuirse a redondeo o una pequeña diferencia de tiempo RTI, no lo suficiente para desencadenar 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 produjo PDF de P60 donde las bandas de ganancias de NI estaban transpuestas: el PDF mostraba cifras incorrectas que no coincidían con la presentación RTI. Los administradores de nóminas que lo discutían en AccountingWEB describieron pasar "tiempo no facturable" diagnosticando 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 transcribe puede contener errores de diseño que ni siquiera el proveedor de software ha detectado.

Cuando un error humano de transposición se combina con un diseño 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 sobre 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 empleados meses después de emitido el P60. El sistema de reembolso de préstamos estudiantiles del Reino Unido tiene ahora 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 para empleadores 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 recurso administrativo sensato, pero significa que todo empleado que en realidad esté en el Plan 1, 2 o 4 y no se lo haya dicho a su empleador tendrá deducciones calculadas con el umbral incorrecto. Un prestatario del Plan 1 (umbral 26.900 £) tratado como Plan 5 (umbral 25.000 £) comienza a reembolsar 1.900 £ de ingresos antes de lo debido — lo que, al 9%, supone unas 171 £ al año de deducciones en exceso. Un prestatario del Plan 4 (umbral 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 datos del P60 a una hoja de conciliación, el P60 muestra una cifra de deducción del préstamo estudiantil — un solo número en libras enteras. No indica qué plan generó esa deducción. El operador escribe 1.200 £ en la columna de la hoja titulada "Deducciones de 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 Plan 1, otro Plan 2 — y la hoja los trata igual. El informe de conciliación que compara las deducciones totales del P60 con los totales del FPS coincidirá, porque los montos de las deducciones son correctos. El error no está en el monto — está 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.