Seis errores de ingreso de datos del P45
que generan un exceso de impuestos al nuevo empleado — y cuánto cuesta solucionarlos

Por qué un solo campo erróneo en un P45 nunca se queda en un solo campo erróneo

Un error en un P45 se agrava porque el PAYE es acumulativo por diseño. A diferencia de un recibo o una factura — donde una cifra mal escrita afecta solo a un documento — un P45 alimenta la posición inicial de un cálculo continuo que su software de nómina repite cada período de pago durante el resto del año fiscal. Si el código tributario, el salario acumulado o la base Semana 1/Mes 1 se introducen mal al inicio, el software no aplica ese error una sola vez; lo arrastra a cada Presentación de Pago Completo (FPS) posterior hasta que alguien lo detecta y corrige la base.

Esa es la diferencia entre un error en un P45 y la mayoría de los errores de ingreso de datos. El empleado del hilo sobre el código de emergencia no pagó de más por un solo número equivocado en el primer mes — pagó de más en el mes uno, el mes dos, el mes tres y el mes cuatro, porque el punto de partida incorrecto generaba deducciones incorrectas de forma continua. Y como HMRC solo concilia la situación cuando tiene todos los datos de ingresos, el reembolso a menudo no llega hasta que se corrige el código tributario a mitad de año o, peor aún, hasta que termina el año fiscal. La consecuencia de un error tipográfico de dos segundos se mide en meses de flujo de caja del empleado.

Los seis errores siguientes son los que aparecen repetidamente en foros de nóminas y en las guías de corrección de HMRC. Cada uno es lo suficientemente específico como para que sepa si lo ha cometido — y cada uno tiene una causa raíz que no es "tener más cuidado".

Error 1: Transponer un dígito en el código tributario

El error más común en un P45 es un solo dígito transpuesto en el código tributario — 1257L ingresado como 1275L, o 1250L como 1205L. Parece trivial porque es un solo carácter, pero el número en un código tributario es la asignación libre de impuestos del empleado dividida entre diez. 1257L concede £12,570 de salario libre de impuestos; 1275L concede £12,750; 1205L concede £12,050. Un código incorrecto significa que el empleado recibe una asignación a la que no tiene derecho (y tendrá que devolverla) o se le niega una a la que sí tiene derecho (y paga de más hasta que se corrige).

La causa raíz no es el descuido — es que los códigos tributarios son cadenas de dígitos sin verificación interna, que se leen de un diseño y se escriben en otro bajo presión de tiempo. No hay nada en "1275L" que parezca incorrecto. Es un código con formato válido; solo que pertenece a una asignación diferente. Y como el software de nómina acepta cualquier código bien formado sin cuestionar si coincide con el P45, el error pasa silenciosamente a la primera ejecución de nómina.

La corrección, una vez que está activa, pasa por HMRC en lugar de una edición rápida: HMRC emite un código revisado mediante un aviso P6 o P9, y su software lo aplica en adelante. Si el código era acumulativo, la siguiente nómina suele autocorregir la posición del año hasta la fecha. Si estaba en base Semana 1/Mes 1, el pago de más o de menos queda sin resolver hasta fin de año. En cualquier caso, la solución es más lenta que el error.

Error 2: Introducir la fecha de baja incorrecta — o en blanco

Una fecha de baja errónea desvirtúa la posición del empleado en la línea temporal del año fiscal, y una en blanco que se sustituye por un valor predeterminado (los sistemas de nóminas a veces convierten una fecha vacía en 01/01/1900) puede crear un registro duplicado de PAYE en HMRC. La fecha de baja en el P45 indica a tu programa informático en qué semana o mes fiscal finalizó el empleo anterior, lo que a su vez determina dónde se retoma el nuevo empleo. Introdúcela mal y el cálculo acumulativo se anclará en el punto equivocado del año.

La propia guía de HMRC para corregir un FPS es explícita sobre lo complicado que resulta la limpieza posterior: si se notifica incorrectamente una fecha de pago o de baja y aparece un indicador de "pago tras la baja", no debes introducir los mismos importes en los campos "pago en el período" y "pago acumulado en el año", o crearás un registro duplicado para el empleado; debes poner 0.00 en el campo de pago en el período y realinear la nómina con el período fiscal correcto. Se trata de una conciliación de varios pasos provocada por una fecha mal tecleada.

La causa raíz es que las fechas de baja son fáciles de confundir: la fecha en que finalizó la relación laboral, la fecha del último pago y la fecha en que recibiste el P45 son tres cosas distintas, y los formatos del P45 no siempre dejan clara la diferencia. Introduce la fecha de pago donde corresponde la de baja y la línea temporal se desplaza.

Error 3: Confundir "Total acumulado hasta la fecha" con "Pago en este empleo"

Cuando un empleado ha tenido más de un trabajo, el P45 muestra dos cifras de pago — "Total acumulado hasta la fecha" (acumulado de todos los empleos en este año fiscal) y "Pago en este empleo" (solo el empleo del que se ha dado de baja) — e introducir la equivocada en el campo de acumulado anual de tu programa informático notifica incorrectamente a HMRC los ingresos acumulados del empleado. Los dos números son diferentes a propósito, y solo uno de ellos corresponde al campo de acumulado anual que impulsa el cálculo del impuesto acumulativo.

Si pones "Pago en este empleo" donde debería ir "Total acumulado hasta la fecha", subestimas los ingresos del empleado en el año. El programa informático entonces cree que el empleado tiene más desgravación personal no utilizada de la que realmente tiene, deduce menos impuestos durante varios meses, y el déficit aparece después como una desagradable corrección del código fiscal: HMRC recupera el impuesto no pagado reduciendo la desgravación en el código, por lo que el empleado ve de repente una deducción mucho mayor para recuperar lo que nunca se retuvo.

Esto atrapa incluso a administradores experimentados, no solo a los nuevos, porque en un P45 de un solo empleo las dos cifras son idénticas, por lo que el hábito de "tomar el número de pago" funciona hasta que falla silenciosamente en un empleado con varios trabajos. La causa raíz es que la distinción solo importa a veces, que es precisamente cuando falla un paso de copia mecánica. El desglose campo por campo de lo que significa cada casilla del P45 merece la pena tenerlo a mano precisamente para estos casos de cifras dobles.

Error 4: Tratar un código de Semana 1/Mes 1 como acumulativo

Un código fiscal con el sufijo "W1" o "M1" — por ejemplo, 1257L M1 — no es acumulativo, e ignorar ese sufijo (ingresar el código como 1257L simple) le indica a su software que distribuya la desgravación de forma acumulativa cuando no debería. Semana 1/Mes 1 significa que cada período de pago se grava de forma aislada, usando solo el pago de ese período e ignorando todo lo anterior en el año. Elimine el sufijo y la base de cálculo cambia.

La consecuencia va en la dirección que haya empujado la base ignorada. Si el empleado realmente debería estar en M1 (HMRC suele aplicarlo cuando sus registros de años anteriores estaban incompletos) y usted ingresa un código acumulativo, el software puede devolver una desgravación que el empleado ya ha usado en otro lugar, sub-reteniendo ahora y generando una factura después. El error inverso — dejar un código M1 de emergencia activo cuando HMRC ha emitido uno acumulativo — mantiene al empleado con exceso de impuestos porque la desgravación nunca se acumula entre períodos.

La causa raíz es que la marca W1/M1 es un sufijo de dos caracteres que parece una ocurrencia tardía pero cambia toda la aritmética. Es fácil tratar "1257L M1" y "1257L" como el mismo código con una etiqueta extraviada. No son el mismo código. Un detalle deliberado: un código W1/M1 genuino en un P45 es una instrucción autorizada de HMRC para ingresarlo tal cual — no un error que "ordenar" haciendo que las cifras parezcan acumulativas.

Error 5: Escribir mal el número de la Seguridad Social

Un número de la Seguridad Social incorrecto impide que HMRC vincule al nuevo empleado con su registro existente, por lo que el primer FPS puede ser rechazado o, peor, asignarse a la cuenta de otra persona. El NINO es la clave de identidad que HMRC usa para conciliar a una persona en todos los empleos que haya tenido. Su formato es rígido — dos letras, seis dígitos, una letra de sufijo (p. ej., QQ 12 34 56 C) — pero el formato rígido no evita un dígito transpuesto, y un NINO bien formado pero incorrecto parece completamente válido.

Cuando el número no coincide, las contribuciones al Seguro Social y el PAYE que reporta pueden acreditarse al registro equivocado. Para el empleado, esto puede significar lagunas en su historial de contribuciones — el tipo que luego afecta los años de calificación para la pensión estatal o el derecho a prestaciones basadas en contribuciones — y el problema es invisible hasta que revisan un estado de cuenta años después. Ciertos prefijos nunca se emiten (las letras D, F, I, Q, U y V nunca se usan como primera letra; O nunca es la segunda), por lo que esos señalan un error obvio, pero un número incorrecto plausible pasa sin problemas.

La causa raíz es que un NINO son nueve caracteres de identificador puro sin significado para verificar su validez — no se puede mirarlo y saber que está mal como se podría cuestionar un salario poco realista. O coincide con el registro de HMRC o no, y se entera después.

Error 6: Omitir el indicador de préstamo estudiantil — o adivinar el plan

El P45 señala los préstamos estudiantiles con un único indicador "Y" en la casilla 5 y nada más — no indica qué plan —, por lo que tanto omitir el indicador como adivinar el plan generan deducciones mensuales incorrectas. Según el Chartered Institute of Payroll Professionals (CIPP), cuando un P45 muestra "Y" en la casilla de préstamo estudiantil, las deducciones deben comenzar desde el próximo día de pago disponible, pero como el formulario no distingue entre Plan 1, Plan 2, Plan 4 o Plan 5, el empleado debe indicar cuál aplica.

Aquí hay dos errores distintos. El primero es pasar por alto el indicador por completo: la casilla es pequeña y, si se pasa por alto, los pagos del empleado se detienen al cambiar de trabajo, acumulando silenciosamente un saldo de atrasos que la Student Loans Company recupera después. El segundo es adivinar el plan. La guía de HMRC para empleadores indica que si el empleado no puede decirle su plan, usted usa por defecto el Plan 5 en su software de nómina hasta que llegue un aviso de inicio SL1 — no invente un plan ni descuente atrasos por el período anterior a recibir el P45. Si elige el plan equivocado, el umbral es incorrecto, por lo que el porcentaje se aplica a la porción de salario equivocada cada mes hasta que un SL1 lo corrija.

La causa raíz es una brecha estructural que el CIPP ha consultado abiertamente entre sus miembros: el P45 simplemente no incluye el tipo de plan, por lo que el formulario en sí no proporciona suficiente información para hacer la deducción correcta. Esto lo convierte menos en un error de transcripción y más en un punto ciego conocido — que se cierra capturando el indicador con precisión y luego confirmando el plan con el empleado o mediante el aviso SL1, no asumiendo.

Lo que realmente cuesta corregir un error de P45 después de procesar la nómina

Corregir un error de P45 nunca es tan rápido como el error que lo causó, y en circunstancias desfavorables expone al empleador a una multa. Lo primero que hay que saber es que no se puede simplemente reemitir un P45 corregido — HMRC prohíbe modificarlo o regenerarlo, porque un segundo P45 crearía registros duplicados de PAYE. Cualquier corrección debe realizarse a través de Real Time Information.

El software de nóminas hace posible la mecánica, pero no la simplifica. BrightPay, por ejemplo, exige reabrir los recibos afectados antes de modificarlos e incluye un selector específico de plan de préstamos estudiantiles para esa corrección; IRIS Staffology expone una función "Earlier Year FPS" por empleado para corregir ejercicios cerrados. Las herramientas existen precisamente porque estas correcciones son habituales, pero cada una es una conciliación manual, no un deshacer con un clic.

El riesgo más grave es la sanción. Los errores en las declaraciones RTI están sujetos al Anexo 24 de la Ley de Finanzas de 2007 y, como resume el CIPP, cuando una declaración inexacta subestima el impuesto adeudado, HMRC puede cobrar el 30% de los ingresos potenciales perdidos por inexactitud negligente, el 70% por una deliberada y hasta el 100% si es deliberada y oculta. Es poco probable que una cifra mal tecleada del P45 se considere deliberada, pero "negligente" es precisamente la categoría en la que cae un error de transcripción, y la defensa contra ello es poder demostrar que se actuó con la diligencia debida. HMRC solo impone una sanción "si no actuó con la diligencia debida o lo hizo deliberadamente", lo que convierte la presencia o ausencia de un proceso controlado y verificable de entrada de datos en la diferencia entre una corrección y una multa.

De dónde vienen estos errores — y la solución que elimina el paso de transcripción

Cada uno de estos seis errores comparte una misma causa raíz: una persona lee un valor de un formato de documento y lo vuelve a escribir en otro, sin una capa de corrección de errores intermedia. El código tributario no está mal en el P45; se vuelve incorrecto al reescribirlo. La solución, entonces, no es "revisar con más cuidado", sino eliminar la reescritura.

Esto es más difícil de lo que parece con los P45 en particular, porque no existe un formato estándar de P45. HMRC exige qué datos debe llevar un P45, pero no cómo se ve, por lo que un P45 generado por Sage 50 Payroll sitúa el código tributario en un lugar diferente al de uno de BrightPay, Xero o QuickBooks UK. El OCR basado en plantillas — que depende de saber dónde está cada campo en la página — falla en cuanto llega un P45 de un proveedor de nóminas para cuyo diseño no fue creado. Por eso el "denominador común" siempre ha sido una persona leyendo el PDF.

ImageToTable.ai elimina la reescritura sin necesidad de una plantilla para cada proveedor. Utiliza la Extracción Personalizada de Columnas: en lugar de indicarle a la herramienta dónde está el código tributario en cada diseño, usted escribe los nombres de campo que necesita su configuración de nóminas — "Código Tributario al Salir", "Total Pagado Hasta la Fecha", "Pago en Este Empleo", "Fecha de Salida", "NINO", "Indicador de Préstamo Estudiantil", "Base Semana1/Mes1" — y la IA lee cada P45 comprendiendo el significado de esos campos etiquetados, dondequiera que aparezcan, en cualquier diseño de proveedor. La definición de columna se escribe una vez y se reutiliza para cada nuevo empleado durante todo el año fiscal. Dado que la herramienta captura tanto "Total Pagado Hasta la Fecha" como "Pago en Este Empleo" como columnas separadas, y conserva el sufijo W1/M1 tal como se imprime, los dos errores que dependen de confundir campos (Errores 3 y 4) no surgen del paso de extracción.

La extracción no es una afirmación de precisión perfecta: es la eliminación del modo de fallo específico del que provienen estos seis errores. Aún debes realizar una validación de la ejecución de nómina: una comprobación rápida en Excel que marque un NINO que no tenga nueve caracteres, un código fiscal que no termine en una letra válida, o una cifra fiscal que no sea una proporción plausible del salario. Pero estás revisando un puñado de filas marcadas contra la fuente, no transcribiendo manualmente cada campo de cada P45 esperando no haber intercambiado un dígito. Para los equipos que quieren un contexto más amplio (gestión por lotes, fórmulas de validación y el conjunto completo de campos), la guía completa de extracción de P45 del Reino Unido y el desglose de costes del procesamiento manual de P45 retoman donde este artículo termina.

Preguntas frecuentes