#Türkiye GİB e-Belge Sistemi — Portal Geliştirme Referansı

Durum tarihi: 1 Eylül 2026 Kapsam: e-Fatura, e-Arşiv Fatura, e-İrsaliye, e-SMM, e-Müstahsil Makbuzu, e-Gider Pusulası, e-Adisyon, e-Bilet, e-Döviz/Kıymetli Maden, e-Sigorta Poliçesi, e-Sigorta Komisyon Gider Belgesi, e-Dekont, kamu faturası, SGK, HKS, ihracat, yatırım teşvik, ilaç/tıbbi cihaz, İDİS, enerji (şarj) Amaç: Logo / Paraşüt / Robom muadili bir fatura kesme portalinin mevzuat ve teknik kural motorunu kurmak

#Bu rapor nasıl üretildi — ve neden diğerlerinden farklı

Bu rapor internet aramasıyla değil, GİB'in kendi dosyaları indirilip makine düzeyinde okunarak hazırlandı.

Kaynak korpusu (31.08.2026'da ebelge.gib.gov.tr'den indirildi):

Buna ek olarak kullanıcının elindeki 13 XSLT görüntüleme şablonu, RAR paketlerinden çıkan XSD/örnek XML'ler (e-Gider Pusulası, e-Döviz, e-Sigorta ×2), e-Defter kılavuzu ve web üzerinden KDV/tevkifat mevzuatı analize dahil edildi. Toplam 70+ dosya / ~3 MB birincil metin. Toplam 481 bulgu üretildi. Denetim düzeyi bölümden bölüme farklıdır — bu rapordaki her satır aynı güvende değildir:

Ayrıca 850 KB'lık bu metnin tamamı satır satır insan gözüyle okunmamıştır; yapısal doğrulama ve örneklem kontrolü yapılmıştır.

#Güven etiketleri

#Uyarılar

1. Bu rapor mali müşavirlik veya hukuki görüş değildir. Mevzuat yorumu gerektiren kararlarda YMM/SMMM görüşü alın.
2. 14.09.2026 kritik tarihtir. 27.07.2026 tarihli kod listesi ve paket güncellemeleri bu tarihte devreye girer. Bu rapordaki kod listeleri o güncellemeyi zaten içerir.
3. Eşikler ve kod listeleri koda gömülmemelidir. Son 9 ayda ENERJI, IDIS, YATIRIMTESVIK senaryoları ve 555 kodu eklendi. Bunları veritabanı/konfigürasyon olarak tutun ve GİB paketi güncellendiğinde yeniden üretilebilir yapın.

#Yönetici Özeti — En Kritik 15 Bulgu

#BÖLÜM 1 — Senaryolar, Fatura Tipleri ve Kod Listeleri

#Senaryolar, Fatura Tipleri ve Geçerlilik Matrisi

Bu bölümün tamamı 24.08.2026 tarihli GİB e-Fatura paketindeki UBL-TR_Codelist.xml, UBL-TR_Common_Schematron.xml, UBL-TR_Main_Schematron.xml dosyaları ile 27.07.2026 tarihli UBL-TR Kod Listeleri V1.43 kılavuzundan türetilmiştir. Verilen tüm kod listeleri eksiksizdir; hata mesajları schematron'dan birebir alıntıdır.

#Doğrulama kanalı ($type) — matrisi okumadan önce

Senaryo ve fatura tipi kurallarının hangisinin devreye gireceği, schematron'un $type değişkenine bağlıdır. Bu, portal validatörünün belge kanalına göre set etmesi gereken tek parametredir.

UBL-TR_Main_Schematron.xml satır 17'de <let name="type" value="efatura"/> sabittir. Yani korpustaki ana schematron yalnızca e-Fatura doğrular; e-Arşiv ve görüntüleme için aynı Common_Schematron'u farklı $type ile include eden ayrı main dosyaları gerekir.

#1. ProfileID (Senaryo) — tam liste ve belge türü geçerliliği

UBL-TR_Codelist.xml içinde dört ayrı ProfileID listesi tanımlıdır (satır 5-8):

<sch:let name="ProfileIDType" value="',TICARIFATURA,TEMELFATURA,YOLCUBERABERFATURA,IHRACAT,OZELFATURA,KAMU,HKS,ENERJI,ILAC_TIBBICIHAZ,YATIRIMTESVIK,IDIS,'"/>
<sch:let name="ProfileIDTypeEarchive" value="',EARSIVFATURA,'"/>
<sch:let name="ProfileIDTypeDespatchAdvice" value="',TEMELIRSALIYE,HKSIRSALIYE,IDISIRSALIYE,'"/>
<sch:let name="ProfileIDTypeGoruntuleme" value="',TICARIFATURA,TEMELFATURA,YOLCUBERABERFATURA,IHRACAT,EARSIVFATURA,OZELFATURA,KAMU,HKS,ENERJI,ILAC_TIBBICIHAZ,YATIRIMTESVIK,IDIS,'"/>

Ek olarak: ApplicationResponse (uygulama/sistem yanıtı) belgelerinde S_APR yanıt kodu için ProfileID sabit olarak UBL-TR-PROFILE-1 olmalıdır; bu değer yukarıdaki dört listede yer almaz, ayrı kuralla (ApplicationResponseProfileIDCheck) doğrulanır.

Senaryo doğrulayan kurallar:

recp:ReceiptAdvice (İrsaliye Yanıtı) belgesinde ProfileID kontrolü yoktur; bu context'e yalnızca ReceiptAdviceTypeCodeCheck, ReceiptAdviceIDCheck ve CustomizationIDCheck bağlıdır.

#2. InvoiceTypeCode (Fatura Tipi) — tam liste (20 değer)

UBL-TR_Codelist.xml satır 10:

<sch:let name="InvoiceTypeCodeList" value="',SATIS,IADE,TEVKIFAT,TEVKIFATIADE,ISTISNA,OZELMATRAH,IHRACKAYITLI,SGK,KOMISYONCU,HKSSATIS,HKSKOMISYONCU,KONAKLAMAVERGISI,SARJ,SARJANLIK,TEKNOLOJIDESTEK,YTBSATIS,YTBIADE,YTBISTISNA,YTBTEVKIFAT,YTBTEVKIFATIADE,'"/>

İsimlendirme tuzağı: SARJ = HAFTALIK, SARJANLIK = ANLIK. Sezgiye ters olduğu için kod üretiminde en sık yapılan hatadır.

e-Arşiv'e özgü ek grup (UBL-TR_Codelist.xml satır 68) — e-Arşiv'de ProfileID daima EARSIVFATURA olduğundan, yatırım teşvik faturaları senaryo yerine tip üzerinden yakalanır:

<sch:let name="YatirimTesvikEArsivInvoiceTypeCodeList" value="',YTBSATIS,YTBIADE,YTBISTISNA,YTBTEVKIFAT,YTBTEVKIFATIADE,'"/>

#3. Senaryo × Fatura Tipi geçerlilik matrisi

Lejant

• OK — schematron ve kılavuz düzeyinde serbest; ek zorunlu alan yok
• KOSULLU — geçerli, ancak senaryo/tip nedeniyle ek zorunlu alan(lar) devreye girer
• KOSULLU* — schematron engellemez, ancak Yatırım Teşvik Teknik Kılavuzu V1.2 bu tipleri e-Arşiv'e özgü kılar; portal kendi katmanında bloklamalıdır
• YASAK — schematron assert hatası verir

Satır = ProfileID (11 e-Fatura senaryosu + EARSIVFATURA), sütun = InvoiceTypeCode (20 tip). Toplam 240 hücre: 153 geçerli (OK + KOSULLU + KOSULLU*), 87 YASAK.

#Tablo A — Genel fatura tipleri

#Tablo B — Özel / sektörel fatura tipleri

#3.1 YASAK hücrelerinin dayanağı

Y2/Y3'ün kaynağı tek bir çift koşulludur: $type ∈ {efatura, ''} iken ProfileID = 'ENERJI' ⟺ InvoiceTypeCode ∈ {SARJ, SARJANLIK}. $type = 'earchive' veya 'goruntuleme' iken assert vacuous geçer — EARSIVFATURA + SARJ/SARJANLIK bu nedenle geçerlidir.

Sektörel satırlarda birden fazla assert aynı hücreyi reddeder (örn. ILAC_TIBBICIHAZ × SARJ hem Y3 hem Y5'e takılır); portal ilk hatayı vermekle yetinmemeli, tüm ihlalleri raporlamalıdır.

#3.2 KOSULLU hücrelerinin dayanağı

Özel VKN tetikleyicisi (matrisi daraltır): alıcı VKN'si 1460415308 (Gümrük ve Ticaret Bakanlığı BİDB) ise TaxFreeInvoiceCheck (Common 275-277) devreye girer — "1460415308 vergi Numaralı mükellefe (GÜMRÜK VE TİCARET BAKANLIĞI BİLGİ İŞLEMDAİRESİ BAŞKANLIĞI) yollanan fatura senaryosu 'YOLCUBERABERFATURA' veya IHRACAT olabilir". XPath fiilen YOLCUBERABERFATURA, IHRACAT, OZELFATURA, KAMU dördünü kabul eder; mesaj metni ikisini sayar.

#4. Senaryo ve tip bazlı ek zorunlu alanlar

#4.1 Senaryo bazlı

Yatırım Teşvik harcama tipi (ItemClassificationCode) zinciri — hem e-Fatura hem e-Arşiv için:

Paket içi çelişki: YatirimTesvikKDVCheck / YatirimTesvikLineKDVCheck KDV > 0 zorunluluğundan yalnızca dört iade tipini muaf tutar; ISTISNA ve YTBISTISNA muaf değildir. Oysa Yatırım Teşvik Teknik Kılavuzu V1.2, KDV tutarının "0" geçilmesi durumunda ISTISNA/YTBISTISNA tipiyle 308/339 kullanılmasını söyler. Bkz. Doğrulanamayanlar.

#4.2 Fatura tipi bazlı

#4.3 Her belgede koşulsuz çalışan kurallar

#5. DespatchAdviceTypeCode, ReceiptAdviceTypeCode ve ResponseCodeType

#5.1 DespatchAdviceTypeCodeList (e-İrsaliye tipi) — 2 değer

<sch:let name="DespatchAdviceTypeCodeList" value="',SEVK,MATBUDAN,'"/>

DespatchAdviceTypeCodeCheck (Common 720-724), 2 assert:

UBL-TR İrsaliye V1.2 ayrıca aynı AdditionalDocumentReference altındaki DocumentType alanına sabit MATBU yazılmasını şart koşar.

e-İrsaliye senaryo × tip matrisi

Her e-İrsaliyede koşulsuz zorunlu olanlar: cac:Shipment/cac:Delivery/cac:Despatch/cbc:ActualDespatchDate (YYYY-MM-DD), cbc:ActualDespatchTime, teslimat adresinde CitySubdivisionName + CityName + Country/Name + PostalZone (regex ^((0[1-9])|([1-7][0-9])|(8[0-1]))[0-9]{3}$), ve cac:ShipmentStage/cac:DriverPerson ile cac:Delivery/cac:CarrierParty'den en az biri. Şoför bilgisi varsa geçerli LicensePlateID zorunludur — schemeID='PLAKA' için regex ^(0[1-9]|[1-7][0-9]|8[01])[A-Z]+[0-9]+$, schemeID='YABANCIPLAKA' için ^[A-Z0-9_-]+$.

#5.2 ReceiptAdviceTypeCodeList (e-İrsaliye Yanıtı tipi) — 1 değer

<sch:let name="ReceiptAdviceTypeCodeList" value="',SEVK,'"/>

ReceiptAdviceTypeCodeCheck (Common 797-799): "Geçersiz cbc:ReceiptAdviceTypeCode elemanı değeri : '…'. Geçerli cbc:ReceiptAdviceTypeCode değerleri için kod listesine bakınız."

Ayrıca ReceiptAdviceIDCheck (Common 158-160): cbc:ID tam 16 hane olmalıdır.

#5.3 ResponseCodeType (uygulama yanıtı) — 5 değer

<sch:let name="ResponseCodeType" value="',KABUL,RED,IADE,S_APR,GUMRUKONAY,'"/>

Zarf türü kısıtı — PostBoxResponseCodeCheck (Common 599-601): POSTBOXENVELOPE zarflarında ResponseCode yalnızca RED, KABUL, IADE, GUMRUKONAY olabilir; yani S_APR posta kutusu zarfı ile gönderilemez.

AppResponseCodeType — tam liste (32 değer): 1000, 1100, 1110, 1111, 1120, 1130, 1131, 1132, 1133, 1140, 1141, 1142, 1143, 1150, 1160, 1161, 1162, 1163, 1170, 1171, 1172, 1175, 1176, 1177, 1180, 1181, 1182, 1183, 1190, 1191, 1195, 1200

EnvelopeType — tam liste (4 değer): SENDERENVELOPE, POSTBOXENVELOPE, SYSTEMENVELOPE, USERENVELOPE

ElementType — tam liste (7 değer): INVOICE, APPLICATIONRESPONSE, PROCESSUSERACCOUNT, CANCELUSERACCOUNT, DESPATCHADVICE, RECEIPTADVICE, CREDITNOTE

#6. Portal için uygulanabilir validasyon kural seti

Aşağıdaki zincir, schematron'un fiilî değerlendirme sırasını yansıtır. Portal bu kuralları koda gömülü sabit olarak değil, veri tabanı tablosu / konfigürasyon dosyası olarak tutmalıdır: matrisin ENERJI, IDIS, Yatırım Teşvik ve 555 satırları son 9 ayda eklenmiştir (History.txt: 20251209, 20260109, 20260312, 20260701).

Adım 0 — Kanal seçimi

type = 'efatura' | 'earchive' | 'goruntuleme'

Adım 1 — ProfileID geçerliliği

if type == 'efatura' or type == '':
    ProfileID ∈ [TICARIFATURA, TEMELFATURA, YOLCUBERABERFATURA, IHRACAT, OZELFATURA,
                 KAMU, HKS, ENERJI, ILAC_TIBBICIHAZ, YATIRIMTESVIK, IDIS]        else -> RED
if type == 'earchive':
    ProfileID == 'EARSIVFATURA'                                                  else -> RED
if type == 'goruntuleme':
    ProfileID ∈ (yukaridaki 11 + EARSIVFATURA)                                   else -> RED
# DespatchAdvice belgesi icin (type efatura/goruntuleme/'' iken):
    ProfileID ∈ [TEMELIRSALIYE, HKSIRSALIYE, IDISIRSALIYE]                       else -> RED
# STDKODFATURA hicbir listede yoktur -> portal uretmemelidir

Adım 2 — InvoiceTypeCode kod listesi

InvoiceTypeCode ∈ [SATIS, IADE, TEVKIFAT, TEVKIFATIADE, ISTISNA, OZELMATRAH,
                   IHRACKAYITLI, SGK, KOMISYONCU, HKSSATIS, HKSKOMISYONCU,
                   KONAKLAMAVERGISI, SARJ, SARJANLIK, TEKNOLOJIDESTEK,
                   YTBSATIS, YTBIADE, YTBISTISNA, YTBTEVKIFAT, YTBTEVKIFATIADE]  else -> RED

Adım 3 — Genel senaryo/tip kombinasyon kuralları

R2 (InvoiceTypeCodeCheck#2):
    if InvoiceTypeCode == 'IADE'
       and ProfileID not in [TEMELFATURA, EARSIVFATURA, ILAC_TIBBICIHAZ,
                             YATIRIMTESVIK, IDIS, KAMU]                          -> RED
R3 (InvoiceTypeCodeCheck#3):  # yalnizca type in ('efatura','')
    if ProfileID == 'ENERJI' and InvoiceTypeCode not in [SARJ, SARJANLIK]        -> RED
    if InvoiceTypeCode in [SARJ, SARJANLIK] and ProfileID != 'ENERJI'            -> RED
R4 (InvoiceTypeCodeCheck#4):
    if InvoiceTypeCode == 'TEKNOLOJIDESTEK' and ProfileID != 'EARSIVFATURA'      -> RED

Adım 4 — Sektörel beyaz listeler

R5 (IlacTibbiCihazInvoiceTypeCodeCheck):
    if ProfileID == 'ILAC_TIBBICIHAZ'
       and InvoiceTypeCode not in [SATIS, ISTISNA, TEVKIFAT, TEVKIFATIADE,
                                   IADE, IHRACKAYITLI]                           -> RED
R6 (YatirimTesvikInvoiceTypeCodeCheck):
    if ProfileID == 'YATIRIMTESVIK'
       and InvoiceTypeCode not in [SATIS, ISTISNA, IADE, TEVKIFAT,
                                   TEVKIFATIADE]                                 -> RED
R7 (IdisInvoiceTypeCodeCheck):
    if ProfileID == 'IDIS'
       and InvoiceTypeCode not in [SATIS, ISTISNA, IADE, TEVKIFAT,
                                   TEVKIFATIADE, IHRACKAYITLI]                   -> RED

Adım 5 — Portal ek kuralı (schematron'da YOK, kılavuzda VAR)

R8: if InvoiceTypeCode startswith 'YTB' and ProfileID != 'EARSIVFATURA'
        -> RED/UYARI   (Yatirim Tesvik Teknik Kilavuzu V1.2; matriste KOSULLU*)

Adım 6 — Tevkifat bloğu (her iki kural da yalnızca UBLVersionID = '2.1' iken devrededir)

if exists(cac:WithholdingTaxTotal)
   and InvoiceTypeCode not in [TEVKIFAT, YTBTEVKIFAT, IADE, YTBIADE,
                               SGK, SARJ, SARJANLIK]                             -> RED
   # DIKKAT: TEVKIFATIADE ve YTBTEVKIFATIADE bu listede YOKTUR
if exists(TaxTotal/.../TaxTypeCode == '4171')
   and InvoiceTypeCode not in [TEVKIFAT, IADE, SGK, YTBIADE]                     -> RED
   # DIKKAT: YTBTEVKIFAT bu listede YOKTUR (assert-1 ile asimetrik)
foreach WithholdingTaxTotal/TaxSubtotal:
    TaxTypeCode ve Percent dolu olmali
    TaxTypeCode ∈ WithholdingTaxType (52 kod)
    concat(TaxTypeCode, Percent) ∈ WithholdingTaxTypeWithPercent (64 deger)

WithholdingTaxType — tam liste (52 kod): 601, 602, 603, 604, 605, 606, 607, 608, 609, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 622, 623, 624, 625, 626, 627, 801, 802, 803, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813, 814, 815, 816, 817, 818, 819, 820, 821, 822, 823, 824, 825

WithholdingTaxTypeWithPercent — tam liste (64 değer; okuma: 60130 = 601 kodu + %30, 801100 = 801 kodu + %100): 60130, 60140, 60290, 60350, 60370, 60450, 60550, 60690, 60790, 60890, 60950, 60970, 61090, 61190, 61270, 61290, 61370, 61390, 61450, 61550, 61570, 61650, 61770, 61870, 61970, 62070, 62190, 62290, 62350, 62420, 62530, 62620, 65090, 65050, 65070, 65020, 65030, 62740, 62750, 801100, 802100, 803100, 804100, 805100, 806100, 807100, 808100, 809100, 810100, 811100, 812100, 813100, 814100, 815100, 816100, 817100, 818100, 819100, 820100, 821100, 822100, 823100, 824100, 825100

Adım 7 — İstisna / özel matrah / ihraç kayıtlı kodu bloğu

if TaxExemptionReason dolu:
    TaxExemptionReasonCode dolu olmali                                           else -> RED
    if code in [308, 339]:
        (ProfileID == 'YATIRIMTESVIK'
         or InvoiceTypeCode in [YTBSATIS, YTBIADE, YTBISTISNA,
                                YTBTEVKIFAT, YTBTEVKIFATIADE])                   else -> RED
    elif code not in TaxExemptionReasonCodeType (111 kod)                        -> RED
    if code != 555 and code in istisnaTaxExemptionReasonCodeType (94 kod):
        InvoiceTypeCode in [ISTISNA, IADE, IHRACKAYITLI, SGK,
                            YTBISTISNA, YTBIADE]                                 else -> RED
    if code in [801,802,803,804,805,806,807,808,809,810,811,812]:
        InvoiceTypeCode in [OZELMATRAH, IADE, SGK]                               else -> RED
    if code in [701, 702, 703, 704]:
        InvoiceTypeCode in [IHRACKAYITLI, IADE, SGK]                             else -> RED
    if code == 702 and InvoiceTypeCode == 'IHRACKAYITLI':
        her InvoiceLine'da 12 haneli RequiredCustomsID (GTIP)
        ve 11 haneli ALICIDIBSATIRKOD                                            else -> RED
    if code == 555:
        ProfileID in [TEMELFATURA, TICARIFATURA, EARSIVFATURA]                   else -> RED
        InvoiceTypeCode not in [ISTISNA, IHRACKAYITLI]                           else -> RED
        not (ProfileID == 'EARSIVFATURA' and InvoiceTypeCode startswith 'YTB')   else -> RED
        hicbir 0015 TaxSubtotal'da Percent == 0 veya TaxAmount == 0 olamaz
        (fatura basi TaxTotal + ../cac:InvoiceLine/cac:TaxTotal birlikte taranir)
    if code in [151, 351]:
        fatura tipi kisiti YOKTUR — bu iki kod hicbir alt listede degildir,
        yalnizca ana TaxExemptionReasonCodeType listesindedir

if KDV(0015) TaxAmount == 0
   and InvoiceTypeCode not in [IADE, YTBIADE, IHRACKAYITLI, OZELMATRAH,
                               SGK, KONAKLAMAVERGISI]:
    TaxExemptionReason ZORUNLU                                                   else -> RED

istisnaTaxExemptionReasonCodeType — tam liste (94 kod; 201-250 aralığı sürekli DEĞİLDİR): 001, 101, 102, 103, 104, 105, 106, 107, 108, 201, 202, 204, 205, 206, 207, 208, 209, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 223, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 250, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 350, 501 Bu listede bulunmayan ara değerler: 203, 210, 222, 224, 243, 244, 245, 246, 247, 248, 249.

308 / 339 kapısı: $YatirimTesvikTaxExemptionReasonCodeType = ',308,339,' ve bu iki kod ana $TaxExemptionReasonCodeType listesinde yoktur. Yani 308 ("13/d Teşvikli Yatırım Mallarının Teslimi") ve 339 ("İmalat Sanayii ile Turizme Yönelik Yatırım Teşvik Belgesi Kapsamındaki İnşaat İşlerine İlişkin Teslim ve Hizmetler") yalnızca ProfileID='YATIRIMTESVIK' iken veya tip YTB* iken kullanılabilir.

"0 KDV'li SATIS" çıkış yolu: 351 ("KDV - İstisna Olmayan Diğer") veya OTV için 151. Bu iki kod istisna alt listesinde olmadığı için fatura tipini ISTISNA'ya çevirmek gerekmez; SATIS tipiyle geçerlidir. 555 bu problemin çözümü değildir — DemirbasKDVTaxExemptionCheck assert-2 555 ile KDV 0'ı yasaklar.

Adım 8 — Senaryo/tip bazlı zorunlu alan enjeksiyonu: §4'teki tablolardan üretilir.

Adım 9 — Regresyon testi: 12 senaryo × 20 tip = 240 kombinasyon; beklenen sonuç 153 geçerli / 87 RED. Portal test paketi bu 240 hücrenin tamamını kapsamalı, schematron paketi her güncellendiğinde matris yeniden üretilip bu testle karşılaştırılmalıdır.

#Doğrulanamayanlar

Aşağıdaki maddeler korpustan kesin sonuca bağlanamamıştır veya kaynaklar arasında çelişki içerir. Portal bu maddeleri olgu olarak uygulamamalı, gerekiyorsa GİB'e sormalıdır.

#Tevkifat Kodları ve Oranları

Tevkifat kodları, cac:WithholdingTaxTotal bloğunun içindeki cbc:TaxTypeCode alanına yazılan ve normal vergi kodu listesinden (0015 KDV, 4171 ÖTV tevkifatı vb.) tamamen ayrı olan bir listedir. Doğrulamanın tek otoritesi e-Fatura paketindeki UBL-TR_Codelist.xml dosyasında tanımlı iki schematron değişkenidir:

Değişkenlerin korpustaki birebir hali (UBL-TR_Codelist.xml, satır 16-17):

<sch:let name="WithholdingTaxType" value="',601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,801,802,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,818,819,820,821,822,823,824,825,'"/>

<sch:let name="WithholdingTaxTypeWithPercent" value="',60130,60140,60290,60350,60370,60450,60550,60690,60790,60890,60950,60970,61090,61190,61270,61290,61370,61390,61450,61550,61570,61650,61770,61870,61970,62070,62190,62290,62350,62420,62530,62620,65090,65050,65070,65020,65030,62740,62750,801100,802100,803100,804100,805100,806100,807100,808100,809100,810100,811100,812100,813100,814100,815100,816100,817100,818100,819100,820100,821100,822100,823100,824100,825100,'"/>

Listelerin başında ve sonunda tek tırnak + virgül olması, contains($WithholdingTaxType, concat(',',kod,',')) biçimindeki alt-dize aramasının ilk (601) ve son (825) elemanı da yakalayabilmesi içindir. Portalde bu iki diziyi sabit (hardcoded) tutabilirsin. 601-627 ve 801-825 dışında hiçbir tevkifat kodu yoktur: 628-800 arası boştur, 826 ve üzeri yoktur, 650 bu listede yoktur.

#601-627: Kısmi Tevkifat Kodları (tam tablo, 27 kod)

Metodoloji uyarısı: V1.43 PDF'inin metin çıktısında tevkifat tablosunun sütunları bir satır kaymıştır — "ADI" başlığı 601 satırına düşmüş, isim akışı bir satır aşağı kaymış görünür (602 Yapim İşleri..., 603 Etüt, Plan-Proje... gibi). Doğru eşleşme, isim akışının ve oran akışının ayrı ayrı sıralı okunmasıyla kurtarılmış ve 52 kodun 52'sinde de schematron'un WithholdingTaxTypeWithPercent listesiyle bire bir çapraz doğrulanmıştır. Aşağıdaki tablo bu nedenle iki bağımsız kaynakla teyitlidir.

Kılavuzun bastığı oran akışı (27 değer, sırayla, birebir): 4/10, 9/10, 7/10, 5/10, 5/10, 9/10, 9/10, 9/10, 7/10, 9/10, 9/10, 9/10, 9/10, 5/10, 7/10, 5/10, 7/10, 7/10, 7/10, 7/10, 9/10, 9/10, 5/10, 2/10, 3/10, 2/10, 5/10 — bunu takip eden 25 adet 10/10 değeri 801-825 bloğuna aittir.

Hizmet / teslim kırılımı: 601-616 hizmet tevkifatı (KDVGUT I/C-2.1.3.2.x), 617-623 ve 626-627 teslim tevkifatı (KDVGUT I/C-2.1.3.3.x), 624-625 tekrar hizmet (I/C-2.1.3.2.11 ve I/C-2.1.3.2.15). Yani numaralandırma konu sırasına göre değil, kronolojik ekleme sırasına göredir; portalde kodları gruplarken "601-616 hizmet, 617+ teslim" gibi bir kısayol kurma.

#801-825: Tam (%100) Tevkifat Kodları (tam tablo, 25 kod)

801-825 bloğu 601-627'den ne ile ayrılır? İkisi de aynı WithholdingTaxType listesinin parçasıdır ve V1.43'te aynı "TEVKİFAT KODLARI LİSTESİ" tablosunun kesintisiz devamı olarak yayımlanmıştır — arada ayrı bir başlık veya bölüm yoktur. Fark tek bir noktadadır:

Yani 801-825, yeni işlem türleri değil; 601-627'deki işlemlerin %100 tevkifatlı hâlidir. 801100 şu demektir: TaxTypeCode = 801, cbc:Percent = 100.

Eşleştirme formülü (üç parçalıdır, tek kural değildir):

616 (Diğer Hizmetler) ve 626 (Diğer Teslimler) kodlarının %100 karşılığı yoktur. 27 kısmi kod vardır ama yalnızca 25 tam-oranlı karşılık bulunmasının nedeni budur. Eşlemeyi portalde formülle değil, yukarıdaki tabloyu sabit bir sözlük olarak tutarak yap — iki kırılma noktası ve iki boşluk olduğu için formül kırılgandır.

En büyük karışıklık riski — 801-812 aynı zamanda ÖZEL MATRAH kodudur. Aynı V1.43 kılavuzunda 801-812 numaraları ikinci bir listede daha geçer: "ÖZEL MATRAH KODLARI LİSTESİ" (801 = Milli Piyango, Spor Toto vb. Oyunlar; 802 = At Yarışları ve Diğer Müşterek Bahis ve Talih Oyunları; ... ; 812 = KDV Uygulanmadan Alınan İkinci El Motorlu Kara Taşıtı veya Taşınmaz Teslimi). Bunlar tamamen farklı bir listedir:

Özel matrah listesi schematron'da ayrıdır: <sch:let name="ozelMatrahTaxExemptionReasonCodeType" value="',801,802,803,804,805,806,807,808,809,810,811,812,'"/>. Portal veritabanında bu iki listeyi asla tek tabloda tutma.

#WithholdingTaxTypeWithPercent Kodlama Mantığı

Kodlama matematiksel değil, metinseldir: TaxTypeCode metni ile cbc:Percent metni arka arkaya yapıştırılır ve sonuç listede aranır. Oran kesir değil, yüzde olarak yazılır.

• 60130 = TaxTypeCode 601 + Percent 30 → 3/10 = %30
• 60140 = TaxTypeCode 601 + Percent 40 → 4/10 = %40
• 801100 = TaxTypeCode 801 + Percent 100 → 10/10 = %100

Bunu doğrulayan schematron assert'i (UBL-TR_Common_Schematron.xml, satır 312) bu birleştirmeyi XPath concat() ile birebir yapar:

<sch:assert test="contains($WithholdingTaxTypeWithPercent, concat(',',cac:TaxCategory/cac:TaxScheme/cbc:TaxTypeCode,cbc:Percent,','))">
  Uyumsuz vergi tipi yüzdesi: '...' vergi tipinin yüzdesi '...' olamaz
</sch:assert>

Kritik geliştirici tuzağı — cbc:Percent ondalık YASAĞI. Birleştirme metinsel olduğu için tevkifattaki cbc:Percent mutlaka ondalıksız tamsayı olmalıdır:

Bu, KDV oranının aksinedir: KDV tarafında kılavuz örneği <cbc:Percent>18.0</cbc:Percent> biçiminde ondalıklı yazar ve bu geçerlidir. Tevkifatta ondalık yasak, KDV'de serbest. Portal kodunda tevkifat Percent alanını decimal değil int olarak serialize et.

#Geçerli kod + oran kombinasyonlarının tam listesi (64 adet)

6xx bloğu — 39 kombinasyon:

8xx bloğu — 25 kombinasyon (hepsi Percent = 100, oran 10/10):

Sayım doğrulaması: 27 adet 6xx kodundan 7'si çift oranlı (7 × 2 = 14 kayıt) + 20'si tek oranlı (20 kayıt) + 650'nin 5 kaydı = 39; 39 + 25 = 64. ✔

Birden fazla orana sahip kodlar — 8 adet (650 hariç 7): 601 (30, 40), 603 (50, 70), 609 (50, 70), 612 (70, 90), 613 (70, 90), 615 (50, 70), 627 (40, 50), 650 (20, 30, 50, 70, 90). Bu kodlarda eski oranlar geriye dönük düzeltme ve iade faturaları için listede tutulmaya devam ediyor.

Ancak her eski oran listede DEĞİL. WithholdingTaxTypeWithPercent geriye dönük olarak eksiktir: 617, 618, 619 ve 620 kodlarının 2015 dönemindeki 5/10 oranı (61750, 61850, 61950, 62050) listede yoktur; aynı şekilde 601'in en eski oranı olan 2/10 (60120) da yoktur — 601 için listedeki en eski değer 3/10'dur. 2015-2019 arası kesilmiş bir faturayı aynı kod ve oranla yeniden üretmeye çalışırsan schematron reddeder.

Listenin schematron'daki fiziksel sırası da bilgi verir: 60130 → 62620 arası artan (32 eleman), sonra 650'nin 5 elemanı, sonra sıra dışına düşmüş 62740 ve 62750, en sonda 801100 → 825100. 627'nin (demir-çelik) sıralamayı bozup 650'den sonra gelmesi, bu kodun listeye en son eklendiğinin kanıtıdır ve History.txt'deki 20221101 tarihli "WithholdingTaxTypeWithPercent güncellendi" kaydıyla örtüşür.

#Ölü ve Kullanılmayan Kodlar

650 kodunu kullanma — kullanılamaz.

WithholdingTaxTypeWithPercent listesinde 650 kodu için beş kombinasyon (65020, 65030, 65050, 65070, 65090) hâlâ duruyor. Ancak 650 kodu WithholdingTaxType listesinde YOKTUR. WithholdingTaxTotalCheck kuralı iki ayrı assert çalıştırır ve ikisinin de geçmesi gerekir:

<cbc:TaxTypeCode>650</cbc:TaxTypeCode> gönderirsen fatura şu hatayla reddedilir: "Geçersiz cac:TaxCategory/cac:TaxScheme/cbc:TaxTypeCode elemanı : '650'. Geçerli değerler için kod listesine bakınız."

650, Ekim 2015 tarihli kılavuzda "DİĞERLERİ" adıyla ve 2/10, 5/10, 7/10, 9/10 oranlarıyla listede yer alıyordu; V1.22 (14.03.2019) değişiklik kaydı "650 Tevkifat koduna 3/10 eklendi" diyor. Ancak ne V1.31'de ne de V1.43'te tevkifat tablosunda 650 satırı vardır — kod yalnızca değişiklik geçmişi satırında adı geçer. Yerini 616 (Diğer Hizmetler) ve 626 (Diğer Teslimler) almıştır. WithholdingTaxTypeWithPercent'teki beş kayıt temizlenmemiş ölü koddur.

Portal aksiyonu: 650'yi kullanıcı arayüzünde hiç gösterme. Eski kayıtlardan / migrasyondan geliyorsa hizmet için 616'ya, teslim için 626'ya map et. Kod listesi doğrulamasını yaparken yalnızca WithholdingTaxType'ı otorite kabul et, WithholdingTaxTypeWithPercent'i kod kaynağı olarak kullanma — o liste 52 değil 53 farklı kod içerir ve fazladan olan 650 geçersizdir.

Ayrıca hiç var olmamış kod aralıkları: 628-800 arası (tamamı), 826 ve üzeri. Bu aralıklarda tek bir geçerli tevkifat kodu bile yoktur.

#XML'de Tevkifat Nasıl Yazılır

Tam XPath — fatura seviyesi: /Invoice/cac:WithholdingTaxTotal/cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:TaxTypeCode

Tam XPath — kalem seviyesi: /Invoice/cac:InvoiceLine/cac:WithholdingTaxTotal/cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:TaxTypeCode

Kılavuzun birebir örneği (UBL-TR Fatura V1.0, bölüm 2.3.42; aynı örnek UBL-TR Ortak Elemanlar V0.7 içinde de tekrarlanır) — korpustaki tek gerçek GİB tevkifat örneği:

<cac:WithholdingTaxTotal>
    <cbc:TaxAmount currencyID="TRY">3240</cbc:TaxAmount>
    <cac:TaxSubtotal>
        <cbc:TaxAmount currencyID="TRY">3240</cbc:TaxAmount>
        <cbc:Percent>90</cbc:Percent>
        <cac:TaxCategory>
            <cac:TaxScheme>
                <cbc:TaxTypeCode>606</cbc:TaxTypeCode>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:TaxSubtotal>
</cac:WithholdingTaxTotal>

Doğrulama: 606 + 90 → 60690 → listede mevcut ✔ (606 = İşgücü Temin Hizmetleri, 9/10).

Yapısal notlar:

• cac:TaxScheme altında cbc:Name yoktur (normal KDV'de <cbc:Name>Katma Değer Vergisi</cbc:Name> yazılır; tevkifat örneğinde kullanılmamıştır).
• cac:TaxCategory altında doğrudan cac:TaxScheme gelir; cbc:TaxExemptionReasonCode burada kullanılmaz.
• cac:WithholdingTaxTotal/cbc:TaxAmount (toplam tevkifat) ile cac:TaxSubtotal/cbc:TaxAmount (o kod için tevkifat) ayrı ayrı yazılır; örnekte tek kod olduğu için ikisi eşittir (3240).
• Örnekte cbc:TaxableAmount kullanılmamıştır; tanımı gereği Seçimli (0..1)'dir.
• currencyID niteliği zorunludur.

Kardinaliteler:

Eleman sırası (şema geçerliliği için kritik):

• Fatura seviyesinde WithholdingTaxTotal ana eleman tablosunda 42. sıradadır: TaxTotal (41) ile LegalMonetaryTotal (43) arasına, InvoiceLine'dan (44) önce yazılmalıdır.
• Kalem seviyesinde InvoiceLine sırası şudur: ID (1), Note (0..1), InvoicedQuantity (1), LineExtensionAmount (1), OrderLineReference (0..n), DespatchLineReference (0..n), ReceiptLineReference (0..n), Delivery (0..n), AllowanceCharge (0..n), TaxTotal (0..1), WithholdingTaxTotal (0..n), Item (1), Price (1), SubInvoiceLine (0..n). Dikkat: LineExtensionAmount, InvoicedQuantity'den hemen sonra 4. sıradadır — Delivery ile AllowanceCharge arasında değildir; ve kalem seviyesinde TaxTotal 0..1'dir (0..n değil).

cac:TaxTotal ile cac:WithholdingTaxTotal paralel ve ayrı elemanlardır. Kılavuz TaxTotal'in üç kullanım biçimini tanımlarken tevkifatı şöyle açıklıyor: "'WithholdingTaxTotal': Tevkifatlı faturalarda, uygulanan tevkifat miktarları, oranları ve diğer bilgileri girilir. TaxAmount: Toplam tevkifat tutarı girilir. TaxSubtotal: Tevkifat kodu ve oranı bilgisi girilir." Yani tevkifat, TaxTotal içindeki KDV'yi azaltmaz; TaxTotal KDV'nin tamamını (TaxTypeCode 0015), WithholdingTaxTotal ise tevkif edilen kısmı ayrı ayrı bildirir.

Hesap sırası (korpustaki eleman tanımlarından türetilmiş):

1. LineExtensionAmount = miktar × birim fiyat − iskonto
2. TaxTotal/TaxSubtotal: TaxableAmount = matrah, Percent = KDV oranı, TaxAmount = matrah × oran, TaxTypeCode = 0015
3. WithholdingTaxTotal/TaxSubtotal: Percent = tevkifat yüzdesi (tamsayı!), TaxAmount = 2. adımdaki KDV × (Percent / 100), TaxTypeCode = 601-627 / 801-825
4. WithholdingTaxTotal/TaxAmount = tüm alt TaxSubtotal/TaxAmount değerlerinin toplamı

Korpus kurallarından inşa edilmiş tam TEVKIFAT fatura iskeleti. Parçaların hepsi korpustaki eleman tanımları ve schematron kısıtlarıyla uyumludur; ancak birleşik hâli GİB'in yayımladığı bir örnek değildir — GİB'in kendi TEVKIFAT.xml örnek dosyası bu korpusta yoktur.

<Invoice ...>
  <cbc:UBLVersionID>2.1</cbc:UBLVersionID>
  <cbc:ProfileID>TICARIFATURA</cbc:ProfileID>
  <cbc:ID>ABC2026000000001</cbc:ID>          <!-- 16 hane -->
  <cbc:InvoiceTypeCode>TEVKIFAT</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>TRY</cbc:DocumentCurrencyCode>
  ...
  <!-- 41: KDV'NİN TAMAMI -->
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="TRY">3600</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="TRY">20000</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="TRY">3600</cbc:TaxAmount>
      <cbc:Percent>18</cbc:Percent>
      <cac:TaxCategory>
        <cac:TaxScheme>
          <cbc:Name>Katma Değer Vergisi</cbc:Name>
          <cbc:TaxTypeCode>0015</cbc:TaxTypeCode>
        </cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>

  <!-- 42: TEVKİF EDİLEN KISIM -->
  <cac:WithholdingTaxTotal>
    <cbc:TaxAmount currencyID="TRY">3240</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxAmount currencyID="TRY">3240</cbc:TaxAmount>
      <cbc:Percent>90</cbc:Percent>
      <cac:TaxCategory>
        <cac:TaxScheme>
          <cbc:TaxTypeCode>606</cbc:TaxTypeCode>
        </cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:WithholdingTaxTotal>

  <!-- 43 -->
  <cac:LegalMonetaryTotal>...</cac:LegalMonetaryTotal>
  <!-- 44 -->
  <cac:InvoiceLine>...</cac:InvoiceLine>
</Invoice>

WithholdingTaxTotalCheck kuralının yaptıkları (3 assert):

1. cbc:TaxTypeCode ve cbc:Percent her ikisi de dolu (boş/whitespace olamaz)
2. Kod geçerliliği: contains($WithholdingTaxType, concat(',',TaxTypeCode,','))
3. Kod + oran uyumu: contains($WithholdingTaxTypeWithPercent, concat(',',TaxTypeCode,Percent,','))

Bu kural UBL-TR_Main_Schematron.xml'de iki context'e bağlıdır (satır 175-177 ve 256-258) — yani hem fatura hem kalem seviyesi aynı üç kontrolden geçer. Context cac:TaxSubtotal olduğu için birden fazla TaxSubtotal varsa her biri ayrı ayrı denetlenir.

Kuralın YAPMADIKLARI — portalde kendin kontrol etmelisin:

• Tevkifat tutarının (cbc:TaxAmount) KDV × oran ile tutarlılığını kontrol etmez
• cac:WithholdingTaxTotal/cbc:TaxAmount ile alt TaxSubtotal/cbc:TaxAmount toplamının eşitliğini kontrol etmez
• LegalMonetaryTotal/PayableAmount'tan tevkifatın düşülüp düşülmediğini kontrol etmez. PayableAmount üzerindeki tek schematron kuralı decimalCheck'tir (UBL-TR_Main_Schematron.xml satır 276-278) — yani sadece ondalık format kontrolü (noktadan önce en fazla 15, sonra en fazla 2 hane); tutar mantığına dair hiçbir denetim yoktur
• Tevkifat varken cac:TaxTotal altında 0015 (KDV) bulunması şartını kontrol etmez

#TEVKIFAT vs TEVKIFATIADE

Kod listesi kılavuzunun tanımı (V1.43, bölüm 1.4 InvoiceTypeCode): "tevkifat içeren faturalar için 'TEVKIFAT' değerini, tevkifat içeren faturaların iadesi için 'TEVKIFATIADE'". e-Arşiv / Yatırım Teşvik karşılıkları YTBTEVKIFAT ve YTBTEVKIFATIADE'dir.

TEVKIFATIADE'nin schematron sorunu — kritik. GeneralWithholdingTaxTotalCheck'in birinci assert'i, fatura seviyesinde cac:WithholdingTaxTotal varken fatura tipinin yalnızca TEVKIFAT, YTBTEVKIFAT, IADE, YTBIADE, SGK, SARJ veya SARJANLIK olmasına izin verir. TEVKIFATIADE ve YTBTEVKIFATIADE bu listede yoktur. Yani adı "tevkifat iadesi" olan fatura tipi, fatura seviyesinde tevkifat bloğu taşıyamaz — schematron reddeder. Bu, kılavuz metniyle schematron arasındaki gerçek bir çelişkidir.

Schematron'un ima ettiği iki çıkış yolu:

1. Tevkifatlı iade faturasını TEVKIFATIADE yerine IADE (veya YTBIADE) tipiyle kes — bu iki tip izin listesindedir.
2. TEVKIFATIADE tipini kullan ama tevkifatı yalnızca kalem seviyesinde (cac:InvoiceLine/cac:WithholdingTaxTotal) yaz — bu context assert'in kapsamı dışındadır ve sadece WithholdingTaxTotalCheck uygulanır.

Korpus bu tercihi açıkça yazmıyor; GİB test ortamında doğrulanması gereken bir noktadır.

IADEInvioceCheck — iade faturasının referans zorunluluğu (UBL-TR_Common_Schematron.xml, satır 362). TEVKIFATIADE, IADE, YTBIADE ve YTBTEVKIFATIADE tiplerinde şu dört şart birlikte sağlanmalıdır:

1. En az 1 adet cac:BillingReference/cac:InvoiceDocumentReference bulunacak
2. Her referansın cbc:DocumentTypeCode değeri İADE (İ ile) veya IADE (I ile) olacak — schematron ikisini de kabul eder
3. Her referansın cbc:ID uzunluğu tam 16 karakter olacak (iade edilen faturanın numarası, ör. GIB2026000000001)
4. Kısmi uyum yetmez: geçerli referans sayısı = toplam referans sayısı olmalı

Kural 20250128'de eklenmiş; 20250905, 20251209 ve 20260109 tarihlerinde güncellenmiştir.

Senaryo (ProfileID) kısıtları. InvoiceTypeCodeCheck bazı senaryolarda fatura tipini sınırlar:

Ayrıca IADE tipi için ters yönde bir kısıt vardır: "Fatura tipi IADE iken fatura profili sadece TEMELFATURA, EARSIVFATURA, ILAC_TIBBICIHAZ, YATIRIMTESVIK, IDIS veya KAMU olabilir." TEVKIFATIADE için böyle bir ProfileID kısıtı yoktur — yani TICARIFATURA senaryosunda TEVKIFATIADE kesilebilir ama IADE kesilemez. Yukarıdaki 1. çıkış yolunu (IADE'ye çevirme) uygularken bu kısıta takılmamak için ProfileID'yi de kontrol et.

#Hangi Fatura Tiplerinde Tevkifat Bloğu Taşınabilir

GeneralWithholdingTaxTotalCheck kuralı UBL-TR_Common_Schematron.xml içinde abstract="true" tanımlıdır ve UBL-TR_Main_Schematron.xml'de <sch:rule context="inv:Invoice"> altında <sch:extends rule="GeneralWithholdingTaxTotalCheck"/> (satır 156) ile devreye alınır. İki aktif assert içerir.

Assert 1 — fatura tipi ile cac:WithholdingTaxTotal uyumu:

<sch:assert test="not(cbc:UBLVersionID ='2.1') or not(exists(cac:WithholdingTaxTotal))
  or cbc:InvoiceTypeCode = 'TEVKIFAT' or cbc:InvoiceTypeCode = 'YTBTEVKIFAT'
  or cbc:InvoiceTypeCode = 'IADE' or cbc:InvoiceTypeCode = 'YTBIADE'
  or cbc:InvoiceTypeCode = 'SGK' or cbc:InvoiceTypeCode = 'SARJ'
  or cbc:InvoiceTypeCode = 'SARJANLIK'">
  Uyumsuz fatura tipi: '...'. cac:WithholdingTaxTotal elamanı varken fatura tipi
  TEVKIFAT,YTBTEVKIFAT,IADE,YTBIADE,SGK,SARJ ve SARJANLIK olabilir.
</sch:assert>

Assert 2 — 4171 (Petrol / Doğalgaz ÖTV Tevkifatı) kısıtı:

<sch:assert test="not(cbc:UBLVersionID ='2.1')
  or not(exists(cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cac:TaxScheme/cbc:TaxTypeCode[text() = '4171']))
  or cbc:InvoiceTypeCode = 'TEVKIFAT' or cbc:InvoiceTypeCode = 'IADE'
  or cbc:InvoiceTypeCode = 'SGK' or cbc:InvoiceTypeCode = 'YTBIADE'">

Dikkat: 4171 kodu WithholdingTaxTotal'da değil, normal cac:TaxTotal altında yazılır. 4171, TaxType listesinin elemanıdır; WithholdingTaxType'ta yer almaz. Kod listesindeki adı: "4171 Petrol Ve Doğalgaz Ürünlerine İlişkin Ötv Tevkifatı / PTR-DGZ ÖTV TEVKİFAT". Burada izin verilen fatura tipleri yalnızca dörttür: TEVKIFAT, IADE, SGK, YTBIADE — YTBTEVKIFAT, SARJ ve SARJANLIK bu listede yoktur.

Dosyada üçüncü bir assert daha vardır ama yorum satırına alınmıştır, aktif değildir: 4171 varken 0071 kodunun da bulunması şartı.

Kural kapsamı asimetriktir — çok önemli. GeneralWithholdingTaxTotalCheck'in context'i inv:Invoice olduğundan test içindeki cac:WithholdingTaxTotal yalnızca doğrudan çocuk elemanı arar. Bu nedenle:

Yani kalem bazlı tevkifatta (cac:InvoiceLine/cac:WithholdingTaxTotal) kod ve oran denetlenir, ama fatura tipi kısıtı denetlenmez. Kalem bazlı tevkifat kılavuzda açıkça desteklenir: "WithholdingTaxTotal: Kalem bazlı tevkifat uygulanması durumunda bu eleman kullanılır."

Kamu e-Fatura (ProfileID = KAMU). Kamu e-Fatura Teknik Kılavuzu v1.5, kamu faturalarına uygulanan kural setinde GeneralWithholdingTaxTotalCheck'i iki ayrı tabloda listeler — yani kamu faturalarında da aynı tevkifat kuralları geçerlidir. Ek olarak şu üç kural devreye girer ve doldurulmazsa fatura reddedilir:

Schematron değişiklik geçmişi (History.txt, doğrulanmış tarihler):

20221101'den bu yana (yaklaşık 3,8 yıldır) tevkifat kod ve oran listelerinde schematron değişikliği yoktur. 20260109, 20260312 ve 20260701 paketlerinde tevkifat listelerine dokunulmamıştır. Not: SARJ / SARJANLIK değerleri 20260701 paketindeki kural metninde bulunmakla birlikte History.txt'nin 20260701 kaydında GeneralWithholdingTaxTotalCheck listelenmemiştir — History.txt bu noktada eksiktir.

#V1.31 → V1.43 Tevkifat Farkları

V1.31 (01.01.2023) ile V1.43 (27.07.2026) tevkifat tabloları satır satır karşılaştırıldı.

Kod kümesi: AYNI. Her ikisinde de 601-627 (27 kod) + 801-825 (25 kod) = 52 kod. Eklenen kod yok, silinen kod yok.

Oran akışı: 52 değerin 51'i aynı.

Tek fark bir dizgi hatasının düzeltilmesidir. V1.31'de 619 kodunun oranı 75/10 (matematiksel olarak imkânsız, %750) olarak basılmıştı; V1.43'te 7/10 olarak düzeltildi. Schematron her iki dönemde de 61970 (yani %70) diyordu — dolayısıyla bu bir baskı hatasıydı, mevzuat değişikliği değil.

Metinsel / biçimsel farklar (kod ve oran etkilenmeden):

1. Harf düzeni: V1.31'de 601-615 ve 617-627 isimleri BÜYÜK HARF ("YAPIM İŞLERİ İLE BU İŞLERLE..."), V1.43'te Başlık Düzeni ("Yapim İşleri İle Bu İşlerle..."). Dikkat: 616 satırı ile 801-825 bloğunun tamamı V1.31'de de zaten Başlık Düzeni'ndeydi — dönüşüm tüm tabloya uygulanmış değildir.
2. Mevzuat atıfları güncellendi: V1.31'de birçok satır [GT 117-Bölüm (3.x.x)] (117 Seri No.lu KDV Genel Tebliği) diye atıf yapıyordu; V1.43'te bu atıflar ya kaldırılmış ya da [Kdvgut-(I/C-2.1.3.x.x)] (KDV Genel Uygulama Tebliği) ile değiştirilmiştir. Örnek: V1.31 "AĞAÇ VE ORMAN ÜRÜNLERİ TESLİMİ [GT 117-Bölüm (3.3.6)]" → V1.43 "Ağaç Ve Orman Ürünleri Teslimi" (atıfsız).
3. 619 vs 818 isim tutarsızlığı her iki sürümde de duruyor: 619 = "Bakır, Çinko Ve Alüminyum Ürünlerinin Teslimi" (Kurşun yok) ama 818 = "Bakır, Çinko, Alüminyum ve Kurşun Ürünlerinin Teslimi" (Kurşun var). GİB bunu düzeltmemiştir.

Değişiklik geçmişi de bunu teyit ediyor: V1.32'den V1.43'e kadar (15.05.2023 – 27.07.2026) değişiklik açıklamalarında "tevkifat" kelimesi hiç geçmez — yalnızca İstisna kodları, ProfileID, InvoiceTypeCode, PartyIdentification, Ek Öğe Tanımlama Alanı gibi başlıklar vardır. V1.43'ün tek değişikliği "Kısmi İstisna Kodları Listesi güncellendi. Kısmi İstisna Kod Listesine yeni kod eklendi."dir.

#2015'ten Bugüne: Değişen Oranlar, Değişmeyen İsimler

Korpustaki en eski tevkifat listesi Ekim 2015 tarihli "UBL-TR Kod Listeleri (İstisna, Tevkifat ve Muafiyet Kodları)" belgesidir.

601-623 kod ↔ hizmet eşleşmesi 2015'ten bugüne DEĞİŞMEMİŞTİR. (2015 PDF'inde de satır kaydırma artefaktı vardır; bu, farklı bir eşleşme olduğu anlamına gelmez.) Değişen tek isim 616'dır: 2015'te "5018 SAYILI KANUNA EKLİ CETVELLERDEKİ İDARE, KURUM VE KURUŞLARA YAPILAN DİĞER HİZMETLER [GT 117-Bölüm (3.2.13)]" iken V1.43'te "Diğer Hizmetler [Kdvgut-(I/C-2.1.3.2.13)]" olmuştur.

Asıl değişen oranlardır — 2015 → V1.43 tam farklar:

Değişmeyenler: 602 (9/10), 604 (5/10), 605 (5/10), 606 (9/10), 607 (9/10), 608 (9/10), 610 (9/10), 611 (9/10), 614 (5/10), 616 (5/10), 621 (9/10), 622 (9/10), 623 (5/10).

Portal aksiyonu. 2023 başından beri tevkifat kod / oran tablosu sabittir; tevkifat tarafında migrasyon dönüşümü gerekmez — yalnızca 619 için 75/10 yazan hatalı kayıt varsa 7/10'a düzelt. Buna karşılık eski faturaları yeniden görüntülerken oranı faturanın düzenlenme tarihine göre versiyonlu bir tablodan çek, tek bir güncel tablodan değil; isimler için bu büyük ölçüde gereksizdir (yalnızca 616 değişmiştir), ama oranlar için zorunludur. WithholdingTaxTypeWithPercent içinde tutulan eski kombinasyonlar (60130, 60350, 60950, 61270, 61370, 61550, 62740) tam da bu geriye dönük ihtiyaç içindir — ancak yukarıda belirtildiği gibi bu geriye dönük set eksiktir.

#e-Arşiv Raporunda Tevkifat Farklı Çalışır

e-Arşiv faturası UBL olarak düzenlenir (ProfileID = EARSIVFATURA, cac:WithholdingTaxTotal kullanılır), ancak GİB'e gönderilen e-Arşiv RAPORU tamamen farklı bir XML şemasıdır ve tevkifatı farklı taşır. e-Arşiv Teknik Kılavuzu V.1.18'de tevkifat elemanı üç ayrı bölümde tanımlıdır (3.3.2.15.3, 3.3.4.10.3, 3.3.6.12.3).

Kılavuzdaki örnek:

<earsiv:tevkifatKodu>410</earsiv:tevkifatKodu>
<earsiv:tevkifatTutari>36 </earsiv:tevkifatTutari>
<earsiv:tevkifatOrani>20</earsiv:tevkifatOrani>

Kod kaynağı farklıdır. Kılavuz açıkça yazıyor: "Tevkifat kodu alanına İnternet Vergi Dairesi Beyanname Düzenleme Programında yayınlanan kodlardan ilgili olan yazılmalıdır." Yani WithholdingTaxType (601-627 / 801-825) değil, Beyanname Düzenleme Programı (BDP) kodları kullanılır. Örnekteki 410 kodu WithholdingTaxType listesinde yoktur. tevkifatOrani ise UBL'deki cbc:Percent ile aynı yüzde mantığındadır (örnekte 20 = 2/10).

Eleman adı tutarsızlığı: kılavuzun açıklama satırında alan adı tevkifatTutar, örnek XML'de ise <earsiv:tevkifatTutari> (sonda 'i' var) yazılıdır — şema dosyasından teyit edilmelidir.

e-Arşiv schematron'unda (earsiv_schematron.xsl) tevkifatla ilgili tek kural Yatırım Teşvik'e ilişkindir: faturaTip değeri YTBSATIS, YTBISTISNA, YTBIADE, YTBTEVKIFAT veya YTBTEVKIFATIADE olduğunda ytbBilgileri alanı zorunludur.

Portal aksiyonu: e-Arşiv modülünde iki ayrı tevkifat kod tablosu tutmalısın — biri UBL faturaya (601-627 / 801-825), biri e-Arşiv raporuna (BDP kodları). Bu ikisi arasındaki eşleme tablosu bu korpusta yoktur.

#Doğrulanamayanlar

Aşağıdaki noktalar korpusta yer almadığı için doğrulanamamıştır. KDV Genel Uygulama Tebliği (KDVGUT) metni korpusta bulunmadığından, kılavuzun atıf yaptığı I/C-2.1.3.x.x bölümlerinin içeriği hiçbir şekilde teyit edilememektedir. Bu maddeleri portale kodlamadan önce GİB'in birincil kaynaklarından (KDVGUT, e-Fatura test ortamı, GİB duyuruları) doğrula.

#Istisna, Ozel Matrah ve Ihrac Kayitli Kodlari — Icerikleriyle

Bu bolumdeki tum kod-ad eslesmeleri uc bagimsiz kaynakla capraz dogrulanmistir: UBL-TR_Kod_Listeleri_-_V_1.43_.txt (27.07.2026), UBL-TR_Kod_Listeleri-V_1_31_.txt (01.01.2023) ve UBL-TR_Kod_Listeleri-Istisna_Tevkifat_ve_Muafiyet_Kodlari_.txt (Ekim 2015); gecerlilik listeleri ise 24.08.2026 tarihli e-Fatura paketindeki UBL-TR_Codelist.xml schematron degiskenlerinden alinmistir.

Kilavuz metnini okurken dikkat: V1.43 ve V1.31 PDF'lerinden cikarilan duz metinde istisna tablolarinin SOL sutunu (KODU) ile SAG sutunu (ADI) ayri ayri akmaktadir. Yani 351* ile ayni satirda gorunen "Imalat Sanayii ile Turizme Yonelik..." metni 351'in adi degildir. Ham cikti soyledir:

```

350 İmalatçıların Mal İhracatları

351* İmalat Sanayii ile Turizme Yönelik Yatırım Teşvik Belgesi Kapsamındaki İnşaat İşlerine

İlişkin Teslim ve Hizmetler

Elektrik Motorlu Taşıt Araçlarının Geliştirilmesine Yönelik Mühendislik Hizmetleri

```

Dogru eslesme, kod sutunundaki N kodun ad sutunundaki N ad ile sirayla eslenmesiyle elde edilir. Kod sayisi = ad sayisi denetimi yapilmistir (tam istisna s.10: 24/24, s.11: 22/22, kismi istisna s.8: 8/8). Asagidaki tablolar bu dogrulanmis eslesmedir.

#Schematron gecerlilik listeleri (UBL-TR_Codelist.xml)

#TAM ISTISNA KODLARI LISTESI (301-351) — TAM TABLO

46 kodun tamami asagidadir. 345-349 arasi kod YOKTUR.

351 dipnotu (birebir): "*1 no.lu kdv beyannamesinin doldurulmasına ilişkin açıklamalar ve işlem kodlari dışındaki, istisna olmayan ancak 0 KDV'li fatura oluşturulması gereken durumlarda kullanılacaktır."

#KISMI ISTISNA KODLARI LISTESI (201-250) — TAM TABLO

Schematron'da gecerli 39 kodun tamami asagidadir. 203, 210, 222, 224 ve 243-249 kodlari YOKTUR.

Not: UBL-TR kilavuzlari kismi ve tam istisnayi yalnizca iki ayri liste basligi ile ayirir; yuklenilen KDV'nin indirim/iade hakki farkina dair bir aciklama korpusta yoktur (bu ayrim KDV mevzuatinda tanimlidir). Korpustaki tek isaret 236 kodunun adindaki "(İade Hakkı Tanınmayan)" ibaresidir. Portalda kod secimini yine de bu iki liste basligina gore gruplamak dogrudur.

#Diger kod gruplari: 001, 101-108, 151, 501, 555

Bu kodlar KDV istisnasi degildir; farkli vergi turlerinin istisna listeleridir ve ayni cbc:TaxExemptionReasonCode alaninda kullanilirlar.

KONAKLAMA VERGISI ISTISNA KODLARI LISTESI (tek kod):

OTV ISTISNA KODLARI LISTESI:

151 dipnotu (birebir): "** 4760 s. ÖTV Kanununa göre istisna olmayan ancak 0 ÖTV'li fatura oluşturulması gereken durumlarda kullanılacaktır."

DIGER ISLEM TURU KODLARI LISTESI:

Kilavuz aciklamasi (birebir): "Faaliyet ve sicil servislerinde faaliyet koduna uygun KDV oranı bulunmayan satışlarda (yansıtma, mükellefin aktifine kayıtlı demirbaş/taşıt satışı gibi) kullanılacaktır."

501: UBL-TR_Codelist.xml icinde hem TaxExemptionReasonCodeType hem istisnaTaxExemptionReasonCodeType listelerinde yer alir (istisna listesinin son elemanidir: ...,344,350,501,). Ancak korpustaki hicbir kilavuzda 501 kodunun adi/aciklamasi yoktur — ne V1.43, ne V1.31, ne 2015 tarihli Istisna/Tevkifat/Muafiyet kilavuzunun tablolarinda gecmez. Davranissal olarak 501, istisna listesinde bulundugu icin fatura tipini ISTISNA/IADE/IHRACKAYITLI/SGK/YTBISTISNA/YTBIADE olmaya zorlar. Portalda 501 kullanilmamalidir.

#151 ve 351 kritik farki — istisna kisitini TETIKLEMEZLER

#555'in ozel kurallari (DemirbasKDVTaxExemptionCheck, context inv:Invoice/cac:TaxTotal)

1. 555 yalnizca ProfileID ∈ {TEMELFATURA, TICARIFATURA, EARSIVFATURA} iken kullanilabilir; InvoiceTypeCode ISTISNA veya IHRACKAYITLI olamaz; EARSIVFATURA senaryosunda YTB ile baslayan fatura tipleri (YTBSATIS, YTBIADE, YTBISTISNA, YTBTEVKIFAT, YTBTEVKIFATIADE) ile de kullanilamaz. Hata: "<ProfileID> senaryolu <InvoiceTypeCode> fatura tipinde '555' vergi muafiyet kodu kullanılamaz."
2. 555 varken KDV sifir gecilemez: ne satir (cac:InvoiceLine/cac:TaxTotal/cac:TaxSubtotal) ne belge seviyesinde, 0015 vergi kodlu bir TaxSubtotal'da cbc:Percent = 0 veya cbc:TaxAmount = 0 olamaz. Hata: "Vergi istisna muafiyet kodu 555 olduğu durumda KDV 0 geçilemez."

555'in yururluk durumu: 555, kod listesine V1.42 (12.03.2026) ile eklendi ve schematron'a 20260312 tarihinde girdi. 16.03.2026 duyurusu ile 1 Nisan 2026'da devreye alinacagi bildirildi, ancak 27.03.2026 duyurusu ile ikinci bir duyuruya kadar ERTELENDI: "sicil ve faaliyet kodu karşılığı KDV oran kontrolleri ... Başkanlığımız tarafından yapılacak ikinci bir duyuruya kadar ertelenmiştir." Buna ragmen 555 kodu ve DemirbasKDVTaxExemptionCheck kurali 24.08.2026 tarihli guncel paketin schematron'unda HALA MEVCUTTUR — ertelenen sey faaliyet/sicil kodu karsiligi KDV oran kontroludur, kodun kendisi kural setinden cikarilmamistir. Portalda 555 secenegini pasif/gizli tutup kurali yine de implemente etmek dogru yaklasimdir.

#OZEL MATRAH KODLARI (801-812) — ve TEVKIFAT 801-825 ile KARISTIRMA UYARISI

UYARI — 801-812 SAYILARI IKI AYRI LISTEDE GECER VE TAMAMEN FARKLI SEYLER ANLATIR. Fark, sayinin yazildigi XML elemanidir. Portal kodunda bu iki listeyi ayni enum'dan beslemek, sessiz ve tespiti cok zor bir hata kaynagidir.

Kilavuz bu ayrimi acikca yapar: TaxTypeCode icin "Diğer yandan bu eleman "WithholdingTaxTotal" elemanı altında bulunduğunda (tevkifatlı fatura durumu) aşağıdaki kod listesi kullanılacaktır."

OZEL MATRAH KODLARI LISTESI (801-812) — TAM TABLO, karsisinda ayni sayinin tevkifat karsiligi:

813-825 sayilari yalnizca tevkifat listesinde vardir, ozel matrah listesinde karsiliklari yoktur (813 Çevre ve Bahçe Bakım, 814 Servis Taşımacılığı, 815 Her Türlü Baskı ve Basım, 816 Hurda Metalden Elde Edilen Külçe, 817 Hurda Metalden Elde Edilenler Dışındaki Bakır/Çinko/Demir Çelik/Alüminyum/Kurşun Külçe, 818 Bakır/Çinko/Alüminyum/Kurşun Ürünleri, 819 İstisnadan Vazgeçenlerin Hurda ve Atık, 820 Metal/Plastik/Lastik/Kauçuk/Kâğıt/Cam Hurda ve Atıklardan Elde Edilen Hammadde, 821 Pamuk/Tiftik/Yün/Yapağı ile Ham Post ve Deri, 822 Ağaç ve Orman Ürünleri, 823 Yük Taşımacılığı, 824 Ticari Reklam, 825 Demir-Çelik Ürünleri). Ayrica WithholdingTaxTypeWithPercent listesinde tevkifat kodu+oran birlesik dogrulanir: 801-825 icin 801100, 802100 ... 825100 (yani %100 = 10/10). Ozel matrah kodlarinin boyle bir oran birlesimi yoktur.

Portal implementasyon kurali: Ozel matrah kodunu ureten kod yolu ile tevkifat kodunu ureten kod yolu birbirinden tamamen ayrilmali, iki ayri enum/tablo kullanilmalidir. Bir ozel matrah faturasinda cac:WithholdingTaxTotal blogu bulunmamalidir.

#IHRAC KAYITLI KODLARI (701-704) — TAM TABLO

ihracExemptionReasonCodeType = ,701,702,703,704,

IHRAC KAYITLI SATISLAR ILE DIIB VE GECICI KABUL REJIMI KAPSAMINDAKI SATIS KODLARI LISTESI:

704 YENIDIR — V1.31'de (01.01.2023) yalnizca 701, 702, 703 vardi.

Kisit 1 (fatura tipi): 701-704 kullanildiginda cbc:InvoiceTypeCode yalnizca IHRACKAYITLI, IADE veya SGK olabilir.

Kisit 2 (702 icin ek zorunluluk — portalda mutlaka uygulanmali): IHRACKAYITLI + 702 kombinasyonunda HER cac:InvoiceLine altinda su iki alan bulunmak zorundadir:

Aksi halde: "IHRACKAYITLI fatura tipinde 702 Muafiyet sebebi için GTİP ve Alıcı Satır Kodu bilgisi girilmelidir". Ayni kosulu satir seviyesinde dogrulayan ikinci bir kural (IhracKayitliPartyIdentificationIDTypeCheck) de vardir.

Kisit 3: Ihrac kayitli satir tanimlayici semalari IhracKayitliPartyIdentificationIDType = ,SATICIDIBSATIRKOD,ALICIDIBSATIRKOD, ile sinirlidir.

Kisit 4: TaxExemptionReasonCheck kurali IHRACKAYITLI faturayi, "KDV=0 ise TaxExemptionReason zorunlu" kuralindan muaf tutar.

#YATIRIMTESVIK ozel kodlari 308 ve 339 — 01.07.2026 kisitlamasi

En kritik yapisal degisiklik: 01.07.2026 (History damgasi 20260701) guncellemesiyle YatirimTesvikTaxExemptionReasonCodeType eklendi ve 308 ile 339 ana TaxExemptionReasonCodeType listesinden cikarildi.

<sch:let name="YatirimTesvikTaxExemptionReasonCodeType" value="',308,339,'"/>

Guncel durum:

Sonuc: 308 ve 339, TaxExemptionReasonCodeCheck'in gecerlilik assert'inde ancak su kosulla kabul edilir: ../../../cbc:ProfileID = 'YATIRIMTESVIK' VEYA cbc:InvoiceTypeCode ∈ YatirimTesvikEArsivInvoiceTypeCodeList = ,YTBSATIS,YTBIADE,YTBISTISNA,YTBTEVKIFAT,YTBTEVKIFATIADE,. Aksi halde "Geçersiz cbc:TaxExemptionReasonCode niteliği" hatasi alinir. TEMELFATURA/TICARIFATURA senaryosunda 308 veya 339 kullanilamaz. V1.31 doneminde 308/339'u serbestce kullanan bir portal, 24.08.2026 paketiyle hata almaya baslayacaktir.

Harcama tipi (cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode) baglantisi:

YatirimTesvikItemClassificationCodeList = ,01,02,03,04,:

Kilavuz birebir: "Bu kapsamda düzenlenecek faturalar "0" KDV'li olarak düzenlenemez." (03 ve 04 icin, iki kez gecer).

Zorlayici schematron kurallari (context = inv:Invoice/cac:InvoiceLine — SATIR SEVIYESI):

• YatirimTesvikTaxExemptionReasonCode308Check: (ProfileID=YATIRIMTESVIK ve InvoiceTypeCode=ISTISNA) VEYA (ProfileID=EARSIVFATURA ve InvoiceTypeCode=YTBISTISNA) iken ItemClassificationCode='01' ise, o satirin cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory icinde TaxTypeCode='0015' ve TaxExemptionReasonCode='308' bulunmak ZORUNDA. Mesaj: "Yatırım Teşvik Faturasında ISTISNA Fatura Tipinde Harcama Tipi 01 ise 308 istisna kodu seçilebilir."
• YatirimTesvikTaxExemptionReasonCode339Check: ayni kosullarda ItemClassificationCode='02' ise TaxExemptionReasonCode='339' ZORUNLU. Mesaj: "...Harcama Tipi 02 ise 339 istisna kodu seçilebilir."

Bu iki kural satir seviyesindedir — yani YATIRIMTESVIK/YTBISTISNA faturalarinda istisna kodu satir altindaki cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode alanina yazilir. Kilavuzun ornek XML'i satir seviyesinde <cbc:TaxExemptionReasonCode>339</cbc:TaxExemptionReasonCode> + <cbc:CalculationSequenceNumeric>-1</cbc:CalculationSequenceNumeric> + <cbc:Percent>20</cbc:Percent> gosterir. Ayrica ayni kilavuzun PaymentMeansCodeCheck blogu YATIRIMTESVIK+ISTISNA / EARSIVFATURA+YTBISTISNA icin "cbc:CalculationSequenceNumeric alanı -1 seçilmelidir" zorunlulugunu getirir.

#Hangi istisna kod araligi hangi fatura tipiyle kullanilabilir

TaxExemptionReasonCodeCheck kurali yalnizca su context'te calisir: inv:Invoice/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory (belge seviyesi). Kural 6 assert icerir (Common Schematron satir 315-327):

A3 assert'i (birebir XPath):

not(../../../cbc:UBLVersionID ='2.1') or not(cbc:TaxExemptionReasonCode != 555 and
contains($istisnaTaxExemptionReasonCodeType, concat(',',cbc:TaxExemptionReasonCode,',')))
or ../../../cbc:InvoiceTypeCode = 'ISTISNA' or ../../../cbc:InvoiceTypeCode = 'IADE'
or ../../../cbc:InvoiceTypeCode = 'IHRACKAYITLI' or ../../../cbc:InvoiceTypeCode = 'SGK'
or ../../../cbc:InvoiceTypeCode = 'YTBISTISNA' or ../../../cbc:InvoiceTypeCode = 'YTBIADE'

OZET MATRIS (portal validasyonu icin):

Ek not — IADE faturasi: IADEInvioceCheck ile IADE / TEVKIFATIADE / YTBIADE / YTBTEVKIFATIADE tiplerinde cac:BillingReference/cac:InvoiceDocumentReference altinda cbc:DocumentTypeCode = 'IADE' (veya 'İADE') ve 16 haneli cbc:ID zorunludur. Ayrica InvoiceTypeCodeCheck: "Fatura tipi IADE iken fatura profili sadece TEMELFATURA , EARSIVFATURA, ILAC_TIBBICIHAZ, YATIRIMTESVIK, IDIS veya KAMU olabilir".

#XML yerlesimi: TaxExemptionReasonCode / TaxExemptionReason ve KDV=0 kurali

Belge (dip toplam) seviyesi — schematron burayi denetler:

/Invoice/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode
/Invoice/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReason

Satir seviyesi — YATIRIMTESVIK / YTBISTISNA'da ZORUNLU:

/Invoice/cac:InvoiceLine/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode

cac:TaxCategory eleman tanimi (UBL-TR Ortak Elemanlar V0.7, bolum 2.2.58):

Kilavuzdaki ornek:

<cac:TaxCategory>
  <cbc:TaxExemptionReasonCode>301</cbc:TaxExemptionReasonCode>
  <cac:TaxScheme>
    <cbc:Name>Katma Değer Vergisi</cbc:Name>
    <cbc:TaxTypeCode>0015</cbc:TaxTypeCode>
  </cac:TaxScheme>
</cac:TaxCategory>

KDV=0 KURALI (TaxExemptionReasonCheck, context inv:Invoice/cac:TaxTotal/cac:TaxSubtotal) — birebir mesaj:

"Vergi miktarı 0 olan 0015 vergi kodlu KDV için cbc:TaxExemptionReason(vergi istisna muhafiyet sebebi) elemanı bulunmalıdır ve boş değer içermemelidir."

Yani cbc:TaxAmount = 0 VE cac:TaxCategory/cac:TaxScheme/cbc:TaxTypeCode = '0015' ise cac:TaxCategory/cbc:TaxExemptionReason DOLU olmak zorundadir. Bu kuraldan muaf fatura tipleri: IADE, YTBIADE, IHRACKAYITLI, OZELMATRAH, SGK, KONAKLAMAVERGISI.

Satir seviyesi dogrulamanin durumu: Main Schematron'da satir seviyesi context, hem TaxExemptionReasonCodeCheck hem TaxExemptionReasonCheck icin yorum satiri yapilmistir:

<!--<sch:rule context="inv:Invoice/cac:InvoiceLine/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory">
    <sch:extends rule="TaxExemptionReasonCodeCheck"/>
</sch:rule>-->

Yani genel istisna kodu dogrulamasi yalnizca dip toplam seviyesinde yapilir; buna karsilik YATIRIMTESVIK 308/339 kurallari satir seviyesinde ayrica ve aktif olarak denetlenir.

Portal implementasyon kurallari:

1. Genel istisna faturalarinda KDV satiri silinmez: cbc:TaxTypeCode = 0015 olarak kalir, cbc:TaxableAmount matrahi tasir, cbc:TaxAmount = 0 gecilir. UYARI: "her istisna faturasinda cbc:Percent = 0" seklinde bir kural schematron'da yoktur ve YATIRIMTESVIK/YTBISTISNA faturalari icin YANLISTIR — GIB'in YTB kilavuzundaki resmi ISTISNA orneginde Percent 20, TaxAmount 300.00 ve CalculationSequenceNumeric -1 kullanilir (KDV hesaplanir, fatura tutarina eklenmez). Percent=0 kurali yalnizca genel istisna faturalari icin uygulanmali, YTB istisnasi ayrik tutulmalidir.
2. cbc:TaxExemptionReasonCode (kod) ve cbc:TaxExemptionReason (serbest metin) birlikte yazilmalidir: A2 assert'i Reason varken Code'un dolu ve gecerli olmasini, TaxExemptionReasonCheck ise KDV=0 iken Reason'in dolu olmasini sart kosar — pratikte ikisi birbirini zorunlu kilar.
3. TaxExemptionReason metnini kod listesindeki resmi adla doldurmak en guvenlisidir; GIB'in YTB kilavuzu ornegi tam olarak bunu yapar (kod 339 + Reason = "İmalat Sanayi ile Turizme Yönelik Yatırım Teşvik Belgesi Kapsamındaki İnşaat İşlerine İlişkin Teslim ve Hizmetler").
4. Belge seviyesindeki cbc:InvoiceTypeCode = ISTISNA (e-Arsiv Yatirim Tesvik'te YTBISTISNA).
5. Serbest bolgedeki bir e-Fatura kullanicisina duzenlenen faturada, GIB SSS'ye gore senaryo IHRACAT degil temel/ticari fatura olmali, fatura tipi "istisna" secilmelidir.

#Bos / kullanilmayan kod numaralari

Asagidaki numaralar hicbir listede tanimli degildir; portal validasyonunda bunlarin girilmesi engellenmelidir:

Onemli uyari: 308 ve 339 "bos" degildir — tanimli kodlardir, sadece ana TaxExemptionReasonCodeType listesinden cikarilip YatirimTesvikTaxExemptionReasonCodeType'a tasinmislardir. Portalda bu ikisini "gecersiz kod" olarak isaretlemek hatali olur; kosullu gecerli olarak modellenmelidirler.

Bu bos numaralarin daha once kullanilip kaldirilip kaldirilmadigi korpusta belirtilmemistir.

#V1.31 (01.01.2023) → V1.43 (27.07.2026) degisiklikleri

EKLENEN TAM ISTISNA KODLARI (5 adet):

(V1.31'de 328'den sonra dogrudan 330 geliyordu; 329 numarasi bostu.)

EKLENEN KISMI ISTISNA KODU (1 adet):

EKLENEN IHRAC KAYITLI KODU (1 adet):

EKLENEN DIGER ISLEM TURU KODU (1 adet, V1.42 / 12.03.2026):

METNI DEGISEN KODLAR (4 adet):

CIKARILAN KOD: Yok. V1.31'deki hicbir istisna kodu V1.43'te silinmemistir.

DEGISMEYENLER: Ozel matrah (801-812) 12 kodun tamami aynidir. OTV (101-108, 151) ve konaklama (001) listeleri degismemistir.

V1.43 changelog (birebir):

1.42 12.03.2026       Sayfa 11              Diğer İşlem Türü Kodları Listesi eklendi.

1.43 27.07.2026       Sayfa 10              Kısmi İstisna Kodları Listesi güncellendi.
                                            Kısmi İstisna Kod Listesine yeni kod eklendi.

Kilavuzda gorunmeyen schematron degisikligi: 01.07.2026 (History damgasi 20260701) itibariyla YatirimTesvikTaxExemptionReasonCodeType eklendi, TaxExemptionReasonCodeType ve istisnaTaxExemptionReasonCodeType guncellendi, TaxExemptionReasonCodeCheck guncellendi. Bu, kod listeleri kilavuzunun hicbir surumune yansimamistir — yalnizca UBL-TR_Codelist.xml ve History.txt uzerinden gorulebilir.

#Dogrulanamayanlar

Asagidaki noktalar hakem kontrolunde korpus kaynagi bulunamayan veya reddedilen iddialardir; portal kurali olarak yazilmamalidirlar.

#BÖLÜM 2 — Zorunluluklar, Eşikler ve Sektörel Kapsam

#Zorunluluklar, Eşikler ve Sektörel Kapsam

Bu bölüm, 509 Sıra No.lu VUK Genel Tebliği'nin (RG: 19/10/2019 - 30923) 31.08.2026 itibarıyla yürürlükteki konsolide hâli esas alınarak hazırlanmıştır. Portal kural motorunun kodlanacağı normatif çekirdek burasıdır.

#Kaynak Önceliği ve Hüküm Hiyerarşisi

Korpustaki kaynaklar birbiriyle çelişmektedir. Kural motoru yalnızca aşağıdaki öncelik sırasına göre kodlanmalıdır:

Kaynak dosyalar: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt, Vergi_Usul_Kanunu_Genel_Tebligi__Sira_No_509__nde_Degisiklik_Yapilmasina_Dair_Teblig__Sira_No_573__.txt, Vergi_Usul_Kanunu_Genel_Tebligi__Sira_No_509__nde_Degisiklik_Yapilmasina_Dair_Teblig__Sira_No_589__.txt, 509_s.VUK_GT_Kapsaminda_Uygulamalara_Gecis_Takvimi_Tablosu__3__.txt, Zorunluluk_Karsilastirma_Tablosu_.txt, 509_Cok_Sorulan__Sorular_.txt

#e-FATURA Zorunluluğu

#Çerçeve Hüküm — IV.1.4(a)

IV.1.4 bölümünün (a) fıkrası, aşağıda sayılan 9 mükellef grubu için iki ayrı yükümlülük getirir:

1. Uygulamaya dâhil olma zorunluluğu,
2. e-Fatura kayıtlı diğer kullanıcılara faturayı e-Fatura olarak düzenleme ve onlardan e-Fatura olarak alma zorunluluğu.

"a) Aşağıda sayılan mükellef gruplarının e-Fatura uygulamasına dâhil olmaları ve bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde, e-Fatura uygulamasına kayıtlı diğer kullanıcılara faturalarını e-Fatura olarak düzenlemeleri ve bunlardan e-Fatura olarak almaları zorunludur."

Portal tasarımı açısından kritik: e-Fatura zorunluluğu mutlak değildir, karşı tarafın e-Fatura kayıtlı kullanıcı olmasına bağlıdır. Kayıtlı olmayana e-Arşiv Fatura düzenlenir (IV.2.1).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Brüt Satış Hasılatı Haddi — IV.1.4(a)(1)

509'un güncel (535 SN ile değişik) hâli e-Fatura genel ciro haddini üç kademeli belirler:

"1- Brüt satış hasılatı (veya satışları ile gayrisafi iş hasılatı); a) 2018, 2019 veya 2020 hesap dönemleri için 5 Milyon TL, b) 2021 hesap dönemi için 4 Milyon TL, c) 2022 veya müteakip hesap dönemleri için 3 Milyon TL ve üzeri olan mükellefler."

2022 sonrası had SABİTTİR. Korpusta 2023, 2024, 2025 veya 2026 hesap dönemleri için farklı had belirleyen bir düzenleme YOKTUR. 589'dan (31.12.2025) sonra 509'u değiştiren başka bir tebliğ korpusta bulunmamaktadır.

Portal kuralı:

had(donem) = donem <= 2020 ? 5_000_000
           : donem == 2021 ? 4_000_000
           : 3_000_000

Had aşıldığında yükümlülük yalnızca e-Fatura değil, IV.2.4.1 uyarınca e-Arşiv Fatura'yı da kapsar.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Ciro Haddinin Tarihsel Zinciri: 10 Milyon → 5 Milyon → 4/3 Milyon

"6 535 Sıra No.lu Vergi Usul Kanunu Tebliği (RG: 22/01/2022 – 31727) ile değiştirilmeden önceki hali: 1-2018 veya müteakip hesap dönemleri brüt satış hasılatı (veya satışları ile gayrisafi iş hasılatı) 5 Milyon TL ve üzeri olan mükellefler."

509'un ilk hâlinde tek ve sabit bir had (5 Milyon TL) vardı; kademeli düşüş 535 SN ile 22/01/2022'de getirilmiştir. 535 sonrası e-Fatura ciro haddini değiştiren başka bir tebliğ korpusta yoktur (550, 573, 589 bu bendi değiştirmemiştir).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt (dipnot 6)

#TAM TABLO — IV.1.4(a) e-Fatura Zorunluluk Bentleri (1–9)

Bent 8 ve 9'daki "bu Tebliğin yayım tarihi" ibaresi, ilgili bendi ekleyen değişiklik tebliğinin yayım tarihini işaret eder (bent 8 → 535 → 22/01/2022; bent 9 → 550 → 07/10/2023).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Bent Bazında Birebir Metinler ve Sektörel Ayrıntı

Bent 2 — ÖTV (I) sayılı liste / EPDK lisansı (akaryakıt):

"2- 6/6/2002 tarihli ve 4760 sayılı Özel Tüketim Vergisi Kanununa ekli I sayılı listedeki malların imali, ithali, teslimi vb. faaliyetleri nedeniyle Enerji Piyasası Düzenleme Kurumu (EPDK)'ndan lisans alan (bayilik lisansı dâhil) mükellefler."

Bayilik lisansı dâhildir. 454 SN GT döneminde bayilik lisansı hariçti (Zorunluluk Karşılaştırma Tablosu'ndaki "Bayilik lisansı hariç" ifadesi bu eski durumu gösterir).

Bent 3 — ÖTV (III) sayılı liste (tütün, alkol, kolalı gazoz):

"3- Özel Tüketim Vergisi Kanununa ekli (III) sayılı listedeki malları imal, inşa ve/veya ithal edenler."

DİKKAT — e-Fatura ile e-İrsaliye kapsamı FARKLIDIR:

Bir tütün/alkol distribütörü e-Fatura zorunlusu olmayabilir ama e-İrsaliye zorunlusudur. Portal kural motorunda bu iki bent AYRI değerlendirilmelidir.

Bent 4 — AHS / e-ticaret pazaryerleri / internet ilanı / internet reklamcılığı / internetten satış:

"4- Mal veya hizmetlerin alınması, satılması, kiralanması veya dağıtımı işlemlerinin gerçekleştirilmesine aracılık etmek üzere internet ortamında 23/10/2014 tarihli ve 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanunda tanımlanan başkalarına ait iktisadi ve ticari faaliyetlerin yapılmasına elektronik ticaret ortamını sağlayan gerçek ya da tüzel kişi aracı hizmet sağlayıcıları, internet ortamında gerçek ve tüzel kişilere ait gayrimenkul, motorlu araç vasıtalarının satılmasına veya kiralanmasına ilişkin ilanları yayınlayan internet sitelerinin sahipleri veya işleticileri ile internet ortamında reklamların yayınlanmasına aracılık faaliyetinde bulunan internet reklamcılığı hizmet aracıları ile kendilerine veya aracı hizmet sağlayıcılarına ait internet sitelerinde veya diğer her türlü elektronik ortamda mal veya hizmet satışını gerçekleştiren mükelleflerden, 2020 veya 2021 hesap dönemleri için 1 Milyon TL, 2022 veya müteakip hesap dönemleri için 500 Bin TL ve üzeri brüt satış hasılatı (veya satışları ile gayrisafi iş hasılatı) olanlar."

Bu tek bent dört grubu birleştirir: (i) aracı hizmet sağlayıcıları (e-ticaret pazaryerleri), (ii) internette gayrimenkul/motorlu araç ilanı yayınlayanlar, (iii) internet reklamcılığı hizmet aracıları, (iv) internetten mal/hizmet satışı yapanlar. Dipnot 7'ye göre değişiklikten önceki hâl yalnızca ilk üç grubu kapsıyordu; 535 ile hem dördüncü grup hem de hasılat eşikleri eklendi.

Bent 5 — Sebze-meyve komisyoncu/tüccar (Hal Kayıt Sistemi):

"5- 11/3/2010 tarihli ve 5957 sayılı Sebze ve Meyveler ile Yeterli Arz ve Talep Derinliği Bulunan Diğer Malların Ticaretinin Düzenlenmesi Hakkında Kanun hükümlerine göre komisyoncu veya tüccar olarak sebze ve meyve ticaretiyle iştigal eden mükellefler."

Ciro eşiği yoktur — faaliyet bazlı mutlak zorunluluktur. Aynı mükellef grubu e-İrsaliye'de de zorunludur (IV.3.5/8) ve orada da geçiş tarihi 1/1/2020'dir.

Bent 6 — SGK sözleşmeli sağlık hizmeti sunucuları (526 ile eklendi):

"6- Sosyal Güvenlik Kurumu ile sözleşme imzalayan sağlık hizmeti sunucuları ile medikal malzeme ve ilaç/etken madde temin eden tüm mükellefler (hastane, tıp merkezleri, dal merkezleri, diyaliz merkezleri, Sağlık Bakanlığından ruhsatlı diğer özelleşmiş tedavi merkezleri, tanı, tetkik ve görüntüleme merkezleri, laboratuvarlar, eczaneler, tıbbi cihaz ve malzeme tedarikçileri, optisyenlik müesseseleri, işitme merkezi, kaplıcalar, beşeri tıbbi ürün/ürün sunan ve/veya üreten özel hukuk tüzel kişileri ve bunların tüzel kişiliği olmayan şubeleri, ecza depoları vb.)."

Parantez içi sayım örnek niteliğindedir ("vb." ile biter) ve şu işletme türlerini açıkça sayar — TAM LİSTE:

Bent 7 — Gayrimenkul ve/veya motorlu taşıt (535 ile eklendi):

"7- Gayrimenkul ve/veya motorlu taşıt, inşa, imal, alım, satım veya kiralama işlemlerini yapanlar ile bu işlemlere aracılık faaliyetinde bulunan mükelleflerden brüt satış hasılatı (veya satışları ile gayrisafi iş hasılatı); a) 2020 veya 2021 hesap dönemleri için 1 Milyon TL, b) 2022 veya müteakip hesap dönemleri için 500 Bin TL ve üzeri olan mükellefler."

Emlakçı, galerici, oto kiralama ve inşaat firmaları bu bent kapsamındadır. Araç kiralama, bu bendin "motorlu taşıt ... kiralama" ibaresi ile kapsanır; korpusta ayrı bir "araç kiralama" bendi YOKTUR.

Bent 8 — Otel işletmeleri (535 ile eklendi):

"8- Kültür ve Turizm Bakanlığı ile belediyelerden yatırım ve/veya işletme belgesi almak suretiyle konaklama hizmeti veren otel işletmeleri."

Ciro eşiği yoktur.

Bent 9 — Şarj ağı ve şarj istasyonu işletmecileri (550 ile eklendi):

"9- 2/4/2022 tarihli ve 31797 sayılı Resmî Gazete'de yayımlanan Şarj Hizmeti Yönetmeliği kapsamında Enerji Piyasası Düzenleme Kurumundan şarj ağı işletmeci lisansı alan mükellefler ile bu mükellefler tarafından sertifika verilen şarj istasyonu işletmecileri."

İki alt grup: (i) EPDK'dan şarj ağı işletmeci lisansı alanlar, (ii) bu mükelleflerce sertifika verilen şarj istasyonu işletmecileri. Ciro eşiği yoktur. Bu grup için korpusta ayrı bir teknik kılavuz da bulunmaktadır: Elektrik_Sarj_Hizmetlerine_Iliskin_Fatura_Teknik_Kilavuzu_V.1.0_.txt (ENERJI senaryosu).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Geçiş Süresi — "İzleyen Yılın Yedinci Ayının Başı" Kuralı (IV.1.5/a)

"a) Söz konusu bölümün (a) fıkrasının (1) numaralı bendi kapsamında olanlardan brüt satış hasılatı (veya satışları ile gayrisafi iş hasılatı) şartını 2018 veya 2019 hesap dönemlerinde sağlayan mükellefler 1/7/2020 tarihinden itibaren, 2020 veya müteakip hesap dönemlerinde sağlayan mükellefler, ilgili hesap dönemini izleyen yılın yedinci ayının başından itibaren, e-Fatura uygulamasına geçmek zorundadır."

Kural: hesap dönemi kapanır → gelir/kurumlar vergisi beyannamesi verilir → izleyen yılın 1 Temmuz'unda e-Fatura mükellefi olunur. Mükellefe fiilen yaklaşık 6 aylık hazırlık süresi verilir.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Bent Bazında Geçiş Süreleri — IV.1.5 (b)–(g)

"b) Özel Tüketim Vergisi Kanununa ekli (I) sayılı liste kapsamındaki mallar nedeniyle EPDK'dan lisans alımı veya mezkur Kanuna ekli (III) sayılı liste kapsamındaki malların imal, inşa veya ithalini 2019 yılında gerçekleştirenler 1/7/2020 tarihinden itibaren, 2020 veya müteakip yıllarda gerçekleştirenler ise, lisans alımı veya imal, inşa veya ithalin gerçekleştirildiği ayı izleyen dördüncü ayın başından itibaren e-Fatura uygulamasına geçmek zorundadır."

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#IV.1.4 (b)–(ğ) Fıkraları — Karşılıklı Zorunluluk, Kamu, Birleşme/Bölünme, Ferdî İşletme, İşi Bırakma, Başkanlık Yetkisi

"e) e-Fatura uygulamasına geçme zorunluluğu olan mükelleflerin; tam bölünme, birleşme (devralma şeklinde birleşme ve yeni kuruluş şeklinde birleşme) veya tür (nev'i) değişikliğine gitmeleri halinde devrolunan veya birleşilen tüzel kişi mükellefler ile tam bölünme veya tür (nev'i) değişikliği sonucunda ortaya çıkan yeni tüzel kişi mükellefler e-Fatura uygulamasına geçmek zorundadır. Uygulamalara geçme süresi hiçbir koşulda işlemin ticaret siciline tescil tarihini izleyen ayın başından itibaren 3 ayı geçemez."

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#İhracat, Bavul Ticareti ve Yolcu Beraberi Eşya — IV.1.7.1

"e-Fatura uygulamasına kayıtlı olan mükelleflerden, 25/10/1984 tarihli ve 3065 sayılı Katma Değer Vergisi Kanununun 11 inci maddesi kapsamındaki mal ihracı (Türkiye'de ikamet etmeyenlere özel fatura ile yapılan bavul ticareti kapsamındaki satışlar dahil) ve yolcu beraberi eşya ihracı (Türkiye'de ikamet etmeyenlere KDV hesaplanarak yapılan satışlar) kapsamında fatura düzenleyecek olanlar, bahsi geçen faturalarını 1/7/2017 tarihinden ... itibaren bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde e-Fatura olarak düzenlemeleri zorunludur."

"21 550 Sıra No.lu Vergi Usul Kanunu Tebliği (RG: 07/10/2023 - 32332) ile değiştirilmeden önceki hali: 1/7/2020 tarihinden"

Usul ve esaslar e-Fatura_Uygulamasi_gumruk_islemleri_Kilavuzu_.txt (e-Fatura Uygulaması Gümrük İşlemleri Kılavuzu) belgesindedir. Uyarı: Geçiş Takvimi Tablosu hâlâ eski "1/7/2020" tarihini göstermektedir — eskimiştir. Ayrıca ihracat faturası düzenlemek tek başına e-Fatura'ya geçmeyi gerektirmez (GİB SSS s.4).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#e-ARŞİV FATURA Zorunluluğu

#IV.2.4.1 — e-Fatura Mükellefi Otomatik Olarak e-Arşiv Mükellefi midir? EVET

"e-Fatura uygulamasına dahil olma zorunluluğu bulunan mükellefler ile isteğe bağlı olarak e-Fatura uygulamasına bu Tebliğin yayım tarihi itibarıyla geçmiş olan mükellefler (faaliyetleri gereği fatura yerine geçen diğer belgeler düzenleyenler hariç) 1/1/2020 tarihine kadar, bu Tebliğin yayım tarihinden itibaren isteğe bağlı olarak ya da bu Tebliğin "IV.1.4" numaralı bölümü ile e-Fatura uygulamasına geçiş zorunluluğu nedeniyle e-Fatura uygulamasına dahil olan mükelleflerin ise, bu Tebliğin "IV.1.5." numaralı bölümünde belirtilen süreler içinde ve/veya e-Fatura uygulamasına isteğe bağlı olarak dahil oldukları süre içinde başvurularını ve fiili geçiş hazırlıklarını tamamlayarak e-Arşiv Fatura uygulamasına da geçmek ... zorunludur."

Portal mantığı: eFaturaMukellefi == true ⇒ eArsivMukellefi == true (aynı tarihte). Bu tarihten itibaren düzenlenen tüm faturalar ya e-Fatura ya e-Arşiv Fatura olmak zorundadır; kâğıt fatura kalmaz.

Ters yön de doğrudur: IV.2.2 uyarınca e-Arşiv'e dâhil olmak isteyenin önce e-Fatura'ya dâhil olması şarttır. GİB SSS (s.87): "Söz konusu mükellef e-Arşiv uygulamasına geçtiği takdirde e-Fatura uygulamasına da geçmek zorundadır."

#IV.2.1 — Belge Seçim Kuralı

"e-Arşiv Fatura uygulamasına kayıtlı mükelleflerin, bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde, e-Fatura uygulamasına kayıtlı mükelleflere gerçekleştirmiş olduğu mal satışları ile hizmet ifalarında faturayı e-Fatura olarak, e-Fatura uygulamasına kayıtlı olmayan vergi mükellefleri ile vergi mükellefi olmayanlara gerçekleştirmiş olduğu mal satışları ile hizmet ifalarında ise faturayı e-Arşiv Fatura olarak düzenlemeleri zorunludur."

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#IV.2.4.2 — AHS / İnternet İlanı / İnternet Reklamcılığı / e-Ticaret Satıcıları

"...internet reklamcılığı hizmet aracıları, 1/1/2020 tarihine kadar (2020 ve müteakip hesap dönemlerinden itibaren bu paragrafta belirtilen işler ile iştigal etmek üzere işe başlayacak mükelleflerin ise işe başlama tarihinden itibaren 3 ay içinde), kendilerine veya aracı hizmet sağlayıcılarına ait internet sitelerinde veya diğer her türlü elektronik ortamlarda mal veya hizmet satışını gerçekleştiren mükelleflerden bu Tebliğin (IV.1.4) bölümünün (a) fıkrasının (4) numaralı bendinde belirtilen brüt satış hasılatı (veya satışları ile gayrisafi iş hasılatı) şartını 2020 veya 2021 hesap dönemlerinde sağlayanlar 1/7/2022 tarihine kadar, 2022 veya müteakip hesap dönemlerinde sağlayanlar ilgili hesap dönemini izleyen yedinci ayın başına kadar başvurularını ve fiili geçiş hazırlıklarını tamamlayarak e-Arşiv Fatura uygulamasına geçmek zorundadır."

DİKKAT: e-Fatura'da AHS/reklamcı/ilan yayınlayanlar için tarih 1/7/2020, e-Arşiv'de aynı gruplar için 1/1/2020'dir — e-Arşiv tarihi DAHA ERKENDİR.

Değişiklik: 535 SN VUK GT ile hem başlık (dipnot 22) hem metin (dipnot 23) değiştirilmiştir.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#IV.2.4.3 — Tutar Eşikli Zorunlu e-Arşiv Fatura (GÜNCEL TAM METİN)

Bu bölüm e-Arşiv uygulamasına dâhil OLMAYAN mükellefleri bağlar ve portal için en kritik eşik kuralıdır.

"e-Arşiv Fatura uygulamasına dahil olmayan mükelleflerce düzenlenecek faturaların; 1/1/2025 ila 31/12/2025 (ticari kazançları basit usulde tespit edilen mükellefler ile işletme hesabı esasına göre defter tutan mükellefler açısından 1/1/2025 ila 31/12/2026) tarihleri arasında vergiler dahil toplam tutarının 3 Bin TL'yi aşması halinde, 1/1/2026 (ticari kazançları basit usulde tespit edilen mükellefler ile işletme hesabı esasına göre defter tutan mükellefler açısından 1/1/2027) tarihinden itibaren ise tutarına bakılmaksızın, bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde, "e-Arşiv Fatura" olarak Başkanlıkça sunulan e-Belge düzenleme portali üzerinden ya da Başkanlığın e-Belge düzenleme portaline gerekli entegrasyonları sağlayarak Başkanlıktan izin alan özel entegratör kuruluşların sistemleri aracılığıyla düzenlenmesi zorunludur."

Düzenleme kanalı: Başkanlıkça sunulan e-Belge düzenleme portali üzerinden ya da Başkanlığın e-Belge düzenleme portaline gerekli entegrasyonları sağlayarak Başkanlıktan izin alan özel entegratör kuruluşların sistemleri aracılığıyla.

Ek kural: Satıcı ve alıcının her ikisi de e-Fatura uygulamasına kayıtlı kullanıcı ise, aralarında düzenlenen faturaların tamamının e-Fatura olması gerekir (tutar eşiği aranmaz).

Ceza: Kâğıt fatura düzenlenmesi/alınması hâlinde, faturayı düzenleyen ile nihai tüketici dışındaki vergi mükellefiyeti bulunan alıcı hakkında, her bir kâğıt fatura için ayrı ayrı VUK md.353 cezası uygulanır.

31.08.2026 itibarıyla yürürlükteki portal kuralı:

if (!eArsivMukellefi) {
  if (mukellefTipi in {BASIT_USUL, ISLETME_HESABI})
      esik = (bugun <= 2026-12-31) ? 3000 : 0;   // 0 = tutarina bakilmaksizin
  else
      esik = 0;                                   // 1/1/2026'dan beri sinirsiz
}

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#e-Arşiv Tutar Eşiğinin Tam Tarihsel Zinciri

"27 526 Sıra No.lu Vergi Usul Kanunu Tebliği (RG: 09/02/2021 - 31390) ile değiştirilmeden önceki hali: e-Arşiv Fatura uygulamasına dahil olmayan mükelleflerce, 1/1/2020 tarihinden itibaren düzenlenecek faturaların, vergiler dahil toplam tutarının 30 Bin TL'yi (vergi mükelleflerine düzenlenenler açısından vergiler dahil toplam tutarı 5.000 TL'yi) aşması halinde ... 28 573 Sıra No.lu Vergi Usul Kanunu Tebliği (RG: 12/11/2024 - 32720) ile yürürlükten kaldırılmadan önceki hali: Aynı günde aynı kişilere düzenlenen faturalar topluca birlikte değerlendirilecek olup, faturaların vergi dâhil tutar toplamının belirtilen tutarı aşması halinde, söz konusu faturaların e-Arşiv Fatura olarak düzenlenmesi ve alınması zorunluluğu bulunmaktadır."

MÜLGA KURAL — "aynı gün aynı kişi" toplaması: 573 SN, "aynı günde aynı kişilere düzenlenen faturaların topluca değerlendirilmesi" kuralını (509 IV.2.4.3 üçüncü fıkra) yürürlükten kaldırmıştır. 12/11/2024'ten sonra gün içi toplama kuralı YOKTUR; her fatura kendi tutarıyla değerlendirilir. Portalde "aynı gün aynı müşteri tutar toplama" kontrolü gerekmemektedir.

573 SN yürürlük maddesi (MADDE 20): 3 Bin TL değişikliği 1/1/2025'ten itibaren gerçekleştirilen teslim ve hizmetlere uygulanmak üzere 1/1/2025'te; üçüncü fıkra değişikliği 1/1/2026'dan itibaren gerçekleştirilen teslim ve hizmetlere uygulanmak üzere 1/1/2026'da yürürlüğe girer.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt (dipnot 26, 27, 28)

#589 SN VUK GT (RG 31.12.2025-33124) — Tek Etkisi

"MADDE 1- 19/10/2019 tarihli ve 30923 sayılı Resmi Gazete'de yayımlanan Vergi Usul Kanunu Genel Tebliği (Sıra No: 509)'nin "IV.2.4.3. e-Arşiv Fatura Olarak Düzenlenme Zorunluluğu Getirilen Diğer Faturalar" başlıklı bölümünün birinci fıkrasında yer alan "1/1/2025 ila 31/12/2025" ifadesinden sonra gelmek üzere "(ticari kazançları basit usulde tespit edilen mükellefler ile işletme hesabı esasına göre defter tutan mükellefler açısından 1/1/2025 ila 31/12/2026)" ve "1/1/2026" ifadesinden sonra gelmek üzere "(ticari kazançları basit usulde tespit edilen mükellefler ile işletme hesabı esasına göre defter tutan mükellefler açısından 1/1/2027)" ifadesi eklenmiştir."

589, 509'da yalnızca tek bir bölümü (IV.2.4.3) değiştirmiştir. Başka hiçbir had veya tarih değişmemiştir. Sonuç: Portalin basit usul / işletme hesabı / bilanço ayrımını yapan bir mükellef-tipi alanı tutması ZORUNLUDUR.

Kaynak: Vergi_Usul_Kanunu_Genel_Tebligi__Sira_No_509__nde_Degisiklik_Yapilmasina_Dair_Teblig__Sira_No_589__.txt

#573 SN VUK GT (RG 12.11.2024-32720) — Zorunluluk Hadlerine İlişkin Maddeler

"MADDE 2- Aynı Tebliğin "IV.2.4.3. e-Arşiv Fatura Olarak Düzenlenme Zorunluluğu Getirilen Diğer Faturalar" başlıklı bölümünün birinci fıkrasında yer alan ", 1/1/2020 tarihinden itibaren düzenlenecek faturaların, vergiler dahil toplam tutarının 5 Bin TL'yi (vergi mükelleflerine düzenlenenler açısından Kanunun 232 nci maddesinin ikinci fıkrasında belirtilen, işlemin gerçekleştiği yıla ait, fatura düzenleme zorunluluğuna ilişkin tutarı) aşması halinde, söz konusu faturaların," ibaresi "düzenlenecek faturaların; 1/1/2025 ila 31/12/2025 tarihleri arasında vergiler dahil toplam tutarının 3 Bin TL'yi aşması halinde, 1/1/2026 tarihinden itibaren ise tutarına bakılmaksızın," şeklinde değiştirilmiş ve aynı bölümde yer alan üçüncü fıkra yürürlükten kaldırılmıştır."

Kaynak: Vergi_Usul_Kanunu_Genel_Tebligi__Sira_No_509__nde_Degisiklik_Yapilmasina_Dair_Teblig__Sira_No_573__.txt

#IV.2.4.4 — Başkanlıkça Re'sen e-Arşiv Zorunluluğu

"Başkanlık, yapılan analiz veya inceleme çalışmaları neticesinde riskli ya da vergiye uyum düzeyi düşük olduğu tespit edilen mükellefleri veya mükellef gruplarını, faaliyet, sektör ve ciro tutarına bağlı olmaksızın, yazılı bildirim yapmak ve geçiş hazırlıkları için en az 3 ay süre vermek suretiyle e-Arşiv Fatura uygulamasına geçme zorunluluğu getirmeye yetkilidir."

Aynı yetki e-Fatura için IV.1.4(ğ), e-İrsaliye için IV.3.5/10'da tekrarlanır.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#IV.2.4.5 — Elektronik Ticaret Kapsamındaki e-Arşiv Faturalarda ZORUNLU ALANLAR

"e-Arşiv Fatura uygulamasına dahil olan mükellefler tarafından elektronik ticaret kapsamında gerçekleştirilen mal ve hizmet satışlarına ilişkin düzenlenecek e-Arşiv Faturalarda aşağıdaki bilgilere yer verilmesi zorunlu olup, ayrıca fatura üzerinde "Bu satış internet üzerinden yapılmıştır." ifadesi yer almalıdır. 1. Satış işleminin yapıldığı web adresi. 2. Ödeme şekli. 3. Ödeme tarihi. 4. Mal satışlarında gönderiyi taşıyanın adı soyadı/unvanı ve VKN/TCKN bilgisi. 5. Satışa konu malın gönderildiği veya hizmetin ifa edildiği tarih. 6. İade bölümünde; malı iade edenin adı soyadı, adresi, imzası, iade edilen mala ilişkin cins, miktar, birim fiyat ve tutarı."

Zorunlu 6 bilgi alanı (TAM LİSTE):

Zorunlu ibare: "Bu satış internet üzerinden yapılmıştır."

Sevkiyat sırasında mal yanında bulunması gerekenlerden BİRİ:

İade mekanizması: Müşteri malı iade etmek isterse elektronik ortamda kendisine iletilen faturanın kâğıt çıktısını alır, iade bölümünü doldurup imzalar ve mal ile birlikte satıcıya gönderir. Bu belge, satıcı tarafından düzenlenen gider pusulası yerine geçer.

e-Fatura kayıtlı alıcılara internetten mal satışı: Düzenlenecek e-Faturada 6. madde hariç yukarıdaki bilgilere yer verilir (iade bölümü e-Faturada aranmaz). Aynı sevk belgesi kuralları geçerlidir.

Değişiklik: 535 SN ile sevk belgesi listesine e-İrsaliye örneği ve özel kodlu belge kâğıt çıktısı eklendi (dipnot 29 ve 30). Önceki hâli yalnızca "e-Arşiv Faturanın kâğıt çıktısı, ÖKC fatura bilgi fişi ya da sevk irsaliyesi" diyordu.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#e-İRSALİYE Zorunluluğu

#Çerçeve Hüküm — IV.3.5

"Aşağıda belirtilen mükelleflerin e-İrsaliye uygulamasına dâhil olmaları ve düzenleyecekleri sevk irsaliyelerini bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde "e-İrsaliye" olarak düzenlemeleri ve uygulama kapsamındaki mükelleflerden alacakları sevk irsaliyelerini de "e-İrsaliye" olarak almaları zorunludur."

#TAM TABLO — IV.3.5 e-İrsaliye Zorunluluk Bentleri (1–10)

573 MADDE 3: "(8) numaralı bentten sonra gelmek üzere ... eklenmiş ve diğer bent buna göre teselsül ettirilmiştir" — eski (9) numaralı Başkanlık yetkisi bendi (10)'a kaymıştır.

Görevde sorulan sektörlerin karşılığı: şeker → bent 4; demir-çelik → bent 5; gübre → bent 6; HKS (sebze-meyve) → bent 8; maden ruhsatı → bent 3; akaryakıt bayileri → bent 1 (bayilik lisansı dâhil).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#IV.3.5/4 — Şeker Kanunu md.2/(e) Şekerin TAM Tanımı

"4- 4/4/2001 tarihli ve 4634 sayılı Şeker Kanununun 2 nci maddesinin (e) bendinde tanımına yer verilen şekerin (Beyaz şeker (standart, rafine küp ve kristal şeker), yarı beyaz şeker, rafine şeker, ham şeker ve kahverengi şeker olarak sınıflandırılan, pancar veya kamıştan üretilen kristallendirilmiş sakaroz ile nişasta kökenli izoglukoz, likid ya da kurutulmuş halde glukoz şurubu, sakaroz veya invert şeker veya her ikisinin karışımının suda çözünmesinden meydana gelen şeker çözeltisi ve invert şeker şurubu ile inülin şurubu) imalini gerçekleştiren mükellefler."

Kapsamdaki ürünlerin TAM listesi:

Ortak tanım: pancar veya kamıştan üretilen kristallendirilmiş sakaroz. Kapsam yalnızca imalatçıdır ("imalini gerçekleştiren mükellefler") — ticaretini yapanlar bu bent kapsamında değildir.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#IV.3.5/5 ve /9 — Demir-Çelik (GTİP 72/73) ve İDİS

Bent 5 güncel hâli:

"5- Demir ve çelik (GTİP 72) ile demir veya çelikten eşyaların (GTİP 73) imali, ithali veya ihracı faaliyetinde bulunan mükellefler (ticari kazançları basit usulde tespit edilenler hariç)."

535 öncesi hâli (dipnot 31): "5- e-Fatura uygulamasına kayıtlı olan mükelleflerden demir ve çelik (GTİP 72) ile demir veya çelikten eşyaların (GTİP 73) imali, ithali veya ihracı faaliyetinde bulunan mükellefler."

Artık e-Fatura mükellefi olmayan bir GTİP 72/73 imalatçısı da e-İrsaliye zorunlusudur. DİKKAT: bentte "teslim" veya "yurt içi ticaret" YOKTUR — yalnızca imal, ithal, ihraç.

Bent 9 (İDİS): İDİS tanımı Tebliğ'in kısaltmalar bölümünde 573 ile eklenmiştir (dipnot 3): "İnşaat Demiri İzleme Sistemi (İDİS): 16/3/2023 tarihli ve 32134 sayılı Resmi Gazete'de yayımlanan İnşaat Demiri İzleme..." Kapsam: İDİS'e geçiş zorunluluğu getirilen mükelleflerden brüt satış hasılatı 2024 ve müteakip hesap dönemlerinde 1 Milyon TL ve üzeri olanlar.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#IV.3.6 — e-İrsaliye Geçiş Süresi (İki Fıkra, İki Rejim)

"Bu Tebliğin "IV.3.5." numaralı bölümünde belirtilen mükelleflerin, e-İrsaliye uygulamasına ilişkin başvurularını ve fiili geçiş hazırlıklarını 1/7/2020 tarihine kadar tamamlayarak (11/3/2010 tarihli ve 5957 sayılı Sebze ve Meyveler ile Yeterli Arz ve Talep Derinliği Bulunan Diğer Malların Ticaretinin Düzenlenmesi Hakkında Kanun hükümlerine göre komisyoncu veya tüccar olarak sebze ve meyve ticaretiyle iştigal eden mükellefler 1/1/2020 tarihine kadar) e-İrsaliye uygulamasına geçmeleri ... zorunludur."

Birinci fıkra (genel takvim): 1/7/2020'ye kadar. İstisna: sebze-meyve komisyoncu/tüccarları 1/1/2020'ye kadar.

İkinci fıkra (1/1/2020'den itibaren yeni girenler):

"brüt satış hasılatı (veya satışları ile gayrisafi iş hasılatı) 2018, 2019 veya 2020 hesap dönemlerinde 25 Milyon TL, 2021 veya müteakip hesap dönemlerinde 10 Milyon TL ve üzeri olan mükelleflerin ise müteakip hesap döneminin yedinci ayı başından itibaren e-İrsaliye uygulamasına geçmeleri ... zorunludur."

e-İrsaliye ciro haddi zinciri:

Takvim örneği: 2021 dönemi 10M → 1/7/2022; 2022 → 1/7/2023; 2023 → 1/7/2024; 2024 → 1/7/2025; 2025 → 1/7/2026; 2026 → 1/7/2027.

NOT: e-İrsaliye ciro haddi için "e-Fatura uygulamasına kayıtlı olma" ön şartı 7. bentte hâlâ vardır (5. bentten 535 ile kaldırılmıştır).

Değişiklikler: İDİS ibaresi 573 (dipnot 34, MADDE 4) ile; hasılat eşikleri ve basit usul istisnası 535 (dipnot 35) ile; ayrıca 526 ile de değişiklik yapılmıştır (dipnot 36).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Diğer e-Belgelerde Zorunluluk ve Eşikler

#e-SMM (Serbest Meslek Makbuzu) — IV.4.4 / IV.4.5

"Serbest meslek erbaplarından; a) 1/2/2020 tarihi itibarıyla faaliyetine devam etmekte olanların 1/6/2020 tarihine, b) 1/2/2020 tarihinden (bu tarih dâhil) itibaren faaliyetine başlayacak olanların ise işe başladıkları ayı izleyen 3 üncü ayın sonuna, kadar e-Serbest Meslek Makbuzu uygulamasına dahil olmaları ... zorunludur."

Kapsam: Vergiden muaf olmayan tüm serbest meslek erbapları. Ciro haddi YOKTUR, sektör/faaliyet ayrımı YOKTUR.

Ceza (IV.4.6): Süresinde geçmeyenler ile kâğıt SMM düzenleyen/alanlar hakkında VUK cezai hükümleri uygulanır.

31.08.2026 itibarıyla bu tarihler geçmiştir; portal açısından "her serbest meslek erbabı e-SMM mükellefidir" kabul edilebilir.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#e-MM (Müstahsil Makbuzu) — IV.5.4 / IV.5.5

"e-Müstahsil Makbuzunu düzenleme zorunluluğu bulunan mükelleflerin, 1/7/2020 tarihine kadar (11/3/2010 tarihli ve 5957 sayılı ... Kanun hükümlerine göre komisyoncu veya tüccar olarak sebze ve meyve ticaretiyle iştigal eden mükellefler 1/1/2020 tarihine kadar) (2020 veya müteakip yıllarda e-Fatura uygulamasına geçen ve müstahsil makbuzu düzenleme zorunluluğu bulunan mükellefler e-Fatura uygulamasına geçiş süresi içinde) gerekli başvuruları yaparak e-Müstahsil Makbuzu uygulamasına geçmeleri ... zorunludur."

Kapsam (IV.5.4) — üç grup:

Takvim (IV.5.5):

Müstahsil makbuzu düzenleme zorunluluğu yoksa e-MM zorunluluğu da yoktur; ayrı bir ciro haddi YOKTUR — had e-Fatura haddine bağlıdır (2022+ için 3 Milyon TL).

İLAVE GÜNCEL ZORUNLULUK (22.05.2026 duyurusu): e-MM çıktısının ıslak imza ile imzalanması yerine, müstahsilin telefonuna gönderilecek SMS kodunun, telefon numarasının ve SMS'i gönderen operatör bilgisinin e-MM'de yer alması zorunlu kılınmıştır. 5.11.2026 tarihinden itibaren düzenlenecek tüm e-Müstahsil Makbuzlarında uygulanması zorunludur (öncesinde isteğe bağlı kullanılabilir).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt, e-Mustahsil_Makbuzu_Teknik_Kilavuzu_V1.1_.txt (22.05.2026), e-Mustahsil_Makbuzu_Duyurusu_.txt

#e-Gider Pusulası — IV.6.4 / IV.6.5: HAD YOK, TARİH YOK

"IV.6.4. e-Gider Pusulası Uygulamasına Geçiş Zorunluluğu — Başkanlık, yapılan analiz veya inceleme çalışmaları neticesinde riskli ya da vergiye uyum düzeyi düşük olduğu tespit edilen mükellefleri veya mükellef gruplarını faaliyet, sektör ve ciro tutarına bağlı olmaksızın, yazılı bildirim yapmak ve geçiş hazırlıkları için en az 3 ay süre vermek suretiyle e-Gider Pusulası uygulamasına geçme zorunluluğu getirmeye yetkilidir."

Geçiş Takvimi Tablosu da aynı sonucu verir: e-Gider Pusulası satırında tek kalem "Başkanlık ... yetkilidir" ve açıklama "Kendisine yazılı bildirim yapılan mükelleflerin, yazılı bildirimde belirtilen süreler içinde e-Gider Pusulası uygulamasına dâhil olması gerekmektedir."

Portal açısından: e-Gider Pusulası mükellefiyeti bir ciro kuralı ile HESAPLANAMAZ; GİB'in mükellef bazlı bildirimi / kayıtlı kullanıcı listesi esas alınmalıdır.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt, 509_s.VUK_GT_Kapsaminda_Uygulamalara_Gecis_Takvimi_Tablosu__3__.txt

#e-Bilet — IV.7.4.1 (Kara/Deniz Yolu) ve IV.7.4.2 (Sinema)

"8/1/2018 tarihli ve 30295 sayılı Resmî Gazete'de yayımlanan Karayolu Taşıma Yönetmeliğinde belirtilen şehirlerarası tarifeli yolcu taşımacılığı faaliyetiyle iştigal eden D1 yetki belgeli işletmeler 1/1/2021 tarihine kadar (2021 veya müteakip yıllarda faaliyetlerine başlayanlar, faaliyete başladığı ayı izleyen dördüncü ayın başından itibaren) e-Bilet uygulamasına geçmek ... zorundadırlar."

Ciro haddi yoktur, faaliyet bazlıdır. D1 yetki belgeliler, bu tarihten sonra düzenleyecekleri yolcu biletlerini ve yolcu listelerini e-Bilet ve e-Bilet Yolcu Listesi olarak düzenlemek zorundadır.

Sinema işletmeleri için ilave YN ÖKC zorunluluğu: Düzenledikleri her e-Bilet belgesindeki bilgileri "e-Bilet Bilgi Fişi (Sinema)" olarak kayıt altına almak amacıyla Yeni Nesil ÖKC kullanmak zorundadır. YN ÖKC'nin her bilet satış gişesinde bulunma zorunluluğu yoktur; sinema mekânı bazında, eğlence vergisinin beyan/ödemesinin yapılacağı belediye bazında ya da (belediyeler bazında aylık satış raporu alınabilmesi koşuluyla) işletme merkez bilgi işlem lokasyonlarında kurulabilir.

HAVA YOLU: 509'da hava yolu için e-Bilet zorunluluğu getirilmemiştir (IV.7.2'de yalnızca "Türkiye'de tam mükellef olmayan hava yolu firmaları" e-Fatura şartından muaf tutulmuştur).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#e-Adisyon — IV.12.4 / IV.12.5

"Başkanlık, adisyon belgesi düzenleyen hizmet işletmelerine, yıllık veya aylık satış hasılatı tutarlarını dikkate alarak, geçiş hazırlıkları için en az 3 ay geçiş süresi vermek ve yazılı bildirim ya da ebelge.gib.gov.tr adresinde duyurmak suretiyle e-Adisyon uygulamasına geçme zorunluluğu getirmeye yetkilidir."

e-Adisyon için sabit bir had/tarih YOKTUR; ancak diğer belgelerden farklı olarak Başkanlığın yetkisi açıkça "yıllık veya aylık satış hasılatı tutarlarını dikkate alarak" şeklinde formüle edilmiştir ve zorunluluk yalnızca yazılı bildirimle değil, ebelge.gib.gov.tr'de duyuru ile de getirilebilir.

573 SN etkisi: e-Adisyon'un içerik alanları da değiştirilmiştir — "Düzenlenen e-Adisyon belgesinin ilişkili olduğu e-Fatura veya e-Arşiv Fatura'nın ETTN'si veya perakende satış fişinin düzenlendiği ÖKC'nin cihaz sicil numarası" alanı (eski d bendi) yürürlükten kaldırılmıştır.

Geçiş Takvimi Tablosunda e-Adisyon satırı hiç yoktur (tablo bu belgeden önceki bir sürüme dayanmaktadır).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt, e-Adisyon_Belgesi_Teknik_Kilavuzu_V1_1_.txt

#İsteğe Bağlı Dört Belge: e-Sigorta Komisyon Gider, e-Sigorta Poliçesi, e-Döviz Alım-Satım, e-Dekont

"e-Dekont uygulaması zorunlu bir uygulama olmayıp, bankalar istemeleri halinde 1/1/2020 tarihinden, Vergi Usul Kanunu Genel Tebliği (Sıra No:435)'nin (2) numaralı bölümünde sayılan kuruluşlar ise istemeleri halinde 1/1/2025 tarihinden53 itibaren uygulamaya dahil olabileceklerdir."

Geçiş Takvimi Tablosu da bu dördü için tarih vermez, yalnızca "Başkanlık tarafından belirlenen süre içinde" der.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#İhtiyari (İsteğe Bağlı) Kullanım — IV.1.2 / IV.2.2 / IV.3.2

"b) e-Fatura uygulamasına dahil olma zorunluluğu bulunan mükellefler ile ihtiyari olarak uygulamaya dahil olan mükelleflerin, birbirlerine sattıkları mallar ve/veya ifa ettikleri hizmetler için düzenlemeleri ve almaları gereken faturaları, bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde e-Fatura olarak düzenlemeleri ve almaları zorunludur."

Üç uygulamada da aynı yapı vardır: zorunluluk kapsamında olmayanlar isteğe bağlı dâhil olabilir. IV.1.4(d) bunu açıkça tekrarlar: "Bu Tebliğle belirlenen hadlerin altında kalan mükellefler de istemeleri halinde e-Fatura uygulamasından yararlanabilir."

Önemli sonuç: İhtiyari olarak dâhil olan mükellef de, diğer kayıtlı kullanıcılarla arasındaki işlemlerde e-Fatura düzenlemek ve almak ZORUNDADIR. Portal, ihtiyari kullanıcıyı da zorunlu kullanıcı gibi ele almalıdır.

Ayrıca IV.2.4.3'teki kural: "Satıcı ve alıcının her ikisinin de e-Fatura uygulamasına kayıtlı kullanıcılar olması halinde, bunlar arasında düzenlenen faturaların tamamının e-Fatura olması gerekmektedir."

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#"NİHAİ TÜKETİCİ" e-Arşiv Faturası Eşiği — 509 V.2

e-Fatura ve e-Arşiv'e kayıtlı olup 483 SN VUK GT md.6/1 şartlarını sağlayarak ÖKC kullanımından muaf olan mükellefler ile 507 SN VUK GT'deki Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sisteminden yararlananlar, vergiler dahil toplam satış tutarı VUK md.232/2'deki işlemin gerçekleştiği yıla ait fatura düzenleme haddine kadar olan perakende mal ve hizmet satışlarında, e-Arşiv Faturayı "müşterinin adı, ticaret unvanı, adresi, vergi dairesi ve hesap numarası" yerine müşteri adı bölümünde "NİHAİ TÜKETİCİ" yazarak düzenleyebilir; bu belgeler perakende satış fişi veya ÖKC fişi olarak kabul edilir.

"66 550 Sıra No.lu Vergi Usul Kanunu Tebliği (RG: 07/10/2023 - 32332) ile değiştirilmeden önceki hali: 500 TL'ye. Bu değişiklik Tebliğin yayımlandığı tarihi izleyen aybaşından itibaren gerçekleştirilen teslim ve hizmetlere uygulanmak üzere yayımı tarihinde yürürlüğe girer."

"67 515 Sıra No.lu Vergi Usul Kanunu Tebliği (RG: 10/01/2020 - 31004) ile değiştirilmeden önceki hali: e-Fatura ve e-Arşiv Fatura uygulamalarına kayıtlı bulunan ve 30/9/2017 tarihli ve 483 Sıra No.lu Vergi Usul Kanunu Genel Tebliği'nin 6 ncı maddesinin birinci fıkrasında belirtilen şartları sağlayarak ÖKC kullanımından muafiyeti bulunan mükellefler tarafından, vergi dahil toplam satış tutarı 500 TL'ye kadar olan perakende mal ve hizmet satışlarına ait düzenlenen e-Arşiv Faturanın ... "NİHAİ TÜKETİCİ" açıklamasına yer verilerek düzenlenmesi halinde, düzenlenen bu belge perakende satış fişi veya ÖKC fişi olarak kabul edilecektir."

Şarj hizmetleri istisnası (550 SN ek fıkra): Şarj ağı işletmeci lisansı alanlar ve şarj istasyonu işletmecileri, IV.1.5/(g) uyarınca e-Fatura'ya dâhil olmaları gereken tarihten itibaren, Şarj Hizmeti Yönetmeliği kapsamındaki teslim/ifalara ilişkin belgeleri VUK 232/2 haddine bağlı olmaksızın e-Fatura veya e-Arşiv Fatura olarak düzenlemek zorundadır (2/1/2024'ten itibaren gerçekleştirilen teslim ve hizmetlere uygulanır).

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Kâğıt Belge Düzenlenebilecek Haller — V.7 ve VIII (Fallback Mantığının Tek Dayanağı)

#V.7 — Özel Usulsüzlük Cezası Kesilmeyen Dört Hal (TAM LİSTE)

"Elektronik belge olarak düzenlenme zorunluluğu getirilen belgelerin; a) Başkanlığın ve e-Belge uygulamalarına taraf olan diğer kamu kurum ve kuruluşlarının bilgi işlem sistemlerinde meydana gelen arıza, kesinti ile bu sistemlerde yapılan bakım, b) İspat veya tevsik edilmek kaydıyla, mükellefin ya da Başkanlıktan izin almış özel entegratör kuruluşların bilgi işlem sistemlerinde meydana gelen arıza, kesinti ile bu sistemlerde yapılan planlı bakım (yazılı bildirimde belirtilen süre ile sınırlı kalmak kaydıyla), c) İspat veya tevsik edilmek kaydıyla, kullanılmakta olan mali mührün veya elektronik imza aracının arızalanması veya çalınması (yeni mali mühür veya elektronik imza aracının temini süresince), ç) Bakanlık veya Başkanlık tarafından e-Belge uygulamalarına ilişkin olarak yayımlanan genel tebliğ, sirküler ve teknik kılavuz ve duyurularda, belgelerin e-Belge yerine kâğıt olarak düzenlenmesine ve e-Fatura yerine e-Arşiv Fatura düzenlenmesine izin verilmesi, gibi nedenlerle, kanunen düzenlenmesi gereken sürenin geçirilmemesi kaydıyla, kâğıt olarak düzenlenmesi [(ç) bendi bakımından e-Fatura yerine e-Arşiv Fatura düzenlenmesi de dâhil] durumunda özel usulsüzlük cezası kesilmez."

Ortak ön şart: "gibi nedenlerle, kanunen düzenlenmesi gereken sürenin geçirilmemesi kaydıyla". Liste "gibi nedenlerle" ifadesiyle örnekleyicidir.

(ç) bendinin kapsamı 573 ile genişletildi: 573 MADDE 17 ile "düzenlenmesine" ibaresinden sonra "ve e-Fatura yerine e-Arşiv Fatura düzenlenmesine" eklenmiş, "düzenlenmesi durumunda" ibaresi "düzenlenmesi [(ç) bendi bakımından e-Fatura yerine e-Arşiv Fatura düzenlenmesi de dâhil] durumunda" şeklinde değiştirilmiştir (dipnot 79 ve 80, RG 12/11/2024-32720). Bu, GİB'in duyuru ile "e-Fatura yerine e-Arşiv kesilsin" demesine yasal zemin sağlar.

Kapsam dışı: "Mükelleften kaynaklanan diğer nedenlerle, e-Belge olarak düzenlenmesi gereken belgelerin kağıt olarak düzenlenmesi yukarıda sayılan nedenler kapsamında değerlendirilmez."

Mücbir sebep: Elektronik olarak düzenlenmesi gereken belgenin, VUK md.13'te yazılı mücbir sebepler nedeniyle elektronik olarak düzenlenememesi hâlinde VUK md.373 gereği özel usulsüzlük cezası kesilmez.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#VIII. Diğer Hususlar — Operasyonel Bağlayıcı Hükümler

"Bu Tebliğde belirtilen e-Belgeleri düzenleme yetkisi bulunan mükelleflerin, sistemlerinde arıza veya kesinti meydana gelmesi veya diğer mücbir sebep durumlarında düzenlenmek üzere yeterli miktarda matbu belgeleri bulundurmaları zorunludur. Bu şekilde belge düzenlemek istisnai bir uygulama olup, belge düzenlemeye başlamadan önce Başkanlığa konu hakkında tevsik edici bilgi ve belgelerle birlikte yazılı olarak bilgi verilmesi ve bu durumun süreklilik arz etmemesi gerekmektedir."

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#VIII — Geçiş Ayı Kâğıt Belge Toleransı (Portal Onboarding Kuralı)

"Bu Tebliğe konu e-Belge uygulamalarına dâhil olan mükellefler, uygulamaya dâhil oldukları tarihin içinde bulunduğu ayın (e-Fatura ve e-Arşiv Fatura uygulamaları için 7 nci günün) sonuna kadar, söz konusu belgeleri kâğıt ortamda da düzenleyebilirler. Ancak aynı işlem için e-Belge veya kâğıt ortamdaki belgelerinden sadece birinin düzenlenmesi gerekmektedir. e-Belge uygulamalarına dahil olunan tarihin ait olduğu ayın sonundan (e-Fatura ve e-Arşiv Fatura uygulamaları için 7 nci günden) itibaren, belgelerin e-Belge olarak düzenlenmesi zorunlu olup, kağıt ortamda belge düzenlenmesi halinde Kanunda yazılı cezalar tatbik edilir."

Çift belge yasağı: Aynı işlem için e-Belge veya kâğıt ortamdaki belgelerden sadece biri düzenlenir.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#VII. Sorumluluk ve Cezai Müeyyideler — Matbu Belge Kullanma Yasağı

"Bu Tebliğe konu e-Belge uygulamalarına dâhil olan mükellefler, bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen haller dışında, yaptıkları mal teslimleri/alımları ve hizmet ifaları kapsamında, anlaşmalı matbaa işletmelerine bastırılan matbu (kağıt) belgeleri kullanamazlar, kullanmaları halinde söz konusu mükellefler hakkında Kanunda öngörülen cezai hükümler uygulanır."

Aynı bölümdeki diğer kritik hükümler:

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Ceza Hükümleri — Belge Bazında Cezalandırılan Taraf

"Zorunluluk getirildiği halde e-İrsaliye uygulamasına süresi içinde geçmeyen mükellefler ile e-İrsaliye şeklinde düzenlenmesi gereken sevk irsaliyesini, bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde e-İrsaliye olarak düzenlemeyen ve almayan (matbu kağıt sevk irsaliyesi olarak düzenleyenler ve alanlar dahil) mükellefler (232 nci maddenin birinci fıkrasının 1 ila 5 numaralı bentlerinde sayılanlar) hakkında Kanununda öngörülen cezai hükümler uygulanır."

"Söz konusu faturaların bu Tebliğin "V.7." ve "VIII." numaralı bölümlerinde belirtilen istisnai durumlar haricinde e-Arşiv Fatura yerine matbu (kağıt) fatura olarak düzenlenmesi veya alınması halinde, faturayı düzenleyen ile nihai tüketici dışındaki vergi mükellefiyeti bulunan alıcı hakkında düzenlenen veya alınan her bir kağıt fatura için ayrı ayrı olmak üzere Kanunun 353 üncü maddesinde öngörülen cezai hüküm uygulanır."

Ceza tutarları (509 V.6 bölümünde VUK 353 metni üzerinden):

Tüm bu cezalar "V.7." ve "VIII." bölümlerindeki istisnai durumlar (sistem arızası vb.) hariç uygulanır.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Hadlerin Hesabında Esas Alınacak Dönem ve Özel Durumlar (GİB SSS)

509 metninde brüt satış hasılatının nasıl hesaplanacağına dair teknik tanım yoktur; esas alınan dönem "hesap dönemi"dir ve geçiş, o dönemi izleyen yılın 7. ayının başındadır. GİB SSS'de netleşen özel durumlar:

"509 Sıra No.lu Genel Tebliğ kapsamında e-fatura ve diğer uygulamalara geçiş hadleri açısından Gelir vergisi mükellefinin kendi gayrisafi iş hasılatı ile adi ortaklıktan elde edilen gelir toplamı birlikte değerlendirilebilir mi? ... İlgili Tebliğ kapsamında geçiş zorunluluğu belirlenirken şahsi işletme ve Adi ortaklıktan elde edilen gelirler ayrı ayrı değerlendirilir."

Kaynak: 509_Cok_Sorulan__Sorular_.txt

#509'u Değiştiren Tebliğlerin Zorunluluk Hükümlerine Etki Haritası

Dipnotlu metinde 87 adet "Sıra No.lu Vergi Usul Kanunu Tebliği" atfı vardır. Zorunluluk hadleri açısından tebliğ tebliğ etki:

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt, Vergi_Usul_Kanunu_Genel_Tebligi__Sira_No_509__nde_Degisiklik_Yapilmasina_Dair_Teblig__Sira_No_573__.txt, Vergi_Usul_Kanunu_Genel_Tebligi__Sira_No_509__nde_Degisiklik_Yapilmasina_Dair_Teblig__Sira_No_589__.txt

#GİB Resmî Geçiş Takvimi Tablosunun Birebir Aktarımı (TARİHSEL REFERANS)

#e-FATURA Bölümü — 11 Satır

"E-FATURA 3- 2020 veya müteakip hesap dönemleri brüt satış hasılatı (veya satışları ile 509 SN VUK GT ilgili hesap dönemini izleyen yılın yedinci ayının başından itibaren, e- gayrisafı iş hasılatı) 5 Milyon TL ve üzeri olan mükellefler Fatura uygulamasına geçmek zorundadır."

UYARI: Tablo 5 Milyon TL'de kalmıştır; 535 SN'nin 4 Milyon / 3 Milyon kademelerini YANSITMAZ. Ayrıca 526 (SGK sağlık hizmeti sunucuları), 535 (gayrimenkul/motorlu taşıt, otel) ve 550 (şarj ağı) bentleri tabloda HİÇ YOKTUR.

#Diğer Belgeler — Tablonun Aktarımı

e-ARŞİV FATURA:

"e-ARŞİV FATURA 1- E-Fatura Uygulamasına Zorunlu veya İsteğe Bağlı olarak Dâhil Olan/Olacak Olan Mükellefler ( E Fatura mükellefi olmayanlara düzenlecek faturalar) ... Hali hazırda e-Fatura uygulamasına dahil olanlar 1.1.2020'de, 1.1.2020'den sonra e-Fatura uygulamasına dahil olanlar ise e-Fatura uygulamasına geçilen tarihte"

e-İRSALİYE (tablodaki 9 kalem): 1- ÖTV (I) EPDK lisanslı → 1.7.2020; 2- ÖTV (III) imal/inşa/ithal/ana bayi-distribütör → 1.7.2020; 3- Maden Kanunu işletme ruhsatı/sertifikası sahipleri ve sözleşmeli üreticiler → 1.7.2020; 4- Şeker Kanunu md.2/(e) şeker imalatçıları → 1.7.2020; 5- e-Fatura'ya kayıtlı olup demir-çelik (GTİP 72) ve demir/çelikten eşya (GTİP 73) imal/ithal/ihraç edenler → 1.7.2020; 6- Gübre Takip Sistemi kayıtlı kullanıcılar → 1.7.2020; 7- e-Fatura'ya kayıtlı ve 2018 veya müteakip hesap dönemleri brüt satış hasılatı 25 Milyon TL ve üzeri → 1.7.2020; 8- Sebze-meyve komisyoncu/tüccar → 1.1.2020; 9- Başkanlık yetkisi; 10/11/13- 1/1/2020'den itibaren şartları sağlayanlar → "söz konusu işlemlerinin gerçekleştirildiği ayı izleyen dördüncü ayın başından itibaren".

e-SMM: 1/6/2020 tarihine kadar; işe başlayanlar işe başladıkları ayı izleyen 3 üncü ayın sonuna kadar.

e-MÜSTAHSİL MAKBUZU: 1- 1.7.2020; 2- e-Fatura uygulamasına geçiş süresi içinde; 3- 1.1.2020 (sebze-meyve); 4- Başkanlık yetkisi.

e-GİDER PUSULASI: Yalnızca Başkanlık yetkisi.

e-BİLET: D1 yetki belgeli şehirlerarası tarifeli yolcu taşımacıları → 1/1/2021 (2021+ başlayanlar izleyen 4. ayın başı); sinema işletmeleri → 1/7/2020 (sonra başlayanlar izleyen 4. ayın başına kadar).

e-SİGORTA KOMİSYON GİDER, e-SİGORTA POLİÇESİ, e-DÖVİZ ALIM-SATIM, e-DEKONT: Tarih yok, "Başkanlık tarafından belirlenen süre içinde".

e-DEFTER (3 SN Elektronik Defter GT): e-Fatura zorunluluğu olanlar e-Fatura geçiş süresi içinde (yıl içinde zorunlu geçenler bakımından izleyen yılın başından); 2018 ya da 2019 hasılatı 5.000.000 TL'yi geçenler 01.01.2021'den; 2018 hasılatı 10.000.000 TL'yi geçenler (454 SN) 01.01.2020'den; 19.10.2019 itibarıyla TTK 397/4 bağımsız denetime tabi şirketler 1/1/2020'den, 2020+ şartı sağlayanlar takip eden yılın başından; tam bölünme/birleşme/nev'i değişikliği → tescili izleyen ayın başından itibaren 3 ayı geçemez; 2018'de internetten satış yapıp brüt satış hasılatı 5 Milyon TL ve üzeri olanlar → 1.1.2020.

Kaynak: 509_s.VUK_GT_Kapsaminda_Uygulamalara_Gecis_Takvimi_Tablosu__3__.txt

#Zorunluluk Karşılaştırma Tablosu — Tarihsel Konum Tespiti

KRİTİK TESPİT: Bu dosya 509'un yürürlükteki hâlini DEĞİL, 509 daha taslak iken 454/464/487 SN tebliğlerle karşılaştırılmasını içerir. Sütun başlıkları bunu açıkça söyler: "YÜRÜRLÜKTEKİ TEBLİĞLERE GÖRE DURUM" ve "TEBLİĞ TASLAKLARINA GÖRE (HENÜZ YÜRÜRLÜĞE GİRMEMİŞTİR.)". Bugün (31.08.2026) hiçbir hükmü doğrudan uygulanabilir değildir.

O dönemde yürürlükte olan durum (sol sütun):

"E-İRSALİYE UYGULAMASINA 487 SIRA İSTEĞE BAĞLIDIR. ... HERHANGİ BİR MÜKELLEF GRUBU İÇİN ZORUNLULUK ÖNGÖRÜLMEMİŞTİR."

Taslakta öngörülen ile yayımlanan 509 arasındaki farklar:

Kaynak: Zorunluluk_Karsilastirma_Tablosu_.txt

#Korpus İçi Çelişkiler — Portal Kural Motoru İçin Karar Matrisi

"düzenlenecek faturaların, vergiler dahil toplam tutarının 30 Bin TL'yi (vergi mükelleflerine düzenlenenler açısından vergiler dahil toplam tutarı 5 Bin TL'yi) aşması halinde, söz konusu"

SONUÇ: Portal kural motoru yalnızca dipnotlu güncel 509 + 573 + 589 metinlerine göre kodlanmalıdır. Geçiş Takvimi Tablosu ve SSS yalnızca geçmiş dönem denetim/analiz senaryolarında referans alınabilir; kural motorunda kullanılamaz.

Kaynak: e-Arsiv_Fatura_Portali_Entegrasyon_Kilavuzu_.txt, 509_s.VUK_GT_Kapsaminda_Uygulamalara_Gecis_Takvimi_Tablosu__3__.txt, 509_Cok_Sorulan__Sorular_.txt, Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt

#Doğrulanamayanlar ve Korpus Boşlukları

Bu bölümdeki hiçbir bulgu hakem tarafından çürütülmemiştir (REFUTED); aşağıdaki hususlar ise korpusta cevabı bulunmadığı için doğrulanamamıştır ve kural motorunda varsayım olarak kullanılamaz.

Kaynak: Dipnotlu_Guncel_Sekli_ile_509_Sira_No_lu_VUK_Genel_Tebligi_.txt, UBL-TR_Kod_Listeleri_-_V_1.43_.txt, e-Fatura_Uygulamasi_gumruk_islemleri_Kilavuzu_.txt, 509_Cok_Sorulan__Sorular_.txt, e-Irsaliye_Uygulama_Kilavuz_1.2_.txt, Ilac_ve_Tibbi_Cihaz_Teslimlerine_Iliskin_Fatura_Teknik_Kilavuzu_V.1.2_.txt, e-Adisyon_Belgesi_Teknik_Kilavuzu_V1_1_.txt, 509_s.VUK_GT_Kapsaminda_Uygulamalara_Gecis_Takvimi_Tablosu__3__.txt

#BÖLÜM 3 — İş Akışları

#Fatura Yaşam Döngüsü: Akışlar, İptal, İtiraz ve İade

Bu bölümdeki her hüküm, kaynak korpusa geri dönülerek hakem ajanı tarafından ayrıca doğrulanmıştır. Kılavuz metni ile schematron çeliştiğinde schematron esas alınmıştır ve çelişki açıkça işaretlenmiştir. Doğrulanamayan çıkarımlar en sonda ayrı başlık altındadır.

#1. TEMELFATURA Akışı vs TICARIFATURA Akışı

#1.1 TEMELFATURA — tek yönlü akış, uygulama yanıtı YOKTUR

Senaryo dokümanı tektir: "UBL-TR Fatura (Invoice)". Uygulama Yanıtı bu senaryonun parçası değildir.

Kritik kurallar:

• Faturanın alıcısına kayıtlı ve güvenli biçimde ulaştırılması ile işlem tamamlanmış sayılır.
• Sistem seviyesinde alıcı faturayı reddedemez; posta kutusuna düştüğü anda teslim edilmiş sayılır.
• İtirazlar harici yollarla yapılır (senaryo içinde KABUL/RED mekanizması yoktur).
• Portal implikasyonu: TEMELFATURA'da alıcıdan beklenecek tek geri dönüş GİB Merkez'in ürettiği Sistem Yanıtı'dır (ResponseCode = S_APR). Ticari bir onay akışı kurgulanmamalıdır. Fatura hatalıysa çözüm: iptal portali (8 gün) veya harici itiraz.

Kaynak: UBL-TR_Temel_Fatura_Senaryosu_-_V_0.2_.txt (satır 49-51, 57-58, 60-62, 94-102).

#1.2 Fatura numarası (cbc:ID) — InvoiceIDCheck

<sch:rule abstract="true" id="InvoiceIDCheck">
  <sch:assert test="matches(cbc:ID,'^[A-Z0-9]{3}20[0-9]{2}[0-9]{9}$')">Geçersiz cbc:ID elemanı değeri. cbc:ID elemanı 'ABC2009123456789' formatında olmalıdır.</sch:assert>
</sch:rule>

Kaynak: UBL-TR_Common_Schematron.xml satır 154-156; UBL-TR_Main_Schematron.xml satır 149 ve 480'de extend edilir.

Yapı: 3 hane [A-Z0-9] birim kodu + 20YY + 9 hane müteselsil = TAM 16 karakter.

ÇELİŞKİ (kılavuz vs schematron — schematron esastır): Temel Fatura Senaryosu V0.2'nin kendi örneğindeki <cbc:ID>GIB20090000000001</cbc:ID> değeri 17 karakterdir (GIB + 2009 + 10 hane) ve GİB'in kendi InvoiceIDCheck kuralından geçemez — zarf 1150 SCHEMATRON KONTROL SONUCU HATALI alır. Portal şablonunda bu örnek KULLANILMAMALIDIR. Doğru şablon 16 hanelidir: ABC2026000000001. (Karşılaştırma: Ticari Fatura Senaryosundaki GIB2009000000011 ve GIB2009000000022 16 hanedir ve kuralı geçer.)

Başlık bloğu şablonu (Temel Fatura örneğinden, cbc:ID düzeltilmiş):

<cbc:UBLVersionID>2.1</cbc:UBLVersionID>
<cbc:CustomizationID>TR1.2</cbc:CustomizationID>
<cbc:ProfileID>TEMELFATURA</cbc:ProfileID>
<cbc:ID>ABC2026000000001</cbc:ID>          <!-- TAM 16 HANE -->
<cbc:CopyIndicator>false</cbc:CopyIndicator>
<cbc:UUID>F47AC10B-58CC-4372-A567-0E02B2C3D479</cbc:UUID>
<cbc:IssueDate>2026-08-31</cbc:IssueDate>
<cbc:IssueTime>14:42:00</cbc:IssueTime>
<cbc:InvoiceTypeCode>SATIS</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>TRY</cbc:DocumentCurrencyCode>
<cbc:LineCountNumeric>1</cbc:LineCountNumeric>

#1.3 TICARIFATURA — Temel Fatura'dan tek farkı: Uygulama Yanıtı

"Bu senaryo kapsamında düzenlenen fatura, temel fatura senaryosunda düzenlenen faturadan farklı değildir. Temel fatura senaryosundan farklı olarak, Ticari Fatura Senaryosunda uygulama yanıtı kullanımına imkan verilmiştir. Ticari Fatura Senaryosu kapsamında faturalaşma, tarafların bu konuda gösterecekleri açık rızaya bağlıdır."

Senaryo dokümanları iki tanedir: UBL-TR Fatura (Invoice) + UBL-TR Uygulama Yanıtı (ApplicationResponse).

A. Faturanın Kabul Edilmesi

B. Faturanın Reddedilmesi

C. İade Faturası Düzenlenmesi

#1.4 RED sürecinin kesin kuralları (portalde kodlanacak kısıtlar)

Kaynak: UBL-TR_Ticari_Fatura_Senaryosu_-_V_0.3_.txt satır 71-75, 108-109, 129-184, 203-262.

#1.5 Durum Makinesi (State Machine) Tablosu