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

Uruguay — DGI e-CFE: LATAM pioneer since 2012

Uruguay is one of the Latin American e-invoicing pioneers. Since 2012 the Dirección General Impositiva (DGI) has imposed Comprobantes Fiscales Electrónicos (CFE) in XML format, with a turnover-threshold rollout completed at the end of 2024 by onboarding micro-taxpayers. The model is near real-time clearance through SOAP Web Services, with prior CAE authorisation (Constancia de Autorización de Emisión) and a mandatory visual representation.

Regulatory timeline

  • 11 January 2012 — Decreto 36/012. Creates the general regime for Comprobantes Fiscales Electrónicos (CFE) and authorises the DGI to organise the system.
  • 8 August 2012 — DGI Resolution 798/012. Sets the operational CFE framework: XML formats, XAdES signature, SOAP Web Services, document types (e-Ticket, e-Factura, e-Remito, e-Resguardo). First batch of 23 pilot taxpayers.
  • 2013-2016 — Annual onboarding waves. Turnover-based schedule (UI — Unidad Indexada): large taxpayers first, descending to mid-sized enterprises.
  • 29 April 2014 — Act 19,210 "Financial Inclusion". Speeds up adoption by mandating electronic payments for many B2C operations, pushing merchants to CFE.
  • 2017-2023 — SME waves. Extension by ingresos brutos tranches with adaptation deadlines.
  • 2024 — Resolution 124/024. Final schedule for micro-taxpayers (Pequeña Empresa and Monotributo regimes): 1 December 2024 deadline.
  • 1 December 2024 — Universal mandate. All IVA taxpayers (excluding specific exemptions) must emit via CFE.

Technical schema

The format is CFE XML (Comprobantes Fiscales Electrónicos), UTF-8 encoded, XAdES-T signed with a certificate issued by a DGI-recognised CA (UCE, Correo Uruguayo, etc.). Main document types:

  • 101 — e-Ticket (B2C)
  • 102 — Nota de Crédito de e-Ticket
  • 103 — Nota de Débito de e-Ticket
  • 111 — e-Factura (B2B)
  • 112 — Nota de Crédito de e-Factura
  • 113 — Nota de Débito de e-Factura
  • 121 — e-Remito (delivery note)
  • 131 — e-Resguardo (withholdings)
  • 181 / 182 — e-Boleta Contado / Crédito (contado variants)

Identifiers:

  • RUT: Registro Único Tributario, 12 digits.
  • CAE: Constancia de Autorización de Emisión — prior authorisation of number blocks, embedded in the CFE.
  • Serie: 2 alpha letters (e.g. A, AA) prefixing the sequential number.
xmluy-cfe-efactura-snippet.xml
<?xml version="1.0" encoding="UTF-8"?>
<CFE xmlns="http://cfe.dgi.gub.uy" version="1.39">
  <eFact>
    <Encabezado>
      <IdDoc>
        <TipoCFE>111</TipoCFE>
        <Serie>A</Serie>
        <Nro>142</Nro>
        <FchEmis>2026-05-19</FchEmis>
      </IdDoc>
      <Emisor>
        <RUCEmisor>210123450017</RUCEmisor>
        <RznSoc>Ediverse Demo Uruguay SA</RznSoc>
        <CdgDGISucur>1</CdgDGISucur>
        <DomFiscal>18 de Julio 1234, Montevideo</DomFiscal>
      </Emisor>
      <Receptor>
        <TipoDocRecep>2</TipoDocRecep>
        <DocRecep>219876540019</DocRecep>
        <RznSocRecep>Customer Demo SA</RznSocRecep>
      </Receptor>
      <Totales>
        <TpoMoneda>UYU</TpoMoneda>
        <MntNetoIvaTasaBasica>50000.00</MntNetoIvaTasaBasica>
        <IVATasaBasica>22.0</IVATasaBasica>
        <MntIVATasaBasica>11000.00</MntIVATasaBasica>
        <MntTotal>61000.00</MntTotal>
      </Totales>
    </Encabezado>
  </eFact>
</CFE>

Submission flow

CAE pre-emission clearance model: the DGI pre-authorises number ranges for each Serie (CAE valid 1 year with a quantity ceiling). The seller consumes that range for emissions and submits in parallel via SOAP Web Service a copy of each CFE. The DGI validates asynchronously; rejection is rare since the main checks happen at the CAE request stage.

textuy-cfe-flow.txt
┌────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ CAE request    │───>│ DGI (Web Service)  │───>│ CAE granted  │
│ per RUT/Serie  │    │ efactura.dgi.gub.uy│    │ + numbers    │
└────────────────┘    └────────────────────┘    └──────┬───────┘
                                                       │
                                                       ▼
┌────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ Seller UY      │───>│ DGI WS (envío)     │    │ Buyer UY     │
│ (signed XML)   │    │ + visual PDF       │───>│ (RR + QR)    │
│ + embedded CAE │    │   with QR          │    │              │
└────────────────┘    └────────────────────┘    └──────────────┘

The visual representation is called RR (Representación Impresa) and must carry a DGI QR Code encoding TipoCFE, Serie, Nro, date, issuer RUT and CFE hash.

Validation

  • DGI Web Service: efactura.dgi.gub.uy — production. SOAP with WS-Security + certificate signature.
  • Test environment: efacturatest.dgi.gub.uy — test endpoint for vendor integration.
  • Official DGI documentation: XSD specifications, CFE manual and examples on dgi.gub.uy (e-Factura section).
  • Digital certificate: issued by approved CAs (UCE-Universidad Católica del Uruguay, Correo Uruguayo, ABITAB, etc.) recognised by the DGI.

Common pitfalls

  1. Upstream CAE management. The CAE pre-authorises a number quota per Serie and validity period. An SME underestimating its emission volume consumes its CAE and must re-request urgently (3 to 5 business days). Monitor consumption rate.
  2. Alpha Serie. The Serie is made of 1 or 2 letters (A, AA, AB...). ERPs that map the series to numbers break DGI consistency during the monthly CFE reporting (informe de comprobantes).
  3. Receiver TipoDocRecep. The TipoDocRecep field distinguishes: 1=CI (Uruguayan), 2=RUC, 3=passport, 4=foreign DNI, 5=NIE. Frequent confusion between codes at CRM integration.
  4. Currency UYU vs USD vs UI. Uruguay accepts multiple currencies (UYU, USD, EUR, UI Unidad Indexada). If TpoMoneda ≠ UYU, fill in TpoCambio (BCU daily exchange rate or sector-specific rules).
  5. CFE hash and QR. The RR QR Code must encode the SHA-1 hash of the signed CFE. Vendors that compute the hash before signing (and not on the signed CFE) produce a QR that does not match what the DGI received.