La pregunta llega siempre igual: "compramos el token para el representante legal, ¿el sistema de facturación puede usar ese mismo certificado?". La respuesta corta es no, y no por una restricción del proveedor ni por una configuración pendiente. Es una consecuencia directa de cómo está construido el dispositivo.
Este artículo explica en detalle por qué el token no encaja con la emisión masiva de comprobantes electrónicos, qué intentos suelen hacerse para forzarlo y por qué fallan, y cuáles son las alternativas correctas.
Cómo firma un comprobante electrónico un sistema de facturación
La emisión de un comprobante electrónico en Ecuador implica generar el documento, firmarlo electrónicamente y enviarlo al SRI para su autorización. Ese ciclo lo ejecuta el sistema de facturación, normalmente en un servidor, y se repite por cada comprobante.
La característica que define el problema es que ese proceso no tiene una persona delante. Corre cuando se emite la venta, a la hora que sea, incluidos fines de semana y madrugadas, y en empresas con volumen puede repetirse cientos o miles de veces al día. El flujo completo está descrito en firma electrónica y facturación electrónica ante el SRI.
Por qué el token no puede resolverlo
Dos características del token, que en otros contextos son virtudes, aquí lo descartan:
- La clave privada no sale del dispositivo. El sistema no puede tomar el certificado, instalarlo en el servidor y firmar con él. No hay exportación posible, y esa es precisamente la garantía por la que se compra un token.
- Cada operación requiere presencia y PIN. El dispositivo tiene que estar físicamente conectado y desbloqueado por su titular. Un proceso automático no puede ingresar un PIN que, por definición, nadie más debe conocer.
Sumadas, estas dos características significan que el token no sirve para firma desatendida. No es una limitación de un modelo ni de un fabricante: es el formato. Los criterios de uso apropiado están en cuándo conviene el token en una empresa.
Los tres intentos habituales y por qué se caen
Antes de aceptar la respuesta, casi todas las empresas prueban alguno de estos caminos. Vale la pena conocer cómo terminan:
| Intento | Qué se hace | Por qué falla |
|---|---|---|
| Equipo dedicado con el token puesto | Un computador encendido de forma permanente, con el dispositivo conectado y desbloqueado | Se cae con cada reinicio, actualización o corte de energía; y deja la capacidad de firma disponible en un equipo sin vigilancia, anulando el control que motivó comprar el token |
| Concentrador USB o extensión hacia el servidor | Llevar el dispositivo físicamente hasta el rack | Sigue necesitando desbloqueo manual y agrega un punto de falla física; el problema de fondo no cambia |
| Redirección de USB por escritorio remoto | Exponer el token de una estación hacia una sesión remota | Depende de que la sesión esté abierta y de que alguien haya ingresado el PIN; cualquier desconexión detiene la emisión |
El patrón es el mismo en los tres: todos requieren que alguien haya desbloqueado el dispositivo y que nada se interrumpa. Funcionan en una demostración y fallan en producción, casi siempre el día de mayor facturación.
El problema de volumen, incluso si se pudiera
Supongamos que se resolviera el desbloqueo. Quedaría un segundo obstáculo: el rendimiento. El chip de un token está diseñado para firmas ocasionales de una persona, no para operaciones continuas de un servidor. En emisión masiva, con picos a fin de mes o en fechas de alta venta, el dispositivo se convierte en el cuello de botella del proceso, y una cola de comprobantes sin firmar es una cola de ventas sin documentar.
Cuando el volumen es el problema central, el enfoque correcto está en firma masiva en la nube para grandes volúmenes.
Las alternativas correctas
Para firma desatendida hay tres caminos válidos, y la elección depende del volumen y del marco de control interno:
| Opción | Cómo funciona | Cuándo conviene |
|---|---|---|
| Archivo .p12 en el servidor | El certificado en archivo, protegido con su contraseña y con acceso restringido | Volúmenes moderados; exige controles estrictos de acceso y custodia de la contraseña |
| Firma en la nube con integración | El sistema solicita la firma al servicio mediante una integración autorizada | Volúmenes medios y altos, sin infraestructura criptográfica propia |
| HSM | Un equipo criptográfico dedicado custodia la clave y firma bajo control de la empresa | Volúmenes muy altos o exigencias regulatorias de custodia interna |
El archivo .p12 es la opción más frecuente por su simplicidad, y también la que exige más disciplina: al ser copiable, el control depende enteramente de la empresa. Quién tiene acceso al servidor, dónde se guarda la contraseña y cómo se rota son decisiones que hay que tomar de forma explícita. La comparación completa entre esquemas está en token vs HSM vs firma en la nube y en HSM para corporativos.
Para la integración con el sistema de facturación, el detalle técnico está en API de firma para facturación masiva y en cómo automatizar la firma en tu ERP.
El esquema que sí funciona en una empresa
La arquitectura habitual no elige entre token y otro formato: usa los dos, para cosas distintas.
- Token para el representante legal, que firma actos societarios, poderes y documentos de alto impacto, con control máximo sobre quién puede firmar.
- Certificado en formato apto para automatización para el sistema de facturación, que emite comprobantes sin intervención humana.
Son dos certificados distintos y no es un gasto duplicado innecesario: son dos necesidades distintas. Intentar cubrir ambas con un solo dispositivo es lo que produce el equipo encendido en un rincón con el token puesto.
Cómo migrar sin cortar la emisión
Si tu empresa hoy sostiene la facturación con un esquema improvisado alrededor de un token, la transición se hace en cuatro pasos:
- Emitir el certificado apto para el proceso automatizado, a nombre de quien corresponda según la configuración del sistema.
- Configurarlo en un ambiente de pruebas y validar la emisión completa, incluida la autorización del comprobante.
- Cortar en un momento de baja emisión, con el esquema anterior disponible como contingencia hasta confirmar la estabilidad.
- Documentar el cambio en el inventario de certificados y liberar el token para su uso propio.
Si durante la migración aparecen rechazos, las causas más comunes están en firma rechazada por el SRI. Consulta valores actualizados de cada formato en la página de precios.
Azur: la facturación electrónica del grupo
Si además del certificado tu empresa necesita el sistema que emite, envía y custodia los comprobantes electrónicos, el grupo también desarrolla Azur, facturación electrónica autorizada por el SRI. Resuelve la emisión de facturas, notas de crédito y retenciones sin que la empresa tenga que sostener infraestructura propia. Puedes crear una cuenta en azur.com.ec/registro. El panorama de obligaciones está en obligados a facturación electrónica.
Omnifox: la conversación después del comprobante
El grupo también desarrolla Omnifox, plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja compartida por el equipo. Buena parte del trabajo posterior a la emisión —enviar el comprobante, atender un reclamo, confirmar datos de un cliente— ocurre por mensajería; centralizarla deja historial y responsable de cada gestión. Más información en omnifox.io.
Preguntas frecuentes
¿Puedo copiar el certificado del token al servidor de facturación?
No. La clave privada se genera dentro del chip y no se puede exportar. Para el servidor hay que emitir un certificado en un formato apto para ese uso.
¿Y si dejo el token conectado permanentemente en un equipo?
Técnicamente puede funcionar hasta el primer reinicio o corte, pero deja la capacidad de firma disponible sin supervisión y contradice la razón por la que se eligió un token. No es un esquema sostenible para producción.
¿El SRI exige un formato específico de certificado?
Lo que se exige es que el comprobante esté firmado electrónicamente con un certificado válido emitido por una entidad acreditada. El soporte donde reside la clave es una decisión técnica de la empresa.
¿Necesito dos certificados entonces?
En la práctica sí: uno para las personas que firman documentos y otro apto para el proceso automatizado. Cubren necesidades distintas y conviene presupuestarlos por separado.
¿Un archivo .p12 en el servidor es seguro?
Puede serlo si el acceso al servidor está restringido, la contraseña se custodia adecuadamente y existe control de quién puede leer el archivo. La responsabilidad de esos controles es de la empresa, a diferencia del token, donde la protege el hardware.
¿Qué pasa si el certificado del sistema de facturación vence?
La emisión se detiene. Por eso el control de vencimientos debe incluir explícitamente los certificados de sistemas, que son los que nadie recuerda porque no tienen una persona que reciba el aviso.
Si tu empresa necesita separar correctamente el certificado de sus firmantes del certificado de su sistema de facturación, conversa con un asesor de Firmas.com.ec. Cotiza tu plan corporativo.