e-Fatura'da Asıl Belge Hangisi: XML mi, PDF mi?

Kısa cevap: e-Fatura'da belge, mali mühür veya nitelikli elektronik imza taşıyan UBL-TR biçimindeki XML dosyasıdır. Ekranda gördüğünüz fatura sayfası, e-postaya eklenen PDF ve kâğıt çıktı bu dosyanın görüntüsüdür. e-Arşiv faturada ise tablo biraz farklıdır, çünkü mevzuat alıcıya hangi yolla teslim edildiğine göre "asıl" nüshayı tanımlar. İki durumu ayırmadan arşiv düzeni kurmak, yıllar sonra bir incelemede elde yalnızca PDF kalmasıyla sonuçlanabilir.

509 sıra no.lu Tebliğ ne diyor

e-Belgelerin temel düzenlemesi Vergi Usul Kanunu Genel Tebliği (Sıra No: 509)'dur. Tebliğin "Belgelerin Elektronik Ortamda Oluşturulması" bölümü, e-Belgelerin yeni bir belge türü olmadığını, kâğıt belgelerle aynı hukuki niteliği taşıdığını söyler ve kullanılan formatın "üzerinde mali mühür/NES taşımaya, belge üzerinde doğrulamaya, görüntülemeye ve kâğıt baskı almaya imkân veren" bir format olmasını şart koşar. Bu cümlede sıralama önemlidir: görüntüleme ve baskı, formatın sağlaması gereken imkânlardan biridir; belgenin kendisi değildir.

e-Fatura için hüküm daha da açıktır. Tebliğe göre GİB'in ebelge.gib.gov.tr adresinde duyurduğu format ve standartlara uygun düzenlenmeyen ya da düzenlense bile e-Fatura uygulaması aracılığıyla gönderilmeyen veya alınmayan belge, e-Fatura hükmünde değildir. Yani bir PDF, içeriği birebir aynı olsa da, sistemden geçen elektronik belgenin yerini tutmaz.

Saklama tarafında Tebliğin "Muhafaza ve İbraz Yükümlülüğü" bölümü gerekçeyi de verir: elektronik imzanın ve mali mührün doğruluk ve geçerlilik kontrolü ancak elektronik ortamda yapılabildiği için düzenleyicinin e-Belgeyi kâğıda basarak saklaması söz konusu değildir. Düzenleyen, belgeyi mali mühür veya imzayla birlikte elektronik ortamda saklar. Alıcı ise belge kendisine elektronik iletildiyse aynı şekilde imzasıyla birlikte elektronik ortamda, kâğıt teslim edildiyse kâğıt olarak saklar.

e-Arşiv faturada "asıl" neye göre belirlenir

e-Arşiv fatura, e-Fatura sistemine kayıtlı olmayan alıcılara düzenlenir ve GİB sistemi üzerinden alıcıya iletilmez. Tebliğin e-Arşiv bölümüne göre faturanın alıcıya talebi doğrultusunda kâğıt olarak gönderilen veya elektronik ortamda iletilen şekli belgenin aslıdır; düzenleyenin sakladığı elektronik hâl ise ikinci nüsha hükmündedir. Elektronik iletimde satıcının e-Fatura format ve standardını (ya da GİB'in izin verdiği başka bir formatı) kullanması ve faturanın basılabilir görüntüsünü de eklemesi gerekir.

Bu yüzden e-postayla gelen bir e-Arşiv faturada XML ile görüntü birlikte anlam taşır. Kâğıt çıktı aldığınız bir alışverişte ise elinizdeki kâğıt asıl nüshadır ve GİB'in 509 sayılı Tebliğe ilişkin sık sorulan sorular dokümanı da bu durumda kâğıt ortamda saklamayı söyler.

Faturanın görüntüsü nereden geliyor

UBL-TR XML'i makine için yazılmış bir veri dosyasıdır: fatura numarası ID, ETTN UUID, senaryo ProfileID, satırlar InvoiceLine, ödenecek tutar LegalMonetaryTotal altında durur. Bu verinin insan gözüne fatura gibi görünmesini XSLT denen bir dönüşüm şablonu sağlar. GİB'in UBL-TR Ortak Elemanlar kılavuzu, faturaya eklenen belgelerin türü için DocumentType alanına örnek olarak "XSLT" değerini sayar; ek dosya da AdditionalDocumentReference içindeki EmbeddedDocumentBinaryObject alanına base64 olarak gömülür.

GİB'in E-Fatura Görüntüleyici kullanım kılavuzu şablonun rolünü net anlatır: XML'in XML görünümü dışında görüntülenebilmesi için fatura içinde XSLT bulunmalıdır. Gönderen şablon koymamışsa program GİB'in varsayılan XSLT'siyle göstermeyi önerir; şablon hatalıysa bunu bildirir. Yani iki farklı programda aynı faturanın iki farklı görünümü olması normaldir.

Görüntü neden XML'den farklı olabilir

XSLT bir belge değil, bir programdır. Satıcının ya da entegratörün hazırladığı şablon, XML'deki bir alanı hiç göstermeyebilir, tutarları yuvarlayabilir, sabit metin basabilir ya da hatalı bir yol ifadesi yüzünden yanlış düğümü okuyabilir. Örnek bir senaryo: tevkifatlı bir faturada şablon WithholdingTaxTotal bölümünü göstermiyorsa görüntüdeki "ödenecek tutar" ile XML'deki PayableAmount farklı görünebilir. Bu kasıtlı olmak zorunda değildir; eski bir şablonun yeni fatura tipleriyle güncellenmemesi yeterlidir.

PDF ayrıca üçüncü bir katmandır. Portal veya entegratör PDF'i XML'den üretir, ama PDF dosyasının içinde imza doğrulaması yapılabilecek bir e-Fatura yapısı bulunmaz. e-Posta ekinde dolaşan bir PDF'in sonradan düzenlenmiş olup olmadığını dosyanın kendisinden anlamak zordur. Faturanın sağ üst köşesindeki karekod da işe yarar bir karşılaştırma noktasıdır: GİB'in Karekod Standardı Kılavuzu'na göre karekodda VKN, senaryo, tarih, fatura numarası, ETTN ve ödenecek tutar gibi alanlar bulunur. Ancak karekod da görüntünün parçasıdır, imza değildir.

Arşivlemede pratik sonuçlar

Bizim önerdiğimiz düzen şudur. Faturayı portal ya da entegratörden aldığınız hâliyle, tek bir baytını değiştirmeden saklayın. XML'i "düzgün görünsün" diye bir editörde girintileyip kaydetmeyin: imza, belgenin belirli bir biçimi üzerinden hesaplandığı için boşluk ve satır değişiklikleri doğrulamayı bozabilir. Dosya adında ETTN'yi kullanmak aynı numaralı iki faturanın karışmasını önler. PDF'i atmayın ama onu kolay okuma kopyası olarak görün; ikisi aynı klasörde durabilir.

Ticari fatura senaryosunda uygulama yanıtları da arşivin parçasıdır. GİB'in UBL-TR Ticari Fatura Senaryosu kılavuzu, reddedilen faturanın değiştirilmeden red uygulama yanıtıyla birlikte yasal saklama süresi boyunca muhafaza edileceğini söyler. Kabul yanıtı için de satıcının yanıtı faturayla birlikte saklaması öngörülür. Entegratörden ZIP içinde toplu indirme yapıyorsanız arşivi olduğu gibi saklayın, açmak için ZIP görüntüleyiciyi kullanın. Ne kadar süre saklanacağını saklama süresi yazısında VUK ve TTK hükümleriyle ayrıca anlattık.

Uyuşmazlıkta hangi dosyaya bakılır

Satıcıyla tutar ya da kalem üzerine anlaşmazlık çıktığında ilk iş, iki tarafın elindeki XML'lerin aynı ETTN'yi taşıyıp taşımadığına bakmaktır. Aynıysa tartışma artık görüntü üzerinde değil veri üzerindedir: hangi satır, hangi miktar, hangi vergi. Farklıysa ortada iki ayrı belge vardır ve hangisinin sistemden geçtiği sorusu öne çıkar. Bir belgenin mahkemede nasıl değerlendirileceği somut olaya ve bilirkişi incelemesine bağlıdır; bu konuda genel bir hüküm vermek doğru olmaz.

Teknik kontrol için iki farklı araç türü vardır. GİB'in E-Fatura Görüntüleyici kılavuzu, programdaki "Doğrula" düğmesinin mali mühür sonucunu, "Sorgula" düğmesinin ise faturanın GİB sisteminden geçip geçmediğini ve alıcının sistem üzerinden red verip vermediğini gösterdiğini anlatır; aynı kılavuz harici yollarla yapılmış itirazların bu programda görünmediğini de not eder. Program Java tabanlıdır ve güncel bilgisayarlarda çalıştırmak ek kurulum isteyebilir.

Tarayıcıdaki e-Fatura XML görüntüleyici farklı bir işe yarar: gömülü XSLT'yi çalıştırmaz, alanları doğrudan XML'den okuyup her faturada aynı tablo düzeninde gösterir. Bu yüzden elinizdeki PDF'i ekranın yanına koyup satır satır karşılaştırmak için uygundur; şablonun gizlediği bir tevkifat satırı veya not burada görünür. Dosyada imza yapısı varsa araç bunu belirtir, ama imzanın geçerli olup olmadığına ve belgenin sahte olup olmadığına karar vermez. Ham etiketleri görmek isterseniz XML görüntüleyiciyi, alanların anlamı için e-Fatura XML okuma rehberini kullanabilirsiniz. Bir e-Arşiv faturanın GİB kaydını nasıl sorgulayacağınızı e-Arşiv doğrulama yazısında anlattık.

Kısa kontrol listesi

• Faturanın senaryosuna bakın: ProfileID değeri EARSIVFATURA ise e-Arşiv kurallarına, TEMELFATURA veya TICARIFATURA ise e-Fatura kurallarına göre saklayın.
• e-Fatura için imzalı XML'i özgün hâliyle, e-Arşivde ise size hangi yolla ulaştıysa o nüshayı saklayın.
• PDF ile XML arasında tutar, vergi ve satır sayısını karşılaştırın; fark varsa XML'i esas alın ve satıcıya bildirin.
• Ticari senaryoda uygulama yanıtlarını faturayla aynı yerde tutun.

Bu yazı genel bilgilendirme amaçlıdır; kendi saklama ve ibraz yükümlülükleriniz için mali müşavirinize danışın.