DGI CFE 25-1 in Uruguay: what changes before the March deadline

One-minute summary

March 3, 2026 is the production deadline for CFE 25-1. If your system still sends XML in the 24-x format, DGI rejects every invoice and the sale never closes legally. This guide explains what changed, which ERPs are already broken, and why "we have l10n_uy installed" is not a compliance answer.

Uruguay runs the most mature e-invoicing jurisdiction in Latin America after Chile. The CFE (Comprobante Fiscal Electrónico) system has been live since 2012, and version 25-1 is the first major format update in three years. It affects nearly everyone: SMBs on Odoo with l10n_uy, retailers with thousands of SKUs, beef and cellulose exporters, and especially companies that spent years issuing CFEs on behalf of third parties under simplified tax regimes. By May 2026 part of the market had migrated; the other half discovered that "everything is configured" actually meant "never tested in the DGI sandbox." This guide is for them.

• March 3, 2026 — production deadline for CFE 25-1. The DGI test environment has been open since August 2025.
• Credit notes (Notas de Crédito) now require a mandatory reference to the original CFE — amount, currency and exchange rate are validated at the XML level.
• GTIN/EAN codes are enforced for retail; new logistics fields apply to exports (integration with VUCE — the Ventanilla Única de Comercio Exterior).
• Sales Mode 91 — Mandating Export is introduced for export-agent (mandato de exportación) scenarios.
• Companies on IVA mínimo, Monotributo and MIDES CAE can no longer issue third-party CFEs — DGI blocks this at the validation layer.
• The Odoo l10n_uy module (especially the OCA community version) lags behind. An "all set" message from your sysadmin does not mean DGI will accept your XML on March 4.

For context on how Odoo is localized in this market, the Odoo in Uruguay pillar guide explains the modular architecture that CFE 25-1 sits on top of.

Why DGI changed the format

Uruguay's CFE system started with Decreto 36/012 and a series of DGI resolutions (798/012, 688/013, 199/015). Dozens of minor updates pushed the format through versions 22-1, 23-1, 23-2, 24-1, 24-2 to the major 25-1, published in 2025.

CFE 25-1 is not cosmetics. It is the first release that simultaneously:

1. Strengthens traceability between related documents (credit notes ↔ original invoices).
2. Aligns Uruguay with the regional GTIN/EAN standard for retail (similar to SUNAT in Peru and DIAN in Colombia).
3. Integrates the fiscal flow with VUCE for exporters — DGI and Customs cross-validate data.
4. Closes the loophole on third-party emission for companies under simplified tax regimes.

DGI publishes the format on the official e-Factura portal and announces changes through the PAC ecosystem (Gosocket published the full details in June 2025). XSD schemas, validation rules and sample XMLs are public. "I didn't know" is not an audit defense.

Transition timeline

• August 2025 — DGI test environment opens; PACs (Proveedores Autorizados de Certificación) and issuers begin XML validation.
• October–December 2025 — validation tweaks based on early-integrator feedback.
• March 3, 2026 — production deadline; every CFE must ship in 25-1 format.
• After March 3, 2026 — old-format XML (24-x) is rejected. No CFE means no legally valid receipt → the sale is not formalized → no taxable base → the buyer cannot deduct.

If your e-factura provider or your ERP did not make it in time, that is your problem, not DGI's. The deadline has been public since the summer of 2025.

What exactly changes in the XML

A breakdown by format block. If you are an IT director, a controller, or an Odoo integrator, this is a working checklist. If you have not audited your system yet, an Odoo 50-point audit scopes the change before you touch anything.

#1. Credit notes: mandatory reference to the original CFE

In 24-x you could issue a credit note without a hard reference to the original — the Referencia field was optional in several scenarios. In 25-1 the field is mandatory for every credit-note type (eNota de Crédito linked to eFactura, eTicket, eRemito). DGI also validates:

• Note amount ≤ original CFE amount
• Note currency = original currency (you cannot issue a USD note against a UYU invoice)
• Exchange rate, when applicable, must match the original (or the current BCU rate at the note's date, explicitly declared)

If your system issues credit notes through a manual journal entry, you will need to rewrite the returns SOP.

#2. GTIN/EAN: product codes for retail

DGI is pushing standardized product codes in CFE line items. In 25-1, for retail sectors (food, beverage, pharma, electronics), the CodItem field is validated more strictly against the GS1 standard: GTIN-8, GTIN-12, GTIN-13, GTIN-14. Systems that ship an internal SKU without a GTIN mapping get warnings that convert into rejections after the grace period.

In practice: the Odoo catalog (product.template.barcode) needs a cleanup. Empty barcodes, internal SKUs in place of GTINs, duplicates — all of it shows up in DGI's production rejection report.

#3. Export CFEs and VUCE fields

Uruguayan exports — USD 2.68B of beef in 2025, plus UPM cellulose, soybeans and dairy — flow through VUCE. In 25-1 the export e-Resguardo and e-Factura must carry new logistics fields:

• IndicadorPais — country-of-destination detail
• ModalidadTransporte — coded (sea, air, ground)
• Incoterm — mandatory for exporters
• ReferenciaVUCE — DUA number when the clearance went through the single window

DGI and Customs exchange data through these fields for cross-validation. A discrepancy between DUA and CFE is an audit red flag.

#4. Sales Mode 91 — Mandating Export

The new sales code 91 covers mandato de exportación cases — when a Uruguayan exporter clears goods on behalf of a foreign principal (agent model). Before 25-1, those operations were buried inside regular exports; now they get a dedicated code and dedicated validation. It affects roughly 5–8% of Uruguayan exporters, mostly in beef and pharma.

#5. Restrictions for simplified regimes

Companies on IVA mínimo, Monotributo, and MIDES CAE (Comunicación de Actividad Económica for social monotributo) can no longer issue CFEs on behalf of third parties in 25-1. This shuts down the practice where a large issuer "rented" the CAE of a small company to optimize taxes. Starting March 3, 2026, those operations are technically impossible at the XML validation layer.

Migration checklist for Odoo

If you are on Odoo 16/17/18 with l10n_uy:

1. Check the module version — OCA community lags behind Enterprise; on community edition, 25-1 may be entirely missing without a custom extension.
2. Check the PAC certification (Gosocket, Sovos, Edicom, Pyxis) — the provider needs current DGI certification on 25-1.
3. Clean up the catalog — GTIN mapping (product.template.barcode) for every active product.
4. Reconfigure the credit-note process — every note must reference the original CFE (field l10n_uy_cfe_uuid or the equivalent in your module version).
5. Run end-to-end in the DGI sandbox — not "the PAC said ok" but a real XML exchange with the DGI test environment using your own data.
6. Monitor the rejection rate — first two weeks post go-live: 1–3% is normal, above 5% is a fire.

When it works and when it does not: 5 real-world scenarios

Not every Uruguayan SMB faces the same project. Effort and cost depend on the profile. If you want to know what a bad migration looks like before it lands on you, read what an Odoo project rescue covers.

1. Small SMB, B2B, no exports, Odoo Enterprise with up-to-date l10n_uy — migration to 25-1 is 2 to 5 days of integrator work plus regression testing. Simple case. Cost: USD 1,500 to 4,000.

2. Retail (multiple branches, POS, thousands of SKUs) — migration becomes a catalog-cleanup project. Without GTIN mapping for 80%+ of active products, the CFE will fail validation within 6–12 months once DGI escalates warnings to rejections. That is 3 to 8 weeks of catalog and IT work. Cost: USD 8,000 to 25,000.

3. Exports (beef, soy, dairy, electronics) — migration includes VUCE and Customs integration. Fields Incoterm, ReferenciaVUCE, ModalidadTransporte must auto-pull from the WMS or TMS. That is 6 to 12 weeks of project work. Cost: USD 15,000 to 60,000. The ROI is large: error rates on export CFEs translate directly into audit risk and taxable base exposure.

4. Custom modifications on l10n_uy (rewritten dispatch functions, custom fields, branded QWeb templates) — migration is a partial refactor. Every customization must be validated against 25-1. Without an audit, you do not find out what broke until production rejection hits. Classic case for an independent Odoo audit: USD 2,500 to 6,000 for a clear risk assessment.

5. Monotributo, IVA mínimo or MIDES CAE with third-party CFE emission — this is not a migration. It is a business-model change. Options: switch to régimen general (higher tax burden) or stop the activity. Consultation with your accountant is mandatory.

Four typical mistakes in Uruguayan Odoo projects

Repeating patterns observed across audits run between November 2025 and March 2026. If you run Odoo, it is worth cross-checking this list against your install — and if the result is uncomfortable, a structured implementation review is the right next step.

#1. "My PAC said everything is ready"

The provider (Gosocket, Sovos, Edicom) confirms certification on 25-1 — but that does not mean your ERP sends the correct XML. PAC certification ≠ data compatibility. Between the ERP and the PAC there is always a transformation layer (often middleware in Python or PHP) that breaks most often — especially with custom discounts, multi-currency operations, and line aggregation.

What to do: run end-to-end in the DGI sandbox with your company's real data, not the provider's demo XML.

#2. GTIN mapped only for "top products"

SMBs map GTIN for the top 50 SKUs and assume the defense is in place. But the Odoo catalog holds 3,000+ products, of which 200 sell actively. Any sale order with an unmapped SKU → CFE rejection → the sale stalls.

What to do: a GTIN-coverage report against product.template, plus a hard rule on sale.order: block confirmation if any line is missing a GTIN. Not a warning — a block.

#3. Credit notes done the "corporate way"

The accountant cuts a credit note via a manual journal entry because "it is faster." In 24-x that sometimes flew (if a compensation invoice was reissued afterward). In 25-1 it is impossible — without a reference to the original CFE, DGI rejects the XML.

What to do: rewrite the returns SOP. Every credit note goes through the e-Nota de Crédito module, with the original CFE mandatorily selected. Lock manual financial entries on CFE operations through user-group ACLs.

#4. Custom QWeb templates never updated

Custom QWeb templates often hold hardcoded fields. In 25-1 the Encabezado XML block changed — some tags were renamed and required fields were added. The custom template keeps rendering the old structure → the PDF does not match the XML → audit risk.

What to do: review every custom QWeb template for CFE documents, sync with the current DGI spec. It is one day of work — usually discovered through a customer complaint.

Real case: pharma retailer, 4 stores in Montevideo

Situation (anonymous case, November 2025 to March 2026): a Uruguayan pharma-cosmetics retailer with 4 stores in Montevideo, 8,500 active SKUs, ~12,000 CFEs per month. They went live on Odoo 17 with l10n_uy Enterprise in 2023. The internal IT team was confident: "everything is in order, the module is installed, the PAC is configured."

What the audit found (November 2025):

• GTIN coverage: 23% of active SKUs (1,950 out of 8,500).
• Credit notes issued through manual journal entries in 47% of cases (the accountant did it that way because it was faster).
• Custom QWeb template for CFE not updated since 2024 — rendered the old Encabezado structure.
• Sandbox testing on 25-1: never performed.

What we shipped (December 2025 to February 2026):

1. GTIN cataloging: outsourced to a Uruguayan call center for 6 weeks; coverage climbed to 94%.
2. Credit-note process rewritten — manual entries for CFE were blocked at the ACL layer.
3. QWeb templates updated, synced with the current XSD.
4. End-to-end testing in the DGI sandbox: 200 CFEs of different types, rejection rate dropped from 31% to 1.5%.

Outcome (March 2026): go-live on CFE 25-1 on March 4, production rejection rate of 0.8% during the first week (industry norm is 3–5%). No sales channel stalled.

Project cost: USD 11,400 (audit + GTIN cataloging + refactor + testing).
Alternative scenario (go-live "as is"): estimated 25%+ rejection rate in the first week = ~3,000 stalled sales × average ticket USD 45 = USD 135,000 of frozen revenue, plus reputation damage for the pharmacy chain.

"The l10n_uy module had been installed since 2023 — but nobody had ever pushed a real XML against the DGI sandbox. The signal that something was wrong was not technical, it was organizational: no team owned compliance."

32-point checklist: CFE 25-1 readiness

We packaged a 32-point technical checklist for Odoo migration to CFE 25-1 — from the PAC integration audit to GTIN coverage and regression testing in the DGI sandbox. Structured by role (IT, accounting, head of operations). Download the CFE 25-1 checklist — leave your email, you get the PDF plus an Excel template.

If you want a benchmark against nearby jurisdictions, read the equivalents in Chile SII 2026, Colombia DIAN 2026, and Peru SUNAT 2026 — Uruguay is among the least invasive, but technical discipline still rules.

25-1 is not the last version

CFE 25-1 is a logical step in the evolution of Uruguayan electronic invoicing. DGI publishes format updates every 12 to 24 months, and 25-2 / 26-1 are already on the horizon. Teams that survived 25-1 with minimal bleeding are now setting up for the next cycle: automated sandbox testing, GTIN discipline in the catalog, PAC-agnostic architecture. The same applies to the data layer — Odoo Analytics as BI on top of the ERP requires clean fiscal flows first.

Uruguay is one of the few LATAM countries where the compliance burden for SMBs is lower than in Peru, Colombia, or Mexico (measured by resolution volume and change cadence). But that is not "install and forget". That is "install correctly — and forget for 18 months until the next update."

If you are an IT director, CFO, or SMB owner in Uruguay and you are not sure whether your system is ready for 25-1 (or it already stopped working after March 3), an independent audit returns a clear answer in 5 business days. Not "your PAC says ok" — actual end-to-end verification against the DGI sandbox with your real data.

Related material

• Odoo in Uruguay: a complete SMB guide — country pillar on Odoo localization for the UY market
• Odoo audit: 50-point diagnostic — independent assessment methodology
• Odoo implementation: what a proper project includes — SMB project structure
• Odoo project rescue — what to do when implementation went sideways
• SUNAT 2026 in Peru — regional compliance benchmark
• SII 2026 in Chile — the closest e-invoicing jurisdiction in maturity
• DIAN 2026 in Colombia — comparison for LATAM expansion
• SIFEN in Paraguay — the newer entrant in electronic invoicing
• AFIP ARCA and Monotributo in Argentina — parallel compliance cycle
• CFE 25-1 downloadable checklist — lead-magnet PDF
• Audit your Odoo template — methodological audit template

Frequently asked questions