SRI real-time in Ecuador: what Odoo needs in 2026

Why SRI real-time in 2026 changes the stack

As of January 1, 2026, every electronic invoice in Ecuador must reach the SRI at the moment it is issued. Not within 4 business days — immediately. If the queue stalls, a Guayaquil restaurant cashier can't close the shift, a Quito distributor can't ship product, and the customer has no valid RIDE to deduct VAT. This isn't theory. It's the daily reality for hundreds of thousands of SMBs, and most Odoo installations in the country are not architecturally ready.

In 2025 the SRI published Resolución NAC-DGERCGC25-00000014, eliminating the 4-business-day window for authorizing comprobantes. The follow-up reform NAC-DGERCGC25-00000017 tightened the rules around cancellations, credit and debit notes, and recipient consent. Effective date: January 1, 2026.

The old "ship it overnight in batch" architecture broke. Most OCA l10n_ec modules, written for Odoo 12–15, run on a "cron every 15 minutes picks up unsent invoices and ships them to the SRI" pattern. Today that is a leaky raft: if the integration goes down for a minute the customer has no valid invoice; if it goes down for an hour, the customer can't operate.

This piece is for CFOs, controllers, and IT directors of SMBs who have already accepted that SRI real time is not a "compliance improvement" — it is a critical dependency of the operating stack. We walk through exactly what changed in the regulation, which Odoo modules hold up under load, where the architecture actually breaks, and what to fix first.

One-minute summary

• Starting January 1, 2026 the SRI requires immediate transmission of every comprobante electrónico. Base regulations: NAC-DGERCGC25-00000014 and NAC-DGERCGC25-00000017.
• Cancellation window: until the 7th of the following month. After that, only a credit note with retroactive justification.
• Recipient consent for cancellations and credit/debit notes: 5 business days; silence equals acceptance.
• Odoo on OCA l10n_ec versions 14–16 is not viable without rewriting cron logic into queue.job. Enterprise 17/18 comes closer to working out of the box.
• The architecture must absorb peaks: card-terminal payments at rush hour mean dozens of requests per second — queue, retry, and a contingency flow are mandatory.
• Middleware (Datil, Ecuafact, Edicom) reduces risk but adds USD 0.02–0.05 per document and introduces vendor lock-in.

What changed: timeline and regulation

Through the end of 2025, Ecuador operated under a "deferred authorization" model. The business issued the invoice in its system, printed the RIDE (the printed representation of the electronic document), and handed it to the customer. The issuer had up to 4 business days to send the XML to the SRI and receive authorization plus a clave de acceso. If the internet went down, the server crashed, or the accountant forgot, the daily batch could be sent on day four. No fines. The SRI absorbed the load because incoming traffic was evenly spread.

In 2025 the SRI published Resolución NAC-DGERCGC25-00000014. The key change: a comprobante is valid only once the SRI responds at the moment of issuance. The 4-day window is gone. The SRI's synchronous API becomes a direct operational dependency.

A few months later came the NAC-DGERCGC25-00000017 reform. It added two new elements:

1. Sliding cancellation window: an invoice can be canceled until the 7th of the following month. After that, credit note only. Issue on January 15 and you can cancel until February 7. February 8 is too late.
2. Recipient confirmation: to cancel or issue credit/debit notes, the recipient must explicitly consent via the SRI portal. Silence for 5 business days counts as acceptance. An explicit refusal leaves the document valid and forces a different workflow.

The SRI rolled out new webservice endpoints for this regime. The URLs are still familiar (celcer.sri.gob.ec for the pilot, cel.sri.gob.ec for production), but the SLA shifted from hours to milliseconds. Production load in January 2026 was tens of millions of transactions per day. The SRI systems only stabilized in March — the first weeks brought widespread complaints about 503s and timeouts, as local reporting and the HLB Ecuador analysis confirm.

Technical requirements: what Odoo must do

#1. Base stack

l10n_ec is not one module — it's a family.

• l10n_ec_account — chart of accounts, taxes, RUC catalog.
• l10n_ec_account_edi — XML document generation and signing.
• l10n_ec_edi_email — RIDE email delivery to the customer.
• l10n_ec_withhold — withholdings (Ecuador-specific, mandatory for most transactions).
• l10n_ec_reports — ATS (Anexo Transaccional Simplificado), Form 103, Form 104.

In Enterprise edition from version 17 on, the modules ship as l10n_ec_edi integrated with the Odoo Account EDI framework. On OCA you have to install separate repositories and watch version compatibility — especially queue_job and account_edi.

#2. Certificate and signing

Three things are critical for real-time:

1. Valid .p12 certificate registered in Odoo. Expiration monitoring is not automated everywhere — you need a Monit script or Nagios check.
2. XAdES-BES signing on the server side, not the client. Signing time runs 50–200 ms on a standard server. That sets the latency floor.
3. CDATA wrappers for description fields with UTF-8 characters. A common cause of SRI rejection in production: a curly apostrophe (’) or an ñ in a product name.

#3. Send architecture

Old way (batch cron):

ir.cron every 15 min →
  account.move.search([state=posted, edi_state=to_send]) →
  loop: sign → send → store response.

This breaks under a real-time SLA. New pattern:

account.move.action_post() →
  immediate: sign → send to SRI →
    success: edi_state=sent, allow RIDE print
    failure: queue.job retry with exponential backoff →
      fallback: contingency mode (claves de contingencia).

This requires rewriting the _post_validate_edi hooks in Odoo, especially for POS. In Odoo POS, most OCA modules assume deferral, which is incompatible with real-time. The fix is a pre-validation check of the SRI service status before opening the shift, with a fallback to claves de contingencia on detected outage.

#4. Queue and retry

For an SMB pushing 500+ invoices per day:

• queue_job (OCA) with at least 2 worker processes on the l10n_ec channel.
• retry_pattern with exponential backoff (10s, 30s, 2min, 10min, 1hr).
• Slack or Telegram alert if the queue holds more than 50 unsent items for over 5 minutes.
• Dead-letter queue for documents rejected for content (not transient errors) — manual review.

#5. Contingency mode

The SRI permits offline operation through claves de contingencia. The document gets a specific clave, is delivered to the customer, and is sent to the SRI once connectivity recovers. This is legal but limited: it's only available during confirmed SRI service downtime (not local internet issues). Technically, in Odoo:

• Cron checking the SRI health endpoint every minute.
• Automatic switch to contingency mode after 3 consecutive failed checks.
• Logged switch with timestamp for audit.
• Auto-recovery that drains the backlog through the same queue.

#6. Odoo versions

If you're on Odoo 14–15 today with more than 100 invoices per day, migration is critical — not "someday".

When it works, when it doesn't

Real-time SRI is a technical contract, not a marketing line. Five real-world scenarios:

Scenario 1: Quito restaurant, 150 invoices per shift, Odoo 17 EE. Works. The Odoo POS with l10n_ec_edi stays synchronized; average authorization latency sits at 800–1500 ms, climbing to 3 seconds at peak (lunch, dinner). The terminal waits for the response before printing the RIDE. Users adjusted to the pause between "paid" and "receipt".

Scenario 2: e-commerce, 3,000 transactions per day, Odoo 16 + custom integration. Works, with trade-offs. The customer pays by card → the confirmation page shows "invoice processing." In the background, queue.job ships to the SRI with 5–15 second average latency. The RIDE lands in the customer's email 30–60 seconds later. The UX was rewritten so the invoice never blocks the "thanks for your order" page.

Scenario 3: distributor, 800 invoices per day, Odoo 15 + Datil middleware. Works, but it's expensive. Datil charges USD 0.03–0.05 per document. At 24,000 documents per month, that's USD 720–1,200 on top of Odoo and hosting. The solution scales; the economics suffer. If the CFO hasn't run the numbers, run them.

Scenario 4: manufacturer with 100+ line credit notes, Odoo 17 OCA. Broken. The legacy OCA module logic for credit notes doesn't account for the recipient confirmation flow. Every commercial contract cancellation lands in pending status and the accountant manually checks the SRI portal. Audit found USD 50,000 of mis-stated revenue in a single quarter — notes were issued in Odoo, the recipient never confirmed them, and the SRI treats them as invalid. Fix: rewrite the workflow and sync against the SRI consultation API once a day.

Scenario 5: micro-business on RIMPE Popular, 30 invoices per month. Odoo doesn't cover it. RIMPE Popular (revenue under USD 20,000 per year) is a simplified tax regime. Real-time is formally required, but in practice these micro-issuers work through the free SRI portal or the mobile app. Deploying Odoo here is overkill.

If your scenario looks like 1 or 3, the configuration holds. If it looks like 4, you have an active compliance risk right now.

Five common migration mistakes

Mistake 1: "A cron every 15 minutes is real-time enough." No. The SRI defines real-time as the moment of XML receipt, not the moment the queue is ready to send. A 15-minute cron means an average 7.5-minute latency. That isn't real-time. An SRI audit will surface invoices with an issuance timestamp and a reception timestamp minutes apart — that's a formal violation. Fix: queue_job + immediate trigger from action_post().

Mistake 2: "The certificate isn't expired, we're fine." The certificate is often valid, but the password in Odoo doesn't match (changed at the Banco Central, never updated in Odoo). The service fails silently — the queue_job task sits at "error: invalid signature". The accountant doesn't notice until month-end when 200 unsent comprobantes pile up. Fix: weekly cron with a test signature, alert on failure.

Mistake 3: ignoring contingency mode. Many teams assume real-time means always online. It doesn't — the SRI goes down too (a February 2026 outage lasted 3 hours). Without a contingency flow, the business loses the shift. Fix: automatic switch plus a pool of claves de contingencia obtained from the SRI in advance.

Mistake 5: trusting an OCA module without integration tests. OCA is a strong base, but l10n_ec is community-maintained and doesn't always cover edge cases. We've seen production installations where l10n_ec_account_edi didn't send debit notes — the module only assumed invoices and credit notes. The business found out 3 months later. Fix: integration tests for all 5 comprobante types (factura, credit note, debit note, withholding, transport guide) against the SRI UAT environment (celcer.sri.gob.ec).

Case: Cuenca distributor, January 2026

Anonymized client: auto-parts distributor in Cuenca, 4 warehouses, 800 invoices per day, Odoo 15 community with a home-grown l10n_ec integration.

January 2026, week 1: 40% rejection rate. The SRI returns "timeout" or "document not received within expected window." Accounting is in shock: 320 invoices per day stuck unauthorized. Customers call: "without authorization I can't deduct VAT." Managers issue invoices on pre-printed forms just to keep shipments moving.

Diagnosis: the _send_to_sri cron runs every 10 minutes. The new SRI endpoint requires stream, not batch. A batch of 80 documents in one transaction returns 503 — the SRI processes synchronously. The home-grown signer doesn't support XAdES-BES; it uses obsolete XMLDsig. The certificate is valid, but the password was changed in December and never updated in Odoo.

Solution (3 weeks):

1. Migration to Odoo 18 EE with the active localization.
2. POS flow rewritten for synchronous submission with a 5 s timeout.
3. Installed queue_job with 4 workers and a retry pattern (10s, 1min, 5min, 30min, FAIL).
4. Connected Datil as backup (failover during SRI downtime).
5. Updated the .p12 certificate plus an automated healthcheck.

Result at 30 days: 99.7% success rate, 1.2 s average latency, accountant reconciliation time −35%, customer VAT deductibility errors = 0. Project cost: USD 18,500 (migration + integration + 30 days of support). ROI: avoided fines plus 1 FTE of accounting work — payback in 4 months.

What's next

SRI real-time is basic hygiene for 2026 in Ecuador — not a competitive advantage. If your Odoo holds up, good. If it doesn't, this isn't just a compliance issue: it blocks operations.

Related reading:

• Odoo in Ecuador — full guide for SMBs
• Odoo audit: 30-minute diagnostic framework
• Odoo implementation: SMB checklist
• Odoo rescue: when the implementation failed
• Odoo + Analytics: BI on top of the ERP
• SUNAT 2026 in Peru — parallels and differences with the SRI
• DIAN 2026 — Colombia and electronic payroll

FAQ