Hacienda 4.4 recovery: a guide for Costa Rica SMBs that never migrated from 4.3

One-minute summary

If your SMB still emits electronic receipts in version 4.3, you are already in cumulative-fine territory and getting rejected by corporate customers. Version 4.4 has been mandatory since September 1, 2025, there is no third extension, and Hacienda began auditing lagging emisores in October. Recovery takes 2 to 6 weeks depending on your ERP stack and the volume of master data you carry.

• Version 4.4 mandatory since September 1, 2025 — Hacienda will not grant a third extension; the first two were in June and September 2025.
• 140+ technical changes vs 4.3: new REP document, mandatory buyer actividad económica, expanded ID types, digital payment methods (SINPE Móvil, platforms), and the new VAT code 11.
• Fines compound: from 1 base salary (~₡462,200 in 2026, ~USD 1,015) per non-compliance period, all the way to suspension of electronic emission for repeat offenders.
• Recovery: 2 to 6 weeks depending on ERP and master-data volume. The heavy lifting is not code — it is partner and economic-activity cleanup.
• The PDF checklist at the end bundles diagnostics, SQL queries, XML templates, and a scenario matrix.

Why Hacienda did not push the deadline a third time

Version 4.4 is the deepest revision of the Sistema de Comprobantes Electrónicos since Costa Rica launched electronic invoicing in 2018. Hacienda published the technical documentation in November 2024. The original obligatorio start was June 1, 2025; it moved to September 1, 2025. There will be no third extension.

The underlying reasons:

• Version 4.3 closed only part of the gaps from the 2018 VAT reform. Version 4.4 closes the rest — especially the criterio de caja on credit sales and operations with public entities.
• Costa Rica's OECD commitments as a nearshoring hub for the United States demand traceability of electronic operations. 4.4 is part of that package.
• The audit cycle on 4.3 emisores started in October 2025. It is no longer a theoretical risk.

What this means if you are still on 4.3:

• Hacienda knows. Every XML your supplier sends with your cédula jurídica as receptor in the new version gets logged. If you emit 4.3 and your environment is on 4.4, the system sees the mismatch.
• Large customers start to reject. Multinationals and public entities already bounce 4.3 documents — the REP for invoices to public entities took effect at the deadline.
• Every day, recovery costs more. The backlog of pending corrections grows: 500 invoices a month on 4.3 means 500 potential corrections.

What changes technically: 7 key blocks

#1. REP — Recibo Electrónico de Pago

The biggest substantive change. A separate electronic document that confirms the actual receipt of payment. Mandatory in two cases:

• Credit sales with deferred VAT. If the invoice is issued today and the debt is paid in 30, 60, or 90 days, VAT is recognized when the payment lands (criterio de caja). The REP fixes the timing for VAT recovery.
• Invoices to public entities. Any document addressed to a ministerio, municipalidad, or autonomous entity requires a REP at payment time.

The old workaround — Nota de Crédito or Recibo Genérico — is no longer valid. Hacienda specifically requires the REP, with its own XML schema and a Referencia link back to the original invoice.

#2. Buyer's economic-activity codes

Since September 1, 2025, every purchase invoice must carry the buyer's economic-activity code. It is not a static field: a single cédula jurídica can have multiple registered activities, and the invoice must indicate the one under which the operation qualifies for VAT recovery.

Master-data impact:

• The ERP must store all registered counterparty activities, not just the primary one.
• At invoice creation, you either explicitly pick or default the activity for the specific operation.
• If the code is missing, the invoice is rejected at validation. Not a warning — a hard reject.

#3. Expanded identification types

New categories that did not exist in 4.3:

• Identificación de no domiciliado especial — for foreigners with tributary presence.
• Identificación de extranjero no domiciliado — for invoices to foreign buyers with no Costa Rican registration.
• No contribuyente — for individuals or organizations with no fiscal-reporting obligation.

The old workaround — tagging every foreigner with cédula extranjera — now gets rejected by the ATV.

#4. Digital payment methods

Recognized payment methods now ship with specific codes: SINPE Móvil, credit/debit card via POS (with separate codes for authorization vs application), digital platforms (PayPal, Stripe, MercadoPago). If you run a POS integration with CGS Card or Pinpad, verify that the new codes are mapped correctly.

#5. VAT classifications — the new code 11

Expanded VAT-code matrix:

Code 11 is critical for specific operations (some financial services, real-estate sub-operations) that previously used 05 Exempt. Keep using 05 for those cases and the buyer's recoverable VAT is miscalculated — which surfaces in audit.

#6. XSD schema validations

The XSD is fully refreshed. Old XMLs with 4.3 fields under the new namespace are auto-rejected at submission to Hacienda — they do not even reach review. The concrete validations that break migrations:

• Receptor.IdentificacionExtranjero is mandatory if Receptor.NoExisteIdentificacion = "true".
• MontoTotalServGravados04 — separate field for the 4% rate.
• OtrosCargos.TipoDocumento now accepts only enumerated values (it used to accept free text).

#7. Regulatory timeline

When recovery is simple and when it is a real project

#1. Odoo 17 or 18 with up-to-date l10n_cr — 2 to 3 days

Odoo Community or Enterprise 17 or 18 with the l10n_cr module installed via OCA or a partner fork. Recovery reduces to pulling the latest l10n_cr-44, running a migration script for master data (assign actividad_economica_id to partners), regenerating XSD templates, and testing submissions against Hacienda's sandbox.

#2. Old Odoo (15 or 16) with custom l10n_cr — 2 to 3 weeks

Odoo 15 or 16, with l10n_cr either custom or outdated. Recovery: upgrade Odoo to 17 or 18 first (a project on its own), then install a clean l10n_cr-44, migrate master data, and train users. Most of the work is the Odoo upgrade. The l10n_cr part is the last three days.

#3. Local ERP (Softland, Codisa, EFinance) — depends on vendor

Local vendors have their own patches. Most have shipped updates. Recovery: verify your vendor has a 4.4-compatible release, buy the patch (usually billed separately from the subscription), and follow up on master-data cleanup (which the vendor often does not handle). If your vendor has not shipped a patch yet, that is a red flag — evaluate alternatives.

#4. Excel + manual XML — move to an ERP

If you still generate XML by hand in Excel with an external signer, recovery makes no sense. 4.4, with 140+ changes, makes the manual approach too error-prone. The realistic move is migrating to an ERP (Odoo, Alegra Pro, Defontana) in 4 to 6 weeks.

#5. POS-only without credit sales — easy case

Restaurants or small retail with electronic tiquetes (no factura-to-customer, no credit terms): recovery is relatively simple — verify the POS vendor updated the firmware and that the new catalog IDs work. REP does not apply here.

5 common mistakes during recovery

#1. They update the XML version but not the master data

The most common mistake. The team updates the XML envelope to 4.4, but actividad_economica_id stays null on all partners. Result: 100% rejection rate.

Fix: assign the activity before the first submission. A migration script fills a default value, then manual review covers the top-50 critical customers.

#2. They skip REP — then get surprised by the VAT gap

Credit-sale invoice for ₡1,000,000 + 13% VAT. The buyer pays in 60 days. The team skips the REP, assuming the invoice is enough. In audit: VAT is not recoverable for the buyer (recovery timing is payment receipt, and no REP exists). The buyer loses ₡130,000 in deduction. Repeat the pattern and you lose the contract.

Fix: REP is a mandatory document for every credit-sale payment. Automate generation at cash-reception time.

#3. They use stale catalogs (CABYS, unit codes)

In 4.4, CABYS (Catálogo de Bienes y Servicios), unit codes, and payment codes were refreshed. An ERP with 2024-cached dictionaries produces invoices rejected at validation.

Fix: pull the latest CABYS from Hacienda's portal every six months. It is a public, free dataset.

#4. Manual workarounds instead of patches

The temptation: "it works with a custom-script workaround — why pay for the upgrade?". The custom script may produce XML that passes validation, but does not conform to the 4.4 spec in edge cases. Hacienda looks at the XML structure, not the business outcome.

Fix: use official l10n_cr or your vendor's patch. Custom modules should only cover business logic, not compliance.

#5. They do not test in Hacienda's sandbox

The ATV provides a sandbox to test 4.4 submissions. Most SMBs jump straight to production — the first 4.4 submission lands on real invoices. If anything breaks, it breaks on production data.

Fix: minimum 50 representative invoices through the sandbox before production cutover.

Case: a services SMB in San José, ~₡180M annual revenue

Situation (August 2025). Bookkeeping on Odoo 16 Community + Excel workarounds for compliance. l10n_cr last updated in 2023. Team: 2 accountants and the owner. Rejection rate on 4.3 — around 6% (workarounds occasionally produced invalid XML).

Recovery (4 weeks).

• Week 1 — audit current state: 240 customers (47 with no economic activity), 89 suppliers (12 with the wrong ID type), POS integration with CGS Card requiring a firmware update.
• Week 2 — upgrade Odoo 16 to 18, install fresh l10n_cr-44, database migration scripts.
• Week 3 — master-data cleanup: bulk script for activities + manual review of top-50 customers, refresh CABYS catalogs, reconfigure POS codes.
• Week 4 — sandbox testing on 100 representative invoices, fix edge cases (3 issues with REP timing on pre-existing credit sales), production cutover.

Result at 3 months:

• Rejection rate: 0.3% (vs 6%).
• REP correctly issued on every credit sale — the VAT mismatch with the top customer disappeared.
• Compliance time per invoice: from 8 minutes (4.3 + workarounds) to 30 seconds.
• Recovery cost: ~USD 4,200 (Odoo upgrade + partner consulting).
• Fines avoided over 3 months on 4.3: ~USD 3,800.

Payback was 4 months on avoided fines, plus reclaimed labor.

We thought the problem would be technical. It turned out 80% of the time was cleanup of partners and reviewing economic activities one by one.

What is inside the Hacienda 4.4 Recovery checklist (full PDF)

In the full version we email you, you will find:

• Diagnostic worksheet — 18 questions on one page: fill it out and you know your scenario (A, B, C, D, E).
• SQL queries for master-data audit — find partners with no activity, customers with the wrong ID type, products with stale CABYS.
• XML 4.4 templates — for every document type (FE, TE, NC, ND, REP) with annotated fields.
• Sandbox testing script — bash + curl examples for submission validation.
• Migration timeline template — 2, 4, or 6-week Gantt depending on scenario.
• Vendor comparison matrix — l10n_cr forks (4 options), Softland, Codisa, EFinance: last update, pricing, support quality.

Download the full Hacienda 4.4 Recovery checklist (PDF + Excel) →

Frequently asked questions