Cada factura, nota de crédito, retención o guía de remisión que una empresa ecuatoriana envía al SRI viaja firmada. Y no con cualquier firma: con una estructura XAdES incrustada dentro del propio XML del comprobante, con reglas precisas de canonicalización, referencias y atributos. Cuando esa estructura tiene un detalle fuera de lugar, el servicio de recepción devuelve el comprobante y el equipo de desarrollo se queda mirando un mensaje genérico.
Esta guía ordena lo que hay que saber para construir o depurar esa firma: qué se firma exactamente, cómo está armada la estructura, dónde se rompe con más frecuencia y qué conviene automatizar del lado del servidor.
Lo primero: se firma el XML, no el PDF
Es la confusión más común en proyectos nuevos. El documento electrónico es el XML. El PDF que recibe el cliente es su representación impresa: sirve para leerlo, no es el comprobante. La firma que el SRI verifica está dentro del XML y el respaldo tributario es ese archivo autorizado, junto con el número de autorización.
De ahí una consecuencia práctica: firmar el PDF del comprobante es opcional y no reemplaza nada. Si tu proyecto también necesita PDF firmados para otros documentos de la empresa, ese es otro camino y usa otro perfil, explicado en firmar PDF con PAdES desde tu backend.
Qué es XAdES y qué perfil pide el esquema ecuatoriano
XAdES es la especificación que extiende la firma XML estándar con los atributos necesarios para una firma electrónica avanzada: identificación del certificado firmante, momento declarado de la firma, políticas y, en niveles superiores, sellos de tiempo e información de revocación.
El esquema del SRI trabaja con firma enveloped: el bloque de firma queda dentro del mismo XML del comprobante, como elemento hijo del nodo raíz. No hay archivo aparte ni firma envolvente. La ficha técnica publicada por el SRI define los detalles exactos —algoritmos, formato de referencias y estructura esperada— y es la fuente que hay que consultar antes de codificar o de cambiar cualquier algoritmo, porque esas definiciones se actualizan con las versiones del esquema.
Anatomía de la firma dentro del comprobante
Sin entrar en el XML literal, la estructura tiene siempre las mismas piezas y entenderlas es lo que permite depurar:
| Pieza | Contiene | Falla típica |
|---|---|---|
| Información firmada | El método de canonicalización, el algoritmo de firma y la lista de referencias | Canonicalización distinta a la esperada |
| Referencia al comprobante | El resumen del documento con la transformación que excluye la propia firma | Olvidar la transformación de firma envuelta |
| Referencia a las propiedades firmadas | El resumen del bloque de atributos XAdES | Identificadores que no coinciden entre nodos |
| Referencia a la información de clave | El resumen del bloque con el certificado | Referencia ausente o apuntando a otro identificador |
| Valor de firma | El resultado criptográfico sobre la información firmada | Firmar el documento en vez del bloque de información firmada |
| Información de clave | El certificado del firmante en base64 y sus datos de clave pública | Certificado sin cadena o con saltos de línea mal colocados |
| Propiedades firmadas | Momento de firma, resumen del certificado y su emisor y serie | Emisor escrito con orden de campos distinto al del certificado |
La regla mental útil: hay tres resúmenes distintos y un solo valor de firma. Si el rechazo dice que la firma es inválida, casi nunca es la clave: es uno de esos resúmenes calculado sobre un contenido que ya no es idéntico al que quedó en el archivo.
Canonicalización: donde se rompe todo
El XML tiene formas equivalentes de escribir lo mismo: espacios entre atributos, orden de declaraciones de espacios de nombres, saltos de línea. Para que dos partes calculen el mismo resumen, el contenido se normaliza antes con un algoritmo de canonicalización. Si tu librería canoniza distinto de como lo hace el validador del otro lado, los resúmenes no coinciden y la firma se rechaza aunque todo lo demás esté perfecto.
Tres precauciones que resuelven la mayoría de los casos:
- No manipules el XML como texto después de firmar. Nada de reemplazos, ni de reindentar, ni de "limpiar" saltos de línea. Serializa una sola vez y guarda ese resultado.
- Cuida la codificación. El archivo debe conservar la codificación declarada de punta a punta; una conversión intermedia altera los bytes y con ellos el resumen.
- Declara los espacios de nombres de forma estable, en el mismo lugar, y evita librerías que los reubican al serializar.
Del XML firmado a la autorización
Firmar es solo el primer paso del ciclo. Después viene el envío al servicio de recepción, que responde si el comprobante fue recibido o devuelto, y luego la consulta de autorización, que devuelve el comprobante autorizado o los motivos del rechazo. Un integrador serio implementa los dos pasos con persistencia de estado, porque el segundo puede necesitar reintentos.
Conviene distinguir tres familias de rechazo, porque se atienden de forma distinta:
- Estructura: el XML no cumple el esquema. Es un error de generación, no de firma.
- Firma: la estructura es correcta pero la validación criptográfica falla, o el certificado no es aceptado. Aquí entran el certificado caducado, el revocado y los problemas de canonicalización.
- Negocio: clave de acceso repetida, secuencial fuera de rango, datos del emisor que no cuadran. No tienen relación con la firma.
El detalle de causas y salidas está en firma electrónica rechazada por el SRI, y el panorama general del régimen en firma electrónica y facturación electrónica ante el SRI.
Vigencia del certificado: el corte que nadie ve venir
Un certificado caducado detiene la facturación completa de la empresa, no un documento. Y el aviso llega en el peor momento: durante la emisión. Dos controles que todo sistema debería tener:
- Una verificación de vigencia al arrancar el proceso de emisión y una alerta programada con semanas de anticipación, no con días.
- Consulta de estado de revocación, sobre todo si hubo cambios societarios. Un cambio de representante legal obliga a revisar de quién es el certificado que está firmando. El mecanismo técnico está en validación OCSP y CRL en tiempo real.
Firma desatendida: certificado en el servidor
La facturación no admite que alguien conecte un token cada vez. El certificado tiene que estar disponible para el proceso, lo que abre la discusión de custodia: el certificado pertenece a una persona natural —normalmente el representante legal o un apoderado— y ponerlo en un servidor significa que la organización custodia su clave. Eso se resuelve con una política interna escrita y controles de acceso, no ignorándolo. Las medidas concretas están en firmar en servidor con .p12.
Cuando el volumen crece —cierres de mes, cadenas con muchos puntos de venta— la emisión debe salir del ciclo de la petición web y procesarse por lotes, tema de colas y workers para firma masiva. Y si además presentas anexos, revisa firma electrónica para el ATS y anexos del SRI.
Si no quieres construir el emisor
Desarrollar y mantener un emisor propio tiene sentido cuando la facturación está muy acoplada al negocio. Si no es el caso, el grupo también ofrece Azur, sistema de facturación electrónica autorizado por el SRI que resuelve la firma, el envío, la autorización y la entrega al cliente sin que tu equipo tenga que sostener el esquema. Puedes crear una cuenta en azur.com.ec/registro. Los certificados para el firmante se emiten en línea en aproximadamente 30 minutos; para planes por volumen consulta la página de precios.
Omnifox para el contacto con el cliente
El grupo desarrolla además Omnifox, plataforma omnicanal que integra WhatsApp, correo, redes y llamadas en una bandeja única. En operaciones de facturación resuelve un punto real: el envío del comprobante por el canal donde el cliente sí lee y la gestión de los reclamos de "no me llegó la factura" con historial por cuenta. Detalles en omnifox.io.
Preguntas frecuentes
¿Sirve cualquier certificado de firma electrónica para facturar?
Sirve un certificado vigente emitido por una entidad de certificación acreditada y que corresponda al emisor o a quien esté facultado para firmar por él. Lo que cambia es el formato de entrega: archivo, token o nube, según cómo vaya a operar tu sistema.
¿Puedo firmar los comprobantes con la firma de un empleado?
Debe firmar quien tenga facultad para hacerlo por el contribuyente. Usar el certificado de una persona sin esa facultad es un problema de control interno, además de generar líos cuando esa persona sale de la empresa.
¿Qué hago si el SRI devuelve "firma inválida"?
Empieza por lo más probable: vigencia del certificado, transformación de firma envuelta y manipulación del XML después de firmar. Si el archivo se modificó por un reemplazo de texto o una reindentación, el resumen ya no coincide.
¿Necesito sello de tiempo en los comprobantes?
El esquema del SRI trabaja con el momento de firma declarado y la autorización lleva su propia fecha. El sello de tiempo de una autoridad es una capa adicional útil en otros documentos, no un requisito de este flujo.
¿Cada punto de venta necesita su propio certificado?
No necesariamente. El comprobante lo firma el contribuyente, no el local. Lo que se define es cuántas instancias del sistema van a firmar en paralelo y cómo se custodia la clave en cada una.
Si necesitas certificados vigentes para tu emisor de comprobantes, o renovar los que están por vencer, habla con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.