Odoo in Uruguay: DGI, CFE 25-1, and the l10n_uy localization

01 One-minute summary

Uruguay is the only LATAM economy with investment-grade ratings from all three major agencies and runs one of the region's pioneer e-invoicing systems (CFE since 2012). On March 3, 2026, every CFE issuer must migrate to format 25.1 — and the l10n_uy module in Odoo arrives only partially ready. Here is what the deadline means for SMBs that invoice on Odoo, and how to close the gap before DGI cuts the lights.

• By March 3, 2026, every CFE issuer in Uruguay must use the 25.1 format — this is a technical XML schema migration, not a cosmetic patch.
• Key 25.1 changes: mandatory linking of Notas de Crédito to the original CFE with amount, currency, and exchange-rate validation; GTIN/EAN on retail line items; new logistics fields for export invoicing (VUCE integration); Sales mode 91 for export-on-behalf; and restrictions on the IVA Mínimo and Monotributo regimes.
• The l10n_uy module in Odoo Community and Enterprise covers basic DGI functionality, but full 25.1 compatibility on most installations lags behind — this is a textbook compliance-audit zone before the deadline.
• The Uruguayan Odoo market is small and premium: typical implementation ticket of USD 10,500 – 52,000, one official Gold partner (Nexit) serving 3.4 million residents.
• SMB tax orbit: IVA básico 22% and IVA mínimo 10%, IRPF Categoría I and II, IRAE annual with inflation adjustment, BPS monthly. All covered, but requires careful l10n_uy setup plus OCA modules or in-house extensions.

02 Why Uruguay is a special case for Odoo

Uruguay runs the most mature e-invoicing system on the continent. The regime is essentially universal and the macro picture supports long-horizon planning — but it also enforces a more conservative sales cycle. Before talking about Odoo, it helps to understand what CFE is and why its new 25.1 release goes well beyond a patch on the XML.

#1. The most mature e-invoicing system in the region

Uruguay launched mandatory electronic invoicing in 2012, five to seven years ahead of most of LATAM. The CFE (Comprobante Fiscal Electrónico) system runs under the DGI (Dirección General Impositiva) and covers five document types: e-Factura, e-Ticket, e-Remito, e-Resguardo, and e-Boleta de Entrada, each with their own credit and debit notes.

Today the regime is universal: every IVA and IRAE taxpayer must issue CFE through certified software or DGI's free CREA CFE service (for micro-volumes). The IVA Mínimo, Monotributo, and Monotributo MIDES CAE regimes are restricted — they cannot issue CFE on behalf of third parties.

The macro context adds nuance. Per FocusEconomics and BBVA Research, Uruguay is the only country in the region with investment-grade ratings from all three major agencies, 2026 GDP is projected between 1.8% and 2.4%, and inflation sits within the BCU's target band (4.5% – 5.0%). Allianz Trade confirms low country risk. Stability buys long-horizon planning but also a more conservative sales cycle: Uruguayan SMBs do not respond to fast-talking presentations.

#2. What changes with the CFE 25.1 format

In September 2025 the DGI published the 25.1 format specification. It is not a cosmetic XML tweak — it is a package of validations that tightens control over:

• Notas de Crédito linked to their original CFE: MontoTotal, TipoMoneda, and TasaCambio on the original document are now compared — any discrepancy gets rejected;
• use of standard GTIN/EAN codes on retail line items;
• new logistics fields on export invoices for VUCE (Ventanilla Única de Comercio Exterior) integration — Incoterm, transport mode, and destination country in structured form;
• Sales mode 91 — Mandating Export, introduced for specific export-on-behalf cases (detailed breakdown by Datalogic);
• stricter checks on the link between e-Factura and e-Remito when references are used.

Timeline:

03 What the Odoo Uruguay localization actually covers

The Odoo technical landscape for Uruguay layers four parts: the standard l10n_uy module, OCA contributions, middleware that talks to DGI, and custom extensions for industry specifics. Knowing where each layer ends prevents false expectations during the compliance audit.

#1. The l10n_uy base module

Out of the box, l10n_uy in Odoo Community and Enterprise ships:

• a chart of accounts for Uruguay aligned with NIIF (DGI's NIC adaptation);
• core tax types: IVA básico 22%, IVA mínimo 10%, IVA exento;
• setup for IRPF Categoría I (dependent labor) and a baseline structure for Categoría II (professional services);
• structure for the CFE types: e-Factura, e-Ticket, e-Remito, e-Resguardo;
• mapping of document and counterparty types to DGI codes.

What the standard module does not include:

• ready integration with DGI web-services (requires third-party wiring or middleware);
• automatic retrieval of the CAE (Constancia de Autorización de Emisión);
• legal templates for every CFE type with the complete set of required fields;
• BPS logic (monthly Banco de Previsión Social contributions) — covered by OCA modules or custom work;
• full handling of the e-Boleta de Entrada.

#2. OCA and custom extensions

The Uruguayan track inside the OCA (Odoo Community Association) repositories is active but compact. There are point modules on GitHub for depositary checks (conformes) and payroll extensions with Uruguayan specifics, but no all-in-one OCA bundle exists for the country.

The largest Gold partner in the country — Nexit — has built a proprietary closed localization package that many large implementations rely on. This explains why even mature Enterprise installations still need extra work: the "box" covers 70 to 80% of scenarios, the rest goes to custom code or the partner package.

#3. Middleware for DGI

Unlike Peru or Chile, where Odoo talks to the regulator through a standard web-service, Uruguay's landscape is fragmented. Most production installations rely on middleware:

• Pyxis (local, Montevideo);
• Datalogic (one of the largest local providers);
• Gosocket (regional, multi-LATAM — convenient for SMBs operating across several countries);
• Edicom, Sovos — for the enterprise segment.

The middleware choice drives license cost, the speed at which 25.1 support lands, and the SLA on incidents. By March 2026 not every connector will be equally ready — this is a critical technical decision worth verifying before migrating, not after.

#4. Multi-currency and the BCU rate

Uruguay is a heavily dollarized economy: a meaningful share of B2B contracts and all exports run in USD, occasionally EUR. Odoo supports multi-currency out of the box, but DGI requires that the exchange rate on the CFE issue date matches the rate from the BCU (Banco Central del Uruguay). The default Odoo setup pulls rates from public sources (ECB, Yahoo Finance) — for compliance the BCU API should be wired in directly, or the middleware should pull the official rate automatically. A 0.20 – 0.50 UYU/USD spread looks minor, but it produces visible IVA discrepancies when the quarter closes.

04 When Odoo works in Uruguay — and when it does not

Not every project needs Odoo, and not every SMB is ready to keep it running. Before buying licenses, place the use case in one of the three buckets below. If it matches the left column, the investment is worth pursuing; if it lands on the right, rethink the spend or commission an audit first.

#1. Works when...

• You are an SMB of 20 to 150 employees that has outgrown Memory + Pyme or Conty and needs a full ERP with manufacturing, inventory, and project management — not just accounting.
• You are a software house or digital business with clients in the US and Europe: you need multi-currency, bilingual reporting (ES/EN), MRR/ARR tracking — local tier-1 systems do not reach that bar.
• You are an exporter (dairy, meat, timber, wine, honey) and you need lot traceability, VUCE integration, multi-currency, and BI by margin per kilo or unit. Per Rio Times, the agroexport sector remains the main 2026 GDP driver.
• You run a hospitality or services business in Punta del Este, Colonia, or Montevideo with OTA integration and multi-channel pricing — you need a PMS-like module sitting on top of the ERP.

#2. Expensive or hard when...

• You are a micro-business on Monotributo with fewer than 5 CFE per month — CREA CFE is enough, Odoo is overkill.
• You expect a boxed l10n_uy with no custom work — this is not realistic; the 25.1 migration will demand adjustments on almost any install, as the LLB Solutions guide shows.
• You need weekly on-site support in Montevideo — most international partners and remote consultants do not provide it; line up a local resource and budget for it from day one.
• You have SAP-tier compliance demands (Big-4 audit, SOX, full IFRS audit trail) — Odoo handles it, but consulting overhead can exceed SAP B1 plus a local partner at the same volume.

#3. Does not work when...

• You operate under IVA Mínimo or Monotributo MIDES CAE and want to issue CFE on behalf of third parties — DGI prohibits this regardless of software; it is not an Odoo problem.
• You drag a legacy custom build on FoxPro or Visual Basic 6 with 15+ years of patches — migration is possible, but this is not "Odoo in 3 months"; it is a 9–12 month project including data migration and team retraining.
• You need highly specific vertical modules (for example, dairy lab analysis with INALE-standard integration) and have no custom budget — a local vendor with an off-the-shelf sector solution will be cheaper.

05 Five common mistakes when implementing Odoo in Uruguay

The same mistakes repeat — and every one costs double when it surfaces two months before the DGI deadline. Each item below comes from a real installation that broke. Before signing the project scope, make sure the partner explains how they cover all five fronts.

#1. Ignoring middleware dependency until 25.1

This is the textbook pattern: an SMB buys an Odoo Enterprise license, installs l10n_uy, and assumes the 25.1 migration "will happen automatically with the 17.x or 18.x release". It does not work like that — the middleware provider (Pyxis, Datalogic, Gosocket) has to independently update XML schemas, validations, and mappers. If the middleware does not arrive by March 3, 2026, Odoo cannot issue a valid CFE no matter how fresh the module is.

What to do: by end of January 2026 request a written confirmation of the 25.1 support version from your provider, a test account, sample XML, and run end-to-end emission plus acceptance in the DGI test environment.

#2. Notas de Crédito without a link to the original CFE

Under 25.1 the DGI tightens validation: a credit note without a link to a specific e-Factura or e-Ticket with matching amount, currency, and exchange rate gets rejected. On many installations this breaks the "cancellation process" because the previous version of Odoo allowed loose credit notes for corrections.

What to do: before migration, run an audit of every credit note from the last 6 months — locate the loose ones, restore links to their original CFE, verify currency and exchange-rate match. Document the cancellation procedure in an SOP.

#3. Multi-currency without the BCU rate

SMBs enable multi-currency, plug in the ECB or Yahoo Finance rate, and start issuing CFE in USD. DGI requires the BCU rate on the issue date. The 0.20 – 0.50 UYU/USD spread looks small — but at quarter-end the IVA mismatch leads to recalculations and, eventually, DGI questions.

What to do: wire the BCU API directly or configure the middleware to pull the official rate. Daily, not weekly — especially on volatile FX days.

#4. No GTIN/EAN in the product catalog

Under 25.1, DGI tightens the retail requirement to include standard GTIN/EAN codes on line items. Many SMBs run products with internal SKUs and no GTIN mapping. Clean this up before the deadline — otherwise lines get rejected or flagged as "non-standard".

What to do: audit the product.template catalog for the barcode field (GTIN-13), validate uniqueness, and map missing codes through GS1 Uruguay.

#5. "Implementation = just IVA 22%" — ignoring IRPF and BPS

Many partners implement l10n_uy with a narrow focus on IVA and CFE, and leave payroll calculation, IRPF Categoría II (withholding on services), and BPS on the legacy bookkeeping software or in Excel. This creates a dual source of truth and reconciliation gaps at month-end close.

What to do: include the payroll module with Uruguayan rates and BPS in scope from day one. It adds 20–30% to the budget, but it pays back within 6 months from eliminating manual reconciliation and withholding mistakes.

06 Case: dairy exporter migration

Anonymized case from the Uruguayan dairy sector (cheese production for export, ~95 employees, shipments to Brazil, Paraguay, and the United States).

Starting point: Memory + Pyme + a custom cheese-production module (8 years of implementation) + Excel for traceability (milk → tank → curd → container) + an external CFE issuer. Pain points:

• manual reporting to INALE (Instituto Nacional de la Leche);
• CFE in USD with exchange-rate gaps (the system pulled the previous day's close rather than the BCU rate on the issue date);
• an IRAE with fixed-asset revaluation error of UYU 1.8M caught at the 2023 close;
• settlement of 14 producer partners through paper payment ledgers.

What was done (5 months): migration to Odoo 17 Enterprise with Manufacturing, Quality, Inventory, l10n_uy + custom extensions. End-to-end traceability from supplier farm to customer container. CFE integration through Datalogic middleware, automatic BCU rate. Mobile app for milk intake at the farm with offline sync. Automated producer settlement based on dry solids with quality bonus and BROU transfers.

Results: INALE 2024 audit cleared on the first pass; container-to-farm traceback dropped from 6 hours to 8 minutes; producer settlement moved from 5 days per month to an automatic run at close; DGI rejections went from 6% to 0% by month two; the IRAE revaluation error was identified and corrected (UYU 1.8M saved at the 2024 close); month-end close dropped from 16 to 4 days.

Investment: USD 38,000 in year one, USD 14,000 from year two (including middleware license and SLA).

"The day the BCU rate started loading by itself was the day the back office stopped asking at 11am whether anyone had checked the dollar."

07 Download the CFE 25-1 readiness checklist

If you issue CFE through Odoo and you are unsure whether the installation is ready for March 3, 2026, we built a 38-point checklist (PDF, 24 pages). It covers l10n_uy module audit, middleware checks, Notas de Crédito linking, GTIN/EAN catalog audit, multi-currency with BCU, and payroll/BPS configuration.

08 Conclusion: three months to audit

Uruguay is a premium but compact market: 3.4 million residents, the highest per-capita income in LATAM, impeccable institutional stability. Odoo holds a specific niche here — between cheap Memory + Pyme and expensive SAP Business One — but demands more precise localization than in any other country in the region.

The single point of leverage in 2026 is the CFE 25-1 migration by March 3. This is not "update a module" — it is a full compliance audit: l10n_uy + middleware + Notas de Crédito + GTIN/EAN + BCU rate + payroll/BPS. SMBs that start preparation in February 2026 run a real risk of missing the date. Those who closed the audit in November or December 2025 meet the deadline calmly.

Related reading

• Odoo in Peru: SUNAT 2026, SIRE, l10n_pe — neighboring market with a similar compliance model
• Odoo in Argentina: AFIP/ARCA, monotributo — the big Mercosur player with similar multi-currency pain
• Odoo in Chile: SII, DTE 2026 — Uruguay's premium competitor on SMB ticket size
• DGI CFE 25-1 specification — detailed breakdown
• Audit your Odoo installation — methodology
• Rescue a stuck Odoo project
• Odoo implementation from scratch
• Odoo + Analytics for LATAM SMBs

Frequently asked questions