Electronic invoicing in Ecuador: how it really works

In Ecuador, "invoicing" stopped meaning printing a paper: today it means generating a file, signing it with a certificate and transmitting it to the Servicio de Rentas Internas. Nearly everyone interacts with the result, a PDF arriving by email, without ever seeing the document that legally exists. This guide explains the whole mechanism, with the rules that hold it up.

What an electronic receipt really is

An electronic receipt is a data message in XML format, electronically signed by its issuer. It is not a PDF that looks like an invoice: it is a structured text file with the fields the SRI requires, and what gives it value is the signature it carries inside.

That equivalence with paper is not a market convention: it is in the law. The electronic commerce law provides that data messages "shall have the same legal value as written documents" (art. 2), and the receipts regulation authorizes issuing receipts that way: it requires them to carry "the electronic signature of whoever issues them" and grants them "the same value and legal effects" as physical ones.

Ley de Comercio Electrónico, Firmas Electrónicas y Mensajes de Datos (Law 2002-67, Registro Oficial supplement 557, April 17, 2002), art. 2 · Reglamento de Comprobantes de Venta, Retención y Documentos Complementarios (Executive Decree 430, Registro Oficial 247, July 30, 2010), Sixth General Provision.

The six documents of the scheme

The electronic scheme covers more than the invoice. Six documents are issued this way, and it pays to tell them apart because each does a different job:

• Invoice. Backs the sale of goods or the rendering of services.
• Credit note. Voids or reduces an already issued invoice (a return, a later discount, an error).
• Debit note. Increases the value of an already invoiced operation (interest, surcharges).
• Withholding receipt. Certifies the tax a withholding agent deducts at the moment of paying.
• Dispatch guide. Supports the physical transport of merchandise between two points.
• Purchase settlement. Issued by the buyer when the seller cannot issue an invoice.

An invoice's path, step by step

1. The XML is generated. The issuer's system builds the file with the operation's data following the structure the SRI publishes in its technical sheet for electronic receipts.
2. The access key is computed. Forty-nine digits that identify the document uniquely and, in the current scheme, double as the authorization number.
3. It is signed. With the issuer's electronic signature certificate, the .p12 file that contains it. The signature is embedded in the XML itself.
4. It is delivered to the customer. Here lies the key of the so-called offline scheme: the receipt is valid from the moment it is issued signed, without waiting for the SRI's reply. As the SRI itself puts it, authorization is no longer requested document by document; the administration authorizes ex officio whoever holds the obligation.
5. It is transmitted to the SRI, which validates and authorizes it. If something does not square (a nonexistent RUC, a bad calculation, an expired signature), it comes back not authorized and the issuer must fix and resend it.

That order explains an everyday situation: receiving an invoice still showing "in processing". The document already exists and was already delivered; what is missing is the SRI's sign-off, which normally arrives in seconds.

The 49-digit access key

It is each receipt's unique identifier and it is not a random number: it is built by joining data from the document itself, among them the issue date, the receipt type, the issuer's RUC, the establishment and issuing point that generate it, and its sequential number. The last digit is a check digit computed over the previous 48: if it does not square, the key is invalid and the receipt is rejected.

In practice, the access key is all that is needed to recover a receipt: it is printed under the RIDE's barcode, travels in the delivery email and stands inside the XML.

Structure and check digit: Ficha Técnica de Comprobantes Electrónicos (offline scheme), published and versioned by the Servicio de Rentas Internas.

The RIDE: the PDF everyone calls "the invoice"

RIDE stands for Representación Impresa del Documento Electrónico: the readable version, in PDF or on paper, of a receipt that legally lives as XML. It is what gets handed to the customer, filed in a folder and attached to an expense report.

Worth having clear, because it is the classic argument with accounting: the RIDE represents the receipt, it does not replace it. A perfect PDF of an XML that was never authorized supports nothing; that is why, when the accountant asks for "the XML", they are asking for the document, not a copy.

The rules on issuing, delivery and transmission under the electronic receipts scheme stand in Resolution NAC-DGERCGC18-00000233 (Registro Oficial second supplement 255, June 5, 2018), amended several times since.

Who is required, and since when

The obligation was built in stages over a decade, until it became general. The decisive leap came with the Ley Orgánica para el Desarrollo Económico y Sostenibilidad Fiscal after the COVID-19 pandemic (Registro Oficial supplement 587, November 29, 2021), which ordered whoever was already required to issue invoices to join the electronic scheme within a year.

The SRI implemented it with Resolution NAC-DGERCGC22-00000024 (Registro Oficial second supplement 80, June 9, 2022), which set November 29, 2022 as the deadline for those issuing invoices without yet being required to do so electronically.

The exception is the RIMPE small businesses (negocios populares), which issue sales notes, a simpler receipt than the invoice. RIMPE is the regime that same 2021 law created for lower-income taxpayers, and its other bracket, the entrepreneurs, does invoice electronically. On each company profile of this directory, the tax status block shows the regime and category it holds with the SRI.

July 2026: the provider's RUC goes inside the receipt

The most recent change and the one most people will notice in their system. Resolution NAC-DGERCGC26-00000027, published in the Registro Oficial of July 28, 2026, creates a mandatory registry of invoicing software and service providers, with two practical consequences:

• For whoever sells invoicing software: they must register in their RUC an establishment and an economic activity exclusive to that line, within thirty days of publication.
• For whoever issues receipts: within the following sixty days, every receipt must include, in the additional information section, the RUC of the invoicing system or service provider being used.

The SRI, for its part, will publish monthly on its portal the directory of registered providers. If a third party issues your invoices, now is the moment to ask for their RUC and confirm their system is already adding that field.

Seven years keeping XML

Sales receipts, complementary documents and withholding receipts must be kept for a minimum term of seven years. Whoever issues electronically does not have to issue copies, provided they keep the documents' information for that same term, counted from issuance.

The practical consequence gets underestimated: what must be kept is the authorized XML, not the PDF. An archive of PDFs does not meet the obligation, because it allows verifying neither the signature nor the authorization.

Reglamento de Comprobantes de Venta, Retención y Documentos Complementarios, art. 41 (amended by Executive Decree 99, Registro Oficial 467, December 29, 2023).

The three ways to issue

All end up producing the same signed XML; what changes is the effort and the control.

• The SRI's free invoicing tool. It serves low volumes and costs nothing. In exchange, it is a separate application: it does not connect with your sales system or your inventory.
• A commercial invoicing system. The usual option for a business with a point of sale or its own accounting. From 2026 on, check that your provider is registered with the SRI and that its RUC shows on your receipts.
• An API, from your own software. An API is a connection that lets your program issue the invoices by itself. It is the path when invoicing has to happen inside something else (an online store, the company's management system, a booking system) and you want nobody transcribing anything by hand.

Whichever the route, one piece cannot be skipped: the electronic signature certificate. Without it there is no valid XML, and not every certificate works. We explain it in the guide on the electronic signature. And if what you need is to check a receipt you received, the procedure is in how to tell if an invoice is authentic.