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.

Turkey — GİB, e-Fatura and e-Arşiv

Turkey rolled out its B2B e-Fatura mandate in 2014 (one of the early movers in Europe), extended by e-Arşiv for B2C flows in 2017. The format is UBL-TR, the Turkish profile of UBL 2.1; the GİB portal and private Özel Entegratör handle routing.

Regulatory timeline

  • 4 January 1961 — Vergi Usul Kanunu (Tax Procedure Law 213). Legal basis for invoicing and retention obligations in Turkey.
  • 5 March 2010 — Tebliğ 397 / Vergi Usul Kanunu. First framework for voluntary e-Fatura between Turkish taxpayers.
  • 14 December 2012 — Tebliğ 421. Introduces mandatory e-Fatura for certain sectors (energy, telecoms, banks) effective 1 April 2014.
  • 1 April 2014 — e-Fatura go-live. Mandatory for businesses with turnover ≥ TRY 25 million.
  • 30 December 2016 — Tebliğ 487. Creates the e-Arşiv Fatura regime for B2C flows, operational on 1 January 2017.
  • 19 October 2019 — Tebliğ 509. Major overhaul: thresholds lowered (TRY 5 million) and extension to new sectors (e-commerce, transport, real-estate brokerage).
  • 22 January 2022 — Tebliğ 535. Further drop to TRY 4 million, then TRY 3 million for FY 2023 onwards.
  • Annual Tebliğ. The GİB revises threshold and sectoral perimeter every year, typically published in December via the Resmi Gazete (Turkish Official Gazette).

Technical schema

The format is UBL-TR, an OASIS UBL 2.1 profile enhanced with Turkish extensions published by GİB. Specifics:

  • CustomizationID TR1.2 — current Turkish profile version.
  • ProfileID: TEMELFATURA (standard e-Fatura), TICARIFATURA (commercial e-Fatura with explicit accept/reject response), IHRACAT (export), EARSIVFATURA (B2C e-Arşiv).
  • PartyIdentification schemeID: VKN or TCKN to identify the Turkish party.
  • InvoiceTypeCode: SATIS (standard sale), IADE (credit note), TEVKIFAT (VAT withholding), ISTISNA (exemption).
  • UUID: mandatory, the universal unique identifier of the invoice on the GİB side.

Minimal example of a TICARIFATURA e-Fatura:

xmlefatura-tr-ublTR12.xml
<?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>

Submission flow

The seller issues the signed UBL-TR via its e-imza or mali mühür, then transmits to the GİB through one of:

  • Method A — Özel Entegratör: certified private integrator acting as service provider. The GİB maintains a registry of authorised Özel Entegratör (Logo, Mikro, Uyumsoft, Foriba/Sovos…).
  • Method B — GİB portal: direct web portal for small volumes, little used in production.
  • Method C — Entegrasyon Yöntemi: direct integration from ERP to GİB infrastructure for very large issuers (bank, energy).
textefatura-gib-flow.txt
┌─────────────┐   ┌──────────────────┐   ┌─────────────┐
│ TR supplier │──>│ GİB or Özel      │──>│ TR customer │
│ (ERP, UBL)  │   │ Entegratör       │   │ (ERP, UBL)  │
└─────────────┘   │ (certified       │   └─────────────┘
                  │ private integ.)  │
                  └────────┬─────────┘


                ┌────────────────────┐
                │ GİB wraps signed    │  ← fiscal stamp
                │ document            │     + GİB UUID
                └────────────────────┘

GİB adds its UUID, fiscal stamp, then routes the invoice to the buyer's e-Fatura mailbox (B2B only). In e-Arşiv (B2C) the invoice goes straight to the consumer (email, link) and the GİB receives a daily report.

Validation

  • GİB e-Fatura portal: efatura.gov.tr.
  • UBL-TR technical documentation: XSD and Schematron specifications published on the GİB portal in the Teknik Doküman section.
  • List of Özel Entegratör: ebelge.gib.gov.tr — official directory.
  • TÜRKTRUST, E-Tugra, Kamu SM — e-imza certification authorities recognised by GİB.

Common pitfalls

  1. e-Fatura ≠ e-Arşiv. e-Fatura is only valid between entities registered in the GİB system (mandatory VKN/TCKN lookup before issuing). If the buyer is not in it, you must fall back to e-Arşiv or paper. An e-Fatura sent to a non-registered party is rejected.
  2. TEMELFATURA vs TICARIFATURA. TEMELFATURA has no acceptance cycle: the invoice is deemed accepted by default. TICARIFATURA includes an explicit accept/reject mechanism with deadlines (8 days by default). Conflating both compromises collection.
  3. Annual threshold schedule. The turnover threshold triggering the obligation is revised yearly by Tebliğ. A business crossing the threshold in FY N must be on e-Fatura from 1 July N+1. Tracking threshold and switchover schedule is critical.
  4. e-imza and mali mühür rotation. e-imza certificates have limited validity (1 to 3 years). Expiry without renewal blocks all issuance. Set a 90-day pre-expiry alert.
  5. Turkish characters (ç, ş, ğ, ı, ö, ü). Encoding must be strict UTF-8. An ERP ASCII → UBL cascade breaks names (İstanbul → Istanbul, proper nouns with wrong diacritics), which can fail VKN matching on the GİB side. Test with datasets containing all Turkish diacritics.