Errores comunes al integrar con el webservice de SUNAT

Los primeros días en producción con el webservice de SUNAT o un OSE producen siempre los mismos rechazos. No porque el equipo haya hecho un mal trabajo de integración, sino porque hay errores que el sandbox no expone con la misma severidad que producción: certificados con cadena de confianza diferente, RUCs que estaban activos en homologación pero con restricciones en producción, o cálculos de IGV que funcionaban con los datos de prueba pero fallan con decimales reales.

Esta guía documenta los 10 errores más frecuentes con su código CDR, la causa raíz más probable y la acción correctiva concreta. Los códigos de error siguen la tabla del Anexo Técnico de SUNAT; algunos OSEs los mapean a sus propios códigos internos, pero la causa y la corrección son las mismas.

La tabla completa de códigos de error del CDR forma parte del Anexo Técnico publicado en el portal oficial de SUNAT.

Error 0 — El sistema no devuelve CDR (timeout o SOAP fault)

Causa: el servidor del OSE o de SUNAT no responde dentro del tiempo de espera del cliente, o devuelve un SOAP fault antes de procesar el documento. Esto no es un error del comprobante; es un error de disponibilidad o conectividad. Acción correctiva: implementar reintentos con backoff exponencial (1s, 2s, 4s) hasta un máximo de 3 intentos. Si el timeout persiste, activar el canal de fallback a SUNAT directo. El comprobante no debe marcarse como Rechazado hasta recibir un CDR explícito; un timeout es estado desconocido, no rechazo.

Error 1033 — El número de serie o correlativo ya fue registrado

Causa: se intentó emitir un comprobante con el mismo RUC-Serie-Correlativo de uno ya aceptado por SUNAT. Ocurre por falta de bloqueo transaccional en la generación de números en ambientes de alta concurrencia, o por un reintento automático que no verificó si el primer intento fue aceptado antes del timeout. Acción correctiva: antes de reintentar un comprobante que recibió timeout, consultar el estado en el OSE con getStatus usando el número de ticket. Si el estado es Aceptado, no reenviar. Implementar un mecanismo de idempotencia en la generación de correlativos.

Error 2072 — Certificado digital inválido

Causa más frecuente: el certificado fue emitido por una entidad certificadora no acreditada por INDECOPI para el sistema peruano de facturación electrónica. Segunda causa: el certificado venció en producción sin que el PSE tuviera una alerta de renovación. Tercera causa: el certificado corresponde a un RUC diferente al del emisor declarado en el XML. Acción correctiva: verificar el emisor del certificado en la cadena de confianza. Implementar alertas automáticas cuando el certificado tenga menos de 30 días de vigencia.

Error 2335 — RUC del emisor no activo o no habilitado

Causa: el RUC del emisor está en estado de baja, suspensión o no está habilitado para emitir comprobantes electrónicos según el padrón de SUNAT. En producción, un emisor puede ser dado de baja por SUNAT sin notificación previa al PSE. Acción correctiva: consultar el estado del RUC en el API de consulta de SUNAT antes de emitir el primer comprobante del día para emisores de bajo volumen. Para emisores de alto volumen, configurar una verificación periódica del estado del RUC y alertar al administrador si el estado cambia.

El estado del RUC puede verificarse en el módulo de consulta de RUC de SUNAT.

Error 3034 — El monto de IGV no coincide con la base imponible

Causa: el TaxAmount del bloque TaxTotal no es igual a TaxableAmount * 0.18 redondeado a dos decimales según las reglas de redondeo bancario de SUNAT. El error más común ocurre cuando hay múltiples líneas con centavos: la suma de IGVs por línea puede diferir del IGV calculado sobre el total por efecto del redondeo. Acción correctiva: calcular el IGV total sobre la base imponible total, no como suma de IGVs por línea. El campo TaxableAmount del TaxSubtotal debe ser la suma de todas las BaseAmount gravadas del comprobante.

Error 3205 — El comprobante referenciado en BillingReference no existe

Causa: se emitió una Nota de Crédito o Débito referenciando un comprobante que no está registrado en SUNAT. Puede ser porque el comprobante original fue rechazado y el PSE no lo detuvo, porque el número de serie está mal formado en el BillingReference, o porque el comprobante original fue enviado por canal de contingencia y aún no se reconcilió en SUNAT. Acción correctiva: verificar que el comprobante referenciado tiene CDR Aceptado antes de emitir la nota. Si el comprobante original fue enviado por contingencia, esperar la reconciliación antes de emitir notas sobre él.

Error 4000 — Nombre del archivo ZIP incorrecto

Causa: el archivo ZIP enviado al OSE no sigue la convención exacta RUC-TipoDoc-Serie-Correlativo.zip. Errores frecuentes: correlativo sin ceros de relleno (debe tener 8 dígitos), extensión en mayúsculas (.ZIP en lugar de .zip), o el nombre del XML dentro del ZIP no coincide con el nombre del ZIP. Este error es devuelto por el OSE antes de procesar el contenido, a veces como un fault SOAP en lugar de un CDR. Acción correctiva: implementar una función centralizada de generación de nombres de archivo con tests unitarios que cubran todos los tipos de comprobante y rangos de correlativo.

Error de autenticación — Credenciales SOL incorrectas o expiradas

Causa: las credenciales SOL (RUC + usuario + clave) del emisor son incorrectas, o la clave SOL fue cambiada por el emisor sin notificar al PSE. También ocurre cuando el PSE usa sus propias credenciales SOL en lugar de las del emisor. Acción correctiva: el PSE debe tener un proceso de actualización de credenciales SOL por emisor, y debe alertar inmediatamente cuando una solicitud de autenticación falla para que el emisor actualice su clave. No almacenar credenciales SOL en texto plano; usar un gestor de secretos.

Error en SummaryDocuments — Fecha de referencia fuera de rango

Causa: el Resumen Diario de Boletas incluye una fecha de referencia anterior a la fecha límite permitida por SUNAT. SUNAT solo acepta resúmenes hasta cierto número de días posteriores a la emisión de las boletas (actualmente el día siguiente como máximo recomendado, aunque hay margen). Si el PSE acumula varios días sin enviar resúmenes, puede encontrar rechazos por fecha expirada. Acción correctiva: implementar un job nocturno que procese automáticamente el resumen del día anterior y genere alerta si falla.

Error de namespace — XML rechazado por estructura inválida

Causa: el XML usa namespaces incorrectos o versiones distintas a las exigidas por SUNAT. El namespace del elemento raíz para Facturas debe ser exactamente urn:oasis:names:specification:ubl:schema:xsd:Invoice-2. Cualquier variación (incluyendo agregar o quitar dígitos de versión) resulta en rechazo inmediato. Acción correctiva: no construir los namespaces manualmente; usar las constantes definidas en el XSD oficial de SUNAT y no modificarlas.

Preguntas frecuentes

¿Cuál es la diferencia entre un rechazo del OSE y un rechazo de SUNAT en el CDR?

El CDR es emitido por el OSE, que incluye en su ResponseCode tanto sus propios errores de validación como los errores de SUNAT que detecta al procesar el comprobante. Los códigos de error de SUNAT (1000-3999) están definidos en el Anexo Técnico y son consistentes entre OSEs. Los errores propios del OSE tienen códigos que varían según el operador; consultar la documentación específica del OSE para mapear sus códigos propietarios.

¿Cómo puedo diagnosticar un error sin CDR cuando el OSE no responde?

Cuando no hay CDR, el problema está antes del procesamiento: fallo de red, autenticación, nombre de archivo incorrecto o SOAP fault. Revisar en este orden: (1) ¿responde el endpoint del OSE con HTTP 200? (2) ¿la respuesta SOAP contiene Fault en lugar de Response? (3) ¿el archivo ZIP tiene el nombre correcto? (4) ¿las credenciales de autenticación son válidas? Si todos son correctos, registrar el request completo y abrir un ticket de soporte con el OSE adjuntando el XML original.

¿Qué diferencia hay entre reintentar un comprobante rechazado y uno con timeout?

Un comprobante Rechazado (CDR con ResponseCode diferente de 0) puede reenviarse con el mismo número de serie si el error es corregible y el número no fue registrado. Un comprobante con timeout es estado desconocido: debe consultarse con getStatus antes de reintentar, porque si llegó al OSE y fue aceptado, reenviar el mismo número resultará en error 1033 por duplicado. La lógica de reintento debe ser diferente para cada caso.

¿Es posible revertir un comprobante Aceptado si contiene un error de datos?

No. Un comprobante con CDR Aceptado no puede eliminarse ni modificarse retroactivamente en SUNAT. Para corregir un error en un comprobante aceptado, la vía es emitir una Nota de Crédito que lo anule (si el ajuste es a la baja o anulación total) o una Nota de Débito (si el ajuste es al alza). La Nota debe referenciar el comprobante original en el campo BillingReference y usar el código de motivo correspondiente según el tipo de corrección.

Para el contexto del modelo de validación en Perú, ver la guía de facturación electrónica para ISVs. Para el proceso completo de integración antes de salir a producción, ver el checklist técnico de integración con SUNAT.