Gelir İdaresi Başkanlığı, Temmuz ve Ağustos ayında art arda e-belge duyurusu yayımladı: 27 Temmuz’da e-Fatura Paketi, e-Arşiv Fatura Paketi ve UBL-TR Kod Listeleri Kılavuzu güncellendi; yürürlük tarihi 14 Eylül 2026 olarak duyuruldu. 11 Ağustos’ta ise ayrı bir düzeltme geldi: e-Arşiv paketindeki earsiv.xsd dosyasında tespit edilen eksiklikler giderildi. Aradan geçen üç hafta içinde iki güncelleme — bu, e-belge ekosisteminin durağan değil, sürekli revize edilen bir altyapı olduğunun somut göstergesi.
Çoğu KOBİ için bu tür duyurular muhasebe biriminin veya entegratör firmanın işi gibi görünür. Oysa ERP’niz e-fatura/e-arşiv akışına doğrudan bağlıysa (çoğu modern sistemde bağlı), bir şema veya kod listesi güncellemesi fatura kesim sürecini durdurabilir. Eylül ortasına kadar sistemlerin uyumlu olması gerekiyor.
Temmuz-Ağustos 2026’da tam olarak ne değişti
Resmî duyurular şu şekilde:
- 27 Temmuz 2026 — e-Fatura Paketi, e-Arşiv Fatura Paketi ve UBL-TR (Kod Listeleri) Kılavuzu güncellendi. Yürürlük tarihi 14 Eylül 2026.
- 11 Ağustos 2026 — e-Arşiv paketinde
earsiv.xsdşema dosyasındaki eksiklikler giderildi (teknik düzeltme, ayrı bir yürürlük tarihi belirtilmedi).
Değişikliklerin teknik kapsamı GİB’in e-Belge Teknik Kılavuzları sayfasında yayımlanıyor; entegratörünüz veya BT ekibiniz bu belgeleri satır satır incelemeli. Bu yazı, güncellemenin kendisini değil, işletmenizde neyi tetiklemesi gerektiğini konu alıyor.
Neden yalnızca muhasebenin değil, yönetimin de gündeminde olmalı
Fatura kesim zinciri kırıldığında sonuç muhasebe hatası değil, nakit akışı sorunudur: sevkiyat bekler, tahsilat gecikir, müşteri güveni zedelenir. Üç risk noktası öne çıkıyor:
- Entegratör bağımlılığı — e-fatura/e-arşiv akışınızı bir özel entegratör üzerinden yürütüyorsanız, güncellemeyi entegratörün ne zaman devreye aldığını netleştirmeniz gerekir. Kendi altyapınızı (özel entegrasyon) kullanıyorsanız sorumluluk doğrudan size ait.
- ERP-e-fatura köprüsü — ERP sisteminiz faturayı üretip e-fatura modülüne veya entegratöre otomatik aktarıyorsa, şema değişikliği bu köprüde uyumsuzluk yaratabilir. Test ortamında doğrulanmadan canlıya alınan bir entegrasyon, 14 Eylül’den sonra fatura reddine yol açabilir.
- Kod listesi tutarsızlığı — UBL-TR kod listeleri (birim, para birimi, vergi türü gibi alanlar) güncellendiğinde, ERP’de tanımlı eski kod değerleri fatura reddi sebebi olabilir.
ERP/e-fatura entegrasyonu kontrol listesi
Eylül’e kadar aşağıdaki maddeleri sırayla geçmek, sürpriz bir kesintiyi büyük ölçüde önler.
| Kontrol maddesi | Ne yapılmalı |
|---|---|
| Entegratör/GİB portal duyurusu | Kullandığınız entegratörün veya GİB portalının güncellemeyi ne zaman uyguladığını yazılı olarak teyit edin |
| Test ortamı doğrulaması | Canlıya almadan önce test ortamında örnek fatura kesip yeni şemaya göre doğrulayın |
| UBL-TR kod listeleri | ERP’de tanımlı birim/vergi/para birimi kodlarını güncel kılavuzla karşılaştırın |
| earsiv.xsd düzeltmesi | 11 Ağustos düzeltmesinin sisteminize yansıyıp yansımadığını sorun |
| Yetkilendirme ve eğitim | Muhasebe ve satış ekibine yürürlük tarihini ve olası kesinti riskini bildirin |
| Yedek plan | Entegrasyon arızalanırsa manuel fatura kesim prosedürünü hazır tutun |
Bu tablo bir denetim listesi değil, önceliklendirme aracıdır. İşletmenizin risk profiline göre bazı maddeler daha kritik olabilir.
Bir güncellemenin gerçek maliyeti ne olabilir
Somut bir örnek üzerinden düşünelim: günde ortalama 40 fatura kesen bir imalatçı KOBİ, entegrasyon uyumsuzluğu yüzünden faturaların bir kısmını reddedilmiş bulursa, önce hatanın kaynağını (ERP mi, entegratör mü, kod listesi mi) bulmak zorunda kalır. Bu teşhis süreci saatler sürebilir; o saatlerde kesilemeyen faturalar sevkiyat veya tahsilat takvimini kaydırır. Rakamı kesin veremeyiz çünkü etki işletmeden işletmeye, entegratör sözleşmesine ve iç süreç olgunluğuna göre değişir — ama örüntü nettir: teknik bir güncelleme, operasyonel bir gecikmeye dönüşebilir.
Bunun önüne geçmenin maliyeti genelde düşüktür: bir test faturası kesmek, entegratörle bir e-posta teyidi almak, kod listesini gözden geçirmek. Riskle önlemin bu dengesizliği, çoğu KOBİ’nin küçümsediği bir noktadır — “nasılsa entegratör hallediyordur” varsayımı, sorumluluğun nerede bittiğini net görmeyi engeller.
e-Defter ve e-İrsaliye ile bağlantısı
e-Fatura, e-Arşiv ve e-İrsaliye aynı teknik altyapıyı (UBL-TR şeması, GİB portalı) paylaşır; birinde yapılan bir kod listesi güncellemesi genellikle diğerlerini de dolaylı etkiler. e-Defter tarafında ayrıca zorunluluk eşikleri ve format güncellemeleri kendi takvimiyle ilerliyor. Sisteminiz bu üç bileşeni birlikte kullanıyorsa, güncelleme testini tek bir modülle sınırlamayın — uçtan uca fatura-irsaliye-defter akışını test ortamında bir kez baştan sona çalıştırmak, ayrı ayrı test etmekten daha güvenilir sonuç verir.
Bu tür güncellemeleri sürekli takip etmenin pratik yolu
e-Belge mevzuatı yılda birkaç kez değil, ayda birkaç kez güncelleniyor. Her duyuruyu tek tek takip etmek küçük bir muhasebe ekibi için sürdürülebilir değil. İki pratik yaklaşım var:
- Entegratör SLA’sını netleştirin — güncellemeyi kaç iş günü içinde uyguladıklarını ve size nasıl bildirdiklerini sözleşmeye bağlayın.
- ERP tarafında değişim yönetimi kurun — kod listesi ve şema güncellemelerini merkezi bir yerden (ERP’nin entegrasyon katmanı) yönetin; her satış/muhasebe kullanıcısının ayrı ayrı takip etmesine gerek kalmasın.
Bu, aslında daha büyük bir örüntünün küçük bir örneği: dağınık, elle takip edilen süreçler mevzuat değiştikçe kırılganlaşır; merkezi ve otomatikleştirilmiş bir veri/entegrasyon katmanı ise güncellemeyi tek noktadan absorbe eder.
İkiz Eksen’in yaklaşımı
İkiz Eksen, ERP entegrasyonlarını kurarken e-belge akışını (e-Fatura/e-Arşiv/e-İrsaliye/e-Defter) izole bir modül olarak değil, dijital dönüşüm mimarisinin bir parçası olarak ele alır: veri tek kaynaktan üretilir, entegratöre veya GİB portalına o kaynaktan akar, güncelleme geldiğinde tek noktadan test edilir. Microsoft Azure altyapısı üzerinde kurduğumuz projeler, Qera’dan gelen 550+ müşteri ve 100+ ERP entegrasyonu birikimiyle Türkiye genelinde anahtar teslim yürütülür.
Mevcut e-fatura/ERP entegrasyonunuzun Eylül güncellemesine hazır olup olmadığını birlikte gözden geçirebiliriz. Çözüm odaklarımıza göz atın ya da doğrudan bize ulaşın — mevcut kurulumunuzu konuşalım.
Sıkça Sorulan Sorular
14 Eylül 2026 güncellemesi kimi kapsıyor?
e-Fatura, e-Arşiv Fatura ve UBL-TR kod listelerini kullanan tüm mükellefleri ilgilendiriyor — hem GİB portalı üzerinden hem özel entegratör/entegrasyon üzerinden fatura kesenler. Kapsamınızın tam olarak nasıl etkilendiğini entegratörünüzden veya GİB’in teknik kılavuzlarından teyit edin.
ERP’m entegratör üzerinden çalışıyor, benim bir şey yapmama gerek var mı?
Entegratör teknik güncellemeyi genelde kendi tarafında uygular, ancak ERP’nizde tanımlı kod listeleri (birim, vergi türü, para birimi gibi) hâlâ sizin sorumluluğunuzdadır. Entegratörün “biz güncelledik” demesi, ERP tarafındaki eski tanımların otomatik düzeleceği anlamına gelmez.
Güncellemeyi kaçırırsam ne olur?
En sık görülen sonuç fatura reddi veya hatalı XML nedeniyle işlem gecikmesidir. Ceza riski, hangi yükümlülüğün ihlal edildiğine göre değişir; kesin sonuç için mali müşavirinize veya GİB’in ilgili duyurusuna bakın.
e-Defter de bu güncellemeden etkileniyor mu?
Doğrudan bu iki duyuru e-Defter’i kapsamıyor, ama e-Defter aynı UBL-TR altyapısını paylaştığı için ekosistemdeki değişiklikleri ayrı takip etmekte fayda var. e-Defter’in kendi zorunluluk ve format takvimi resmî GİB duyurularından teyit edilmeli.
Küçük bir işletmeyim, ERP’m bile yok; bu yazı beni ilgilendirir mi?
Evet, dolaylı olarak. Kullandığınız e-fatura/e-arşiv yazılımı (muhasebe programı veya entegratör paneli) bu güncellemeyi arka planda uygular. Yine de yazılımınızın 14 Eylül’e hazır olduğunu sağlayıcınızdan yazılı teyit almanız, olası bir kesinti anında elinizde kanıt bulunması açısından faydalıdır.
Bu tür güncellemeleri ERP yenileme veya değiştirme kararı için gerekçe sayabilir miyim?
Tek başına bir şema güncellemesi ERP değişikliği için yeterli sebep değildir. Ancak aynı sistemde tekrarlayan entegrasyon sorunları, elle yapılan kod listesi düzeltmeleri ve güncellemeleri takip eden kişinin belirsiz olması bir arada görülüyorsa, bu genellikle daha köklü bir mimari sorunun belirtisidir. O noktada ERP entegrasyonu tarafını uçtan uca değerlendirmek mantıklı olur.