Firma electrónica para facturar: qué certificado necesitas y qué pasa cuando vence

Qué firma necesitas para facturar

El SRI lo dice sin rodeos: «Un comprobante electrónico tendrá validez legal siempre que contenga una firma electrónica», y la firma electrónica es el primero de los requisitos para facturar electrónicamente (facturación electrónica). La ARCOTEL, que regula a quienes emiten las firmas, también la pone como requisito obligatorio para emitir los comprobantes que autoriza el SRI (firma electrónica acreditada).

Lo que necesitas, en concreto:

• Un certificado de firma electrónica de tipo archivo. Es lo que pide el Facturador SRI: «Adquirir y mantener vigente un certificado de firma digital electrónica (tipo archivo)» (Facturador SRI). El archivo es un PKCS #12, con extensión .p12, y viene protegido con una clave.
• Emitido por una entidad de certificación acreditada. La ficha técnica del SRI pide certificados «adquiridos en cualquiera de las entidades de certificación autorizadas en el país» (secciones 2 y 4.2).
• Vigente el día en que firmas.

Quién está acreditado lo decide la ARCOTEL, que evalúa, acredita y controla a las entidades de certificación y mantiene su registro. Consulta siempre su listado oficial de entidades acreditadas: cambia con el tiempo, y es la única lista que vale.

El certificado tiene que ser de quien emite. Entre sus preguntas frecuentes, la ficha técnica recoge el rechazo «Firma inválida- No existe el RUC en el certificado digital» (sección 16): el SRI busca tu RUC en el certificado con el que firmaste.

Archivo .p12 o token

La norma técnica de la ARCOTEL distingue dos formas de entregar un certificado (artículo 6): en archivo, el .p12 (PKCS #12), y en un dispositivo seguro de creación de firma, que puede ser un dispositivo criptográfico como un token USB, un certificado remoto o en la nube, o una tarjeta criptográfica.

Para facturar, la diferencia importa:

• El Facturador SRI pide el de tipo archivo (página oficial).
• La ficha técnica pide un archivo PKCS #12 (.p12) como forma de intercambiar el certificado con el software que firma, y prevé dos maneras de que el software lo tenga: directamente, a través del token USB, o extraído e instalado en una carpeta de la que el software lo toma (sección 6.8).
• Un sistema que firma por ti necesita el archivo. Una API o un servidor firma cada comprobante en el momento en que se emite, a cualquier hora y sin nadie frente al computador. No hay dónde conectar un token: se trabaja con el .p12 y su clave.

Si vas a pedir tu firma para facturar, pídela en archivo. Si ya tienes una en token y la quieres usar para emitir desde un sistema, pregunta a tu entidad de certificación por un certificado en archivo.

Lo que la ficha técnica pide de la firma

Cada comprobante es un XML que lleva la firma adentro. Estos son los requisitos que fija la ficha técnica del SRI, versión 2.34:

El comprobante es válido una vez que el SRI lo autoriza (sección 6.1). Si firmas por tu cuenta, el detalle de cada nodo está en la guía de firma electrónica XAdES-BES.

Vigencia y vencimiento

Todo certificado trae su fecha de emisión y su fecha de expiración (Ley de Comercio Electrónico, Firmas y Mensajes de Datos, artículo 22). Lo que dura lo acuerdas con la entidad que te lo emite; si no se acuerda nada, se emite por dos años (reglamento de la ley, artículo 11).

Cuando llega su fecha de expiración, el certificado se extingue (ley, artículo 24). También se extingue si lo pide su titular, y puede suspenderse o revocarse en los casos que la ley señala (artículos 25 y 26).

Para la facturación electrónica, eso tiene dos consecuencias en la ficha técnica:

• Tu sistema no debería enviar comprobantes firmados con un certificado vencido. La sección 11 lista, entre las validaciones que debe hacer el sistema del contribuyente antes de enviar, el código 42, «Certificado revocado»: «Certificado que ha superado su fecha de caducidad, y no ha sido renovado».
• El SRI revisa la firma al autorizar. En la autorización valida «los documentos firmados electrónicamente (segunda validación a detalle con certificados de firma electrónica)» (sección 7), y el error 39, «Firma inválida», es el que corresponde a una firma electrónica del emisor que no es válida (sección 11).

Cómo anticiparte

• Anota la fecha. La ves en el propio certificado, o en la herramienta con la que lo usas.
• Atiende el aviso de tu entidad. La norma técnica de la ARCOTEL obliga a las entidades a avisarte de la caducidad por medios electrónicos con al menos 30 días de anticipación, en los certificados que duran un año o más (artículo 5, literal l).
• Renueva antes, no después. Pide el nuevo certificado con tiempo y cámbialo en tu sistema apenas lo tengas, sin esperar el último día.

Cómo se usa con una API

Con una API no firmas tú cada comprobante: subes tu .p12 y su clave una sola vez, y cada comprobante sale firmado con él. Así funciona en Fiscalbase, según su documentación:

• Antes de guardarlo, lo revisa: que la clave abre el archivo, que el certificado es de ese negocio (su RUC, o la cédula de la persona natural titular del RUC), que lo emitió una entidad de certificación acreditada y que está vigente hoy.
• Lo guarda sellado. Al recibirlo, lo sella junto con su clave con una llave pública; la API solo tiene esa llave, así que, una vez sellado, ni la API puede abrirlo. Solo el proceso que firma comprobantes tiene la llave privada, y abre el certificado únicamente para firmar. Nunca lo devuelve, ni el archivo ni la clave.
• Te avisa antes de que venza. La consola te avisa en la campana cuando tu certificado vence pronto y cuando ya venció, y también por correo (buscar y avisos). En la página Firma electrónica ves hasta cuándo vale y cuántos días le quedan, en ámbar cuando falta un mes o menos y en rojo si venció (tu negocio en la consola).
• El cambio no interrumpe tu emisión. Subes el nuevo cuando lo recibas, aunque el anterior siga vigente, y desde ese momento firma el más reciente.
• No emite con un certificado vencido. Si el más reciente vence, emitir en Pruebas o Producción responde 409 hasta que subas uno vigente, en lugar de aceptar un comprobante que no podría firmar.

Subir el certificado

Así se sube el certificado de un negocio con su API key de Pruebas. ENTITY_ID es el id de tu negocio, que GET /v1/ec/entities te devuelve con esa misma API key. El archivo pesa hasta 100 KB:

read -s CERTIFICATE_PASSWORD
curl -X POST https://api.fiscalbase.io/v1/ec/entities/$ENTITY_ID/certificates \
  -H "Authorization: Bearer fb_test_..." \
  -F "file=@firma.p12" \
  -F "password=$CERTIFICATE_PASSWORD"

read -s te pide la clave sin mostrarla ni dejarla en el historial de tu terminal.

La respuesta es un 201 con lo que dice el certificado: su titular y su cédula o RUC, quién lo emitió, su número de serie y su vigencia, en valid_from y valid_until. Nunca el archivo ni la clave.

Si el certificado ya venció, no se guarda. La respuesta es un 422 que dice desde cuándo:

{
  "type": "invalid_request",
  "title": "The certificate expired on 2024-12-31",
  "status": 422,
  "errors": [
    {
      "path": "certificate",
      "code": "expired",
      "expired_on": "2024-12-31",
      "message": "The certificate expired on 2024-12-31"
    }
  ]
}

Los otros motivos llegan con su propio code: wrong_password, not_a_certificate, no_private_key, tax_id_mismatch, not_yet_valid o issuer_not_recognized. Para revisar un archivo sin guardarlo, POST /v1/ec/entities/$ENTITY_ID/certificates/verify hace las mismas verificaciones.

Para practicar no necesitas nada de esto. Un negocio de Sandbox, el ambiente de práctica, firma con un certificado de práctica: subirle uno propio responde 422 con el código certificate_not_needed_in_sandbox. Tu certificado entra en juego cuando pasas a Pruebas, el ambiente de pruebas del SRI, y a Producción.

Errores del SRI ligados a la firma

Estos son los códigos de la ficha técnica (sección 11) que tienen que ver con el certificado o la firma. Todos los demás están en errores del SRI.

Entre sus preguntas frecuentes (sección 16), la ficha agrega variantes de «Firma inválida» con su causa:

• «La fecha de la firma es posterior a la actual»: el reloj del equipo que firma va adelantado. Los servidores del SRI toman la hora de un servidor NTP, así que sincroniza el tuyo y reenvía los comprobantes rechazados.
• «No existe el RUC en el certificado digital»: el certificado con el que firmaste no trae tu RUC.
• «El nodo comprobante no está firmado», «La estructura de la firma es incorrecta» y «La firma no corresponde con el contenido del documento»: la firma no sigue el estándar o el documento cambió después de firmarse. La ficha menciona caracteres extraños en los campos de texto como causa frecuente del último.

Lo que vimos en la práctica

El 30 de septiembre de 2026, el dueño de un RUC de persona natural subió su .p12 a Fiscalbase por la API, con la clave leída por read -s, para emitir en el ambiente de Pruebas del SRI. El 2 de octubre de 2026, con el certificado de ese negocio, emitimos un comprobante de cada uno de los seis tipos (factura, nota de crédito, nota de débito, comprobante de retención, guía de remisión y liquidación de compra), firmados con XAdES-BES. El SRI autorizó los seis en Pruebas en segundos, sin ningún mensaje.

Fuentes

• SRI, Facturador SRI: beneficios, requisitos y consultas
• SRI, Facturación electrónica: requisitos y ambientes
• SRI, Ficha técnica de comprobantes electrónicos, esquema offline, versión 2.34
• ARCOTEL, Firma electrónica acreditada
• ARCOTEL, Listado de las entidades de certificación de información acreditadas y terceros vinculados
• Ley de Comercio Electrónico, Firmas y Mensajes de Datos (publicada por la ARCOTEL)
• Reglamento General a la Ley de Comercio Electrónico, Firmas Electrónicas y Mensajes de Datos
• Norma técnica ARCOTEL-2024-0176 para las entidades de certificación