Códigos de error de KSeF: qué rechaza realmente el sistema y cómo solucionarlo

Una factura rechazada no existe. Legalmente, nunca ocurrió. No se puede corregir, anular ni referenciar en la JPK_V7. Se corrige el error y se reenvía. Esa distinción parece trivial hasta que aparece un código de excepción 21401 un viernes a las 16:55 con un cliente esperando el cobro.

La encuesta de Grant Thornton de abril de 2026 reveló que el 74 por ciento de las empresas sufrió errores de facturación electrónica en el primer mes de KSeF obligatorio. El veinte por ciento afirmó que esos errores perturbaban la operativa diaria. El problema no es teórico. Es la experiencia más común tras el lanzamiento en el ecosistema polaco de facturación.

Este artículo vincula cada código de rechazo de la taxonomía de KSeF 2.0 con su causa, el campo que falla y la solución exacta. También nombra los códigos inventados que circulan en artículos de granjas de contenido, porque actuar sobre una taxonomía falsa hace perder tiempo y retrasa el reenvío.

KSeF solo rechaza por dos motivos

El Ministerio de Hacienda confirmó públicamente en mayo de 2026 que KSeF solo valida dos cosas: el cumplimiento del esquema FA(3) y los permisos del emisor. No comprueba el cálculo del IVA. No contrasta los datos del comprador con el registro fiscal. No valida el valor del tipo de cambio. No coteja los importes de la factura con ninguna base de datos externa.

Una factura conforme al esquema con el tipo de IVA incorrecto, el NIP del comprador incorrecto y un tipo de cambio inventado superará la validación de KSeF y recibirá un número KSeF. El Estado asigna el número, emite el UPO (potwierdzenie przyjęcia, la confirmación de recepción) y la factura entra en circulación legal. El error material sale a la luz semanas después: en la conciliación, en una inspección o cuando el comprador descubre que no puede deducir el IVA soportado porque la factura lleva el NIP de otra persona.

No es un defecto de diseño. Es la arquitectura. KSeF es un sistema de compensación, no un sistema de validación. La validación material es responsabilidad del contribuyente, es decir, una lista de verificación manual o una función de producto. Plandesk incorpora una validación previa al envío que comprueba lo que KSeF no comprueba: dígito de control y consulta de registro del NIP, aritmética del IVA, números de factura duplicados, verificación del tipo NBP y coherencia de los códigos GTU.

Estados de sesión: cuándo existe realmente su factura

Antes de descifrar los códigos de rechazo, hay que entender los estados de sesión. El error más dañino tras el lanzamiento no es un rechazo. Es un duplicado causado por reenviar durante el procesamiento.

Los estados 100 y 150 no son errores. Significan que KSeF recibió la factura y la está procesando. El tiempo de procesamiento del Ministerio varía de segundos a horas bajo carga. Reenviar en esta ventana crea una factura duplicada con otro número KSeF, la causa más común de rechazos con código 440.

Si usa una herramienta que consulta el estado automáticamente, déjela trabajar. Si usa la Aplikacja Podatnika manualmente, actualice la página de estado de la sesión. No vuelva a pulsar "enviar".

La taxonomía real de códigos de error

KSeF 2.0 devuelve un estado HTTP más un exceptionCode en el cuerpo de la respuesta. Los códigos siguientes proceden de la documentación oficial OpenAPI del Ministerio de Hacienda. Son los códigos con los que se encuentran los profesionales.

Código 21401: incumplimiento del esquema FA(3)

Qué significa: El XML enviado no se ajusta al esquema FA(3).

Causas habituales:

• Plantilla FA(2) obsoleta aún en uso (FA(2) se desactivó definitivamente el 1 de febrero de 2026)
• Bytes BOM (marca de orden de bytes) al inicio del archivo XML
• Orden incorrecto de elementos o elementos obligatorios ausentes
• Declaración de espacio de nombres incorrecta

Solución: Regenere la factura desde una plantilla FA(3) actual. Si usa software de facturación, actualícelo a la última versión. No edite nunca el XML a mano. El esquema es tan estricto que las ediciones manuales introducen más errores de los que corrigen.

Ejemplo: La factura de una autónoma se rechaza con 21401 porque su herramienta de facturación se actualizó por última vez en enero de 2026 y sigue generando XML FA(2). La solución es actualizar el software, no editar el XML.

Código 21405: error de validación de entrada

Qué significa: Falló una validación a nivel de campo. El XML es estructuralmente válido, pero un campo concreto contiene datos en formato incorrecto.

Causas habituales:

• NIP con guiones, espacios o prefijo "PL" (FA(3) espera 10 dígitos sin separadores)
• Fecha en formato incorrecto (FA(3) exige YYYY-MM-DD)
• Campo numérico con coma decimal en lugar de punto
• KursWaluty con menos de 6 decimales

Solución: Corrija los datos de origen en la ficha del cliente o en el formulario de factura y reenvíe. La respuesta de error incluye la ruta del campo, que indica exactamente qué elemento corregir.

Ejemplo: La factura de un autónomo se rechaza con 21405 porque la ficha del cliente guarda el NIP del comprador como "PL-123-456-78-90". FA(3) espera "1234567890". Corregir la ficha, regenerar, reenviar.

Código 21301: error de autorización

Qué significa: El emisor no tiene permiso para emitir facturas para el NIP de la cabecera de la factura.

Causas habituales:

• Token caducado (la vigencia de los tokens KSeF depende del tipo de concesión)
• Token emitido para un NIP distinto del de la factura
• El administrador concedió derechos de emisión, pero la concesión aún no ha surtido efecto
• Uso de un acceso personal (Profil Zaufany) en lugar de token o certificado

Solución: Regenere el token con los permisos correctos para el NIP emisor. Si usa un acceso personal, cambie a autenticación por token. La autenticación por token era el método recomendado antes del lanzamiento y se convirtió en el estándar de facto tras el colapso de Profil Zaufany los días 2 y 3 de febrero de 2026.

Ejemplo: Una asesoría intenta emitir una factura para un cliente nuevo y recibe 21301. El token de la asesoría se emitió antes de que el cliente se añadiera a sus permisos de KSeF. La solución: conceder derechos de emisión para el NIP del cliente y regenerar el token.

Código 440: factura duplicada

Qué significa: Ya existe en KSeF una factura con el mismo número del mismo emisor.

Causas habituales:

• Reenvío a ciegas tras un tiempo de espera agotado (la causa más común)
• Emisión en paralelo a través de la app de facturación y de la Aplikacja Podatnika
• Estado de sesión no comprobado antes de reenviar

Solución: Consulte KSeF con su propio número de factura antes de reenviar. Si el primer envío tuvo éxito (estado 200), adopte la factura existente. No cree un duplicado. Si el primer envío falló de verdad, corrija el error y reenvíe con el mismo número de factura.

Ejemplo: Un usuario envía una factura, recibe un tiempo de espera agotado y reenvía. El primer envío en realidad tuvo éxito, solo que la respuesta llegó tarde. El segundo envío topa con el 440. La acción correcta: comprobar el estado de la primera sesión, encontrar el 200 y usar ese número KSeF.

HTTP 500, 503, 429: errores del servidor

Qué significa: La plataforma KSeF está sobrecargada o limita la tasa de peticiones.

Causas habituales:

• Oleadas de tráfico del período de lanzamiento (febrero y abril de 2026)
• Limitación de tasa tras demasiadas peticiones en poco tiempo
• Problemas transitorios de infraestructura

Solución: Implementar reintentos con espera progresiva. Si el error persiste, cambiar al modo offline24: emitir la factura localmente y transmitirla antes del siguiente día laborable. La fecha de emisión P_1 se conserva en modo offline, de modo que la fecha legal de la factura no se desplaza.

Facturas fantasma: aceptadas pero invisibles

Un patrón que no genera código de rechazo pero duele igual: la factura se acepta (estado 200, número KSeF asignado, UPO emitido), pero el comprador no la ve en su bandeja de KSeF. Su deducción de IVA queda bloqueada. Los expertos lo atribuyen a fallos de integración entre el ERP y KSeF y a una semántica poco clara de los estados enviada, aceptada y rechazada.

La factura existe. Está en circulación legal. El contable del comprador simplemente no puede acceder a ella. La solución temporal: el vendedor comparte el número KSeF y el UPO directamente con el comprador, que puede consultar KSeF manualmente. La solución estructural es una mejor sincronización de estados entre KSeF y los sistemas contables comerciales, uno de los problemas que debe abordar el paquete de "7 mejoras" anunciado por el Ministerio para el 1 de enero de 2027.

Códigos de error inventados que debe ignorar

Las granjas de contenido han inventado códigos de error que no existen en la documentación de la API de KSeF. Si busca códigos de error de KSeF, encontrará artículos que mencionan códigos como "TOTAL_MISMATCH", "NIP_REGISTRY_REJECTION" o "VAT_RATE_INVALID". Son inventados. No corresponden a ningún exceptionCode de la especificación OpenAPI oficial.

El Ministerio de Hacienda ha declarado públicamente que KSeF no valida aritmética, datos del comprador ni tipos de IVA. Todo artículo que afirme que KSeF rechaza facturas por importes de IVA incorrectos o por NIP de comprador no registrados está equivocado. Esos errores pasan por KSeF. Salen a la luz después: como correcciones, inspecciones o deducciones de IVA soportado perdidas.

Si se encuentra un código de error que no aparece en la documentación oficial, compruebe la fuente. La referencia autorizada es la especificación OpenAPI publicada por el Ministerio de Hacienda y reflejada en el repositorio de documentación de la API de KSeF.

Siete comprobaciones antes de cada envío

Ejecute estas comprobaciones antes de enviar cualquier factura a KSeF. Atrapan los errores que KSeF no atrapa.

1. Formato del NIP: 10 dígitos, sin guiones, sin espacios, sin prefijo "PL".
2. Dígito de control del NIP: Valide el dígito de control. KSeF no lo comprueba.
3. Consulta del NIP en el registro: Verifique que el comprador figura en la biała lista podatników VAT (lista blanca de contribuyentes del IVA).
4. Aritmética del IVA: Neto por tipo igual a IVA. Neto más IVA igual a bruto. Compruebe cada línea.
5. Unicidad del número de factura: Consulte KSeF con su propio número de factura antes de enviar.
6. Coherencia de fechas: La fecha de emisión (P_1) es hoy o está dentro de la ventana offline24. Nada de retrodatación.
7. Campos de divisa: KodWaluty es un código ISO 4217 válido. KursWaluty tiene 6 decimales. El tipo coincide con la tabla del NBP del día correcto.

Estas comprobaciones llevan segundos en software y eliminan la mayoría de los errores posteriores al lanzamiento. Hacerlas manualmente es posible pero propenso a errores, por eso la validación previa al envío existe como función de producto y no como ejercicio de documentación.

Este material es de carácter informativo general y no constituye asesoramiento legal ni fiscal. Para un caso concreto, verifique la normativa vigente o consulte a un asesor cualificado.