Turquie — GİB, e-Fatura et e-Arşiv

La Turquie a déployé son mandat e-Fatura B2B en 2014 (parmi les pionniers en Europe), étendu par e-Arşiv pour les flux B2C en 2017. Le format est UBL-TR, profil turc d'UBL 2.1 ; le portail GİB et les Özel Entegratör privés assurent le routage.

Timeline réglementaire

• 4 janvier 1961 — Vergi Usul Kanunu (Loi 213 sur les Procédures Fiscales). Base juridique des obligations de facturation et de conservation en Turquie.
• 5 mars 2010 — Tebliğ 397 / Vergi Usul Kanunu. Première cadre pour l'e-Fatura volontaire entre redevables turcs.
• 14 décembre 2012 — Tebliğ 421. Introduction de l'obligation e-Fatura pour certains secteurs (énergie, télécoms, banques) à partir du 1^er avril 2014.
• 1^er avril 2014 — Mise en service e-Fatura. Obligation pour les entreprises avec CA ≥ 25 millions de TRY.
• 30 décembre 2016 — Tebliğ 487. Création du régime e-Arşiv Fatura pour les flux B2C, opérationnel le 1^er janvier 2017.
• 19 octobre 2019 — Tebliğ 509. Refonte majeure : abaissement des seuils (5 millions TRY) et extension à de nouveaux secteurs (e-commerce, transport, courtage immobilier).
• 22 janvier 2022 — Tebliğ 535. Nouvelle baisse à 4 millions TRY, puis 3 millions TRY pour les exercices 2023+.
• Tebliğ annuel. La GİB révise chaque année le seuil et le périmètre sectoriel, généralement annoncé en décembre via la Resmi Gazete (Journal officiel turc).

Schéma technique

Le format est UBL-TR, un profil OASIS UBL 2.1 enrichi d'extensions turques publiées par GİB. Les particularités :

• CustomizationID TR1.2 — version courante du profil turc.
• ProfileID : TEMELFATURA (e-Fatura standard), TICARIFATURA (e-Fatura commerciale avec réponse acceptation/rejet explicite), IHRACAT (export), EARSIVFATURA (e-Arşiv B2C).
• PartyIdentification schemeID : VKN ou TCKN pour identifier la partie turque.
• InvoiceTypeCode : SATIS (vente classique), IADE (avoir), TEVKIFAT (retenue TVA), ISTISNA (exonération).
• UUID : obligatoire, identifiant universel unique de la facture côté GİB.

Exemple minimal d'une e-Fatura TICARIFATURA :

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
  <cbc:UBLVersionID>2.1</cbc:UBLVersionID>
  <cbc:CustomizationID>TR1.2</cbc:CustomizationID>
  <cbc:ProfileID>TICARIFATURA</cbc:ProfileID>
  <cbc:ID>TRA2026000000142</cbc:ID>
  <cbc:UUID>F47AC10B-58CC-4372-A567-0E02B2C3D479</cbc:UUID>
  <cbc:IssueDate>2026-05-16</cbc:IssueDate>
  <cbc:IssueTime>10:30:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode>SATIS</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>TRY</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="VKN">1234567890</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName><cbc:Name>Ediverse Demo A.Ş.</cbc:Name></cac:PartyName>
      <cac:PostalAddress>
        <cbc:CityName>İstanbul</cbc:CityName>
        <cbc:Country><cbc:IdentificationCode>TR</cbc:IdentificationCode></cbc:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="VKN">9876543210</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName><cbc:Name>Müşteri Demo A.Ş.</cbc:Name></cac:PartyName>
    </cac:Party>
  </cac:AccountingCustomerParty>
</Invoice>

Flux de soumission

Le vendeur émet l'UBL-TR signé via son e-imza ou mali mühür, puis transmet au GİB de l'une de ces façons :

• Méthode A — Özel Entegratör : intégrateur privé certifié qui agit comme service provider. La GİB tient un registre des Özel Entegratör autorisés (Logo, Mikro, Uyumsoft, Foriba/Sovos…).
• Méthode B — Portail GİB : portail web direct pour les petits volumes, peu utilisé en production.
• Méthode C — Entegrasyon Yöntemi : intégration directe ERP vers infrastructure GİB pour les très grands émetteurs (banque, énergie).

┌─────────────┐   ┌──────────────────┐   ┌─────────────┐
│ Vendeur TR  │──>│ GİB ou Özel      │──>│ Acheteur TR │
│ (ERP, UBL)  │   │ Entegratör       │   │ (ERP, UBL)  │
└─────────────┘   │ (intégrateur     │   └─────────────┘
                  │ privé certifié)  │
                  └────────┬─────────┘
                           │
                           ▼
                ┌────────────────────┐
                │ GİB enveloppe le    │  ← timbre fiscal
                │ document signé      │     + UUID GİB
                └────────────────────┘

GİB ajoute son UUID, son timbre fiscal, puis route la facture vers le mailbox e-Fatura de l'acheteur (en B2B uniquement). En e-Arşiv (B2C), la facture est envoyée directement au consommateur (email, lien) et la GİB reçoit un rapport quotidien.

Validation

• Portail GİB e-Fatura : efatura.gov.tr.
• Documentation technique UBL-TR : spécifications XSD et Schematron publiées sur le portail GİB section Teknik Doküman.
• Liste des Özel Entegratör : ebelge.gib.gov.tr — annuaire officiel.
• TÜRKTRUST, E-Tugra, Kamu SM — autorités de certification e-imza reconnues par GİB.

Pièges courants

1. e-Fatura ≠ e-Arşiv. e-Fatura n'est valable que pour les flux entre entités enregistrées dans le système GİB (lookup VKN/TCKN obligatoire avant émission). Si l'acheteur n'y est pas, il faut basculer en e-Arşiv ou facture papier. Une e-Fatura envoyée à un non-enregistré est rejetée.
2. TEMELFATURA vs TICARIFATURA. TEMELFATURA est sans cycle d'acceptation : la facture est réputée acceptée par défaut. TICARIFATURA inclut un mécanisme accept/reject explicite avec délais (8 jours par défaut). Confondre les deux compromet le recouvrement.
3. Calendrier annuel des seuils. Le seuil de CA déclenchant l'obligation est révisé chaque année par Tebliğ. Une entreprise qui dépasse le seuil sur l'exercice N doit être en e-Fatura dès le 1^er juillet N+1. Le suivi du seuil et du calendrier de bascule est critique.
4. e-imza et mali mühür rotation. Les certificats e-imza ont une validité limitée (1 à 3 ans). Une expiration sans renouvellement bloque toute émission. Mettre en place une alerte 90 jours avant.
5. Caractères turcs (ç, ş, ğ, ı, ö, ü). L'encodage doit être strict UTF-8. Une cascade ERP ASCII → UBL casse les noms (İstanbul → Istanbul, noms propres mal accentués), ce qui peut faire échouer le matching VKN côté GİB. Tester avec des jeux contenant tous les diacritiques turcs.

Liens transverses

• UBL — standard OASIS de base d'UBL-TR.
• PEPPOL — comparaison avec le BIS Billing 3.0 européen (la Turquie n'est pas dans PEPPOL).
• Roumanie — comparaison avec un autre mandat UBL-based.
• Pologne — KSeF, autre architecture de portail centralisé.
• Sources officielles : gib.gov.tr, efatura.gov.tr, ebelge.gib.gov.tr.