Test CFE 25-1: ¿está lista tu Odoo para el nuevo formato DGI?

Resumen en un minuto

El 3 de marzo de 2026 la DGI cerró el formato CFE 24 y dejó al 25-1 como única versión válida en producción. Casi tres meses después, una parte importante de las PYME uruguayas sigue emitiendo CFE que la DGI rebota en validación — no por mala fe, sino porque su instalación de Odoo nunca pasó por el test que el regulador deja abierto 24/7 en homologación.

Si sos director, contador o dueño de PYME y tu Odoo emitió aunque sea un CFE desde el 3 de marzo, este test debería estar corriendo en tu agenda mensual. No "en algún momento": ahora, con los escenarios que la propia DGI publica, antes de que un comprador te llame preguntando dónde está su factura.

En este artículo te muestro cómo se prueba un Odoo contra el formato CFE 25-1, qué valida la DGI por debajo, dónde tropieza la mayoría de las instalaciones community y qué setting de l10n_uy hay que tocar para dejar de coleccionar RECHAZADO. Sin relleno, con referencias a recursos oficiales y casos reales de abril–mayo de 2026.

• CFE 25-1 es obligatorio desde el 3 de marzo de 2026. La DGI ya no acepta el formato anterior para emisión productiva.
• El ambiente de homologación de la DGI está disponible 24/7; cualquier emisor puede correr sus escenarios antes de mandar a producción.
• Seis chequeos clave en el test: vínculo de notas de crédito con el CFE original, GTIN/EAN para retail, campos logísticos VUCE para exportación, uso correcto del Sales Mode 91, validación del tipo de cambio BCU en multi-moneda y tributos coherentes para Monotributo / IVA mínimo.
• El módulo community l10n_uy llegó a la versión 25-1 con dos a tres meses de atraso: el stable apareció en febrero de 2026, justo sobre el deadline.
• Multas DGI por CFE inválido: rango UY$ 4 000 – UY$ 36 000 por incidente. En reincidencia, suspensión del estatus de emisor.

Contexto: por qué 25-1 no es cosmética

El CFE nació en Uruguay en 2012 y es uno de los sistemas de facturación electrónica más viejos de la región. Hasta 2024 los cambios fueron cosméticos. La versión 25-1 es la primera reforma estructural en cinco años, y tiene tres motores detrás.

• Integración con VUCE (Ventanilla Única de Comercio Exterior) para dar trazabilidad a las operaciones de exportación.
• Alineamiento con GS1 Uruguay en los estándares de retail (GTIN/EAN obligatorio en lugar de opcional).
• Cierre de ventanas grises en notas de crédito, que históricamente se usaron para inflar deducciones; ahora el vínculo criptográfico con el CFE original es obligatorio.

La cronología que importa cabe en cuatro filas.

Lo que cambió por debajo es estructura XML que la DGI parsea con tolerancia cero. Si un campo falta o el formato no coincide, el endpoint devuelve <RESULTADO>RECHAZADO</RESULTADO> y el comprobante queda sin existencia jurídica.

1. Notas de crédito — referencia obligatoria al CFE original: tipo, serie, número, monto, moneda y fecha. La DGI valida la coincidencia de los cinco campos.
2. GTIN/EAN — para CFE de retail (Tipo 101 y 111), el código GS1 deja de ser opcional.
3. Campos logísticos de exportación — DUA, código de cancha portuaria, modalidad de transporte. Todo se envía a VUCE automáticamente.
4. Sales Mode 91 — Mandating Export — código nuevo para el caso "exportador uruguayo vende a través de un intermediario comercial". Antes se codificaba como exportación común.
5. Prohibición de CFE de terceros para emisores en IVA mínimo, Monotributo y MIDES CAE: no pueden emitir CFE en nombre de otras empresas.
6. Tipo de cambio en multi-moneda — fijación obligatoria del tipo BCU del día de emisión. Antes la DGI aceptaba cualquier fuente.

Cómo Odoo se prepara: 6 chequeos técnicos

Toda instalación de Odoo que emita CFE tiene que pasar seis chequeos antes de tocar producción. Acá va el desglose en orden de impacto.

#1. Versión correcta de l10n_uy

La OCA mantiene l10n_uy_account, l10n_uy_invoice y l10n_uy_cfe. La actualización a 25-1 salió en febrero de 2026 — pegado al deadline. Si tenés Odoo 16 o 17 community con l10n_uy anterior a esa fecha, el XML se genera con la schema vieja.

Cómo se chequea: Settings → Apps → Installed → l10n_uy*, columna Latest version. Si la fecha de aplicación es anterior al 15 de febrero de 2026, actualizá ya. Odoo Enterprise por canal partner recibe el update automáticamente, pero solo si el maintenance contract está activo, y eso se omite más seguido de lo que parece.

#2. Certificado de firma electrónica

El certificado tiene que estar emitido por una CCA acreditada en la UCE. Para 25-1 la DGI acepta certificados de El Correo Uruguayo, Abitab y El País Digital. Los certificados viejos de CA ya no acreditadas se rechazan en handshake.

Cómo se chequea: Accounting → Configuration → Companies → Electronic Invoice → Certificate expiration. Si vence en los próximos 90 días, renová con anticipación: la renovación por CA estatal toma 5–10 días hábiles.

#3. Conexión con el WebService de la DGI

La DGI recibe los CFE por SOAP. En 25-1 cambiaron los endpoints — producción y homologación quedaron en puertos y rutas distintos. Si tu configuración tiene el endpoint viejo, todos los requests caen en timeout o en error de handshake TLS.

Es un problema frecuente: en l10n_uy_cfe.cfg el default viejo queda hardcodeado y no se actualiza solo en el upgrade del módulo.

#4. Configuración de tipos de documento

El CFE 25-1 distingue tipos básicos con criterio estricto.

Si emitís out_invoice genérico sin mapeo concreto contra l10n_uy.document.type, la DGI rebota en el primer request.

#5. Campos para integración VUCE (exportación)

Para Tipo 121 (e-Factura Exportación) en 25-1 se completan estos campos.

• DUACode — número de DUA (Documento Único Aduanero).
• MTransporte — modalidad (1=Marítimo, 2=Aéreo, 3=Terrestre, 4=Ferroviario, 5=Postal, 8=Multimodal).
• CodPaisDest — país destino en ISO 3166-1 alpha-2.
• Incoterm — estándar ICC 2020.

En el l10n_uy_cfe estándar estos campos no aparecen en el formulario de factura. Hace falta un parche custom o el módulo l10n_uy_export del repositorio OCA l10n-uruguay (release de marzo de 2026).

#6. Tipo de cambio en multi-moneda

Cuando emitís un CFE en moneda extranjera, Odoo toma el tipo de cambio desde Configuration → Currencies → Rates. Con 25-1 la DGI exige el tipo BCU del día de emisión — no el de ayer ni un promedio mensual. Si la sincronización automática de tipos está apagada (default en community), cada CFE de exportación va a salir con error.

Escenarios reales: cuándo pasa el test y cuándo no

Cuatro situaciones típicas de PYME uruguayas en abril y mayo de 2026, en orden creciente de dificultad.

#1. Pasa: comercio retail con una caja, Odoo 17 Enterprise

Una sola sucursal, emisión solo de e-Ticket (Tipo 101), productos con GTIN cargado en product.template.barcode, moneda solo UYU. El partner actualizó l10n_uy el 20 de febrero de 2026. El test pasa en todos los escenarios sin parches custom: alcanzan 5 escenarios en homologación y una hora de trabajo.

#2. Pasa con ajustes: importador B2B multi-moneda

Importás mercadería, emitís e-Factura (Tipo 111) en UYU y USD, ocasionalmente e-Resguardo (Tipo 141) en retenciones. Odoo 17 Community con l10n_uy de febrero de 2026. Hay que prender la sincronización automática de tipo de cambio BCU, mapear account.tax contra los tributos uruguayos (IVA Básica 22 %, IVA Mínima 10 %, IRAE Anticipo) y revisar que partner.l10n_uy_cfe_doc_type tenga el tipo correcto (RUT/CI/Pasaporte) para cada contacto. El test pasa después de 2–4 horas de ajuste.

#3. No pasa: exportador sin l10n_uy_export

Emitís Tipo 121, vendés a través de un intermediario comercial en Brasil (Sales Mode 91), usás Odoo Community con l10n_uy base. Te faltan los campos VUCE (DUA, MTransporte, Incoterm), la lógica del Sales Mode 91 y el vínculo con el código TUPA del régimen aduanero. La DGI rebota cada intento. La solución es desarrollo custom o el salto a Enterprise más el módulo l10n_uy_export. Plazo realista: 2–4 semanas de trabajo.

#4. No pasa: Monotributista usando un Odoo ajeno

Sos Monotributista, el contador "te dejó usar" su Odoo para emitir CFE desde su emisor. Con 25-1 eso está prohibido: cada Monotributista necesita su propia registración de emisor en la DGI. Ningún test va a pasar porque el rechazo cae en la validación de RUT, antes de evaluar la schema. La salida es registrarte como emisor independiente (gratis vía e-Factura DGI) y conectar tu propio Odoo o una multicompany.

Los 5 errores más caros

#1. "Ya lo arreglamos cuando rebote el primero"

El reflejo más común en PYME es esperar a que la DGI rebote un CFE para reaccionar. El problema: en Uruguay, rebote significa que el comprobante no existe jurídicamente aunque la mercadería ya salió. El cliente no puede pagar porque no hay CFE válido, la contabilidad no cierra el período y la DGI suma mora por cada día. Lo correcto es correr 20 escenarios mínimos en homologación antes de la primera emisión productiva.

#2. "Actualizamos el módulo, ya está todo bien"

Actualizar l10n_uy cambia la schema XML, pero no reconfigura datos existentes. Los productos sin GTIN, los contactos con tipo RUT incorrecto y los taxes sin mapeo siguen como estaban. El test rebota en el primer e-Ticket. Después de cada upgrade hace falta un data audit corto sobre productos, partners, taxes y monedas.

#3. Usar el certificado de homologación en producción

La DGI emite dos certificados separados: test y producción. Es muy común dejar Odoo con el certificado de test, y entonces todos los requests caen con la firma rechazada como "not valid for production". Separá test y prod en bases distintas y nunca cruces certificados.

#4. Notas de crédito sin referencia al original

En Odoo, Refund Invoice crea la nota de crédito automáticamente, pero no siempre llena referencia_documento_original — sobre todo si el comprobante original se emitió antes del upgrade. La DGI rebota la nota y se pierde la deducibilidad. Revisá manualmente la primera nota de crédito post-migración: Logs → CFE XML → bloque <Referencia>.

#5. Ignorar el Sales Mode 91 en exportación con intermediario

Los CFE de exportación viejos iban como Sales Mode 1 (exportación directa). Con 25-1, cuando hay un intermediario comercial el código es 91. Si lo dejás en 1, la DGI acepta el CFE, pero la operación nunca aparece en la declaración VUCE — y la aduana bloquea la próxima partida. Es un error que se descubre tarde y caro.

Caso anónimo: exportador textil de Canelones

Caso anonimizado, armado sobre una situación típica que revisamos con un contador de Montevideo en abril de 2026.

La situación. Fabricante de tejidos de punto que exporta a Brasil y Argentina a través de un agente comercial en São Paulo. Volumen: ~USD 2,5 M/año, cerca de 300 CFE de exportación por año. Odoo 16 Enterprise, l10n_uy base, sin l10n_uy_export. El partner actualizó el módulo el 1 de marzo de 2026 — dos días antes del deadline.

Lo que apareció en el test. Una corrida de 15 escenarios en homologación el 5 de marzo dejó el siguiente cuadro:

• 12 de 15 e-Factura Exportación (Tipo 121) — RECHAZADO por falta de DUACode y MTransporte.
• 3 de 3 con Sales Mode 91 — RECHAZADO, el campo nunca llegaba al XML.
• 5 de 5 e-Resguardo (Tipo 141) por retención de IRAE — aceptados; el problema estaba acotado al bloque de exportación.

Lo que hicimos. Tres pasos en 12 días hábiles.

1. Instalamos el módulo OCA l10n_uy_export (beta el 5 de marzo, stable el 18 de marzo).
2. Cargamos custom fields a nivel partner para el intermediario comercial (mapeo del Sales Mode).
3. Pre-cargamos Incoterm FOB Montevideo automático para todas las líneas de exportación.

Resultado a 30 días. Todas las e-Factura Exportación pasan validación. El tiempo de emisión por CFE bajó de 12 minutos de ajuste manual a 90 segundos. Se recuperó deducibilidad de 3 notas de crédito que la DGI había rebotado antes. Costo: USD 3 800 de trabajo único más el soporte OCA del módulo (sin costo recurrente).

El test en homologación no encontró nada inesperado: encontró todo lo que el partner no había priorizado antes del deadline. La diferencia fue ordenar el descubrimiento antes de que el primer cliente brasilero quedara sin factura.

Checklist + cómo seguir

Para hacer tu propio test, armé un Checklist CFE 25-1 para Odoo de 18 páginas: 47 puntos de control segmentados por tipo de CFE, plantillas XML listas para homologación y ejemplos de mensajes de rechazo de la DGI con su decodificación.

Bajalo gratis (con email) en data-metrics.pro/checklist-cfe-25-1. Si preferís delegar, reservá 30 minutos de auditoría de tu instalación Odoo y vamos juntos a los seis chequeos.

CFE 25-1 no es maquillaje: es una schema XML nueva que la DGI parsea sin clemencia. El test en homologación es la forma práctica de saber, antes de que un comprador llame, si tu Odoo está generando un documento válido. La diferencia entre un emisor preparado y uno que improvisa son seis chequeos, media jornada de data audit y la disciplina de correr el test después de cada upgrade.

Para ver cómo encaja CFE 25-1 dentro del stack uruguayo, mirá la guía pillar de DGI CFE 25-1, la implementación de Odoo en Uruguay, el servicio de implementación, la recuperación de proyectos Odoo o el checklist de auditoría Odoo.

Sergei Filatov / Hacker Sergio — Forbes 30 Under 30 LATAM, Lima. Ayudo a PYME en LATAM a no perder plata por compliance mal armado o instalaciones Odoo sin disciplina. Sobre mí · Portfolio.

Preguntas frecuentes