ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Costa Rica — comprobantes electrónicos, XML 4.4 clearance

Costa Rica runs one of the most mature clearance regimes in Latin America. Every comprobante electrónico (invoice, ticket, credit/debit note) is an XML file signed with XAdES-EPES, transmitted to the Dirección General de Tributación (DGT) of the Ministerio de Hacienda for near real-time validation before it carries any tax value. Mandatory in sector-by-sector waves since 2018, the system moved to format 4.4 — mandatory since 1 September 2025 — and is migrating to the new TRIBU-CR platform.

Regulatory timeline

  • 2016 — Resolución DGT-R-48-2016. First framework resolution for comprobantes electrónicos: gives electronic invoices and tickets the same tax value as paper, without yet fixing a mandate calendar.
  • 2017 — Reforms DGT-R-13-2017 and DGT-R-25-2017. Specify the XML format, the XAdES signature, the clave numérica and the taxpayer onboarding mechanism.
  • 2018 — Phased mandate. Sector rollout: health (15 January 2018), then accounting/financial sector (1 February 2018), liberal professions in H1, and the remaining taxpayers in the final third of the year by tax ID number.
  • 2019 — Generalisation. Almost all VAT (IVA) taxpayers issue comprobantes electrónicos; the regime becomes the default fiscal channel.
  • April 2025 — 4.3 / 4.4 coexistence. Voluntary use of version 4.4 opened on 1 April 2025; coexistence window until 1 September.
  • 1 September 2025 — Version 4.4 mandatory. After a delay (initial date 1 June 2025), version 4.4 becomes mandatory for issuers and receivers; over 140 technical changes, including the new Recibo Electrónico de Pago (REP).
  • 6 October 2025 — TRIBU-CR launch. The new unified tax platform replaces ATV (migration of ~883 million records); the free TicoFactura 4.4 tool is integrated, with pre-filled returns targeted for 2026.

Technical schema

A comprobante electrónico is an XML file conforming to the XSD schemas published by the DGT (version 4.4 since September 2025). The regime covers several document types:

  • FE — Factura Electrónica (taxable B2B/B2G/B2C sale).
  • TE — Tiquete Electrónico (final-consumer sale).
  • NC / ND — Nota de Crédito / Nota de Débito (cancellation or adjustment).
  • FEE — Factura Electrónica de Exportación (exports).
  • FEC — Factura Electrónica de Compra (self-billing, issued by the buyer for an unregistered supplier).
  • REP — Recibo Electrónico de Pago, a new document introduced by 4.4 for credit operations / collections.

Each document carries a 50-digit clave numérica: country code (506), issuance date, issuer identifier, consecutive number (20 positions), comprobante status and an 8-position security code. The signature is an XAdES-EPES in enveloped mode (ETSI TS 101 903 v1.3.2 or higher), applied with a certificate issued by the national certification authority. Example root:

  • <FacturaElectronica xmlns="https://cdn.comprobanteselectronicos.go.cr/xml-schemas/v4.4/facturaElectronica">
  • <Clave>506…</Clave> (50 digits)
  • <Emisor> / <Receptor> with <Identificacion> (cédula física, jurídica or NITE)
  • <ds:Signature> XAdES-EPES at the end of the document

Submission flow

Costa Rica applies a near real-time clearance model, close to Italy's SdI: an invoice carries tax value only once validated by Hacienda.

  1. Generation + signing. The issuer builds the 4.4 XML, computes the 50-digit clave numérica and applies the XAdES-EPES signature.
  2. Submission to the DGT. The signed XML is sent to the Ministerio de Hacienda reception services (API / TRIBU-CR platform, or TicoFactura), in principle within 3 hours of issuance.
  3. Validation. Hacienda has an indicative window of roughly 3 hours to return a mensaje de respuesta: aceptado, aceptado parcialmente or rechazado.
  4. Delivery to the receiver. The issuer sends the buyer the XML plus a graphical representation (PDF). No invoice is legally valid without Hacienda's acceptance message.
  5. Receipt confirmation. The receiver must in turn accept or reject the document (recipient message) within the set deadlines — otherwise the VAT credit may be lost.
  6. Retention. Both parties archive the original XML (and the associated messages) for 5 years.

Validation

Common pitfalls

  1. Confusing issuance with validity. A signed XML is not a valid invoice until Hacienda returns the « aceptado » mensaje de respuesta. Design the flow around the acknowledgement, not around the send.
  2. Skipping the receiver message. On the buyer side, accepting the document (within the TRIBU-CR deadlines) conditions the VAT credit; failing to process it forfeits deductibility.
  3. Missing the 4.3 → 4.4 switch. 4.4 is mandatory since 1 September 2025; schemas, some fields and the new REP differ. Integrations still on 4.3 are rejected.
  4. Building the clave numérica wrong. The 50 digits have a strict structure (country, date, identifier, consecutive, status, security code); a length or sequence error triggers rejection.
  5. Non-compliant signature. Only XAdES-EPES enveloped with a recognised certificate is accepted; a CAdES, a detached signature or an invalid certificate is rejected.
  6. Assuming Peppol transport. Costa Rica uses neither Peppol nor EN 16931: it is a proprietary national format, transmitted directly to Hacienda.