Por qué el SRI sigue aceptando XML y no JSON en Ecuador

Si vienes del mundo de las APIs REST, lo natural cuando te toca integrar facturación electrónica en Ecuador es preguntarte lo mismo que se preguntan casi todos los desarrolladores que empiezan: ¿por qué el SRI sigue pidiendo XML y no acepta JSON?

La respuesta corta: el SRI publica los esquemas oficiales en XSD y expone web services SOAP (RecepcionComprobantesOffline y AutorizacionComprobantesOffline), y la factura debe estar firmada con XAdES-BES — un estándar de firma digital que vive únicamente sobre XML. Cambiar a JSON significaría rehacer el modelo de firma, los esquemas, los WSDLs y la infraestructura de validación del SRI y de miles de softwares contables y ERPs ya conectados.

La respuesta larga es interesante porque combina decisiones históricas, restricciones criptográficas reales, y la influencia del estándar UBL en toda Latinoamérica. Te la cuento sin atajos.

El SRI no es un caso raro: toda LATAM usa XML

Antes de pensar en por qué Ecuador no usa JSON, conviene mirar a los vecinos. Todos los países de la región con facturación electrónica obligatoria usan XML como formato de comprobante:

JSON no aparece en ninguno de estos esquemas oficiales. No es coincidencia: cuando estos países diseñaron sus sistemas (entre 2003 y 2014, dependiendo del país), el estándar internacional para intercambio B2G —es decir, empresa a gobierno— era XML. Y se quedó.

Razón 1: la firma digital del SRI vive sobre XML

Esta es probablemente la razón técnica más fuerte. El SRI exige que cada comprobante electrónico se firme con XAdES-BES (XML Advanced Electronic Signatures, perfil Basic Electronic Signature), un estándar publicado por ETSI que solo existe para documentos XML.

XAdES-BES no es una elección estética. Resuelve cosas concretas:

• Integridad sobre nodos XML específicos, no sobre el archivo completo. Puedes firmar <factura> sin firmar la envoltura.
• Canonicalización (c14n) del XML antes del hash, para que cambios cosméticos (espacios, orden de atributos) no rompan la firma.
• Inclusión del certificado del firmante, política de firma y rol — todo dentro del propio XML.
• Compatibilidad legal con la Ley de Comercio Electrónico, Firmas y Mensajes de Datos del Ecuador, que reconoce la firma electrónica como equivalente a la manuscrita siempre que cumpla con estos perfiles.

¿Y JSON? Tiene su equivalente, JSON Web Signature (JWS), definido en el RFC 7515. Pero JWS llegó cuando el SRI ya tenía su esquema en producción y, más importante: JWS firma payloads enteros, no nodos selectivos, y nunca alcanzó adopción tributaria en LATAM. Hoy ninguna agencia tributaria de la región acepta JWS como firma válida de un comprobante fiscal.

Para el SRI, migrar a JSON implica redefinir desde cero el modelo de firma. Y eso no se hace por gusto cuando ya tienes millones de comprobantes diarios autorizándose sin fricción.

Razón 2: los esquemas XSD ya están en producción y son la “fuente de verdad”

El SRI publica oficialmente los XSD (XML Schema Definition) de cada tipo de comprobante: factura, nota de crédito, nota de débito, retención, guía de remisión y comprobante de pago. La Ficha Técnica de Comprobantes Electrónicos Esquema Off-line va por la versión 2.32 (actualizada en noviembre de 2025) y describe todos los campos, formatos, longitudes y reglas de negocio que valida el web service.

Un XSD te da algo que JSON Schema solo logró años después y con menor soporte de herramientas: validación automática y exhaustiva en cualquier lenguaje, sin escribir una línea de código de validación manual. Si tu XML cumple el XSD, el SRI sabe que tiene los campos correctos en el orden correcto con los tipos correctos.

Cambiar a JSON exige:

1. Reescribir todos los XSD como JSON Schema.
2. Republicar la ficha técnica.
3. Probar que los millones de comprobantes diarios siguen funcionando.
4. Esperar a que los miles de softwares contables, ERPs, POS, integraciones bancarias y SDKs migren.
5. Mantener ambos esquemas en paralelo durante años para no romper a nadie.

El costo es enorme. El beneficio para el SRI es marginal — el formato no es lo que limita la facturación electrónica en Ecuador, ni lo que la hace mejor o peor.

Razón 3: SOAP era el estándar B2G cuando se diseñó el sistema

El SRI lanzó su primer esquema de facturación electrónica en 2012-2014. En esa época, el patrón establecido para servicios gobierno-empresa era SOAP sobre HTTPS con WSDL, no REST con JSON. Los web services del SRI siguen ese patrón:

• RecepcionComprobantesOffline?wsdl — envías el XML firmado, te responde RECIBIDA o DEVUELTA.
• AutorizacionComprobantesOffline?wsdl — consultas con la clave de acceso de 49 dígitos, te responde AUTORIZADO, NO AUTORIZADO o EN PROCESO.

SOAP en 2014 era la opción defensiva: contratos fuertes (WSDL), transacciones tipadas, herramientas maduras (Apache CXF, .NET WCF, Axis2). Hoy, REST+JSON es lo dominante para B2C y B2B, pero para B2G —donde necesitas garantías formales, auditoría y firma criptográfica— XML+SOAP sigue siendo la norma en muchas agencias tributarias del mundo, no solo en Ecuador.

Curiosamente, la propia ARCA en Argentina (ex AFIP) sí expone algunos endpoints REST que aceptan JSON, pero el comprobante mismo se sigue armando como XML internamente, porque la firma sigue siendo XAdES.

Razón 4: el estándar regional es UBL 2.1, y UBL es XML

Cuando Colombia, Perú y República Dominicana modernizaron sus esquemas, no inventaron un formato propio: adoptaron UBL 2.1 (Universal Business Language), un estándar publicado por OASIS y reconocido como ISO/IEC 19845.

UBL es XML. Solo XML. No tiene una variante en JSON oficial. Y los catálogos de códigos, tipos de documento, monedas y tributos están todos pensados para coexistir con un esquema XML.

Ecuador no usa UBL puro —tiene su esquema propio—, pero la estructura conceptual es muy similar (cabecera + información tributaria + detalles + totales + información adicional), y el SRI ha alineado sus actualizaciones con la dirección que toma la región. Migrar a JSON significaría alejarse de ese estándar regional, no acercarse.

Lo que sí cambia en 2026: transmisión en tiempo real (pero sigue siendo XML)

A partir del 1 de enero de 2026, la Resolución NAC-DGERCGC25-00000017 estableció que todos los comprobantes electrónicos deben transmitirse al SRI en el mismo momento en que se generan. Se acabó el esquema diferido donde podías acumular comprobantes durante el día y enviarlos en lotes.

Pero —y aquí está el punto— la transmisión en tiempo real no cambia el formato. Sigue siendo:

• XML estructurado según los XSD oficiales.
• Firmado con XAdES-BES.
• Enviado al web service SOAP.
• Validado contra el mismo esquema y devuelto autorizado.

Lo que cambió es la latencia operativa, no la representación de datos. Los softwares de facturación que ya estaban al día con la versión 2.32 de la ficha técnica no tuvieron que cambiar su lógica de generación de XML — solo su orquestación para enviar en el momento de emisión y no en batch al final del día.

Entonces, ¿cómo trabajo desde mi app si no quiero tocar XML?

Aquí está la buena noticia para los developers que vienen del ecosistema JSON/REST: no necesitas hablar XML directamente con el SRI. Los proveedores tecnológicos autorizados —Factuplan entre ellos— exponemos APIs REST que reciben JSON desde tu lado y se encargan de:

1. Construir el XML según el esquema del SRI.
2. Firmarlo con tu certificado P12 (XAdES-BES).
3. Enviarlo al web service SOAP.
4. Hacer polling al endpoint de autorización.
5. Devolverte el resultado en JSON con la clave de acceso, el número de autorización y el RIDE en PDF.

Esto es lo que internamente llamamos Modo A en nuestra API. Tú mandas algo así:

{
  "customer": {
    "identificationType": "RUC",
    "identification": "0993378150001",
    "legalName": "Empresa Demo S.A."
  },
  "items": [
    {
      "code": "SERV-001",
      "description": "Servicio de consultoría",
      "quantity": 1,
      "unitPrice": 150.0,
      "taxType": "IVA_RATE",
      "tax": 15
    }
  ],
  "payments": [
    { "method": "20", "amount": 172.5 }
  ]
}

Y nosotros nos encargamos del XML, la firma, el SOAP y la conversación con el SRI. La capa REST/JSON existe del lado del proveedor; el SRI sigue recibiendo XML. Es lo mejor de los dos mundos: tu stack se mantiene moderno y el SRI mantiene su esquema estable.

Si te interesa cómo aprovechar esto en una integración limpia, mira la guía de API whitelabel para emitir facturas sin enviar correos al cliente.

¿Y si en el futuro el SRI sí adopta JSON?

Es posible, pero improbable a corto plazo. Para que pase, harían falta tres cosas en orden:

1. Que aparezca un estándar internacional de firma JSON ampliamente adoptado en tributario — hoy no existe equivalente real a XAdES.
2. Que UBL publique una variante JSON oficial — hay borradores en OASIS, pero ninguno con tracción tributaria.
3. Que la región se mueva primero o en paralelo — el SRI sigue las decisiones de DIAN, SUNAT y SAT más de lo que las lidera.

Es más probable que el SRI siga puliendo el esquema actual (ya pasó de la versión 2.26 a la 2.32 en pocos meses), añadiendo campos para nuevas casuísticas tributarias —como el IVA del 5% y del 8% en feriados turísticos—, que migrar el formato base.

Mientras tanto, si vas a integrar facturación electrónica en Ecuador, la decisión correcta es construir tu app en JSON y delegar el XML al proveedor tecnológico. Es lo que la mayoría de devs hacen hoy y es lo que mantiene el código mantenible.

Tabla resumen: XML vs JSON en el SRI

Tip para developers: si estás evaluando integrar facturación electrónica en Ecuador y dudas entre construir tu propio cliente SOAP+XAdES o usar un proveedor, calcula el costo total: armar y mantener el firmador XAdES, la conexión SOAP, los reintentos, los webhooks de cambios de estado y la migración a cada nueva versión de la ficha técnica se vuelve un trabajo a tiempo completo. Si tu producto no es “ser proveedor del SRI”, delega esa capa a quien sí lo es.

Si quieres profundizar en cómo se firma un XML del SRI y qué diferencia hay entre tu firma electrónica en archivo vs token, lee la comparativa entre firma electrónica en token o archivo en Ecuador 2026 y la diferencia entre firma digital y firma electrónica.