Hacienda 4.4 in Costa Rica: REP, SINPE Móvil, and late-filing fines

Executive summary in thirty seconds

Costa Rica's version 4.4 of electronic invoices has been mandatory since September 1, 2025. There is no transition period. If your ERP still emits XML against the 4.3 schema, every invoice is legally invalid — and the DGT has already opened its audit cycle on companies that missed the cutover.

This is not a cosmetic upgrade. Hacienda 4.4 is a structural redesign of how Costa Rica controls VAT: a new mandatory REP document, an expanded VAT-code catalog, SINPE Móvil formalized as a payment method, the buyer's CIIU activity code required for B2B, and new ID types. Goal: real-time pre-validation, like SII in Chile or CFDI in Mexico.

If you run finance at a Costa Rican SMB in San José or Heredia — 30 employees, USD 2–5M in revenue — this is for you. We break down what changes in the XSD, what breaks in Odoo by default, the 5 failure patterns we saw in one out of every two Q1 2026 migrations, and why "we'll just use Excel for now" is the most expensive strategy available.

• Deadline: version 4.4 in force since September 1, 2025. No grace window — the 4.3 schema is no longer accepted by ATV.
• Headline change: REP (Recibo Electrónico de Pago) is mandatory for credit sales with deferred VAT and for invoices to public entities.
• SINPE Móvil: now has its own code in the MedioPago catalog. Classifying it as "cash" no longer works.
• New fields: buyer CIIU code mandatory in B2B, plus ID types 05 (non-resident foreign) and 06 (non-contributor).
• Penalties: 2 base salaries per missing or invalid document — roughly CRC 940,000 per episode, plus suspension of the electronic-invoicing authorization.
• Odoo: the community l10n_cr module does not cover the REP flow out of the box — you need a partner extension or custom development.

What changes with Hacienda 4.4 and why 4.3 is dead

The Dirección General de Tributación (DGT), under the Ministry of Finance, has been issuing e-invoicing resolutions since 2018. The current legal base:

• Reglamento de Comprobantes Electrónicos — executive decree published in La Gaceta.
• Resolución DGT-R-033-2019 — original technical specification.
• Resolución DGT 2024 — the official transition to version 4.4.
• Código de Normas y Procedimientos Tributarios (Law 4755) — the legal basis for fines.

#1. The eight documents in the system

REP is the structural change. In 4.3, credit sales tracked payment indirectly: you issued an FE on credit, VAT deferred until cash arrived, and Hacienda trusted your books. In 4.4, when cash actually lands you must generate a separate REP document, link it to the original FE, and submit it to ATV. No REP, no payment recognition — and the VAT liability stays open.

#2. The timeline in six lines

• Q4 2024: DGT publishes the 4.4 XSD schemas and technical docs.
• December 2024 – July 2025: ATV sandbox open for testing.
• September 1, 2025: version 4.4 becomes mandatory. 4.3 stops being accepted.
• September – November 2025: Hacienda's "soft window" — rejections on technical errors, not content.
• From December 2025: strict validation. Invalid XML equals a document that does not exist.
• 2026: systemic audit cycle. Penalties for non-migrants.

The macro context pushes in the same direction. Costa Rica in 2026 is losing some of its nearshoring edge to US tariffs — Hacienda needs the tax revenue, so compliance pressure is going up, not down.

Six places where 4.4 XML breaks

If your answer is "we run Odoo, everything works," open the XML of your latest FE and check six specific points. Country pillar deep-dive at Odoo in Costa Rica for SMBs.

#1. REP — the new mandatory document

REP fires in three scenarios:

• Credit sale: FE issued with CondicionVenta = 02 (Credit), VAT deferred. Once the payment is received, REP is mandatory inside the regulated window (standard: 8 business days).
• Invoice to a public entity: any FE against a state institution requires REP at the moment payment lands. Public sector pays at 30–90 days, so the error window is huge.
• Partial payments: aggregated REPs are allowed, but they require extra logic in the ERP.

In Odoo, the OCA community l10n_cr module does not generate REP automatically. You need an extended package from a Costa Rican Gold partner (Vauxoo, Delfix) or your own development. This is the first pain point that 80% of self-managed migrations skip.

#2. SINPE Móvil as a formal payment method

SINPE Móvil is the instant-payment rail from the Banco Central de Costa Rica (BCCR). Before 4.4, SMBs booked SINPE payments as "cash" or "transfer." In 4.4, SINPE has its own code in the MedioPago catalog. In an audit, Hacienda reconciles the BCCR bank report against your XML — any payment-method mismatch is an automatic flag.

#3. Buyer CIIU activity codes

The Receptor.CodigoActividad field is mandatory in most B2B operations. It is the buyer's economic activity code in the CIIU taxonomy. Your ERP must:

• Store the CIIU code on res.partner.
• Inject it into the right FE / REP field automatically.
• Look it up by tax ID against the ATV API for new counterparties.

If you have 500 partners in the database and 480 lack this field, the migration stops at the first FE.

#4. New ID types

• Type 05 — non-resident foreign (US nearshoring clients without a CR tax ID).
• Type 06 — non-contributor (individuals with no fiscal registration obligation).

Without these types you cannot classify a meaningful share of HORECA and nearshoring operations. For Costa Rica as a services-export hub, this matters.

#5. New VAT classifications

Hacienda expanded CodigoImpuesto and CodigoTarifa. The clearest case: code 11, 0% rate with no input credit. For certain exempt operations you do not charge VAT, but you also cannot deduct VAT on related purchases. Standard Odoo usually treats 0% as plain "no VAT" — that shortcut produces the wrong fiscal effect.

Other new or changed codes:

• Tourism VAT at 4% — separate classification.
• Reduced VAT at 1% — for specific medicines and basic-basket goods.
• Exonerated vs. exempt — distinct catalog codes.

#6. XSD schema changes

Roughly 40 new mandatory fields and more than 100 renamed or optional ones. The main buckets:

• Extended Detalle.LineaDetalle — new discount and product-code fields.
• Updated ResumenFactura.CodigoMoneda — broader currency list.
• New OtrosCargos block to break out commissions, freight, and tips.

Who migrates fast and who takes 10 weeks

Actual complexity depends on your dominant transaction flow. These are the six typical profiles.

#1. Retail / QSR / stores (TE flow)

Quick win. Tiquetes Electrónicos changed minimally in 4.4. The work: update tax mapping and add SINPE Móvil as a payment method. Realistic Odoo timeline: 2–3 weeks including testing. A multi-store network adds about a week for rollout.

#2. B2B with credit sales (FE + REP flow)

The hardest category. REP is a new document flow that touches accounts receivable. Standard Odoo has no "partial REP against an ongoing credit flow" concept. The options are a custom module (roughly 80 dev hours) or a dedicated e-invoicing middleware. Realistic timeline: 6–10 weeks.

#3. SaaS / subscriptions with deferred billing

Gray zone. REP formally applies to credit sales, but a subscription with automatic charges is not classic credit. Hacienda clarified in several consultations that recurring billing must produce a REP per successful charge. Translated: every successful Stripe or PayPal charge fires a REP. The integration load is heavy, but architecturally workable.

#4. Export (FEE flow)

Minimal but not zero changes. Exports do not require buyer CIIU (the buyer is abroad), but a destination country field per ISO 3166-1 is now mandatory and the Incoterms block was expanded. Timeline: about a week.

#5. HORECA — restaurants, hotels, travel agencies

Mixed case. The TE flow holds, but tips and service charges now go in the OtrosCargos block. SINPE Móvil becomes critical because customers pay massively from the bank app. Tourism has a specific 4% VAT that needs the right code. Timeline: 3–5 weeks. For HORECA with a CV overlay see Odoo for restaurants (Computer Vision).

#6. Nearshoring / service exports to the US

Special case. Part of your client base is non-resident foreign (ID type 05). Without that type, you cannot issue FE correctly. In Odoo you extend res.partner. It is more configuration than development, but it requires understanding the business model and testing with real nearshoring scenarios.

If you used Vauxoo or Delfix for 4.3 — good news: those partners already ship adapted modules. Bad news: you are locked into their stack, and rescue out of a bad situation costs as much as a new migration.

Five mistakes that trigger fines

These are the patterns we saw in one out of every two 4.4 migrations audited during Q1 2026.

#1. REP not generated automatically for credit sales

The most common. The SMB migrates to 4.4, updates the XSD, but forgets that REP is a separate document flow. Accounting keeps issuing FE on credit, collects payment, and closes the books. Three months later Hacienda flags every credit operation as incomplete.

Consequence: at audit, a fine per missing REP. Under article 83 of the CNPT, 2 base salaries per document. With 100 missing REPs, the tab clears CRC 94 million in direct fines.

#2. SINPE Móvil booked as "cash"

Hacienda reconciles BCCR data against your XMLs. If 60% of inbound payments in your account are SINPE Móvil and the FEs say "cash," that is an automatic audit trigger.

Consequence: formally not an omission, but a clear elevated audit risk and potential income-reconstruction adjustments.

#3. Old VAT codes in the new schema

The community Odoo package for 4.3 used a simple VAT mapping: 13%, 4%, 2%, 1%, 0%, exempt. In 4.4 each rate can have several subtypes with different CodigoTarifa. What used to be 0% can now be code 01 (exonerated), 06 (no input credit), 11 (0% without credit), and others.

Consequence: wrong VAT return — adjustments plus an inaccuracy penalty (typically 50% of unpaid tax).

#4. Ignoring the buyer CIIU code

The field is mandatory in most B2B operations. If you have 500 counterparties and 480 lack the code, ATV rejects the XML and the document does not legally exist.

Consequence: VAT liability accelerates, plus a fine under CNPT article 85 for failure to file.

#5. "We'll patch it with Excel for now"

We hear this constantly: "Sergio, it is complicated — for now we invoice in Excel and migrate later." That is the most expensive mistake. Every Excel invoice not registered in ATV is an omission. One month of "temporary fix" is easily CRC 20 million+ in potential fines. By the time you do migrate, you have 200 missing documents and the project turns into a forensic exercise.

Anonymous case: SMB rescue on Hacienda 4.4

Situation. Manufacturing company, around 30 employees, roughly USD 2.5M in annual revenue, B2B supplier for the construction sector in San José. They ran Odoo 16 community with a homegrown integration module for 4.3. September 2025 came and went without migration: "we thought we were fine, planned to upgrade by December."

By early 2026 they had ~80 FEs rejected by ATV (XSD errors), ~40 credit sales with no REP, and the DGT had formally opened an audit notice.

Seven-week rescue plan:

1. Discrepancy audit between the Odoo journal and ATV. 121 problem operations surfaced: 80 rejected FEs, 40 missing REPs, and one wrong tariff code repeated across 67 product lines.
2. Updated l10n_cr to a build compatible with XSD 4.4, plus a custom module for the REP flow.
3. Mass partner update: CIIU codes added to 350 partner records via a script that hit the ATV lookup API.
4. Re-issued the 80 rejected FEs against the correct schema (DGT authorization required — took 2 weeks).
5. REP backfill: 40 retroactive REPs generated and submitted for 2024–2025 credit sales.

Outcome. The audit closed without fines — the DGT accepted the rescue plan. Direct rescue cost: about USD 28,000 across Odoo development, accounting hours, and ATV fees. Potential fines without the rescue: estimated at CRC 180 million+ (roughly USD 395,000). We run similar engagements as Odoo project rescue.

Checklist and next steps

A 12-point PDF checklist — l10n_cr version, tax-mapping validation, REP-flow test, partner-record audit for CIIU codes, and a dry run against the ATV sandbox. Grab the checklist and it lands in your inbox along with a sample ATV validation report.

If you want a live audit, book a 30-minute call: in half an hour we tell you the state of your system and how long the migration takes.

Related reads:

• Odoo in Costa Rica for SMBs — country pillar with service tiers and a comparison against local competitors.
• Odoo audit — 30-minute express review of your setup.
• Odoo project rescue — for teams already inside the audit zone.
• Odoo implementation — full SMB rollout from zero.
• SAT CFDI 4.0 — Mexico — regional comparison.
• SII 2026 — Chile — regional comparison.
• DIAN e-invoicing — Colombia — for contrast with the CR model.

Hacienda 4.4 is not cosmetic. It is a structural redesign of VAT control in Costa Rica. SMBs that keep running on 4.3 or on the "Odoo plus Excel" combo are stacking systemic debt that surfaces at the first audit cycle — and at that point rescue runs ten times the cost of a preventive migration.

Two paths from where you stand. First: if you have not migrated, do not wait for December — run the audit now, before the DGT shows up first. Second: if you migrated but are unsure of the result, run an independent review of the XML output for the last 90 days. Discrepancies against ATV validation surface fast.

Frequently asked questions