SRI provider RUC
If your company issues electronic documents in Ecuador, there is a new field on them. The RUC Proveedor is the RUC number, Ecuador's tax identification number, of whoever provides the system you issue with. Since 26 September 2026 it goes in the additional information section of every invoice, credit note, debit note, withholding receipt, waybill and purchase settlement. Article 5 of Resolution NAC-DGERCGC26-00000027, from the SRI, Ecuador's tax authority, requires it.
The rule was written for a company that buys its invoicing system from an Ecuadorian vendor. If yours was bought abroad, or built in-house, there is no Ecuadorian RUC to report and you are still the one obliged to fill the field. Here is the answer case by case. And if you would rather have it done, I do it: the criterion documented with your accountant and the field configured and tested at the SRI, for USD 320 in two steps.
Resolution NAC-DGERCGC26-00000027, signed on 27 July 2026 and published the next day in the Fifth Supplement of Official Register 335, creates a register of providers of electronic invoicing systems and asks you, the issuer, for one new piece of data on every document.
The RUC number of the provider of the software system or of the electronic invoicing service, in the additional information section of the document. The SRI's ficha técnica 2.34, its technical specification for electronic documents, defines it in annex 26 as an additional field whose name is exactly "RUC Proveedor".
All the electronic ones: invoice, credit note, debit note, withholding receipt, waybill and purchase settlement. Article 5 speaks of electronic documents without distinguishing between types.
Sixty calendar days from publication, under the third transitory provision: 26 September 2026. It fell on a Saturday, so the first business day under the rule was Monday the 28th.
Whoever sells or licenses invoicing systems, and is domiciled in Ecuador or has a permanent establishment here, registers an exclusive establishment in the RUC under activity J62021002 or J62021003, within thirty days. The SRI publishes the list from October 2026 and updates it every month.
Article 5 of the resolution, word for word: «Los sujetos pasivos emisores de comprobantes electrónicos deberán incluir, en la sección de información adicional, el número de RUC del proveedor del sistema informático o servicios de facturación electrónica, conforme lo señalado en la Ficha Técnica de Comprobantes Electrónicos». That is: issuers of electronic documents must include, in the additional information section, the RUC number of the provider of the software system or electronic invoicing service, as set out in the ficha técnica. The Spanish is the text that binds. The full resolution and the ficha técnica.
Article 5 is worded in general terms, but it defers to the technical specification, and the specification narrows it: annex 26 directs the requirement at «contribuyentes emisores de comprobantes electrónico que utilicen sistemas de facturación electrónicos de terceros», issuers using third-party invoicing systems. Anyone issuing with a system nobody supplies them falls outside that sentence. Article 2, for its part, narrows who counts as a provider: only whoever commercialises the system and is domiciled in Ecuador or has a permanent establishment here. Out of that crossing come the clear cases and the ones that are not.
That vendor's RUC goes in: the company that sells or licenses you the system or the invoicing service. This is the case the rule was written for. Ask them for the RUC in writing and, from October, check that they appear on the SRI's list.
Clear case
Whoever develops for internal use is not a provider, because article 2 requires the purpose of commercialising. Nor do they use a third-party system, which is who annex 26 directs the requirement at: on the wording of the specification, this case falls outside it. The broad reading of article 5 would say otherwise, and until the SRI rules on it both readings coexist. If you would rather not be exposed, entering your own RUC complies without contradicting either. What is not advisable is deciding it without putting it in writing.
Documented criterion
It depends on who you pay. If the contract, the localisation and the support come from a partner with an Ecuadorian RUC, that partner may be the provider of the service. If you pay Odoo directly and nobody with an Ecuadorian RUC provides you the system, you are in the case below. As of 21 September 2026 I did not find Odoo publishing how to configure this field in its Ecuadorian localisation.
Documented criterion
A provider with no domicile and no permanent establishment in Ecuador falls outside the register: there is no Ecuadorian RUC of theirs to report. And you do use a third-party system, so the annex 26 requirement reaches you squarely. The rule did not close that gap. What closes it is a criterion written with your accountant, with the query to the SRI made and kept on file. This is the case that prompted this page: an Odoo 19 Enterprise bought in the United States.
Documented criterion
The field is a configuration parameter: the setup wizard writes it, it comes out in the additional information of every document, and the readiness checklist flags it in red if it is missing or is not a RUC. The value is still whichever one your case calls for. On my own company's production Odoo, the field carries my RUC.
Configurable
If it is not Odoo, your provider is the one who fills the field, and the RUC that goes in is theirs. What you can do is ask them in writing which RUC they are including and since when, and keep the answer.
Clear case
The reading of the cases with no express answer follows the analysis by AVL Abogados: it is not defined which RUC they should enter, although the reasonable thing would be their own. That is a reading, not a rule from the SRI. Which is why the criterion is documented and the query is made.
The resolution carries no penalty of its own. What it does is create a formal duty: it invokes article 96 of the Tax Code, which obliges taxpayers to meet the specific duties the tax administration sets, and failing a formal duty is penalised as a regulatory offence.
I did not find, in the ficha técnica or in the resolution, a rule saying the SRI rejects the document when the field is absent. What is written down is the duty, and with it the exposure to the penalty. And the public list of providers, which the SRI publishes from October 2026 within the first ten business days of each month, makes it possible to check which RUC corresponds to a registered system.
The way not to argue about it is to have the field in place and the criterion in writing before 26 September. If the date has already passed, what follows is to comply as soon as possible: every document that goes out without the field is a document outside the rule.
The field already comes configurable. It is written once in Settings, or the setup wizard writes it, and from there it comes out in the XML and in the RIDE of every document. Before the first real invoice, each type is authorised in the SRI's test environment and the authorised XML is read, not just the acknowledgement.
The first thing is to check which module generates the XML and whether it lets the field be configured. If it does, it is configured and tested at the SRI. If it does not, step 1 ends with the criterion documented, and you know exactly what to ask Odoo or your partner for.
The same review: which module signs and transmits, whether it exposes the additional information per document, and whether the maker has published the change. It is configured wherever the module allows it; where it does not, what is missing is written down.
Development on third-party modules, changes to other fields of the document, the electronic signature or its renewal, or the support of your system's maker. That falls outside the package and, if needed, is quoted separately.
A single package in two steps, because the second only happens if the first calls for it. The proposal is signed online from your portal and is valid for three days: the SRI's deadline sets the pace.
Includes: the review of your Odoo (version, plan and hosting, which module generates the documents and how they are signed and transmitted to the SRI) and the criterion for your case, settled with your accountant and documented in writing, with the query to the SRI and to your system's maker. With the criterion in hand, you decide whether step 2 follows. Paid on signature.
Includes: the "RUC Proveedor" field in the additional information of invoices, credit and debit notes, withholding receipts, waybills and purchase settlements, and each document type tested in the SRI's test environment before going to production. Paid when the tested configuration is handed over.
If the review shows the field should not be included, or that your Odoo does not allow it to be configured, the work ends with the documented criterion and you pay only the USD 120 of step 1.
Timing: the documented criterion within two business days of payment of step 1, and the tested configuration within five, provided I have access to your Odoo and your accountant's contact on the first day; if an access, or an answer from your accountant, from the SRI or from the maker, is delayed, the deadline moves by the same number of days. Prices in United States dollars; under my tax regime, RIMPE Negocio Popular, my services are invoiced with VAT at 0 %, so the figure is the final one. Guarantee: if you cancel within fourteen days of payment and before receiving the documented criterion, I return the USD 120 in full; if within thirty days of delivery the SRI rejects a document because of the configured field, I fix it at no cost. The decision to apply the criterion and the tax liability before the SRI remain your company's. Full conditions in the proposal and in the refund policy.
The RUC Proveedor is the most recent one, not the only one. These are already in force and your system has to meet them today, each with its source.
Since 1 January 2026 the document is transmitted to the SRI at the moment it is issued. Resolution NAC-DGERCGC25-00000014 removed the margin of "up to four business days" the 2018 rule allowed, and NAC-DGERCGC25-00000017 set 1 January 2026 as the date it applies. An Odoo with the transmission job switched off posts the invoice and never sends it.
Resolution NAC-DGERCGC26-00000009 set new income tax withholding rates at source, applicable from 1 March 2026, and allowed the withholding receipts of the first half of March to be issued until the 31st of that month while systems were being adjusted. It is stated in the SRI bulletin NAC-COM-26-014. The withholdings Odoo proposes when a purchase is recorded have to be on that table.
The version in force of the technical specification for electronic documents. Besides annex 26 for the RUC Proveedor, it carries the legend for the RIMPE regime that goes on the document (annex 22) and the catalogues of payment methods and taxes the XML has to use.
Providers of invoicing systems register their activity in the RUC and, from October 2026, the SRI publishes the list on its portal and updates it in the first ten business days of each month (articles 3 and 4 of Resolution NAC-DGERCGC26-00000027).
With the Issuing plan of electronic invoicing in Odoo Community, these changes are applied on your installation at no extra cost while the plan is active.
It is the RUC number of the company that provides you the system or the service you issue your electronic documents with. Since 26 September 2026 it goes in the additional information section of every document, as an additional field named "RUC Proveedor", under article 5 of Resolution NAC-DGERCGC26-00000027 and annex 26 of the SRI's ficha técnica 2.34.
It depends on the module that generates the XML. In Odoo 19 Community with my localisation it is a Settings parameter that the setup wizard writes and that comes out in the additional information of every document. In Odoo Enterprise and in other localisations you have to check whether the module exposes the field; that is the first thing I do in step 1.
The resolution only defines as providers those domiciled in Ecuador or with a permanent establishment here. A provider from abroad has no Ecuadorian RUC to report, and even so you are still obliged to include the field. The rule does not say what goes in that case: it is settled with your accountant, queried with the SRI and put in writing. That documented criterion is step 1, for USD 120.
Set it up as soon as possible: every document that goes out without the field is a document outside the rule. From payment of step 1, the documented criterion is within two business days and the configuration tested at the SRI within five, provided I have access to your Odoo and your accountant's contact on the first day.
I did not find, in the ficha técnica or in the resolution, a rule saying so. What is written down is the formal duty to include it, and failing a formal duty is penalised as a regulatory offence under the Tax Code. And if within thirty days of my delivery the SRI rejects a document because of the configured field, I fix it at no cost.
Only if you sell or license an invoicing system to third parties, and are domiciled in Ecuador or have a permanent establishment here. Whoever uses a system for their own operations, or built one for internal use and does not sell it, is an issuer and not a provider: article 5's field applies to them, not article 3's register.
As of 21 September 2026 I did not find Odoo publishing how to configure it in its Ecuadorian localisation. It may well exist without being published, and that is why step 1 starts by reviewing your Odoo rather than assuming. If your Odoo will not take it, you pay only the review and keep the criterion and the list of what to ask Odoo for.
08 /
Tell me which Odoo you issue with, where it is hosted and who you bought it from. I reply with the two-step proposal within one business day.
contacto@andresbrinez.comSix years building systems for companies in three countries: Colombia, Ecuador and Australia · Member of the Odoo Community Association