Üç belgeyi ayıran şey vergi mevzuatı değil, UBL-TR'de karşılık geldikleri doküman tipidir. e-Arşiv Fatura bir Invoice'tır ve ProfileID alanına EARSIVFATURA yazılır. e-İrsaliye bir DespatchAdvice'tır ve kendi zorunlu alan kümesi vardır. e-Müstahsil Makbuzu ise fatura değil, UBL-TR CreditNote'tur; CreditNoteTypeCode alanına MUSTAHSILMAKBUZ, ProfileID alanına EARSIVBELGE yazılır. Bu üçünü aynı fatura sınıfından türetmeye çalışan her veri modeli, GİB'in şema ve şematron kontrollerinde takılır.
e-Fatura ile e-Arşiv arasındaki temel ayrımı, UBL-TR'nin genel yapısını ve entegratör seçimini GİB e-Fatura ve e-Arşiv API Entegrasyonu yazımızda ele almıştık. Bu yazı oradan devam ediyor: sevk ve üreticiden alım belgeleri, rapor yükümlülükleri ve iptal/itiraz sistemi.
Hangi Belge Ne Zaman Düzenlenir
Karar, ticari olayın türüne bağlıdır. Tutara değil, tarafa değil, olaya.
| Ticari olay | Belge | Kritik ayrıntı |
|---|---|---|
| e-Fatura kayıtlı mükellefe satış | e-Fatura | GİB üzerinden karşı tarafa iletilir |
| e-Fatura kayıtlı olmayan mükellefe veya nihai tüketiciye satış | e-Arşiv Fatura | Alıcıya kâğıt veya elektronik iletilir, GİB'e rapor olarak gider |
| Malın fiziksel sevki | e-İrsaliye | Fiili sevkten önce düzenlenmesi ve iletilmesi zorunlu |
| Vergiden muaf çiftçiden zirai ürün alımı | e-Müstahsil Makbuzu | Belgeyi alıcı düzenler; UBL-TR CreditNote yapısındadır |
Sık karıştırılan iki durum: e-Arşiv Fatura ile e-İrsaliye birbirinin alternatifi değildir, bir satışta ikisi de gerekebilir. e-Müstahsil Makbuzu ise bir fatura türü değildir; müstahsil makbuzunun elektronik hâlidir ve kâğıt müstahsil makbuzuyla aynı hukuki niteliğe sahiptir.
GİB'in e-Arşiv Hakkında sayfası, uygulamaya dâhil olmayan mükellefler için 01/01/2020'den itibaren geçerli eşikleri şöyle veriyor: düzenlenecek faturaların vergiler dâhil toplam tutarının 30 bin TL'yi (vergi mükelleflerine düzenlenenlerde vergiler dâhil 5 bin TL'yi) aşması hâlinde belge e-Arşiv Fatura olarak, Başkanlığın e-Belge düzenleme portalı üzerinden düzenlenir. Bu tutarlar tebliğ değişiklikleriyle güncellenebildiği için, eşiği koda gömmek yerine konfigürasyondan okuyun.
Üç Belge, Üç Farklı UBL Doküman Tipi
| e-Arşiv Fatura | e-İrsaliye | e-Müstahsil Makbuzu | |
|---|---|---|---|
| UBL kök tipi | Invoice | DespatchAdvice | CreditNote |
| ProfileID | EARSIVFATURA | Kullanılan senaryo | EARSIVBELGE |
| Tip kodu alanı | InvoiceTypeCode | DespatchAdviceTypeCode | CreditNoteTypeCode = MUSTAHSILMAKBUZ |
| Kalem elemanı | InvoiceLine | DespatchLine | CreditNoteLine |
| İmza standardı | XAdES-BES (belge), PAdES (özel izinli PDF) | Mali mühür / NES | XAdES-BES |
| Karşı taraf yanıtı | Yok | İrsaliye Yanıtı (kabul / kısmi kabul / red) | Yok |
Tablodaki son satır, yazılım mimarisi açısından en önemli olanıdır. e-İrsaliye çift yönlü bir belgedir; diğer ikisi tek yönlü. Bu, e-İrsaliye için bir durum makinesi ve gelen yanıtları dinleyen bir kuyruk yazmanız gerektiği anlamına gelir.
e-Arşiv'de Asıl İş Belge Değil, Rapor
e-Arşiv Fatura, e-Fatura gibi merkezî bir platform üzerinden karşı tarafa iletilmez. Alıcıya sizin ilettiğiniz, GİB'e ise rapor olarak gönderdiğiniz bir belgedir. Ekiplerin efor tahmininde en çok yanıldığı yer burasıdır: belge üretmek işin yarısıdır, rapor hattı diğer yarısı.
GİB'in Ağustos 2025 tarihli e-Arşiv Kılavuzu (sürüm 1.18) rapor yükümlülüğünü net tanımlıyor. Portal dışındaki yöntemleri kullanan mükellefler ve izin almış özel entegratörler, raporları günlük dönemler hâlinde ve en geç izleyen günün sonuna kadar e-Arşiv uygulaması üzerinden göndermek zorundadır. SARJANLIK fatura tipindeki e-Arşiv faturalar için rapor, faturanın düzenlenmesinin hemen ardından anlık olarak gönderilir.
Gönderim servisinin üç metodu ve gerçek limitleri
Test WSDL : https://test.efatura.gov.tr/earsiv/services/EArsivWsPort?wsdl
sendDocumentFile(fileName, dataHandler) // dosya adı UUID formatında, içerik zip
getBatchStatus(paketID) // paket durum sorgulama
getUserList(XML | CSV) // kullanıcı listesi
Kılavuzun verdiği kısıtlar, mimarinizi doğrudan şekillendirir:
- Zip dosyasının açık boyutu en fazla 100 MB olmalıdır. Aşıyorsa rapor bölünür. Yüksek hacimli bir e-ticaret operasyonunda bu bölme mantığını sonradan eklemek pahalıdır.
- Dosya adı 36 karakter +
.zip, toplam 40 karakter olmalıdır. Kod009tam olarak bu kuralı ihlal ettiğinizde döner. - Zip içinde aynı isimde tek bir XML bulunmalıdır. Birden fazla dosya koyarsanız kod
153alırsınız. - Raporlar XAdES-A standardıyla, zaman damgalı olarak imzalanır. Belge imzasında kullanılan XAdES-BES ile karıştırmayın; ikisi farklı işlerdir.
- Web servis güvenliği WSS ile sağlanır; SOAP mesajındaki
TimeStampveBodyblokları imzalanır, imza anahtarı tanımlayıcısıDirectReferenceolmalı ve imza algoritmasırsa-sha256kullanılmalıdır.
Birim kodu kuralı: v1.18 ile daralan bir alan
Kılavuzun açık kuralı şu: e-Arşiv kapsamında düzenlenen faturalarda, e-Fatura uygulamasında kullanılan birim kodlarından farklı birim kodları kullanılır. Ayrıca internet üzerinden yapılan satışlar için, diğer satışlardan ayrı bir birim kod belirlenmesi gerekir. Ağustos 2025'te yayımlanan 1.18 sürümü buna bir kısıt daha ekledi: GIB birim kodu yalnızca portal kullanıcıları tarafından kullanılabilir; yetkilendirilmiş özel entegratörler ve entegrasyon kullanıcıları bu kodu kullanamaz.
Aynı sürüm rapor şemasına faturaUUID, faturaTip ve toplamIskonto alanlarını da ekledi. Rapor şemanızı sabitleyip unutmak mümkün değil; sürüm geçmişini takip eden bir süreç kurun.
Rapor şemasında gözden kaçan iki zorunluluk
İnternet üzerinden satış yapıyorsanız internetSatisBilgi grubu şema kuralları gereği seçimli görünür, ama kılavuz 509 Sıra No.lu Tebliğ uyarınca bu alanları doğru doldurmakla yükümlü olduğunuzu yazıyor. İçindeki webAdresi alanı zorunludur. Aynı mantık abone faturası düzenleyenler için tesisat/hizmet/hat numarası alanında geçerlidir. "Şema seçimli diyorsa göndermeyelim" yaklaşımı burada mevzuata aykırı bir sonuç üretir.
Bir de ozetDeger alanı var: mali mühür ya da nitelikli elektronik sertifika ile imzalanmış faturanın SHA-256 özet değeri, hex formatında. Bu alanı üretmek için imzalanmış belgeyi saklamanız gerekir; imzayı üretip atmak, raporu üretilemez hâle getirir.
e-İrsaliye: Zamanlama Kuralları İşin Kendisi
e-İrsaliye'yi diğer iki belgeden ayıran şey, zaman kısıtlarının şema kadar bağlayıcı olmasıdır. GİB'in Eylül 2022 tarihli e-İrsaliye Uygulama Kılavuzu (sürüm 1.2) şu kuralları koyuyor:
- Belge malın fiili sevk zamanından önce düzenlenmeli ve Başkanlık sistemlerine iletilmelidir.
- Özel entegratör kullanıyorsanız, belgeyi entegratörün sistemine iletmeniz sevkiyatı başlatmak için yeterlidir. Ancak entegratör, imzalama ve Başkanlığa iletimi azami 15 dakika içinde tamamlamak zorundadır.
- Belge üzerinde hem düzenleme tarihi/zamanı hem fiili sevk tarihi/zamanı bulunur. Fiili sevk zamanı düzenleme zamanıyla aynı ya da daha ileri olabilir; kılavuzdaki istisnai hâller dışında daha önce olamaz.
Bu üç kural birlikte okunduğunda ortaya şu çıkıyor: e-İrsaliye üretimi bir gece toplu işi olamaz. Sevkiyat operasyonunun içine, gerçek zamanlı çalışan bir bileşen olarak girmek zorundadır. Lojistik tarafındaki genel yaklaşımımızı lojistik ve kargo sayfasında, taşıyıcı API'leriyle ilişkisini kargo entegrasyonu yazımızda bulabilirsiniz.
Zorunlu UBL alanları
Kılavuz, UBL-TR İrsaliye 1.2 dokümanında zorunlu olduğu belirtilen alanları tek tek listeliyor:
| UBL alanı | Anlamı |
|---|---|
ProfileID | Kullanılan senaryo |
ID / UUID | Sevk irsaliyesi numarası / evrensel tekil numara |
IssueDate / IssueTime | Düzenleme tarihi ve zamanı |
DespatchAdviceTypeCode | Sevk irsaliyesi tipi kodu |
Signature | Mali mühür / imza |
DespatchSupplierParty | Sevkiyatı sağlayan taraf |
DeliveryCustomerParty | Malları teslim alan taraf |
Shipment / ShipmentStage | Gönderi; taşıyıcı plaka ve şoför bilgisi burada |
Delivery | Taşıyıcı firma, fiili sevk tarihi, asıl teslim tarihi |
DespatchLine | İrsaliye kalemleri |
Kılavuzun uyarısı sert: zorunlu alanlar eksikse belge şema-şematron kontrollerinden geçemez ve düzenlenen belge geçersizdir. Plaka ve şoför bilgisini "sonra ekleriz" diye boş bırakmak, sevkiyatı durduran bir hatadır.
İrsaliye Yanıtı: 7 gün, üç sonuç, bir istisna
e-İrsaliye'nin e-Faturadaki "uygulama yanıtı" karşılığı vardır. Fiili sevk tarihinden itibaren 7 gün içinde alıcı, malların tamamını kabul yanıtıyla kabul edebilir ya da kısmi kabul yanıtıyla bir kısmını kabul edip kalanını reddedebilir.
RED yanıtı ise özel bir durumdur. Kılavuzun ifadesiyle belgenin tamamı reddedilebilir, ancak bu durum sadece fiili sevkten önce ve mal muhteviyatının ya da alıcının hatalı olması hâlinde mümkündür. Bu durum ve süreler dışında yapılan retler hükümsüzdür.
Mal kabul edilmez ya da alıcıya ulaşılamazsa, malın geri getirilmesi veya başka bir alıcıya sevki için yeni bir e-İrsaliye düzenlenmesi zorunludur. Teknik imkânsızlık nedeniyle o lokasyonda düzenlenemiyorsa, üzerinde "e-İrsaliyeye Dönüştürülecektir" ibaresi, taşıyıcı ve plaka bilgisi bulunan matbu sevk irsaliyesi kullanılır; bu belge en geç izleyen gün içinde MATBUDAN türünde e-İrsaliye olarak düzenlenir.
Son bir not: irsaliye yanıtı düzenlemek zorunluluk değildir, mükellefe sunulan bir imkândır. Ticari akışınızı "alıcı mutlaka yanıt verir" varsayımı üzerine kurmayın.
e-Müstahsil Makbuzu Bir Fatura Değildir
GİB'in Ocak 2018 tarihli UBL-TR Müstahsil Makbuzu kılavuzu, belgeyi CreditNote şeması üzerine kuruyor. Bu, veri modelinizde faturadan ayrı bir varlık gerektirir. Ana elemanlar arasında dikkat çekenler:
ProfileID=EARSIVBELGE,CreditNoteTypeCode=MUSTAHSILMAKBUZ.AccountingSupplierPartymakbuzu yazan taraftır,AccountingCustomerPartyise üretici/çiftçidir. Fatura mantığından gelen "supplier satıcıdır" alışkanlığı burada yanlış eşleme üretir.IDalanı üç haneli alfanümerik birim kod ile 13 haneli müteselsil numaranın birleşimidir. Müteselsil numaranın ilk dört hanesi düzenlendiği yılı gösterir. Örnek:GIB2016000000001.UBLExtensionsalanında XAdES formatında mali mühür/elektronik imza bilgisi bulunur ve bu alan zorunludur (kardinalite 1..1).
e-Arşiv Kılavuzu, aynı CreditNote yapısının e-Adisyon belgesi için de kullanıldığını belirtiyor. Yani "CreditNote = iade faturası" varsayımıyla yazılmış bir ayrıştırıcı, Türkiye'de üç farklı belgeyi yanlış sınıflandırır.
Burası Kırılıyor: İptal ve İtiraz Artık Ayrı Bir Sistem
2021'de değişen ve pek çok ERP entegrasyonunun hâlâ eksik uyguladığı kısım burası. 526 Sıra No.lu Vergi Usul Kanunu Genel Tebliğiyle, 509 Sıra No.lu Tebliğe "V.10. e-Belgelere İlişkin İptal/İtiraz, İhbar ve İhtarların Bildirilmesi" bölümü eklendi. Buna göre, Türk Ticaret Kanunu'nun 18/3 maddesi uyarınca noter, taahhütlü mektup, telgraf veya güvenli elektronik imzalı KEP ile yapılan ihbar ve ihtarlar ile e-Belge iptal işlemleri, 1/5/2021 tarihinden itibaren elektronik ortamda GİB sistemine bildirilmek zorundadır.
Bu değişikliğin ikinci ayağı muhasebe tarafında: 523 Sıra No.lu Tebliğ ile Temmuz 2021 döneminden itibaren e-Belgeler Ba ve Bs formlarına dâhil edilmiyor. Bunun yerine GİB, e-Belge veri tabanı üzerinden "sanal BA" ve "sanal BS" formları üretiyor. Yani iptal/itiraz bildirimini yapmamak artık sadece bir usul eksiği değil, doğrudan mükellefin vergi analizindeki görünümünü değiştiren bir durum.
Süre kuralı ve asimetrik sonuç
Ocak 2025'te yayımlanan İptal, İhtar/İtiraz Bildirim Kılavuzu (sürüm 1.1) itiraz talebinin kabul süresini değiştirdi. Güncel kural şu:
| Senaryo | Alıcının sanal BA'sı | Satıcının sanal BS'i |
|---|---|---|
| İptal talebi onaylandı | Belge yer almaz | Belge yer almaz |
| İptal talebi reddedildi | Belge yer alır | Belge yer alır |
| İtiraz, izleyen ayın 15'ine kadar kabul edildi | Belge yer almaz | Belge yer almaz |
| İtiraz süresinde onaylanmadı ya da reddedildi | Belge yer almaz | Belge yer alır |
Son satır, sistemin en çok gözden kaçan davranışıdır. İtirazı süresinde cevaplamayan satıcı, alıcının formunda görünmeyen ama kendi formunda görünen bir belgeyle kalır. Bu uyumsuzluk, sonradan açıklanması gereken bir fark üretir. Bu yüzden gelen iptal/itiraz taleplerini izleyen bir işiniz olmalı ve bu iş aylık değil, günlük çalışmalıdır.
Entegrasyon ve özel entegrasyon yöntemini kullanan mükellefler, düzenledikleri belgeler için iptal talebini portaldan değil, Başkanlığa gönderecekleri İptal Raporu ile iletir. Bu yol kullanıldığında satıcı tarafında portalda ayrıca yapılacak bir işlem yoktur, ama alıcı yine portal üzerinden kabul veya red işlemi yapabilir.
Bir de ticaret hukuku tarafındaki saat işliyor: TTK'nın 21/2 maddesi uyarınca "Bir fatura alan kişi aldığı tarihten itibaren sekiz gün içinde, faturanın içeriği hakkında bir itirazda bulunmamışsa bu içeriği kabul etmiş sayılır." Sekiz günlük bu süre GİB'in bildirim sisteminden bağımsızdır; ikisini aynı takvimde izleyin.
Hata Kodlarını Baştan Eşleyin
e-Arşiv rapor gönderiminde alacağınız kodlar kılavuzda tanımlı. Bunları destek ekibinizin anlayacağı mesajlara baştan eşlerseniz, üretimdeki ilk yoğun günü çok daha sakin geçirirsiniz.
| Metot | Kod | Açıklama |
|---|---|---|
getBatchStatus | 10 / 15 / 30 | Dosya kuyrukta / işlenmeye başlandı / başarıyla işlendi |
150 | Aynı paket ID | |
153 | Pakette birden fazla dosya var | |
154 / 159 | İmza doğrulanamadı / imza bulunamadı | |
157 | XML validasyon hatası | |
165 | Maksimum dosya boyutu hatası | |
167 | İmza sahibi ile hazırlayan VKN/TCKN uyuşmuyor | |
sendDocument | 000 | Dosya kaydedildi |
004 | Paket daha önceden gönderilmiş | |
009 / 010 | Dosya adı 36 + .zip = 40 karakter olmalı / uzantı zip olmalı |
Kod 004 özellikle değerlidir: paketin daha önce gönderildiğini söyler, yani yeniden deneme mantığınız için doğal bir idempotency sinyalidir. Bunu hata sayıp alarm üretmek yerine, "zaten gönderilmiş" olarak işaretleyin.
Kapsam Kararı: Hangi Belgeyi Ne Zaman Projeye Alırsınız
| İşletmeniz | İlk fazda | Neden |
|---|---|---|
| Nihai tüketiciye satan e-ticaret | e-Arşiv + günlük rapor + iptal/itiraz takibi | Hacim buradadır; iade oranı yüksek olduğu için iptal akışı ilk günden gerekir. |
| Bayi ağına fiziksel mal sevk eden üretici | e-İrsaliye + irsaliye yanıtı dinleyicisi | Sevk öncesi gönderim kuralı operasyonu durdurabilir; gerçek zamanlı olmalı. |
| Hal kayıt sistemine bildirim yapan komisyoncu | e-İrsaliye ve e-Müstahsil birlikte | 509 SN Tebliğ bu grubu her iki uygulamaya da dâhil etmiştir. |
| Yalnızca kurumsal müşteriye hizmet satan şirket | e-Fatura; e-Arşiv ikinci fazda | Fiziksel sevk yoksa e-İrsaliye kapsam dışıdır. |
Bu belgeleri mevcut ERP'nizle birlikte kurgulamak isterseniz ERP entegrasyonları sayfamıza, e-ticaret tarafındaki yaklaşımımız için e-ticaret ve perakende sayfamıza bakabilirsiniz.
Sırada Ne Var
Kapsamınızı netleştirmek için yapılacak ilk iş bir envanter: son 12 ayda kestiğiniz belgeleri tipine göre sayın, içlerinden kaçının iptal veya itiraza konu olduğunu çıkarın ve fiziksel sevk içeren sipariş oranınızı hesaplayın. Bu üç sayı, hangi belgenin ilk fazda olacağını ve iptal/itiraz otomasyonunun sizin için kritik olup olmadığını tek başına söyler.
Ardından teknik tarafta tek bir karar kalır: raporu ve belgeyi üreten kodu aynı yere mi koyacaksınız, ayrı mı? Ayrı koyun. Belge üretimi işlem anında, rapor üretimi gün sonunda çalışır ve ikisinin hata yolları birbirine benzemez.
Bu yazıdaki alan adları, kodlar, süreler ve limitler 25 Eylül 2026 tarihinde Gelir İdaresi Başkanlığı'nın resmî kılavuzlarından doğrulanmıştır: e-Arşiv Kılavuzu v1.18 (Ağustos 2025), e-İrsaliye Uygulama Kılavuzu v1.2 (07.09.2022), UBL-TR Müstahsil Makbuzu v1.0 (04.01.2018), e-Arşiv Uygulamaları İptal, İhtar/İtiraz Bildirim Kılavuzu v1.1 (Ocak 2025) ve ebelge.gib.gov.tr üzerindeki e-Arşiv, e-İrsaliye ve e-Müstahsil tanıtım sayfaları. Tebliğ ve kılavuzlar güncellenir, tutar eşikleri değişebilir; üretime çıkmadan önce ilgili kılavuzun son sürümünü teyit edin.