ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

Uruguay — DGI e-CFE : pionnier LATAM depuis 2012

L'Uruguay est l'un des pionniers de l'e-invoicing en Amérique latine. Depuis 2012, la Dirección General Impositiva (DGI) impose les Comprobantes Fiscales Electrónicos (CFE) au format XML, avec un déploiement par tranches de chiffre d'affaires achevé fin 2024 par l'intégration des micro-contribuables. Le modèle est clearance en temps quasi réel via Web Services SOAP, avec autorisation préalable par CAE (Constancia de Autorización de Emisión) et représentation visuelle obligatoire.

Timeline réglementaire

  • 11 janvier 2012 — Decreto 36/012. Crée le régime général des Comprobantes Fiscales Electrónicos (CFE) et habilite la DGI à organiser le système.
  • 8 août 2012 — Resolución DGI 798/012. Établit le cadre opérationnel CFE : formats XML, signature XAdES, Web Services SOAP, types de documents (e-Ticket, e-Factura, e-Remito, e-Resguardo). Premier lot de 23 contribuables pilotes.
  • 2013-2016 — Vagues d'enrôlement annuelles. Calendrier par chiffre d'affaires (UI — Unidad Indexada) : grands contribuables d'abord, descente vers les moyennes entreprises.
  • 29 avril 2014 — Ley 19.210 "Inclusión Financiera". Accélère l'adoption en imposant le paiement électronique pour de nombreuses opérations B2C, ce qui pousse les commerces à passer au CFE.
  • 2017-2023 — Vagues PME. Extension par tranches de ingresos brutos avec délais d'adaptation.
  • 2024 — Resolución 124/024. Calendrier final pour les micro-contribuables (régime Pequeña Empresa et Monotributo) : échéance 1er décembre 2024.
  • 1er décembre 2024 — Mandat universel. Tous les contribuables IVA (sauf exonérations spécifiques) doivent émettre via CFE.

Schéma technique

Le format est CFE XML (Comprobantes Fiscales Electrónicos), encodage UTF-8, signé XAdES-T avec un certificat délivré par une AC reconnue par la DGI (UCE, Correo Uruguayo, etc.). Types de documents principaux :

  • 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 (bon de livraison)
  • 131 — e-Resguardo (retenues)
  • 181 / 182 — e-Boleta Contado / Crédito (variantes contado)

Identifiants :

  • RUT : Registro Único Tributario, 12 chiffres.
  • CAE : Constancia de Autorización de Emisión — autorisation préalable de blocs de numéros, intégrée au CFE.
  • Serie : 2 lettres alpha (e.g. A, AA) précédant le numéro séquentiel.
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>

Flux de soumission

Modèle clearance pré-émission par CAE : la DGI pré-autorise des plages de numéros pour chaque Serie (CAE valide 1 an avec quantité plafond). Le vendeur consomme cette plage pour ses émissions et transmet en parallèle via Web Service SOAP la copie de chaque CFE. La DGI valide en différé ; le rejet est rare car les contrôles principaux ont lieu lors de la demande de CAE.

textuy-cfe-flow.txt
┌────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ Demande CAE    │───>│ DGI (Web Service)  │───>│ CAE attribué │
│ par RUT/Serie  │    │ efactura.dgi.gub.uy│    │ + numéros    │
└────────────────┘    └────────────────────┘    └──────┬───────┘


┌────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ Vendeur UY     │───>│ DGI WS (envío)     │    │ Acheteur UY  │
│ (CFE XML signé)│    │ + représentation   │───>│ (RR + QR)    │
│ + CAE intégré  │    │   PDF avec QR      │    │              │
└────────────────┘    └────────────────────┘    └──────────────┘

La représentation visuelle s'appelle RR (Representación Impresa) et doit porter un QR Code DGI encodant TipoCFE, Serie, Nro, fecha, RUT émetteur et hash du CFE.

Validation

  • Web Service DGI : efactura.dgi.gub.uy — production. SOAP avec WS-Security + signature certificat.
  • Environnement de test : efacturatest.dgi.gub.uy — endpoint test pour intégration éditeur.
  • Documentation officielle DGI : spécifications XSD, manuel CFE et exemples sur dgi.gub.uy (section e-Factura).
  • Certificat numérique : délivré par AC agréées (UCE-Universidad Católica del Uruguay, Correo Uruguayo, ABITAB, etc.) reconnues par la DGI.

Pièges courants

  1. Gestion CAE en amont. Le CAE pré-autorise un quota de numéros par Serie et par durée. Une PME qui sous-estime son volume d'émission consomme son CAE et doit en redemander un en urgence (3 à 5 jours ouvrés). Surveiller le taux de consommation.
  2. Serie alpha. La Serie est composée de 1 ou 2 lettres (A, AA, AB...). Les ERP qui mappent la série sur des nombres font sauter la cohérence DGI lors du reporting mensuel CFCFE (informe de comprobantes).
  3. RUT récepteur RUC vs CI vs RUT étranger. Le champ TipoDocRecep distingue : 1=CI (uruguayen), 2=RUC, 3=passeport, 4=DNI étranger, 5=NIE. Confusion fréquente entre les codes au niveau de l'intégration CRM.
  4. Devise UYU vs USD vs UI. L'Uruguay accepte plusieurs devises (UYU, USD, EUR, UI Unidad Indexada). Si TpoMoneda ≠ UYU, il faut renseigner TpoCambio (taux de change BCU du jour ou règles spécifiques selon le secteur).
  5. Hash CFE et QR. Le QR Code de la RR doit encoder le hash SHA-1 du CFE signé. Les éditeurs qui calculent le hash avant la signature (et non sur le CFE final signé) produisent un QR qui ne correspond pas à ce qu'a reçu la DGI.

Liens transverses