Inicio / Blog / Tutoriales / DGI CFE 25-1
TutorialesUruguay

DGI CFE 25-1 en Uruguay: qué cambia antes del deadline de marzo

3 marzo 2026 es production-deadline del nuevo formato.
Si tu sistema sigue mandando XML 24-x, DGI rechaza cada CFE y la venta no se completa legalmente.

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

Resumen en un minuto

3 marzo 2026 es production-deadline del formato CFE 25-1. Si tu sistema todavía envía XML 24-x, DGI rechaza cada comprobante y la venta no se cierra legalmente. Esta guía explica qué cambió en el formato, qué ERPs ya están rotos, y por qué "tenemos l10n_uy instalado" no es respuesta de compliance.

Uruguay es la jurisdicción de facturación electrónica más madura de Latinoamérica después de Chile. El sistema CFE (Comprobante Fiscal Electrónico) opera desde 2012, y la versión 25-1 es la primera actualización mayor del formato en tres años. Afecta a casi todos: PYMEs sobre Odoo con l10n_uy, retail con miles de SKU, exportadores de carne y celulosa, y especialmente compañías que durante años emitieron CFE en nombre de terceros bajo regímenes simplificados. Para mayo de 2026 una parte ya migró; la otra mitad descubrió que "está todo configurado" significaba "no probado en el sandbox de DGI". Esta guía es para esos.

  • 3 marzo 2026 — production-deadline para CFE 25-1. El ambiente de prueba de DGI está abierto desde agosto 2025.
  • Notas de Crédito ahora requieren referencia obligatoria al CFE original: monto, moneda y tipo de cambio se validan a nivel XML.
  • GTIN/EAN reforzado para retail; nuevos campos logísticos para exportación (integración con VUCE — Ventanilla Única de Comercio Exterior).
  • Sales Mode 91 — Mandating Export introducido para esquemas de mandato de exportación.
  • Empresas en IVA mínimo, Monotributo y MIDES CAE no pueden seguir emitiendo CFE de terceros — DGI bloquea a nivel de validación.
  • El módulo Odoo l10n_uy (sobre todo la versión community en OCA) va atrasado. Un "todo listo" del administrador de sistemas no significa que DGI acepte tu XML el 4 de marzo.

Si querés contexto sobre cómo se localiza Odoo en este país, antes de seguir conviene mirar la guía pillar de Odoo en Uruguay — explica la arquitectura modular sobre la cual se monta CFE 25-1.

Por qué DGI cambia el formato

El sistema CFE en Uruguay arrancó con el Decreto 36/012 y una serie de resoluciones DGI (798/012, 688/013, 199/015). Decenas de actualizaciones menores llevaron al formato a través de las versiones 22-123-123-224-124-2 hasta el mayor 25-1, publicado en 2025.

CFE 25-1 no es cosmética. Es la primera versión que simultáneamente:

  1. Refuerza la trazabilidad entre documentos relacionados (notas de crédito ↔ facturas originales).
  2. Acerca a Uruguay al estándar regional GTIN/EAN para retail (similar a SUNAT en Perú y DIAN en Colombia).
  3. Integra el flujo fiscal con VUCE para exportadores — DGI y Aduana hacen cross-validation de datos.
  4. Cierra el agujero de la emisión de terceros para empresas en regímenes tributarios simplificados.

DGI publica el formato en su portal oficial de e-Factura y anuncia cambios a través del ecosistema PAC (Gosocket publicó los detalles en junio 2025). XSD-schemas, reglas de validación y XMLs de muestra son públicos. "No sabía" no funciona como defensa en una auditoría.

Timeline de transición

  • Agosto 2025 — ambiente de prueba DGI abierto; PAC (Proveedores Autorizados de Certificación) y emisores comienzan validación XML.
  • Octubre–diciembre 2025 — ajustes de validación con feedback de los primeros integradores.
  • 3 marzo 2026 — production-deadline; todos los CFE deben enviarse en formato 25-1.
  • Después del 3 marzo 2026 — XML en formato viejo (24-x) son rechazados. Sin CFE no se emite el comprobante con validez legal → la venta no se formaliza → no hay base imponible → el comprador no puede deducir.

Si tu proveedor de e-factura o tu ERP no llegó, es tu problema, no de DGI. El plazo se conoce desde el verano de 2025.

Qué cambia exactamente en el XML

Desglose por bloque del formato. Si sos director de IT, contador o integrador Odoo, esto es checklist de trabajo. Si todavía no auditaste tu sistema, una auditoría Odoo de 50 puntos ordena el alcance del cambio antes de hacer cualquier modificación.

#1. Notas de Crédito: referencia obligatoria al CFE original

En la versión 24-x se podía emitir una nota de crédito sin referencia obligatoria al original — el campo Referencia era optional en varios escenarios. En 25-1 el campo es obligatorio para todos los tipos de nota (eNota de Crédito asociada a eFactura, eTicket, eRemito). Además DGI valida:

  • Monto de la nota ≤ monto del CFE original
  • Moneda de la nota = moneda del original (no podés emitir una nota en USD contra factura en UYU)
  • Tipo de cambio, si aplica, debe ser el mismo del original (o el valor BCU vigente a la fecha de la nota, explícitamente declarado)

Si en tu sistema las notas de crédito se emiten vía manual journal entry, vas a tener que reescribir el SOP del proceso de devoluciones.

#2. GTIN/EAN: códigos de producto para retail

DGI promueve códigos estandarizados de producto en las líneas del CFE. En 25-1, para sectores retail (alimentos, bebidas, pharma, electrónica), el campo CodItem se valida con mayor rigor contra el estándar GS1: GTIN-8, GTIN-12, GTIN-13, GTIN-14. Los sistemas que envían SKU interno sin mapeo GTIN reciben warnings que se convierten en rechazos después del grace period.

En la práctica: el catálogo de Odoo (product.template.barcode) debe estar limpio. Códigos vacíos, SKU internos en lugar de GTIN, duplicados — todo eso aparece en el rejection report de producción de DGI.

#3. CFE de exportación y campos VUCE

La exportación uruguaya — USD 2.68B de carne en 2025, más celulosa de UPM, soja y lácteos — pasa por VUCE. En 25-1 el e-Resguardo y la e-Factura de exportación deben portar nuevos campos logísticos:

  • IndicadorPais — detalle del país de destino
  • ModalidadTransporte — codificado (marítimo, aéreo, terrestre)
  • Incoterm — obligatorio para exportadores
  • ReferenciaVUCE — número DUA si el despacho pasó por Ventanilla Única

DGI y Aduana intercambian datos vía estos campos para cross-validation. Discrepancia en DUA vs CFE es red flag en auditoría.

#4. Sales Mode 91 — Mandating Export

El nuevo régimen de venta 91 se introduce para casos de mandato de exportación — cuando un exportador uruguayo despacha mercadería por cuenta de un principal extranjero (esquema de agencia). Antes de 25-1, esas operaciones se enmascaraban como exportación común; ahora tienen código separado y validación separada. Afecta a entre 5% y 8% de los exportadores uruguayos, sobre todo en carne y pharma.

#5. Restricciones para regímenes simplificados

Empresas en IVA mínimoMonotributo y MIDES CAE (Comunicación de Actividad Económica para monotributo social) no pueden emitir CFE en nombre de terceros en formato 25-1. Esto cierra la práctica donde un emisor grande "alquilaba" el CAE de una empresa chica para optimizar carga tributaria. A partir del 3 de marzo de 2026, esas operaciones son técnicamente imposibles a nivel de validación XML.

!
Gotcha que casi nadie revisa: el QWeb-template custom que imprime el PDF del CFE. La estructura del bloque Encabezado cambió en 25-1, algunos tags fueron renombrados y se agregaron required fields. Si tu template no fue actualizado, el XML que se firma queda correcto, pero el PDF que el cliente recibe sigue renderizando la estructura vieja. Discrepancia PDF vs XML — riesgo de auditoría aunque el rechazo DGI no se dispare.

Checklist de migración para Odoo

Si estás en Odoo 16/17/18 con l10n_uy:

  1. Verificá la versión del módulo — la community en OCA va atrasada respecto a enterprise; en community-edition, 25-1 puede no estar disponible sin una extensión custom.
  2. Verificá la certificación del PAC (Gosocket, Sovos, Edicom, Pyxis) — el proveedor debe tener certificación DGI vigente sobre 25-1.
  3. Limpiá el catálogo — mapeo GTIN (product.template.barcode) para todos los productos activos.
  4. Reconfigurá el proceso de notas de crédito — cada nota debe referenciar el CFE original (campo l10n_uy_cfe_uuid o equivalente).
  5. Corrida en sandbox DGI — no "el PAC dijo ok" sino intercambio XML real con el ambiente de prueba DGI sobre tus datos.
  6. Monitoreo del rejection rate — primeras dos semanas post-go-live: 1–3% es normal, arriba de 5% es incendio.

Cuándo funciona y cuándo no: 5 situaciones reales

No toda PYME uruguaya enfrenta el mismo proyecto. La estimación de esfuerzo y costo depende del perfil. Si querés saber qué pasa con una mala migración antes de tiempo, mirá qué incluye un rescate de proyecto Odoo.

1. PYME pequeña, B2B, sin exportación, Odoo Enterprise con l10n_uy al día — la migración a 25-1 son 2 a 5 días de trabajo del integrador más testing de regresión. Caso simple. Costo: USD 1.500 a 4.000.

2. Retail (sucursales múltiples, POS, miles de SKU) — la migración se convierte en proyecto de limpieza de catálogo. Sin mapeo GTIN para 80%+ de los productos activos, el CFE no pasa validación en 6–12 meses (cuando DGI suba los warnings a rejections). Son entre 3 y 8 semanas de trabajo de catalogador más IT. Costo: USD 8.000 a 25.000.

3. Exportación (carne, soja, lácteos, electrónica) — la migración incluye integración con VUCE y Aduana. Los campos IncotermReferenciaVUCEModalidadTransporte deben venir automáticamente del WMS o TMS. Son entre 6 y 12 semanas de proyecto. Costo: USD 15.000 a 60.000. ROI enorme: la tasa de error en CFE de exportación impacta directo en riesgo de auditoría y base imponible.

4. Modificaciones custom sobre l10n_uy (funciones de despacho reescritas, campos propios, QWeb-templates con branding) — la migración es refactorización parcial. Cada customización debe validarse contra 25-1. Sin auditoría, no te enterás qué se rompió hasta el rechazo en producción. Caso clásico para una auditoría Odoo independienteUSD 2.500 a 6.000 por una evaluación clara de riesgos.

5. Monotributo, IVA mínimo o MIDES CAE con emisión de CFE en nombre de terceros — esto no es migración. Es cambio de modelo de negocio. Opciones: pasar a régimen general (con mayor carga tributaria) o cesar esa actividad. La consulta con tu contador es obligatoria.

Cuatro errores típicos en proyectos uruguayos

Patrones repetidos en auditorías hechas entre noviembre 2025 y marzo 2026. Si tenés Odoo, vale la pena cruzar este listado con tu instalación — y si el resultado preocupa, conviene una revisión estructurada del proceso de implementación.

#1. "Mi PAC dijo que está todo listo"

El proveedor (Gosocket, Sovos, Edicom) confirma su certification sobre 25-1 — pero eso no significa que tu ERP envíe el XML correcto. Certificación PAC ≠ compatibilidad de tus datos. Entre el ERP y el PAC siempre hay una transformation layer (a menudo middleware en Python o PHP) que se rompe más seguido — especialmente con descuentos custom, operaciones multi-moneda y agregación de líneas.

Qué hacer: corrida end-to-end en sandbox DGI con datos reales de tu empresa, no el XML demo del proveedor.

#2. GTIN mapeado solo para "top products"

Las PYMEs mapean GTIN para los top 50 SKU y creen que la defensa está armada. Pero el catálogo de Odoo tiene 3.000+ products, de los cuales 200 se venden activos. Cualquier sale order con SKU sin mapear → CFE rejection → venta colgada.

Qué hacer: reporte de GTIN-coverage sobre product.templatey regla dura en sale.order: bloquear confirm si alguna línea no tiene GTIN. No warning — bloqueo.

#3. Notas de crédito "estilo corporativo"

El contador emite la credit note vía manual journal entry porque "es más rápido". En 24-x a veces pasaba (si después se reemitía una compensación). En 25-1 es imposible — sin referencia al CFE original, DGI rechaza el XML.

Qué hacer: reescribir el SOP de devoluciones. Cada nota de crédito vía módulo e-Nota de Crédito, con selección obligatoria del CFE original. Bloquear en Odoo la posibilidad de financial entries manuales sobre operaciones CFE (vía ACL en grupos de usuarios).

#4. QWeb-templates custom no actualizados

Los templates QWeb custom suelen contener campos hardcoded. En 25-1 la estructura del bloque XML Encabezado cambió — algunos tags fueron renombrados y se agregaron required fields. El template custom sigue renderizando la estructura vieja → el PDF no se condice con el XML → riesgo de auditoría.

Qué hacer: review de todos los QWeb-templates custom de documentos CFE, sync con la spec DGI vigente. Es un día de trabajo — pero suele descubrirse a través de una reclamación de cliente.

Caso real: retailer farmacéutico, 4 sucursales en Montevideo

Situación (caso anónimo, noviembre 2025 a marzo 2026): retailer uruguayo de pharma-cosmetics con 4 sucursales en Montevideo, 8.500 SKU activos, ~12.000 CFE por mes. Lanzaron Odoo 17 con l10n_uy Enterprise en 2023. El departamento interno de IT confiaba: "está todo en orden, módulo instalado, PAC configurado".

Qué se encontró en la auditoría (noviembre 2025):

  • GTIN-coverage: 23% de los SKU activos (1.950 de 8.500).
  • Las notas de crédito se emitían vía manual journal entries en el 47% de los casos (el contador lo hacía más rápido así).
  • QWeb template custom del CFE sin actualizar desde 2024 — renderizaba la estructura vieja del bloque Encabezado.
  • Sandbox-testing sobre 25-1no se hizo nunca.

Qué se hizo (diciembre 2025 a febrero 2026):

  1. Catalogación GTIN: se tercerizó a un call-center uruguayo durante 6 semanas, la cobertura subió a 94%.
  2. Reescritura del proceso de credit notes — los manual entries para CFE fueron bloqueados a nivel ACL.
  3. QWeb-templates actualizados, sync con la XSD vigente.
  4. End-to-end testing en sandbox DGI: 200 CFE de distintos tipos, rejection rate bajó de 31% a 1.5%.
MétricaAntes (nov 2025)Después (feb 2026)
GTIN coverage23%94%
Notas de crédito vía manual entry47%0% (bloqueado ACL)
Sandbox rejection rate31%1.5%
QWeb template aligned con XSD 25-1No

Resultado (marzo 2026): go-live en CFE 25-1 el 4 de marzo, production rejection rate de 0.8% en la primera semana (la norma del sector es 3 a 5%). Ningún canal de venta se detuvo.

Costo del proyecto: USD 11.400 (auditoría + catalogación GTIN + refactor + testing).
Escenario alternativo (go-live "as is"): estimación de 25%+ rejection rate la primera semana = ~3.000 ventas colgadas × ticket promedio USD 45USD 135.000 de revenue congelado más daño reputacional para la cadena.

"El módulo l10n_uy estaba instalado desde 2023 — pero nadie había probado un XML real contra el sandbox DGI. La señal de que algo estaba mal no era técnica, era organizacional: ningún equipo era dueño del compliance."

Checklist de 32 puntos: preparación a CFE 25-1

Preparamos un checklist técnico de 32 puntos — migración de Odoo a CFE 25-1, desde audit de la integración PAC hasta GTIN-coverage y regression testing en sandbox DGI. Estructurado por rol (IT, contabilidad, director de operaciones). Descargá el checklist CFE 25-1 — dejá tu mail, recibís PDF y plantilla Excel.

Si querés un benchmark con jurisdicciones cercanas, mirá las equivalencias en Chile SII 2026Colombia DIAN 2026 y Perú SUNAT 2026 — Uruguay es de los menos invasivos, pero la disciplina técnica no perdona.

25-1 no es la última versión

CFE 25-1 es un paso lógico en la evolución de la facturación electrónica uruguaya. DGI publica actualizaciones del formato cada 12 a 24 mesesy 25-226-1 ya están en el horizonte. Los sistemas que pasaron 25-1 con sangre mínima se preparan para el próximo ciclo: sandbox-testing automatizado, GTIN-discipline en el catálogo, arquitectura PAC-agnostic. Lo mismo se aplica a la capa de datos — Odoo Analytics como BI sobre ERP requiere que los flujos fiscales estén limpios primero.

Uruguay es uno de los pocos países LATAM donde la carga de compliance para PYMEs es menor que en Perú, Colombia o México (por volumen de resoluciones y frecuencia de cambios). Pero no significa "ponelo y olvidalo". Significa "ponelo bien — y olvidalo por 18 meses hasta la próxima actualización".

Si sos director de IT, CFO o dueño de PYME en Uruguay y no tenés certeza de que tu sistema esté listo para 25-1 (o ya no funciona después del 3 marzo) — una auditoría independiente da respuesta clara en 5 días hábiles. No "tu PAC dice ok" sino verificación end-to-end con sandbox DGI y análisis de tus datos reales.

Materiales relacionados

Preguntas frecuentes

¿Cuál es exactamente el deadline de producción para CFE 25-1?

3 marzo 2026. El ambiente de prueba de DGI estuvo disponible desde agosto 2025. Después del 3 marzo, los XML en formato 24-x son rechazados — eso significa que no se emite un CFE legalmente válido y la venta no puede completarse.

¿Y si mi PAC dice que está "certificado" en 25-1?

La certificación PAC significa que el proveedor puede recibir y enviar XML en el nuevo formato. No garantiza que tu ERP envíe el XML correcto. Entre el ERP y el PAC siempre hay una transformation layer — se rompe más seguido. La corrida end-to-end en sandbox DGI con datos reales es obligatoria.

¿Cuánto cuesta la migración para una PYME pequeña?

Migración base de Odoo Enterprise con l10n_uy al día, para PYME B2B sin exportación: USD 1.500 a 4.000. Con catálogo de 3.000+ SKU y retail: USD 8.000 a 25.000. Con operación de exportación (integración VUCE): USD 15.000 a 60.000.

¿Qué cambia en las notas de crédito en el formato 25-1?

Referencia obligatoria al CFE original. El monto de la nota debe ser menor o igual al original, la moneda debe coincidir, el tipo de cambio debe estar alineado. Los manual journal entries para credit notes dejan de funcionar — DGI rechaza el XML en la etapa de validación.

¿Qué hago si estoy en Monotributo y emitía CFE en nombre de terceros?

Esa práctica es técnicamente imposible a partir del 3 marzo 2026 — DGI rechaza esos XML en la validación del formato. Opciones: pasar a régimen general (mayor carga tributaria) o cesar la actividad. La consulta con tu contador es obligatoria antes de decidir.

¿Odoo Community soporta el formato 25-1?

El módulo l10n_uy en OCA soporta escenarios básicos, pero va atrasado varios releases respecto a Enterprise. Para operaciones críticas de producción (exportación, retail con miles de SKU), Enterprise es recomendado. Alternativa: extensión custom del módulo community por un integrador con experiencia.

¿Qué incluyen los nuevos campos VUCE en los CFE de exportación?

IndicadorPaisModalidadTransporteIncotermReferenciaVUCE (número DUA). DGI y Aduana hacen cross-validation de estos campos; las discrepancias contra el DUA son red flag para auditoría tributaria y aduanera.

¿Cuánto tarda la limpieza de catálogo GTIN para un retailer?

Para un retailer con 5.000 a 10.000 SKU activos, la catalogación GTIN tercerizada lleva entre 4 y 8 semanas — depende de la calidad del data base de origen. En paralelo, se implementa la regla de bloqueo en sale.order para que ningún ítem sin GTIN llegue a confirmación. Ese paso es el que evita rejections en el día post-go-live.