SRI real-time en Ecuador: qué exige Odoo en 2026

Por qué SRI real-time en 2026 cambia el stack

Desde el 1 de enero de 2026, cualquier factura electrónica en Ecuador debe llegar al SRI en el momento de su emisión. No en 4 días hábiles, sino al instante. Si la cola se atasca, el cajero de un restaurante en Guayaquil no cierra el turno, un distribuidor en Quito no despacha mercancía y el cliente se queda sin RIDE válido para deducir IVA. No es teoría: es la realidad operativa de cientos de miles de PYMES, y la mayoría de las instalaciones de Odoo en el país no están arquitectónicamente preparadas.

En 2025 el SRI publicó la Resolución NAC-DGERCGC25-00000014, eliminando la ventana de 4 días hábiles para autorización de comprobantes. La reforma NAC-DGERCGC25-00000017 precisó las reglas de anulación, notas de crédito y débito, y el consentimiento del receptor. Punto de entrada en vigor: 1 de enero de 2026.

La vieja arquitectura "lo mandamos de noche en lote" se rompió. Buena parte de los módulos OCA l10n_ec, escritos para Odoo 12-15, operan bajo el esquema "el cron cada 15 minutos junta los unsent invoices y los manda al SRI". Hoy eso equivale a una balsa con fugas: si la integración cae un minuto, el cliente no tiene factura válida; si cae una hora, no puede operar.

Este artículo es para CFO, contadores y directores de TI de PYMES que ya entendieron que SRI real time no es una "mejora de compliance" sino una dependencia crítica del stack operacional. Revisamos qué cambió exactamente en la normativa, qué módulos de Odoo aguantan la carga, dónde se rompe la arquitectura en serio y qué arreglar primero.

Resumen en un minuto

• Desde el 1 de enero de 2026 el SRI exige transmisión inmediata de todos los comprobantes electrónicos. Normativas base: resoluciones NAC-DGERCGC25-00000014 y NAC-DGERCGC25-00000017.
• Ventana de anulación: hasta el día 7 del mes siguiente. Después, solo nota de crédito con justificación retroactiva.
• Consentimiento del receptor para cancelaciones y notas de crédito/débito: 5 días hábiles; el silencio se considera aceptación.
• Odoo con OCA l10n_ec en versiones 14-16 es inviable sin reescribir la lógica de cron a queue.job. Enterprise 17/18 está más cerca de funcionar out-of-the-box.
• La arquitectura debe aguantar picos: pagos con datáfono en hora pico = decenas de requests por segundo, hacen falta cola, retry y flujo de contingencia.
• El middleware (Datil, Ecuafact, Edicom) reduce riesgo, pero suma USD 0.02–0.05 por documento y atrae vendor lock-in.

Qué cambió: cronología y normativas

Hasta fines de 2025, Ecuador operaba con un modelo de "autorización diferida". El negocio emitía la factura en su sistema, imprimía el RIDE (Representación Impresa del Documento Electrónico) y lo entregaba al cliente. El emisor tenía hasta 4 días hábiles para enviar el XML al SRI y recibir la autorización con clave de acceso. Si caía internet, se caía el servidor o se olvidaba el contador, el lote del día podía mandarse hasta el cuarto. No había multas. El SRI aguantaba la carga porque el tráfico entrante se distribuía de manera pareja.

En 2025 el SRI publicó la Resolución NAC-DGERCGC25-00000014. Cambio clave: el comprobante se considera válido solo cuando el SRI devuelve respuesta en el momento de la emisión. La ventana de 4 días desaparece. El API síncrono del SRI se vuelve dependencia directa de la operación.

Meses después salió la reforma NAC-DGERCGC25-00000017. Añadió dos elementos nuevos:

1. Sliding window de anulación: una factura puede anularse hasta el día 7 del mes siguiente. Después, solo nota de crédito. Si emites el 15 de enero, puedes anular hasta el 7 de febrero. El 8 ya es tarde.
2. Confirmación del receptor: para anular o emitir notas de crédito/débito, hace falta el consentimiento explícito del receptor vía portal SRI. El silencio durante 5 días hábiles se considera aceptación. Un rechazo explícito deja el documento válido y obliga a otro workflow.

El SRI desplegó nuevos webservice endpoints bajo este régimen. Las URLs siguen siendo conocidas (celcer.sri.gob.ec para piloto, cel.sri.gob.ec para producción), pero el SLA pasó de responder en horas a responder en milisegundos. La carga productiva en enero de 2026 fue de decenas de millones de transacciones diarias. Los sistemas del SRI se estabilizaron recién en marzo: las primeras semanas hubo quejas masivas por 503 y timeouts, algo que confirman las noticias locales y el análisis de HLB Ecuador.

Requisitos técnicos: lo que Odoo debe hacer

#1. Stack base

l10n_ec no es un módulo: es una familia.

• l10n_ec_account — plan de cuentas, impuestos, catálogo de RUC.
• l10n_ec_account_edi — generación y firma de documentos XML.
• l10n_ec_edi_email — envío del RIDE por email al cliente.
• l10n_ec_withhold — retenciones (específico de Ecuador, obligatorio en la mayoría de transacciones).
• l10n_ec_reports — ATS (Anexo Transaccional Simplificado), Formulario 103, Formulario 104.

En Enterprise edition desde la versión 17, los módulos se entregan como l10n_ec_edi e integrados al framework Account EDI de Odoo. En OCA hay que instalar repositorios aparte y vigilar compatibilidad de versiones — sobre todo queue_job y account_edi.

#2. Certificado y firma

Para el régimen real-time son críticos tres puntos:

1. Certificado .p12 vigente y registrado en Odoo. La verificación de expiración no está automatizada en todas partes — se necesita un script Monit o un chequeo Nagios.
2. Firma XAdES-BES del lado servidor, no del cliente. Velocidad de firma: 50–200 ms en un servidor estándar. Esa es la cota inferior de latencia.
3. Envoltorios CDATA para campos de descripción con caracteres UTF-8. Causa frecuente de rechazo del SRI en producción: una comilla curva (’) o una ñ en el nombre del producto.

#3. Arquitectura de envío

Old way (cron en lote):

ir.cron cada 15 min →
  account.move.search([state=posted, edi_state=to_send]) →
  loop: firmar → enviar → guardar response.

Eso se rompe bajo el SLA real-time. Patrón nuevo:

account.move.action_post() →
  inmediato: firmar → enviar al SRI →
    success: edi_state=sent, permitir impresión del RIDE
    failure: queue.job retry con exponential backoff →
      fallback: modo de contingencia (claves de contingencia).

Esto exige reescribir los hooks _post_validate_edi en Odoo, especialmente para POS. En Odoo POS, la mayoría de módulos OCA presuponen deferral, incompatible con real-time. La solución pasa por una pre-validación del estado del servicio SRI antes de abrir el turno y un fallback a claves de contingencia ante outage detectado.

#4. Cola y reintentos

Para una PYME con flujo de 500+ facturas/día:

• queue_job (OCA) con al menos 2 procesos worker para el channel l10n_ec.
• retry_pattern con exponential backoff (10s, 30s, 2min, 10min, 1hr).
• Alerta en Slack o Telegram si la cola supera 50 unsent más de 5 minutos.
• Dead-letter queue para documentos rechazados por contenido (no error temporal) — revisión manual.

#5. Modo de contingencia

El SRI permite operar offline mediante claves de contingencia. El documento recibe una clave específica, se entrega al cliente, y al SRI se envía cuando se restablece la conexión. Es legal pero limitado: solo cuando se confirma indisponibilidad del servicio SRI (no del internet local). Técnicamente, en Odoo:

• Cron que chequea el health-endpoint del SRI cada minuto.
• Switch automático a modo contingencia si 3 chequeos consecutivos fallan.
• Log del switch con timestamp para auditoría.
• Auto-recovery con vaciado del backlog por la misma cola.

#6. Versiones de Odoo

Si hoy estás en Odoo 14-15 y mueves más de 100 facturas/día, la migración es crítica — no "cuando se pueda".

Cuándo funciona, cuándo no

Real-time SRI es un contrato técnico, no una frase de marketing. Cinco escenarios reales:

Escenario 1: restaurante en Quito, 150 facturas por turno, Odoo 17 EE. Funciona. El POS de Odoo con l10n_ec_edi queda sincronizado; la latencia media de autorización ronda 800–1500 ms y en hora pico (almuerzo, cena) sube a 3 segundos. El terminal espera respuesta antes de imprimir el RIDE. Los usuarios se acostumbraron a la pausa entre "pagado" y "comprobante".

Escenario 2: e-commerce, 3000 transacciones/día, Odoo 16 + integración custom. Funciona con trade-offs. El cliente paga con tarjeta → la página de confirmación muestra "factura en proceso". En background, queue.job envía al SRI con latencia media de 5–15 segundos. El RIDE llega por email entre 30 y 60 segundos después. La UX se reescribió para que la factura no bloquee la página de "gracias por tu compra".

Escenario 3: distribuidora, 800 facturas/día, Odoo 15 + middleware Datil. Funciona, pero sale caro. Datil cobra USD 0.03–0.05 por documento. Sobre 24.000 documentos/mes son USD 720–1.200 adicionales al hosting y a Odoo. La solución escala, la economía sufre. Si el CFO no lo calculó, recalcúlenlo.

Escenario 4: manufactura con notas de crédito de 100+ líneas, Odoo 17 OCA. Se rompió. La lógica vieja del módulo OCA para notas de crédito no contempla el flujo de confirmación del receptor. Cada anulación de contrato comercial queda en pending y el contador revisa a mano en el portal SRI. La auditoría encontró USD 50.000 de revenue mal contabilizado en un trimestre: notas emitidas en Odoo, no confirmadas por el receptor, inválidas para el SRI. Solución: reescribir el workflow y sincronizar con el consultation API del SRI una vez al día.

Escenario 5: microempresa RIMPE Popular, 30 facturas/mes. No la cubre Odoo. RIMPE Popular (ingresos menores a USD 20.000/año) es un régimen tributario simplificado. Real-time es formalmente obligatorio, pero en la práctica los microemisores trabajan vía el portal SRI gratuito o la app móvil. Implementar Odoo ahí es overkill.

Si tu escenario se parece al 1 o al 3, la configuración aguanta. Si se parece al 4, tienes un compliance-risk activo hoy mismo.

Cinco errores típicos de migración

Error 1: "Un cron cada 15 minutos ya es real-time enough". No. El SRI considera real-time el momento de recepción del XML, no el momento en que la cola está lista para enviar. Cron cada 15 minutos = latencia media de 7,5 minutos. Eso no es real-time. En una auditoría del SRI aparecerán facturas con un timestamp de emisión y otro de recepción separados por minutos — falta formal. Solución: queue_job + trigger inmediato desde action_post().

Error 2: "El certificado no venció, todo bien". A menudo el certificado está vigente, pero la contraseña en Odoo no coincide (la cambiaron en Banco Central y se olvidaron de actualizar Odoo). El servicio falla en silencio — el job en queue_job queda en "error: invalid signature". El contador no lo mira hasta fin de mes, cuando ve 200 unsent comprobantes. Solución: cron semanal con firma de prueba y alerta ante fallo.

Error 3: ignorar el modo de contingencia. Muchos creen que real-time = siempre online. No es así — el SRI también se cae (hubo un caso en febrero de 2026 con 3 horas de downtime). Sin flujo de contingencia, el negocio pierde el turno. Solución: switch automático y pool de claves de contingencia obtenidas del SRI con antelación.

Error 5: confiar en el módulo OCA sin tests de integración. OCA es una base excelente, pero l10n_ec lo actualiza la community y no siempre cubre los edge cases. Hemos visto instalaciones en producción donde l10n_ec_account_edi no enviaba notas de débito — el módulo presuponía solo factura y nota de crédito. El negocio se enteró 3 meses después. Solución: tests de integración para los 5 tipos de comprobantes (factura, nota crédito, nota débito, retención, guía de remisión) en el entorno UAT del SRI (celcer.sri.gob.ec).

Caso: distribuidor en Cuenca, enero 2026

Cliente anonimizado: distribuidor de repuestos en Cuenca, 4 bodegas, flujo de 800 facturas/día, Odoo 15 community con integración l10n_ec hecha en casa.

Enero 2026, semana 1: rejection rate del 40%. El SRI responde "timeout" o "document not received within expected window". La contabilidad en shock: 320 facturas/día quedan en estado no autorizado. Llaman los clientes: "sin autorización no puedo deducir IVA". Los gerentes emiten facturas en preimpresos para no parar la despachada.

Diagnóstico: el cron _send_to_sri corre cada 10 minutos. El nuevo endpoint del SRI exige stream, no batch. Un lote de 80 documentos en una sola transacción retorna 503 — el SRI procesa síncrono. La firma casera no soporta XAdES-BES, usa XMLDsig obsoleto. El certificado está vigente, pero la contraseña se cambió en diciembre y no se actualizó en Odoo.

Solución (3 semanas):

1. Migración a Odoo 18 EE con localización activa.
2. Reescritura del flujo POS para envío síncrono con timeout de 5 s.
3. Instalación de queue_job con 4 workers y retry-pattern (10s, 1min, 5min, 30min, FAIL).
4. Conexión de Datil como backup (failover ante downtime del SRI).
5. Actualización del certificado .p12 y healthcheck automático.

Resultado a 30 días: success rate de 99.7%, latencia media de 1.2 s, tiempo del contador en reconciliación −35%, errores de deducibilidad de IVA en clientes = 0. Costo del proyecto: USD 18.500 (migración + integración + 30 días de soporte). ROI: multas evitadas + 1 FTE de contabilidad = payback en 4 meses.

Qué sigue

SRI real-time es higiene básica de 2026 en Ecuador, no una ventaja competitiva. Si tu Odoo aguanta, bien. Si no, no es solo un tema de compliance: bloquea la operación.

Materiales relacionados:

• Odoo en Ecuador — guía completa para PYMES
• Auditoría Odoo: framework diagnóstico de 30 minutos
• Implementación Odoo: checklist para PYME
• Rescate Odoo: cuando la implementación falló
• Odoo + Analytics: BI sobre el ERP
• SUNAT 2026 en Perú — paralelos y diferencias con SRI
• SII 2026 en Chile — el modelo real-time que lleva 20 años funcionando
• DIAN 2026 — Colombia y la nómina electrónica

Preguntas frecuentes