Los 7 errores de SUNAT al firmar un comprobante y qué significa cada uno
Un código de rechazo de SUNAT es un diagnóstico, y casi siempre uno más preciso de lo que parece. El problema es que el mensaje describe el síntoma que vio el validador, no la causa que lo produjo, y esas dos cosas rara vez coinciden.
Estos son los siete que aparecen cuando el problema está en la firma o en el certificado, con lo que hay que revisar en cada caso y en qué orden.
Antes de tocar nada, tres preguntas
Responderlas ahorra la mitad de los diagnósticos.
¿Funcionaba ayer? Si sí, lo que cambió no es el XML. Mira el certificado, el reloj y las fechas de vigencia.
¿Falla con todos los comprobantes o solo con algunos? Si falla con todos, es configuración. Si falla con algunos, es contenido: caracteres especiales, importes, un campo que solo aparece en cierto tipo de documento.
¿Renovaste el certificado hace poco? La mitad de los rechazos por firma en producción vienen de una renovación a medias, con el archivo nuevo instalado y el registro en SUNAT todavía apuntando al anterior.
1059 · El XML no contiene firma digital
SUNAT recibió el documento y no encontró el nodo ds:Signature donde tiene que estar, dentro del ExtensionContent del comprobante.
La causa habitual no es que falte la firma, es que está en otro sitio. Algunas librerías la insertan al final del documento, que es válido según el estándar de firma XML y no según lo que espera SUNAT.
La causa menos obvia: la librería intentó firmar, falló al cargar el certificado y devolvió el XML sin firmar sin lanzar ningún aviso. Conviene revisar si el proceso de firma escribió algo en su registro.
Para confirmarlo, basta mirar el archivo que se envió:
grep -c "ds:Signature" comprobante.xml
Si devuelve cero, la firma nunca se generó.
2325 · El certificado usado no es el comunicado a SUNAT
Firmaste con un certificado distinto del que tienes registrado en SUNAT Operaciones en Línea. El comprobante puede estar perfectamente firmado y aun así se rechaza.
Aparece casi siempre después de una renovación. El certificado nuevo entra en el servidor, el registro en SOL se queda con el viejo, y el primer envío del día siguiente rebota.
También aparece en instalaciones con más de un entorno, cuando el servidor de pruebas y el de producción tienen certificados distintos y alguien copia la configuración de uno al otro.
Para confirmarlo, compara la huella del certificado instalado con la del registrado:
openssl x509 -in certificado.cer -noout -fingerprint -sha256 -subject -serial
2326 · El certificado usado se encuentra de baja
Lo dio de baja el emisor, normalmente porque el titular lo pidió o porque el contrato terminó. No se arregla desde tu lado: hay que hablar con quien lo emitió.
2327 · El certificado usado no se encuentra vigente
Aquí está el error que más veces se diagnostica mal, porque el mensaje sugiere una sola causa y hay dos.
La primera es la evidente: el certificado venció. Un certificado tiene fecha de inicio y fecha de fin, y fuera de esa ventana no vale.
La segunda es el reloj. Si la hora del servidor que firma está adelantada respecto a la fecha de inicio de un certificado recién emitido, o atrasada más allá de su vencimiento, el resultado es el mismo mensaje aunque el certificado esté perfecto. Pasa en máquinas virtuales que estuvieron suspendidas y en contenedores sin sincronización horaria.
Se descarta comparando las dos cosas:
date -u
openssl x509 -in certificado.cer -noout -dates
Si el notBefore es posterior a la hora del servidor, el problema es el reloj, no el certificado.
2328 · El certificado usado se encuentra revocado
Revocado no es lo mismo que vencido ni que dado de baja. Vencido significa que se acabó su plazo. De baja, que el emisor lo retiró de servicio. Revocado significa que se anuló antes de tiempo, y la causa típica es que la clave privada se comprometió o se sospecha que pudo hacerlo.
Es el único de los tres que obliga a revisar algo más que el certificado: si se revocó por compromiso, hay que averiguar qué pasó con la copia del archivo y con la contraseña que lo protege.
El estado se consulta en la lista de revocación o en el servicio de comprobación en línea que el propio certificado declara:
openssl x509 -in certificado.cer -noout -text | grep -A2 "CRL Distribution\|OCSP"
2335 · El documento electrónico ingresado ha sido alterado
El mensaje suena a manipulación y casi nunca lo es. Es la señal de un problema de canonicalización.
La firma se calcula sobre una representación exacta del XML. Si después de firmar algo vuelve a escribir el archivo, aunque el contenido «se vea igual», el resumen criptográfico deja de coincidir. Los sospechosos habituales son un formateador que indenta la salida, una librería que reordena atributos, un paso de registro que reescribe el documento, o un editor que cambia el fin de línea al abrirlo para revisarlo.
La regla que lo evita es simple: firmar tiene que ser la última operación sobre el XML antes de comprimirlo y enviarlo. Nada lo toca después, ni siquiera para verlo bonito.
2336 · Ocurrió un error en el proceso de validación de la firma digital
El cajón de sastre. La firma no valida y SUNAT no precisa por qué. Tres causas cubren la mayoría de los casos, y conviene revisarlas en este orden porque van de la más barata de comprobar a la más cara.
Primero, el certificado equivocado. Un certificado de servidor web no sirve para firmar comprobantes, y el rechazo tiene esta forma. Se descarta en medio minuto mirando el uso declarado del certificado, y el detalle está en certificado de firma o certificado SSL.
Segundo, la cadena incompleta. Si el archivo .pfx no incluye el certificado intermedio de la entidad emisora, el validador no puede llegar hasta la raíz de confianza:
openssl pkcs12 -in certificado.pfx -nokeys | grep -c "BEGIN CERTIFICATE"
Un solo certificado en la respuesta suele significar cadena incompleta.
Tercero, el algoritmo. Un certificado con SHA-1, o una firma calculada con un resumen que la norma ya no admite, se rechaza aunque todo lo demás esté bien. El artículo 1 de la Resolución de Superintendencia 097-2012/SUNAT pide SHA-2 y RSA de 2048 bits.
Los tres que se confunden entre sí
2326, 2327 y 2328 hablan del mismo objeto y de estados distintos, y en la conversación con soporte conviene usar la palabra correcta:
| Código | Estado | Quién lo provocó | Se arregla |
|---|---|---|---|
| 2326 | De baja | El emisor o el titular | Emitiendo uno nuevo |
| 2327 | Fuera de vigencia | El paso del tiempo, o el reloj del servidor | Renovando, o sincronizando la hora |
| 2328 | Revocado | Se anuló antes de tiempo | Emitiendo uno nuevo, y averiguando por qué se revocó |
Qué guardar antes de pedir ayuda
Cuando el diagnóstico propio se agota, estas cuatro cosas convierten una consulta de tres días en una de una hora: el XML tal como se envió, la respuesta completa de SUNAT con su código, el certificado público en formato .cer, y la hora exacta del intento con la zona horaria.
Sin el XML firmado no hay forma de saber si el problema fue la firma o lo que vino después, y es lo que casi nunca se conserva.
Si estás decidiendo qué certificado comprar o comprobando si necesitas alguno, la guía del certificado digital para facturación electrónica SUNAT cubre los requisitos, el certificado gratuito que entrega la propia SUNAT y qué preguntar antes de pagar.
Fuentes
- Catálogo de errores de facturación electrónica de SUNAT. Códigos y mensajes contrastados en mifact.net y appfact.pe.
- Resolución de Superintendencia 097-2012/SUNAT, artículo 1.
- RFC 5280, validación de la cadena de certificación.
Última revisión: 22 de agosto de 2026.