Inicio / Blog / Tutoriales / CFE 25.1 DGI
TutorialesUruguay

Odoo en Uruguay: DGI, CFE 25-1 y la localización l10n_uy

Guía para PYME que facturan sobre Odoo en Uruguay.
Qué cambia con el formato CFE 25.1, qué cubre l10n_uy, qué deja al middleware, y cómo cerrar el audit antes del 3 de marzo de 2026.

Sergei Filatov
Sergei FilatovFounder · data-metrics.pro · 27 may 2026
◷ 14 min de lectura

01 Resumen en un minuto

Uruguay es la economía LATAM con investment-grade de las tres calificadoras grandes y una de las pioneras del e-invoicing regional (CFE desde 2012). El 3 de marzo de 2026 todos los emisores de CFE deben migrar al formato 25.1 — y el módulo l10n_uy de Odoo llega a esa fecha solo parcialmente listo. Aquí cuál es el riesgo para la PYME que factura sobre Odoo y cómo cerrar la brecha antes del deadline DGI.

  • El 3 de marzo de 2026 todos los emisores de CFE en Uruguay deben usar el formato 25.1 — es una migración técnica del esquema XML, no un retoque cosmético.
  • Cambios principales del 25.1: vinculación obligatoria de Notas de Crédito al CFE original con validación de monto, moneda y tipo de cambio; GTIN/EAN en líneas de retail; nuevos campos logísticos para exportación (integración con VUCE); Sales mode 91 para exportación por encargo; y restricciones para regímenes IVA Mínimo y Monotributo.
  • El módulo l10n_uy en Odoo Community y Enterprise cubre la base DGI, pero la compatibilidad completa con 25.1 en la mayoría de las instalaciones está atrasada — es zona típica de auditoría de compliance antes del deadline.
  • El mercado uruguayo de Odoo es chico y premium: ticket de implementación de USD 10 500 – 52 000, un solo Gold-partner oficial (Nexitpara 3.4 millones de habitantes.
  • Órbita fiscal de la PYME: IVA básico 22% y IVA mínimo 10%IRPF Categoría I y II, IRAE anual con ajuste por inflación, BPS mensual. Se cubre, pero exige configurar bien l10n_uy + módulos OCA o extensiones propias.

02 Por qué Uruguay es un caso especial para Odoo

Uruguay opera el sistema de facturación electrónica más maduro del continente. El régimen es prácticamente universal y la macroeconomía da horizon planning largo — pero también un sales cycle más conservador. Antes de hablar de Odoo conviene entender qué es CFE y por qué su nueva versión 25.1 trasciende un parche de XML.

#1. El e-invoicing más maduro de la región

Uruguay arrancó la factura electrónica obligatoria en 2012, cinco a siete años antes que la mayoría de LATAM. El sistema CFE (Comprobante Fiscal Electrónico) opera bajo la DGI (Dirección General Impositiva) y cubre cinco tipos: e-Facturae-Tickete-Remitoe-Resguardo y e-Boleta de Entrada, cada uno con sus notas de crédito y débito.

Hoy es régimen universal: todos los contribuyentes de IVA e IRAE deben emitir CFE mediante software certificado o el servicio gratuito CREA CFE de la propia DGI (para microvolúmenes). Restringidos quedan los regímenes IVA MínimoMonotributo y Monotributo MIDES CAE — no pueden emitir CFE por cuenta de terceros.

El contexto macro suma especificidad. Según FocusEconomics y BBVA Research, Uruguay es el único país de la región con investment-grade de las tres calificadoras grandes, el PIB 2026 se proyecta entre 1.8 % y 2.4 % y la inflación dentro del target del BCU (4.5 % – 5.0 %). Allianz Trade confirma bajo country risk. La estabilidad da horizon planning largo, pero también un sales cycle más conservador: la PYME uruguaya no quiere fast-talking presentations.

#2. Qué cambia con el formato CFE 25.1

En septiembre de 2025 la DGI publicó la especificación de la versión 25.1. No es un retoque cosmético del esquema XML — es un paquete de validaciones que aprieta el control sobre:

  • Notas de Crédito vinculadas a su CFE original: ahora se comparan MontoTotalTipoMoneda y TasaCambio del documento original — cualquier discrepancia se rechaza;
  • uso de códigos estándar GTIN/EAN en las líneas de productos retail;
  • nuevos campos logísticos en facturas de exportación para integración con VUCE (Ventanilla Única de Comercio Exterior) — Incoterm, medio de transporte y país de destino estructurados;
  • Sales mode 91 — Mandating Export, que entra en vigor para casos específicos de exportación por encargo (análisis detallado de Datalogic);
  • controles más estrictos del vínculo entre e-Factura y e-Remito cuando se usan referencias.

Cronología:

FechaEvento
Septiembre 2025Publicación de la especificación del formato 25.1
Q4 2025Entorno de testing DGI abierto para emisores
3 de marzo de 2026Production deadline — todos los emisores obligados a usar 25.1
!
DGI ya pateó deadlines antes (2018), pero apostar a otra prórroga es estrategia de quien está dispuesto a pagar multas. El testing está abierto desde Q4 2025 y la trazabilidad del retraso queda registrada — la próxima inspección encontrará exactamente cuándo cada CUIT empezó a emitir 25.1.

03 Qué incluye la localización de Odoo para Uruguay

El landscape técnico de Odoo para Uruguay se arma en cuatro capas: el módulo estándar l10n_uy, los aportes de la OCA, el middleware que dialoga con DGI y las extensiones a medida según el rubro. Conocer dónde termina cada capa evita expectativas falsas en el audit de compliance.

#1. El módulo l10n_uy de base

En la entrega estándar de Odoo Community y Enterprise el módulo l10n_uy aporta:

  • Plan de cuentas uruguayo conforme a NIIF (adaptación NIC de la DGI);
  • tipos de impuesto base: IVA básico 22%IVA mínimo 10%IVA exento;
  • configuración de IRPF Categoría I (trabajo dependiente) y estructura base para Categoría II (servicios profesionales);
  • estructura para los tipos de CFE: e-Facturae-Tickete-Remitoe-Resguardo;
  • mapeo de tipos de documento y contrapartes a códigos DGI.

Lo que el módulo estándar no trae:

  • integración lista con los web-services de DGI (requiere obra civil third-party o middleware);
  • obtención automática de la CAE (Constancia de Autorización de Emisión);
  • plantillas legales para todos los tipos de CFE con la lista completa de campos required;
  • lógica de BPS (aportes mensuales al Banco de Previsión Social) — la cubren módulos OCA o desarrollo propio;
  • manejo completo de la e-Boleta de Entrada.

#2. OCA y extensiones custom

El track uruguayo en los repositorios OCA (Odoo Community Association) está activo pero es compacto. Hay módulos puntuales en GitHub para depositary checks (conformes) y para extensiones de payroll con especificidades locales, pero no existe un paquete OCA «todo-en-uno» para Uruguay.

El partner Gold más grande del país — Nexit — desarrolló un paquete propio cerrado de localización en el que se apoyan muchas implementaciones grandes. Eso explica por qué incluso instalaciones Enterprise maduras requieren trabajo extra: la «caja» cubre el 70–80 % de los escenarios, el resto va a custom o al paquete del partner.

#3. Middleware para DGI

A diferencia de Perú o Chile, donde Odoo dialoga con el regulador vía un web-service estándar, en Uruguay el paisaje está fragmentado. La mayoría de las instalaciones productivas usan middleware:

  • Pyxis (local, Montevideo);
  • Datalogic (uno de los proveedores locales grandes);
  • Gosocket (regional, multi-LATAM — cómodo para la PYME con operaciones en varios países);
  • EdicomSovos — para el segmento enterprise.

La elección de middleware impacta en el costo de licencia, en la velocidad con que cubre 25.1 y en el SLA ante incidentes. Para marzo de 2026 no todos los conectores estarán igual de listos — es una decisión técnica crítica que conviene chequear antes de migrar, no después.

#4. Multi-moneda y cotización BCU

Uruguay es una economía altamente dolarizada: una parte importante del B2B y toda la exportación se facturan en USD, a veces en EUR. Odoo soporta multi-currency de fábrica, pero para DGI es crítico que la cotización al día de emisión del CFE coincida con la del BCU (Banco Central del Uruguay). La configuración estándar trae cotizaciones de fuentes públicas (ECB, Yahoo Finance) — para compliance conviene conectar el API del BCU directamente o configurar el middleware para que tire el oficial. Una diferencia de 0.20 – 0.50 UYU/USD parece menor, pero al conciliar el trimestre genera desfasajes visibles en IVA.

04 Cuándo Odoo funciona en Uruguay — y cuándo no

No todo proyecto necesita Odoo, ni toda PYME está lista para mantenerlo. Antes de comprar licencias, conviene ubicarse en uno de los tres escenarios siguientes. Si el caso de uso encaja con la columna izquierda, vale la pena seguir; si cae en la derecha, hay que repensar la inversión o pensar en una auditoría previa.

#1. Funciona si...

  • Sos una PYME de 20 a 150 empleados que ya quedó chica para Memory + Pyme o Conty, y necesita un ERP completo con manufacturing, inventario y project management — no solo contabilidad.
  • Sos una software house o un digital-business con clientes en EE. UU. y Europa: necesitás multi-currency, reporting bilingüe (ES/EN), tracking de MRR/ARR — los tier-1 uruguayos no llegan a eso.
  • Sos un exportador (lácteo, carne, madera, vino, miel) y necesitás trazabilidad de lotes, integración con VUCE, multi-currency y BI por margen por kilo/unidad. Según Rio Times, el agroexportador sigue siendo el motor del PIB 2026.
  • Sos un negocio hotelero o de servicios en Punta del Este, Colonia o Montevideo, con integración a OTAs y multi-channel pricing — necesitás un módulo PMS sobre el ERP.

#2. Es caro o difícil si...

  • Sos una micro-empresa en Monotributo con menos de 5 CFE al mes — CREA CFE alcanza, Odoo es overkill.
  • Esperás un l10n_uy de caja sin custom — no va a pasar; la migración a 25.1 demanda ajustes en casi cualquier instalación, como muestra la guía LLB Solutions.
  • Necesitás soporte semanal on-site en Montevideo — la mayoría de partners internacionales o remote-consultores no lo dan; conseguir uno local y dejarlo presupuestado de entrada.
  • Tenés un requerimiento tipo SAP de compliance (Big-4 audit, SOX, IFRS full audit-trail) — Odoo lo banca, pero el overhead de consultoría puede superar a SAP B1 + partner local en el mismo volumen.

#3. No funciona si...

  • Estás en régimen IVA Mínimo o Monotributo MIDES CAE y querés emitir CFE por cuenta de terceros — DGI lo prohíbe independientemente del software; no es un problema de Odoo.
  • Arrastrás un legacy custom en FoxPro o Visual Basic 6 con 15+ años de parches — la migración es posible, pero no es un «Odoo en 3 meses»: es un proyecto de 9–12 meses con migración de datos y reentrenamiento del equipo.
  • Necesitás módulos verticales muy específicos (por ejemplo, análisis de laboratorio lechero con integración a estándares INALE) y no tenés presupuesto para custom — un vendor local con solución sectorial lista saldrá más barato.

05 Cinco errores típicos al implementar Odoo en Uruguay

Los errores se repiten — y todos cuestan el doble cuando aparecen a dos meses del deadline DGI. Cada punto siguiente vino de una instalación real que se rompió. Antes de firmar el alcance del proyecto vale la pena que el partner explique cómo cubre estos cinco frentes.

#1. Ignorar la dependencia del middleware hasta 25.1

Es el patrón clásico: la PYME compra licencia Enterprise de Odoo, instala l10n_uy y espera que la migración a 25.1 «pase sola con el release 17.x o 18.x». No funciona así — el proveedor de middleware (Pyxis, Datalogic, Gosocket) debe actualizar de manera independiente los esquemas XML, las validaciones y los mappers. Si el middleware no llega al 3 de marzo de 2026, Odoo no podrá emitir CFE correcto por más fresco que esté el módulo.

Qué hacer: antes de fin de enero de 2026 pedirle al proveedor confirmación escrita de la versión que soporta 25.1, una cuenta de testing, XML de muestra y correr end-to-end emisión + aceptación en el ambiente de testing de DGI.

#2. Notas de Crédito sin vínculo al CFE original

En 25.1 la DGI aprieta la validación: una nota de crédito sin link a un e-Factura o e-Ticket concreto con monto, moneda y tipo de cambio coincidentes, se rechaza. En muchas instalaciones eso rompe el «proceso de anulación», porque en la versión anterior Odoo permitía credit notes «sueltas» para correcciones.

Qué hacer: antes de la migración correr un audit de todas las credit notes de los últimos 6 meses — encontrar las sueltas, restaurar la vinculación con el CFE original, chequear coincidencia de moneda y cotización. Documentar el proceso de anulación en un SOP.

#3. Multi-currency sin cotización BCU

La PYME activa multi-currency, conecta cotización ECB o Yahoo Finance, y emite CFE en USD. DGI exige cotización del BCU al día de emisión. La diferencia de 0.20 – 0.50 UYU/USD parece chica — pero al conciliar el trimestre el desfasaje en el cálculo de IVA termina en reliquidaciones y, eventualmente, en preguntas de la DGI.

Qué hacer: conectar el API del BCU en directo o configurar el middleware para que tire la cotización oficial. Diario, no semanal — especialmente en días de volatilidad cambiaria.

#4. Ausencia de GTIN/EAN en el catálogo de productos

En 25.1 la DGI refuerza, para retail, la exigencia de códigos estándar GTIN/EAN en las líneas. Muchas PYME manejan productos con SKU interno sin mapping a GTIN. Antes del deadline conviene limpiarlo, si no las líneas se rechazan o quedan marcadas «no estándar».

Qué hacer: audit del catálogo product.template sobre el campo barcode (GTIN-13), validación de uniqueness y mapeo de códigos faltantes vía GS1 Uruguay.

#5. «Implementación solo IVA 22 %» — ignorar IRPF y BPS

Muchos partners implementan l10n_uy con foco en IVA y CFE, y dejan el cálculo de sueldos, IRPF Categoría II (retención por servicios) y BPS en el software de bookkeeping viejo o en Excel. Eso da doble fuente de verdad y desfasajes al cierre de mes.

Qué hacer: incluir desde el día uno el módulo de payroll con tasas uruguayas y BPS dentro del scope. Suma 20–30 % al presupuesto, pero se paga en 6 meses solo por eliminar la conciliación manual y los errores de retención.

06 Caso: migración de un exportador lácteo

Caso anónimo del sector lácteo uruguayo (producción de quesos para exportación, ~95 empleados, envíos a Brasil, Paraguay y Estados Unidos).

Punto de partida: Memory + Pyme + un módulo custom para producción de quesos (8 años de implementación) + Excel para la trazabilidad (leche → tanque → cuajada → contenedor) + emisor externo de CFE. Dolor concentrado en:

  • reporting manual al INALE (Instituto Nacional de la Leche);
  • CFE en USD con desfasajes de cotización (se tomaba el cierre del día anterior, no el BCU del día de emisión);
  • error en IRAE con revalúo de activos fijos por UYU 1.8 M detectado al cierre 2023;
  • liquidación de 14 productores socios sobre planilla de pagos en papel.

Qué se hizo (5 meses): migración a Odoo 17 Enterprise con Manufacturing, Quality, Inventory, l10n_uy + extensiones custom. Trazabilidad de punta a punta desde el tambo proveedor hasta el contenedor del cliente. CFE integrado vía middleware Datalogic, cotización BCU automática. App móvil para recibir la leche en el tambo con sincronización offline. Liquidación de productores automatizada por sólido seco con bonificación por calidad y transferencias BROU.

Resultados: auditoría INALE 2024 aprobada de primera; trace-back de contenedor a tambo bajó de 6 horas a 8 minutos; liquidación de productores pasó de 5 días al mes a corrida automática al cierre; rechazos DGI 6 % → 0 % desde el segundo mes; el error de IRAE-revalúo se identificó y se corrigió (ahorro de UYU 1.8 M en el cierre 2024); cierre de mes pasó de 16 a 4 días.

Inversión: USD 38 000 el primer año, USD 14 000 desde el segundo (incluye licencia de middleware y SLA).

«El día que la cotización BCU se cargó sola fue el día que el equipo de administración dejó de preguntar si alguien había mirado el dólar a las once.»

07 Descargá el checklist de preparación CFE 25-1

Si emitís CFE desde Odoo y tenés dudas sobre si la instalación está lista para el 3 de marzo de 2026, preparamos un checklist de 38 puntos (PDF, 24 páginas). Cubre auditoría del módulo l10n_uy, validaciones de middleware, vínculo de Notas de Crédito, audit de GTIN/EAN en el catálogo, multi-currency con BCU y configuración payroll/BPS.

08 Conclusión: tres meses para auditar

Uruguay es un mercado premium pero compacto: 3.4 millones de habitantes, el ingreso per cápita más alto de LATAM, estabilidad institucional impecable. Odoo ocupa acá un nicho específico — entre la «económica» Memory + Pyme y el «caro» SAP Business One — pero exige una localización más precisa que en cualquier otro país de la región.

El punto de aplicación de fuerza en 2026 es la migración a CFE 25-1 al 3 de marzo. No es «actualizar un módulo» — es una auditoría completa de compliance: l10n_uy + middleware + Notas de Crédito + GTIN/EAN + cotización BCU + payroll/BPS. La PYME que arranque la preparación en febrero de 2026 corre serio riesgo de no llegar. La que cierre el audit en noviembre o diciembre de 2025 va a recibir la fecha tranquila.

Materiales relacionados

Preguntas frecuentes

¿Cuánto cuesta implementar Odoo para una PYME uruguaya?

Para una PYME de 20–80 empleados el rango es USD 10 500 – 28 000 el primer año, y desde el segundo USD 12 000 – 18 000 entre licencias y soporte. Una auditoría puntual de readiness para 25.1 ronda USD 3 200 fijos.

Software-house o exportador con multi-currency y obra civil custom se ubica en USD 25 000 – 52 000 el primer año.

¿El l10n_uy de Odoo 17/18 llega listo al formato 25.1 para el 3 de marzo de 2026?

La estructura base sí — el módulo lo actualiza el equipo de Odoo junto con la OCA. Pero lo crítico es la disponibilidad del middleware (Pyxis, Datalogic, Gosocket, Sovos), que es quien dialoga con DGI.

Antes de fin de enero de 2026 pedile a tu proveedor la confirmación escrita de la versión que soporta 25.1, una cuenta de testing y XML de muestra.

¿Qué pasa si el 3 de marzo de 2026 falla la emisión de CFE?

DGI rechaza los documentos como inválidos. No es una multa per se, pero la operación se frena: no podés facturar legalmente y el comprador no recibe el crédito de IVA.

Las multas vienen después, cuando se detecta el atraso y se reliquidan IVA e IRAE de los períodos afectados.

¿Sirve usar el CREA CFE gratuito en lugar de Odoo para emitir?

Sí, para micro-PYME que emiten hasta ~30 CFE por mes. Pero CREA CFE es una web-form standalone, sin conexión a inventario, pipeline de ventas ni contabilidad. Cualquier integración significa carga manual = errores.

Por encima de 50 CFE al mes, pasarse a una solución integrada se paga en 4–6 meses.

¿Cubre Odoo IRPF Categoría II (retención de servicios profesionales)?

El l10n_uy estándar lo cubre de manera parcial. La automatización completa de la retención según la escala y la generación de e-Resguardo exige un módulo custom o funcionalidad específica del middleware.

Conviene chequear este punto en el alcance del proyecto antes de firmar, no después de la primera retención mal calculada.

¿Cuántos partners Gold de Odoo hay en Uruguay?

Uno — Nexit (20+ años, 100+ implementaciones, oficinas en Montevideo). Hay además algunos Ready y Silver.

Para PYME con componente internacional (exportación, clientes en EE. UU.) a veces resulta más rentable un equipo remote de un país vecino combinado con un contador local como bridge.

¿Cuánto tarda la migración de Memory + Pyme a Odoo?

Típicamente 10–14 semanas para una PYME de 30–80 empleados. El critical-path: mapeo de plan de cuentas, migración del histórico de CFE, configuración del middleware DGI y entrenamiento del equipo en tres niveles (operadores / contador / management).

¿Conviene mantener Memory + Pyme en paralelo durante la migración?

Solo durante los primeros dos cierres de mes posteriores al go-live, como red de seguridad. Tras el segundo cierre validado, mantener el sistema viejo en paralelo cuesta más en conciliación humana que el seguro que aporta.

El plan típico es: parallel run de octubre y noviembre, switch definitivo en el cierre de diciembre.