e-Belge Paketleri Güncellendi: ERP ve Entegrasyon Tarafında Ne Yapmalı?
GİB e-Fatura, e-Arşiv ve UBL-TR paket güncellemeleri 14 Eylül 2026'da devreye giriyor. Şema sürümü, kod listeleri, test ortamı ve ERP tarafında yapılacaklar.
Bir fabrikanın mali işler sorumlusu, entegratöründen kısa bir e-posta alıyor: "Yeni paket yayımlandı, 14 Eylül'de devreye alınacak." Cümle teknik, muhatabı belirsiz ve çoğu şirkette aynı yere gidiyor: gelen kutusunda bekleyen bir e-posta. Sonra bir gün, sistemin daha önce sorunsuz kestiği bir fatura reddediliyor ve iş sevkiyatı bekletmeye kadar uzanıyor.
Gelir İdaresi Başkanlığı'nın e-Belge portalında yayımlanan duyurulara göre e-Fatura, e-Arşiv ve UBL-TR paketleri 2026 yazında güncellendi; duyuruda güncellemelerin 14.09.2026 tarihi itibarıyla devreye alınacağı belirtildi. Temmuz sonunda yayımlanan paketlerin ardından Ağustos ayında hem e-Arşiv hem e-Fatura paketlerinde eksiklikler giderilerek güncel sürümler yayımlandı.
Bu yazı, böyle bir güncellemenin ERP ve entegrasyon tarafında ne anlama geldiğini, "entegratör hallediyor" cümlesinin nerede doğru nerede yanıltıcı olduğunu ve fabrikanızın hangi kontrolleri kendi tarafında yapması gerektiğini anlatıyor. Güncel paket sürümü ve tarihleri için her zaman ebelge.gib.gov.tr üzerindeki duyuruları esas alın; bu sayfadaki tarihler yazının yayımlandığı tarihteki duyuruları yansıtıyor.
"Paket" Tam Olarak Nedir?
e-Belge paketleri; belgelerin XML yapısını tanımlayan şema dosyalarını (XSD), kod listelerini ve uygulama kılavuzlarını içerir. Kestiğiniz her fatura, bu şemaya göre doğrulanır. Şema değiştiğinde sizin gönderdiğiniz belgenin biçimi de o tanıma uymak zorundadır.
Değişiklikler genellikle üç yerde olur:
- Şema (XSD). Yeni alanlar eklenir, bazı alanların zorunluluğu veya biçimi değişir.
- Kod listeleri. Birim kodu, vergi kodu, ülke kodu, senaryo ve tip tanımları gibi listelerde eklemeler ve düzeltmeler yapılır.
- Kılavuz. Alanların nasıl doldurulacağına dair açıklamalar netleşir; çoğu zaman en az okunan ama en çok soruna yol açan parça budur.
Bir güncelleme çoğu firmada hiçbir şeyi bozmaz. Sorun çıkardığı yer neredeyse her zaman aynıdır: standart dışı doldurulan alanlar. Yıllardır "çalıştığı için" öyle bırakılmış bir birim kodu ya da açıklama alanına sıkıştırılmış bir bilgi, kural sıkılaştığında reddedilir.
"Entegratör Hallediyor" Nerede Doğru, Nerede Değil?
e-belge akışı üç katmandan geçer ve sorumluluk her katmanda farklıdır.
| Katman | Ne yapar | Sorumluluk kimde |
|---|---|---|
| ERP veya muhasebe yazılımı | Belgenin içeriğini üretir: kalemler, kodlar, tutarlar, senaryo | Sizde |
| Entegratör veya özel entegratör | Belgeyi taşır, şemaya göre doğrular, GİB ile iletişimi yürütür | Hizmet sağlayıcıda |
| GİB | Kuralı ve şemayı tanımlar, belgeyi kabul veya reddeder | Kurumda |
Entegratörünüz taşıma ve doğrulama katmanını günceller; bu kısım gerçekten onların işidir. Ama belgenin içeriğini üreten sizsiniz. Şema yeni bir alan zorunlu kıldığında ya da bir kod listesi değiştiğinde, o alanı dolduracak veriyi ERP'niz üretmek zorundadır. Entegratör, olmayan bir veriyi sizin adınıza uyduramaz.
Bu ayrım özellikle özel geliştirilmiş ERP'lerde ve eski sürümde kalmış paket programlarda kritik. ERP yazılımı tarafındaki eşlemeler bir kez kurulup unutulduğu için, değişimin farkına çoğu zaman ilk reddedilen belgeyle varılır.
Devreye Alma Öncesi Kontrol Listesi
Bir güncelleme duyurusu geldiğinde, teknik ekibin bir gün içinde yapabileceği kontroller şunlar:
- Test ortamında bir tur atın. Gerçek hayattaki en karmaşık üç belgenizi test ortamında yeni pakete karşı geçirin: ihracat faturası, iskontolu ve çok kalemli bir satış, iade veya tevkifatlı bir belge. Rutin faturanız zaten geçer; asıl risk istisnalardadır.
- Kod listesi eşlemelerini gözden geçirin. Birim kodları, vergi ve muafiyet kodları, ülke kodları. Bu eşlemelerin ERP'de nerede tutulduğunu bilen bir kişi olmalı ve bu kişi izinde olduğunda da erişilebilir olmalı.
- Reddedilen belge kuyruğunu görünür yapın. Reddedilen bir belge sessizce bir tabloda birikiyorsa, sorun ancak müşteri aradığında öğrenilir. Reddedilen belgelerin bir ekranda, sorumlusuyla birlikte görünmesi gerekir.
- Gelen belge tarafını unutmayın. Çoğu entegrasyon giden fatura üzerine kurulur; gelen e-fatura ve e-irsaliyenin ERP'ye otomatik düşmesi ise yıllarca elle yapılan bir işe bırakılır. Güncelleme, bu eksiği gözden geçirmek için iyi bir vesiledir.
- Arşiv ve saklama. Belgelerinizin yasal saklama süresi boyunca erişilebilir olduğundan emin olun. Arşivin tamamının yalnızca entegratörde durması, sözleşme bittiğinde sorun üretir.
- Sürüm notlarını takip eden bir sorumlu. Duyuru sayfasını izleyen bir kişi ve bu bilginin ulaşacağı bir iç kanal olmalı. Bu, bir yazılım işi değil bir düzen işidir.
Üçüncü ve dördüncü maddeler, gördüğümüz aksaklıkların büyük bölümünün kaynağıdır. İkisi de teknik olarak zor değildir; sadece kimsenin sahiplenmediği alanlardır.
Test Ortamı Neden Atlanıyor?
Cevap genellikle şu: test ortamı kurmak ilk seferinde emek ister ve o emek "üretime bir katkısı yok" diye ertelenir. Oysa e-belge tarafında test ortamı, yılda birkaç kez işe yarayan bir sigortadır. Belge örneklerini bir kez hazırlayıp saklamak, her paket güncellemesinde aynı seti tekrar geçirmeyi yarım saatlik bir işe indirir.
Bu, aslında test ve kalite otomasyonunun en somut örneklerinden biri: değişmeyen bir kontrol setini, değişen bir dış kurala karşı tekrar tekrar çalıştırmak.
Daha Geniş Resim: e-Dönüşümün Yönü Tek
Paket güncellemeleri tek başına bakıldığında teknik bir ayrıntı. Birlikte bakıldığında ise bir yön gösteriyor: kâğıt belgenin alanı daralıyor, kapsam genişliyor ve belgeler arası tutarlılık denetimi artıyor. e-Fatura, e-Arşiv, e-İrsaliye ve e-Defter aynı verinin farklı yüzleri hâline geliyor.
Bunun ERP tarafındaki sonucu şu: belgeleri ayrı ayrı üreten değil, tek bir veri modelinden türeten bir yapı gerekiyor. Sevkiyat irsaliyesiyle faturanın farklı yerlerden beslendiği sistemlerde tutarsızlık kaçınılmazdır; ve denetim tarafı artık bu tutarsızlıkları görebiliyor.
Hangi eşiğin sizin için geçerli olduğu, hangi belge türüne ne zaman geçmeniz gerektiği ise vergi mevzuatı sorusudur ve mali müşavirinizle netleştirilmelidir. Eşikler ve kapsam zaman içinde değiştiği için, bu yazıda tutar vermek yerine kaynağa yönlendiriyoruz: güncel tebliğ ve duyurular esastır.
Sık Yapılan Beş Hata
Sahada tekrar tekrar gördüğümüz hatalar, teknik zorluktan değil varsayımdan doğuyor:
- "Muhasebe programı zaten yapıyor" varsayımı. Program belgeyi gönderiyor olabilir; ama gönderilen belgenin içeriğini kimin ürettiği ve reddedilirse ne olduğu ayrı bir sorudur.
- Tek yönlü entegrasyon. Giden fatura otomatik, gelen fatura elle. Bu, tedarikçi mutabakatını ve maliyet kaydını sessizce geciktirir.
- Açıklama alanının veri deposu gibi kullanılması. Yapıya sığmayan bilgi serbest metne yazıldığında, kural sıkılaştığı gün belge reddedilir ya da daha kötüsü, veriyi kimse raporlayamaz.
- Arşivin tamamen dışarıda tutulması. Sözleşme bittiğinde veya sağlayıcı değiştiğinde geçmişe erişim sorun olur.
- Sürüm takibinin kişiye bağlı kalması. Duyuruları izleyen kişi işten ayrıldığında süreç de ayrılır.
Tek Kişiye Bağlı Sistemlerde Ek Risk
Özel yazılım kullanan pek çok fabrikada e-belge entegrasyonunu yıllar önce tek bir geliştirici yazmıştır ve o günden beri kimse dokunmamıştır. Sistem çalıştığı sürece bu bir sorun gibi görünmez. Sorun, dış kural değiştiği gün başlar: değişikliği yapacak kişi ulaşılamıyorsa, kaynak kod elinizde değilse veya kodun nasıl çalıştığını anlatan hiçbir belge yoksa, teknik olarak yarım günlük bir iş haftalara yayılır.
Bu riski ölçmenin basit bir yolu var: entegrasyon kodunun nerede durduğunu, kimin erişebildiğini ve son bir yılda kim tarafından değiştirildiğini sorun. Cevaplar net değilse, paket güncellemesi asıl sorununuz değil demektir. Bu durumdaki sistemleri devralıp sürdürülebilir hâle getirme çalışmalarını mevcut yazılımın devralınması başlığı altında ayrıca ele alıyoruz.
Dürüstlük Sınırı
Vergisel yorum, eşik değerlendirmesi ve mükellefiyet kararı bizim işimiz değil; bunlar mali müşavirinizin alanıdır. Entegratör seçimi de teknik olduğu kadar ticari bir karardır ve tarafsız kalmayı tercih ediyoruz.
Bizim yaptığımız iş, ERP ile entegratör arasındaki katmanı sağlam kurmaktır: verinin doğru üretilmesi, eşlemelerin yönetilebilir olması, hataların görünür hâle gelmesi ve gelen belgelerin sisteme düşmesi. Bu, klasik bir API ve entegrasyon işidir ve bir kez düzgün kurulduğunda her paket güncellemesinde tekrar tekrar değer üretir.
Sonuç
14 Eylül 2026 gibi bir devreye alma tarihi, hazırlıklı bir firma için takvimde işaretlenmiş sıradan bir gün. Hazırlıksız bir firma içinse reddedilen belgelerle, telefon trafiğiyle ve bekleyen sevkiyatla geçen bir hafta. Aradaki farkı yaratan şey yeni bir yazılım değil: test ortamı, sahiplenilmiş eşlemeler, görünür hata kuyruğu ve duyuruları izleyen bir sorumlu.
e-belge akışınızı uçtan uca gözden geçirmek ve ERP tarafındaki eksikleri görmek için bizimle iletişime geçin. İnceleme genellikle en karmaşık üç belgenizle başlar; sistemin gerçek sınırları orada görünür.
İlgili rehberler: