Seis errores de entrada de datos del P45
que tributan de más a un nuevo empleado — y cuánto cuesta corregirlos

Por qué un campo incorrecto en un P45 nunca se queda en un solo campo incorrecto

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 está mal en un solo documento — un P45 alimenta la posición inicial de un cálculo continuo que su software de nóminas repite cada período de pago durante el resto del año fiscal. Si introduce mal el código de impuesto, el salario acumulado o la base de la Semana 1/Mes 1 al configurarlo, el software no aplica ese error solo una vez; lo arrastra a cada Full Payment Submission (FPS) posterior hasta que alguien lo detecta y corrige la línea base.

Esa es la diferencia entre un error de P45 y la mayoría de los otros errores de entrada de datos. Al empleado en el hilo de impuesto de emergencia no se le cobró de más por un solo número incorrecto en el primer mes — se le cobró de más en el primer mes, el segundo, el tercero y el cuarto, porque el punto de partida incorrecto seguía generando deducciones incorrectas. Y como el HMRC solo concilia el panorama una vez que tiene datos de ingresos completos, el reembolso a menudo no llega hasta que el código de impuesto se corrige a mitad de año o, peor, hasta que termina el año fiscal. La consecuencia de un error tipográfico de dos segundos se mide en meses del flujo de caja del empleado.

Los seis errores siguientes son los que se repiten en los foros de nóminas y en la guía de corrección del propio HMRC. Cada uno es lo bastante específico como para que usted 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 de impuesto

El error más común en un P45 es un solo dígito transpuesto en el código de impuesto — 1257L tecleado como 1275L, o 1250L como 1205L. Parece trivial porque es un solo carácter, pero el número en un código de impuesto es la desgravación libre de impuestos del empleado dividida entre diez. 1257L otorga £12,570 de pago libre de impuestos; 1275L otorga £12,750; 1205L otorga £12,050. Un código incorrecto significa que al empleado se le otorga una desgravació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 corrija).

La causa raíz no es el descuido — es que los códigos de impuesto son cadenas de dígitos sin verificación interna, leídos de un formato y tecleados en otro bajo presión de tiempo. No hay nada en "1275L" que parezca incorrecto. Es un código con formato válido; solo pertenece a una desgravación diferente. Y como el software de nóminas 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 el HMRC en lugar de una edición rápida: el 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 una base de Semana 1/Mes 1, el pago de más o de menos queda sin resolver hasta el final del año. En cualquier caso, la corrección es más lenta que el error.

Error 2: Introducir una fecha de cese incorrecta — o en blanco

Una fecha de cese incorrecta distorsiona la posición del empleado en la línea temporal del año fiscal, y una en blanco que se rellena con un valor predeterminado (los sistemas de nóminas a veces convierten una fecha vacía en 01/01/1900) puede crear un registro PAYE duplicado en HMRC. La fecha de cese en el P45 indica a su software qué semana o mes fiscal terminó el empleo anterior, lo que a su vez determina dónde se retoma el nuevo empleo. Si la introduce mal, el cálculo acumulativo se ancla en el punto equivocado del año.

La propia guía de HMRC sobre cómo corregir un FPS es explícita sobre lo complicada que resulta la limpieza posterior: si se notifica incorrectamente una fecha de pago o de cese y está implicado un indicador de "pago después del cese", no debe introducir los mismos importes tanto en el campo "pago en el período" como en el de "pago en el acumulado del año", o creará un registro duplicado para el empleado — debe poner 0.00 en el campo de pago en el período y realinear la nómina al 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 cese son fáciles de confundir: la fecha en que terminó el empleo del trabajador, la fecha de su pago final y la fecha en que usted recibió el P45 son tres cosas distintas, y los formatos del P45 no siempre hacen evidente la diferencia. Si introduce la fecha de pago donde corresponde la de cese, la línea temporal se desplaza.

Error 3: Confundir "Total Pay to Date" con "Pay in This Employment"

Cuando un empleado ha tenido más de un empleo, el P45 muestra dos cifras de pago — "Total Pay to Date" (acumulado en todos los empleos de este año fiscal) y "Pay in This Employment" (solo el empleo que se deja) — e introducir la equivocada en el campo de acumulado del año de su software notifica incorrectamente a HMRC las ganancias acumuladas del empleado. Los dos números son diferentes a propósito, y solo uno de ellos corresponde al campo de acumulado del año que impulsa el cálculo fiscal acumulativo.

Si pone "Pay in This Employment" donde debería ir "Total Pay to Date", subestimará las ganancias del empleado para el año. El software entonces cree que el empleado tiene más asignació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 recortando la asignació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 afecta a administradores experimentados, no solo a los nuevos, porque en un P45 de un solo empleo las dos cifras son idénticas — así que el hábito de "tomar el número de pago" funciona hasta que silenciosamente falla con un empleado que deja varios trabajos. La causa raíz es que la distinción solo importa algunas veces, que es exactamente cuando un paso de copia automático falla. El desglose campo por campo de lo que significa cada casilla del P45 merece la pena tenerlo a mano precisamente para estos casos de doble cifra.

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