Skip to main content

Odoo and DGII electronic invoicing: how they actually connect

There is a claim going around that Odoo cannot meet DGII requirements. It is not accurate — and neither is the opposite. Here is what Odoo covers, what it does not, and what has to be added.

7 min read

If you are evaluating Odoo in the Dominican Republic you will meet two opposing claims, both incomplete. One says Odoo does not understand DGII rules and that its Dominican localisation depends on third-party modules. The other, usually from an implementer, says Odoo issues e-CF out of the box. There are three layers here and they are worth separating before signing anything.

Layer 1: what Odoo ships

Nothing Dominican. Odoo is an international ERP: its accounting, invoicing and taxes are generic, and each country is handled by a localisation package. This is equally true of Community and Enterprise — the edition changes nothing here, and that is the most expensive misunderstanding in the evaluation.

So "Odoo does not understand DGII rules" is literally true of the base product, and equally true of SAP, of Dynamics, and of any ERP not written in Santo Domingo. It is not an Odoo flaw; it is how multinational software works.

Layer 2: the Dominican localisation

It exists, it is open source, and it is maintained by the Dominican Odoo community. It supplies the DGII-aligned chart of accounts, ITBIS at 18 % and 16 %, withholdings, the legal service charge, NCF sequences by type, and the 606, 607, 608 and IT-1 filings.

Depending on community modules is not the same as being fragile, but it does change who answers when something breaks. With a community localisation, keeping it working across a version upgrade falls to your implementation partner, not to the vendor. That is a legitimate risk decision — take it with your eyes open rather than discover it during the first migration.

Layer 3: issuing e-CF to the DGII

This is where the project is decided. Issuing an e-CF is not printing a different document: you generate an XML in the current format, sign it with a digital certificate, transmit it to the DGII, receive and store the response, and handle rejections. And before any of that, the company must be authorised as an Emisor Electrónico.

The DGII recognises three routes: build your own issuing system, use the free invoicing tool, or work through an authorised Proveedor de Servicios de Facturación Electrónica. Odoo on its own is none of the three — it is the system the invoice comes from, and it has to connect to whichever route you choose.

How they fit together in practice

  1. Odoo remains the system where the operation happens: selling, shipping, invoicing, accounting.
  2. The Dominican localisation supplies the fiscal structure: accounts, taxes, withholdings, sequences and the 606, 607, 608 and IT-1 filings.
  3. Electronic issuance happens against the DGII, either through your own development or an authorised provider, depending on the route.
  4. The DGII response comes back into Odoo, because a rejected receipt is not an issued invoice and someone has to see it inside the system where they work.

What to settle before starting

  • Which issuing route you choose. It sets the recurring cost and who answers for a transmission failure.
  • Who maintains the localisation when the next major Odoo version ships. There is one a year.
  • How rejections are handled day to day, and by whom. That is the task that appears after go-live and that nobody budgets.
  • What happens in contingency if the DGII does not respond: the system must queue and retry, not stop invoicing.
  • If you already issue from another system, whether to move issuance into Odoo or leave it and integrate.

So does Odoo work or not?

It works, with the Dominican localisation in place and the issuing route settled. What does not work is buying Odoo expecting the fiscal side to be included, or contracting an e-CF certification expecting it to fix a badly configured ERP. The useful question is not whether Odoo complies, but who is accountable for it still complying two years and one version upgrade from now.

If that is the decision in front of you, each side is covered in Odoo implementation and e-CF electronic invoicing.

Frequently asked questions

The question is framed wrongly: the DGII does not authorise software. It authorises taxpayers as electronic issuers and certifies electronic invoicing service providers. Your company gets authorised; Odoo is the system you issue from. That is why certification runs against your real operation and cannot be inherited from a product.

No. The edition does not determine Dominican tax compliance: neither ships DGII regulation and both depend on the localisation. Choosing between Community and Enterprise comes down to modules, support and total cost — not e-CF.

Technically you can issue through the free tool while invoicing in Odoo, but it means keying every receipt twice and maintaining two sources of truth. It works at low volume; it stops working as soon as volume rises or somebody mistypes.

Authorised NCF sequences coexist during the transition and stop being used once you are authorised as an electronic issuer and move to production. The Odoo configuration has to cover both worlds during that period, not just the end state.

Odoo, e-CF, or both at once?

We review your operation and tell you what each layer needs, in what order, and what can run in parallel. If Odoo is already running, we start from there.

See our Odoo implementation service

Keep reading