Hacienda 4.4 recovery: guía para PYMEs de Costa Rica que no migraron desde 4.3

Resumen en un minuto

Si tu PYME todavía emite comprobantes electrónicos en versión 4.3, ya estás en territorio de sanciones acumulativas y rechazos por parte de clientes corporativos. La versión 4.4 fue obligatoria desde el 1 de septiembre de 2025, no hay tercera prórroga y Hacienda inició auditorías a emisores rezagados en octubre. El recovery toma de 2 a 6 semanas dependiendo de tu stack ERP y del volumen de master data que arrastres.

• Versión 4.4 obligatoria desde el 1 de septiembre de 2025 — Hacienda no dará una tercera prórroga; las dos primeras ya fueron en junio y septiembre de 2025.
• 140+ cambios técnicos vs 4.3: nuevo documento REP, actividad económica obligatoria del comprador, tipos de identificación ampliados, métodos de pago digitales (SINPE Móvil, plataformas) y el nuevo código de IVA 11.
• Las sanciones se acumulan: desde 1 salario base (~₡462 200 en 2026, ~USD 1 015) por período de incumplimiento, hasta suspensión de la emisión electrónica tras reincidencias.
• Recovery: 2 a 6 semanas según el ERP y el volumen de master data. El trabajo grueso no es código — es cleanup de partners y actividades económicas.
• El checklist PDF al final reúne diagnóstico, queries SQL, plantillas XML y matriz de escenarios.

Por qué Hacienda no movió el deadline una tercera vez

La versión 4.4 es la revisión más profunda del Sistema de Comprobantes Electrónicos desde que Costa Rica lanzó facturación electrónica en 2018. Hacienda publicó la documentación técnica en noviembre de 2024. El inicio obligatorio original era el 1 de junio de 2025; se movió al 1 de septiembre. No habrá tercera prórroga.

Las razones de fondo:

• La versión 4.3 solo cerró parte de las brechas de la reforma de IVA de 2018. La 4.4 cierra el resto — especialmente el criterio de caja en credit sales y el trato a operaciones con entidades públicas.
• Los compromisos OCDE de Costa Rica como hub de nearshoring para Estados Unidos exigen trazabilidad de operaciones electrónicas. 4.4 es parte del paquete.
• El ciclo de auditoría sobre emisores 4.3 arrancó en octubre de 2025. Ya no es un riesgo teórico.

Qué significa eso si seguís en 4.3:

• Hacienda sabe. Cada XML que tu proveedor envía con tu cédula jurídica como receptor en la versión nueva queda registrado. Si vos emitís 4.3 y tu entorno está en 4.4, el sistema ve la inconsistencia.
• Los clientes grandes empiezan a rechazar. Multinacionales y entidades públicas ya devuelven documentos en 4.3 — el REP para invoices a entidades públicas entró en vigor con el deadline.
• Cada día el recovery cuesta más. El volumen de correctivos pendientes crece: 500 invoices al mes en 4.3 son 500 potenciales correcciones.

Qué cambia técnicamente: 7 bloques clave

#1. REP — Recibo Electrónico de Pago

El cambio más sustantivo. Un documento electrónico separado que confirma la recepción efectiva del pago. Es obligatorio en dos casos:

• Credit sales con IVA diferido. Si el invoice se emite hoy y la deuda se paga a 30, 60 o 90 días, el IVA se reconoce al recibir el pago (criterio de caja). El REP fija el timing para el recovery del IVA.
• Invoices a entidades públicas. Cualquier documento dirigido a un ministerio, municipalidad o entidad autónoma exige REP en el momento del pago.

El workaround viejo — Nota de Crédito o Recibo Genérico — ya no es válido. Hacienda exige específicamente el REP con su propio XML schema y enlace por Referencia al invoice original.

#2. Códigos de actividad económica del receptor

Desde el 1 de septiembre de 2025, cada purchase invoice debe llevar el código de actividad económica del comprador. No es un campo estático: una cédula jurídica puede tener varias actividades registradas, y en el invoice se indica aquella bajo la cual la operación califica para recovery de IVA.

Impacto en master data:

• El ERP debe almacenar todas las actividades registradas del contrapartner, no solo la primaria.
• Al crear el invoice hay que elegir explícitamente, o asignar por defecto, la actividad correspondiente a la operación.
• Si el código no aparece, el invoice se rechaza en validación. No es warning, es hard reject.

#3. Tipos de identificación ampliados

Categorías nuevas que no existían en 4.3:

• Identificación de no domiciliado especial — para extranjeros con presencia tributaria.
• Identificación de extranjero no domiciliado — para invoices a compradores extranjeros sin registro en Costa Rica.
• No contribuyente — para personas u organizaciones sin obligación de reporte fiscal.

El workaround viejo — usar cédula extranjera para todo extranjero — ya recibe rechazo del ATV.

#4. Métodos de pago digitales

Los métodos de pago reconocidos se ampliaron con códigos específicos: SINPE Móvil, tarjeta crédito/débito vía POS (con códigos separados para autorización vs aplicación), plataformas digitales (PayPal, Stripe, MercadoPago). Si tenés integración POS con CGS Card o Pinpad, hay que verificar que los códigos nuevos estén mapeados.

#5. Clasificaciones de IVA — el nuevo código 11

Matriz de códigos IVA ampliada:

El código 11 es crítico para operaciones específicas (algunos servicios financieros, sub-operaciones inmobiliarias) donde antes se usaba el 05 Exento. Si seguís usando 05 para esos casos, el IVA recoverable del comprador queda mal calculado — y eso aparece en auditoría.

#6. Validaciones del XSD schema

El XSD está completamente actualizado. XMLs viejos con campos 4.3 en el namespace nuevo se rechazan automáticamente en el envío a Hacienda — ni siquiera llegan a revisión. Las validaciones concretas que rompen migraciones:

• Receptor.IdentificacionExtranjero es obligatorio si Receptor.NoExisteIdentificacion = "true".
• MontoTotalServGravados04 — campo separado para la tarifa del 4%.
• OtrosCargos.TipoDocumento ahora acepta solo valores enumerados (antes aceptaba texto libre).

#7. Timeline normativo

Cuándo el recovery es simple y cuándo es proyecto serio

#1. Odoo 17 o 18 con l10n_cr actualizado — 2 a 3 días

Odoo Community o Enterprise 17 o 18, con módulo l10n_cr instalado vía OCA o partner-fork. El recovery se reduce a hacer pull del último l10n_cr-44, correr un script de migration para master data (asignar actividad_economica_id a los partners), regenerar las plantillas XSD y probar envíos contra el sandbox de Hacienda.

#2. Odoo viejo (15 o 16) con l10n_cr custom — 2 a 3 semanas

Odoo 15 o 16, con l10n_cr custom o desactualizado. Recovery: primero upgrade de Odoo a 17 o 18 (es un proyecto aparte), después instalar l10n_cr-44 limpio, migration de master data, training de usuarios. El grueso es el upgrade de Odoo. El l10n_cr son los últimos 3 días.

#3. ERP local (Softland, Codisa, EFinance) — depende del vendor

Los vendors locales tienen sus propios parches. La mayoría ya publicó actualizaciones. Recovery: verificar que tu vendor tenga un release compatible con 4.4, comprar el patch (suele cobrarse aparte de la suscripción), seguir el cleanup de master data (que el vendor no siempre hace). Si tu vendor todavía no sacó el patch, es red flag: evaluá alternativas.

#4. Excel + XML manual — migrar a un ERP

Si seguís generando XML a mano con Excel y un signer externo, el recovery no tiene sentido. La 4.4, con 140+ cambios, vuelve el enfoque manual demasiado error-prone. Lo realista es migrar a un ERP (Odoo, Alegra Pro, Defontana) en 4 a 6 semanas.

#5. Solo tiquetera POS sin credit sales — caso simple

Restaurante o retail chico con tiquetes electrónicos (sin factura-to-customer y sin credit terms): el recovery es relativamente simple — verificar que el vendor del POS actualizó el firmware y que los nuevos IDs de catálogos funcionan. El REP no aplica a este escenario.

5 errores típicos durante el recovery

#1. Actualizan la versión del XML, pero no el master data

El error más común. El equipo actualiza el envelope XML a 4.4, pero actividad_economica_id queda en null para todos los partners. Resultado: tasa de rechazo del 100%.

Fix: asignar la actividad antes del primer envío. Un script de migration llena un valor por defecto y después se hace revisión manual sobre los top-50 clientes críticos.

#2. No emiten REP — y después se sorprenden con la diferencia de IVA

Invoice credit-sale por ₡1 000 000 + IVA 13%. El comprador paga a 60 días. El equipo no emite REP porque cree que con el invoice alcanza. En la auditoría: el IVA no es recoverable para el comprador (el momento del recovery es la recepción del pago, y no hay REP). El comprador pierde ₡130 000 en deducción. Si se repite, se pierde el contrato.

Fix: el REP es documento obligatorio para cada pago de credit-sale. Automatizá su generación en el momento de la recepción del cash.

#3. Usan catálogos viejos (CABYS, unit codes)

En 4.4 se actualizaron CABYS (Catálogo de Bienes y Servicios), códigos de unidades, códigos de pago. Un ERP con diccionarios cacheados de 2024 produce invoices rechazados en validación.

Fix: hacer pull del CABYS más reciente desde el portal de Hacienda cada 6 meses. Es un dataset público y gratuito.

#4. Workarounds manuales en lugar de parche

La tentación: «funciona con un workaround vía custom script — ¿para qué pagar el upgrade?». El script custom puede generar un XML que pasa la validación, pero no cumple con la spec 4.4 en casos borde. Hacienda mira la estructura del XML, no el business outcome.

Fix: usar el l10n_cr oficial o el patch del vendor. Los módulos custom solo deberían cubrir lógica de negocio, no compliance.

#5. No testean en el sandbox de Hacienda

El ATV provee un entorno sandbox para probar envíos 4.4. La mayoría de las PYMEs va directo a producción — el primer envío 4.4 ocurre sobre invoices reales. Si algo se rompe, se rompe sobre datos productivos.

Fix: mínimo 50 invoices representativos enviados al sandbox antes del cutover a producción.

Caso: PYME de servicios en San José, ~₡180M de facturación anual

Situación (agosto 2025). Contabilidad sobre Odoo 16 Community + workarounds en Excel para compliance. l10n_cr con última actualización en 2023. Equipo: 2 contadores y el dueño. Tasa de rechazo sobre 4.3 — alrededor del 6% (los workarounds a veces generaban XML inválido).

Recovery (4 semanas).

• Semana 1 — auditoría del estado actual: 240 customers (47 sin actividad económica), 89 suppliers (12 con tipo de identificación incorrecto), integración POS con CGS Card que exigía update de firmware.
• Semana 2 — upgrade de Odoo 16 a 18, instalación limpia de l10n_cr-44, scripts de migration de base.
• Semana 3 — cleanup de master data: script bulk para actividades + revisión manual de los top-50 customers, refresh de catálogos CABYS, reconfiguración de códigos POS.
• Semana 4 — sandbox testing con 100 invoices representativos, fix de casos borde (3 problemas con timing del REP en credit-sales pre-existentes), cutover a producción.

Resultado a los 3 meses:

• Tasa de rechazo: 0,3% (vs 6%).
• REP emitido correctamente en todos los credit-sales — desapareció el mismatch de IVA con el cliente top.
• Tiempo de compliance por invoice: de 8 minutos (4.3 + workarounds) a 30 segundos.
• Costo del recovery: ~USD 4 200 (upgrade de Odoo + consultoría de partner).
• Sanciones evitadas en 3 meses sobre 4.3: ~USD 3 800.

El payback fueron 4 meses sobre las sanciones evitadas, más el trabajo recuperado.

Pensábamos que el problema iba a ser técnico. Resultó que el 80% del tiempo fue cleanup de partners y revisión de actividades una por una.

Qué hay dentro del checklist Hacienda 4.4 Recovery (PDF completo)

En la versión completa que te enviamos por email vas a encontrar:

• Diagnostic worksheet — 18 preguntas en una página: lo llenás y sabés en qué escenario estás (A, B, C, D, E).
• Queries SQL para auditoría de master data — encontrar partners sin actividad, customers con tipo de ID incorrecto, productos con CABYS desactualizado.
• Plantillas XML 4.4 — para cada tipo de documento (FE, TE, NC, ND, REP) con campos comentados.
• Sandbox testing script — ejemplos en bash + curl para validar envíos.
• Migration timeline template — Gantt de 2, 4 o 6 semanas según escenario.
• Matriz comparativa de vendors — forks de l10n_cr (4 opciones), Softland, Codisa, EFinance: última actualización, precio, calidad de soporte.

Descargar el checklist completo Hacienda 4.4 Recovery (PDF + Excel) →

Preguntas frecuentes