e-Fatura UBL-TR Formatı Nedir? XML Yapısını Anlama Rehberi

UBL-TR formatı, Türkiye'de e-Fatura verilerinin standart XML yapısına dönüştürülmesini sağlayan belge formatıdır. Fatura numarası, taraf bilgileri, kalemler, vergiler, toplamlar, senaryo ve imza gibi bilgiler bu yapı içindeki alanlarda tutulur.

Bu rehber, e-Fatura XML dosyasını okumak isteyen işletme sahiplerine, muhasebe çalışanlarına, yazılım geliştiricilere ve mali müşavirlere yarar. XML alanlarının ne anlama geldiğini, hangi bilgilerin birlikte değerlendirilmesi gerektiğini ve doğrulama hatalarının nasıl araştırılacağını açıklar.

UBL-TR formatı nedir ve e-Fatura XML içinde neyi gösterir?

UBL-TR formatı, UBL belge modelinin Türkiye'deki e-Fatura kurallarına uyarlanmış XML profilidir. UBL, farklı ticari belgelerin bilgisayar sistemleri arasında ortak alanlarla taşınmasını amaçlar. UBL-TR ise bu ortak yapıyı GİB'in e-belge süreçleri, kod listeleri ve teknik kurallarıyla birlikte kullanır.

Bir UBL-TR dosyası, faturanın yalnızca görüntüsünü değil, işlenebilir verisini taşır. Alıcının vergi kimlik bilgisi, ürün miktarı, birim fiyat, KDV oranı ve ödenecek tutar ayrı XML elemanlarında bulunur. Bu ayrım, muhasebe ve ERP yazılımlarının faturayı yeniden yazmadan işlemesine imkân verir.

UBL-TR formatı bir PDF tasarım şablonu değildir. PDF, faturadaki bilgilerin insan tarafından okunabilen görsel sunumudur; UBL-TR XML ise alanların ve değerlerin makine tarafından yorumlandığı asıl veri katmanıdır. Aynı XML, farklı yazılımlarda farklı görsel tasarımlarla gösterilebilir.

UBL-TR dosyasını anlamak, işletmenin e-Fatura mükellefiyetini tek başına belirlemez. Zorunluluk kapsamı sektör, faaliyet ve güncel mevzuata göre ayrıca incelenir; kapsam için e-Fatura zorunluluğu ve sektör bazlı kapsam bilgisini kontrol edin. Güncel GİB duyurusunu ve mali müşavirinizi mutlaka kontrol edin.

XML içindeki alanlar tek başına değil, ilişkili alan gruplarıyla okunmalıdır. Örneğin bir tutarın doğru olup olmadığı, yalnızca PayableAmount değerine bakılarak anlaşılmaz; para birimi, vergi toplamı, iskonto ve satır toplamları da birlikte incelenir.

Bir entegrasyon yazılımı için UBL-TR, alanları belirli bir düzende taşıyan veri sözleşmesi gibi çalışır. İnsan okuyucu için ise bu sözleşmenin hangi alanı temsil ettiğini ve alanlar arasındaki bağlantıyı anlamak gerekir. Bu nedenle dosyayı sadece görsel olarak açmak yeterli değildir.

XML'i okurken bir alanın boş olmasını doğrudan hata kabul etmeyin. Alanın zorunlu olup olmadığı, fatura senaryosu, belge türü ve ilgili teknik kural birlikte değerlendirilmelidir. Emin olunamayan durumlarda güncel GİB teknik kılavuzu ve mali müşavir görüşü esas alınmalıdır.

e-Fatura XML yapısı hangi ana bölümlerden oluşur?

e-Fatura XML yapısı, kök Invoice düğümü altında kimlik, taraf, kalem, vergi, toplam ve referans bölümlerinden oluşur. Her bölüm, belirli bir ticari bilgiyi temsil eden UBL elemanlarını ve bu elemanların değerlerini içerir.

Dosyanın en üstünde yer alan kök yapı, belgenin bir fatura olduğunu belirtir. Namespace tanımları ise elemanların hangi XML sözlüğüne ait olduğunu gösterir. Örneğin cbc öneki temel veri elemanlarını, cac öneki ise ortak ticari bileşenleri ifade eder. Önek adı değişse bile namespace adresi aynı anlamı taşıyabilir.

XML'de aynı bölüm içinde birden fazla eleman bulunabilir. Örneğin farklı KDV oranları, birden fazla TaxSubtotal kaydıyla; birden fazla fatura kalemi ise ayrı InvoiceLine kayıtlarıyla gösterilir. Bu nedenle yalnızca ilk görülen tutarı okumak, toplamı yanlış yorumlayabilir.

XML dosyasını incelerken önce kök yapıyı, sonra belge üst bilgilerini, tarafları ve kalemleri takip edin. Alan sırası çoğu zaman okunabilirliği etkiler; ancak anlamı yalnızca sıradan değil, elemanın adı, namespace'i ve şema kuralları birlikte belirler.

Bir yazılım geliştirirken eleman adlarını sabit metin gibi kabul etmek yerine namespace bilgisiyle eşleştirme yapmak gerekir. Çünkü iki dosyada aynı cbc veya cac öneki kullanılmayabilir. Namespace'i dikkate almayan bir ayrıştırıcı, doğru görünen dosyada bile alan bulamayabilir.

UBL-TR XML içinde fatura numarası ve tarih nasıl okunur?

UBL-TR XML içinde fatura numarası genellikle cbc:ID, benzersiz belge tanımlayıcısı ise cbc:UUID alanında okunur. Bu iki alan aynı amaçla kullanılmaz ve birinin yerine diğerini yazmak, belge eşleştirme süreçlerini bozabilir.

cbc:ID alanı, işletmenin fatura numarasını taşır. Bu değer, faturanın görünen yüzündeki numarayla ve muhasebe kaydıyla uyumlu olmalıdır. cbc:UUID ise belgenin sistemler arasında ayırt edilmesine yardımcı olan benzersiz tanımlayıcıdır. XML dosya adı, fatura numarası ve UUID birbirinden farklı olabilir.

cbc:IssueDate belgenin düzenlenme tarihini, cbc:IssueTime ise kullanılıyorsa düzenlenme saatini gösterir. XML tarihleri, ekranda görülen gün.ay.yıl biçiminden farklı yazılabilir. Bu yüzden 01.03.2026 benzeri bir görüntüyü doğrudan XML'e kopyalamak yerine, kullanılan teknik şemanın beklediği tarih biçimi uygulanmalıdır.

Belge üst bilgilerinde ayrıca UBLVersionID, CustomizationID, ProfileID, DocumentCurrencyCode ve LineCountNumeric gibi alanlar bulunabilir. CustomizationID, belgenin hangi özelleştirme kurallarına göre üretildiğini; para birimi alanı ise tutarların hangi dövizle ifade edildiğini anlatır.

Bir yazılım fatura numarasını yalnızca PDF üzerindeki metinden okuyorsa, XML'deki ID ile karşılaştırma yapmalıdır. Tarih, para birimi ve satır sayısı da aynı kontrol zincirine eklenebilir. Böylece görsel çıktı ile makine tarafından işlenen belge arasında fark varsa işlem durdurulabilir.

Fatura numarası kontrolünde yalnızca değerin varlığına bakılmaz. Başındaki harf veya seri, boşluk kullanımı, tekrar edip etmediği ve işletmenin numara akışıyla uyumu da incelenir. Numara biçiminin mevzuata uygunluğu ise güncel kurallar ve mali müşavir değerlendirmesiyle doğrulanmalıdır.

Yanlış: Dosya adını fatura numarası kabul ederek XML içindeki cbc:ID değerini kontrol etmemektir. Doğru: Dosya adını yardımcı bilgi olarak kullanmak, asıl eşleştirmeyi cbc:ID ve UUID alanlarıyla yapmaktır.

e-Fatura XML içinde satıcı ve alıcı bilgileri nerede bulunur?

e-Fatura XML içinde satıcı bilgileri cac:AccountingSupplierParty, alıcı bilgileri ise cac:AccountingCustomerParty bölümünde bulunur. Bu bölümler, tarafın kimliğiyle birlikte unvan, adres, vergi bilgisi ve iletişim detaylarını ayrı elemanlar halinde taşır.

Taraf kimliği çoğunlukla cac:Party altında yer alan PartyIdentification elemanlarıyla gösterilir. VKN veya TCKN gibi kimlik türleri, ID değerinin hangi kimlik sistemine ait olduğunu belirten schemeID bilgisiyle birlikte değerlendirilir. SchemeID değeri gelişigüzel yazılamaz; ilgili GİB teknik kılavuzundaki kodla uyumlu olmalıdır.

PartyName veya cac:PartyLegalEntity içindeki kayıtlar, unvanın nasıl gösterildiğini açıklar. PostalAddress bölümünde sokak, ilçe, il, posta kodu ve ülke bilgileri bulunabilir. TaxScheme altında vergi dairesi veya vergiyle ilgili tanımlayıcı bilgiler yer alabilir. Her alan her belge türünde aynı zorunluluk düzeyine sahip olmayabilir.

Yanlış: Alıcının vergi numarasını yalnızca Note alanına yazıp AccountingCustomerParty bölümünü boş bırakmaktır. Doğru: Alıcı kimliğini ilgili PartyIdentification alanında, kimlik türünü uygun schemeID ile birlikte göstermektir.

Taraf kontrolü yapılırken satıcı ve alıcının yeri karıştırılmamalıdır. Satış yapan taraf AccountingSupplierParty, faturayı alan taraf AccountingCustomerParty içinde aranır. Bu ayrım, özellikle iade faturalarında metinle yapılan yorumlardan daha güvenilir sonuç verir.

Taraf bilgilerini kontrol etmek için aşağıdaki sıra kullanılabilir:

1. Önce AccountingSupplierParty ve AccountingCustomerParty bölümlerinin dosyada bulunup bulunmadığını kontrol edin.
2. Her tarafın PartyIdentification içindeki kimlik değerini ve schemeID bilgisini birlikte okuyun.
3. Unvanı, adresi ve vergi bilgilerini işletmenin cari kayıtlarıyla karşılaştırın.
4. Gerekirse XML'deki taraf verilerini PDF görünümü ve muhasebe kaydıyla eşleştirin.

Yanlış: PartyName alanındaki kısa adı, resmi unvan ve vergi kimliğiyle aynı kabul etmektir. Doğru: Resmi kimliği PartyIdentification ve PartyLegalEntity alanlarıyla, görünen adı ise unvan alanlarıyla ayrı değerlendirmektir.

Bir tarafın adresinde küçük bir yazım farkı bulunması, her zaman XML'in teknik olarak geçersiz olduğu anlamına gelmez. Kimlik numarası, taraf rolü ve zorunlu alanlar öncelikle incelenmelidir. Ancak resmi belge ve muhasebe kayıtlarıyla çelişen kimlik bilgileri işlemden önce düzeltilmelidir.

e-Fatura XML içinde fatura kalemleri ve miktar nasıl okunur?

e-Fatura XML içinde fatura kalemleri, her mal veya hizmet için ayrı oluşturulan cac:InvoiceLine kayıtlarında bulunur. Miktar, birim, birim fiyat, kalem açıklaması, iskonto ve satır tutarı bu kayıtların alt elemanlarıyla birlikte okunur.

Her InvoiceLine içinde bulunan cbc:ID, kalemin sıra veya satır kimliğini gösterebilir. cbc:InvoicedQuantity miktarı, unitCode ise ölçü birimini belirtir. Örneğin adet, kilogram veya saat gibi birimler kodla taşınabilir. Miktarı yalnızca açıklama metninden okumak güvenilir değildir.

Fiyat bilgisi çoğunlukla cac:Price içindeki cbc:PriceAmount alanında yer alır. Satırın vergiler öncesi toplamı ise cbc:LineExtensionAmount alanından izlenebilir. Bu iki tutar aynı olmayabilir; miktar, birim fiyat, iskonto ve ek bedeller aradaki farkı oluşturabilir.

Kalemin ürün veya hizmet açıklaması cac:Item içindeki Name ve Description alanlarında bulunabilir. Ürün kodu, üretici kodu veya satıcı kodu varsa SellersItemIdentification ve benzeri tanımlayıcılarla ayrıca taşınabilir. Kodun bulunması, ürünün açıklama alanının boş bırakılabileceği anlamına gelmez.

İskonto ve ek bedeller cac:AllowanceCharge kayıtlarında gösterilebilir. ChargeIndicator değeri, kaydın indirim mi yoksa ek ücret mi olduğunu yorumlamaya yardım eder. Bu kayıtları yalnızca tutar alanına bakarak okumak, satır toplamının yanlış hesaplanmasına neden olabilir.

Örneğin mahalle marketi sahibi, tedarikçiden gelen XML'de beş ayrı InvoiceLine görebilir. Bir satırda ürün miktarı, diğerinde koli birimi bulunabilir. Market sahibi toplamı kontrol ederken satır açıklamalarını, ölçü birimlerini ve vergi öncesi tutarları cari kayıtlarıyla karşılaştırmalıdır.

Yanlış: PDF'de görünen ürün açıklamasını kopyalayıp XML'deki miktar ve birim alanlarını yok saymaktır. Doğru: InvoiceLine, InvoicedQuantity, unitCode, PriceAmount ve LineExtensionAmount alanlarını aynı satır içinde birlikte kontrol etmektir.

KDV, vergi matrahı ve toplamlar UBL-TR XML'de nasıl kontrol edilir?

UBL-TR XML'de KDV ve diğer vergi bilgileri çoğunlukla cac:TaxTotal, cac:TaxSubtotal ve cac:TaxCategory bölümlerinde; genel fatura toplamları ise cac:LegalMonetaryTotal bölümünde kontrol edilir. Doğru sonuç için oran, matrah, vergi tutarı ve para birimi birlikte okunmalıdır.

TaxSubtotal kaydı, belirli bir vergi oranına veya vergi kategorisine ait matrahı ve vergi tutarını taşır. TaxableAmount vergiye esas tutarı, TaxAmount hesaplanan vergi tutarını, Percent ise uygulanan oranı gösterebilir. Bir faturada birden fazla TaxSubtotal bulunması normaldir.

Vergi kategorisi, istisna veya özel uygulama açıklaması varsa ayrıca incelenmelidir. Vergi oranının sıfır görünmesi, otomatik olarak her durumda istisna olduğu anlamına gelmez. Kategori kodu, istisna nedeni ve fatura türü birlikte değerlendirilmeden sonuç çıkarılmamalıdır.

LegalMonetaryTotal içinde LineExtensionAmount, TaxExclusiveAmount, TaxInclusiveAmount ve PayableAmount gibi toplamlar bulunabilir. İskonto veya ek ücret varsa AllowanceTotalAmount ve ChargeTotalAmount alanları da hesaplamaya katılabilir. Ödenecek tutar ile vergi hariç tutarın aynı olması her faturada beklenmez.

Toplam kontrolünde önce satır toplamları toplanır, sonra belge düzeyindeki indirim ve ek ücretler incelenir. Ardından vergi matrahı ve vergi tutarı kontrol edilir. Son aşamada TaxInclusiveAmount, PayableAmount ve DocumentCurrencyCode değerleri karşılaştırılır.

Yanlış: İlk TaxAmount değerini faturanın toplam KDV'si kabul etmektir. Doğru: Tüm TaxSubtotal kayıtlarını, ilgili matrahları ve TaxTotal içindeki genel vergi tutarını birlikte değerlendirmektir.

Yuvarlama farkları, farklı para birimleri ve satır bazında yapılan hesaplamalar küçük ayrışmalar oluşturabilir. Bu farkın kabul edilebilir olup olmadığı, kullanılan teknik kurala ve muhasebe uygulamasına göre incelenmelidir. Güncel GİB kurallarını ve mali müşavirinizi kontrol etmeden tutarı elle değiştirmeyin.

ProfileID ve InvoiceTypeCode e-Fatura senaryosunu nasıl gösterir?

ProfileID, e-Fatura XML içinde belgenin hangi senaryo veya işlem akışına göre üretildiğini gösteren temel alanlardan biridir. InvoiceTypeCode ise belgenin satış, iade veya ilgili başka bir fatura türünü ifade eder; bu iki alan aynı amaçla kullanılmaz.

ProfileID içinde teknik kurallarda tanımlanan senaryo değerleri bulunabilir. Yaygın olarak görülen TEMELFATURA ve TICARIFATURA gibi değerler, belgenin kabul ve yanıt akışını anlamaya yardımcı olur. Ancak yalnızca bu metne bakarak faturanın bütün hukuki sonuçları belirlenemez.

InvoiceTypeCode, belgenin işlem türünü anlamak için kullanılır. SATIS veya IADE gibi değerler, satış ve iade ayrımını gösterebilir. TEVKIFAT gibi özel türlerde vergi ve toplam alanları ayrıca incelenmelidir. Her değer için güncel teknik kod listesi kontrol edilmelidir.

CustomizationID, UBL-TR özelleştirmesini; DocumentCurrencyCode ise tutarların para birimini gösterir. Bu alanların birbiriyle uyumu, XML'in doğru profile göre üretilip üretilmediğini anlamaya yardım eder. Satır sayısı alanı da dosyadaki InvoiceLine kayıtlarıyla karşılaştırılabilir.

Yanlış: ProfileID değerini fatura türü, InvoiceTypeCode değerini ise senaryo kabul etmektir. Doğru: ProfileID ile işlem akışını, InvoiceTypeCode ile belge türünü ayrı okuyup diğer alanlarla doğrulamaktır.

Bir işletme, e-Fatura süreçlerini incelerken önce belgenin hangi senaryoda geldiğini ve hangi türü taşıdığını belirlemelidir. Ardından taraf, yanıt ve imza bilgileri değerlendirilmelidir. Senaryo alanı eksik veya beklenmeyen bir değerdeyse dosya kabul edilmiş görünse bile teknik inceleme yapılmalıdır.

UBL-TR XML içinde imza ve referans belgeleri nasıl incelenir?

UBL-TR XML içinde imza bilgileri genellikle cac:Signature yapısında, ilişkili belge ve ek bilgiler ise cac:AdditionalDocumentReference bölümlerinde bulunur. İmzanın varlığı tek başına doğrulamanın tamamlandığını göstermez; imza bütünlüğü ve belge kabul durumu ayrıca incelenmelidir.

Signature yapısında imzalayan tarafı ve elektronik imzaya bağlı teknik referansları gösteren alanlar bulunabilir. İmza değeri, sertifika bilgisi veya dış referans gibi bileşenlerin nasıl taşındığı kullanılan teknik uygulamaya göre değişebilir. Bu nedenle yalnızca Signature etiketinin dosyada bulunmasına bakılmamalıdır.

AdditionalDocumentReference, önceki fatura, sipariş, irsaliye veya başka bir ilişkili belgeye işaret edebilir. DocumentTypeCode, DocumentType, ID ve IssueDate gibi alanlar referansın ne olduğunu anlamaya yardım eder. Ek dosya varsa Attachment içindeki gömülü veya harici bağlantı da kontrol edilmelidir.

İrsaliye bağlantısı, sipariş numarası veya ek açıklama faturanın ticari bağlamını destekleyebilir. Ancak referans alanının bulunması, ilişkili belgenin otomatik olarak geçerli olduğu anlamına gelmez. Referans numarası ve tarih, ilgili belge kayıtlarıyla karşılaştırılmalıdır.

Uzman notu: İmza bölümü XML içinde görünse bile dosyanın sonradan değiştirilmediğini yalnızca gözle kontrol etmeyin; imza doğrulama sonucunu, sertifika durumunu ve sistemin belge kabul yanıtını birlikte inceleyin.

Yanlış: PDF'de imza görüntüsü bulunduğu için XML imzasının doğrulandığını kabul etmektir. Doğru: Orijinal XML dosyasını, elektronik imza doğrulama sonucunu ve sistem yanıtını birlikte saklamaktır.

UBL-TR ile e-Arşiv fatura dosyalarının teknik ve operasyonel akışları aynı kabul edilmemelidir. Belgenin e-Fatura mı, e-Arşiv mi olduğunu belge türü, sistem kaydı ve ilgili mevzuatla doğrulayın. Güncel GİB duyurusunu ve mali müşavirinizi kontrol edin.

e-Fatura UBL-TR XML doğrulama hataları nasıl araştırılır?

e-Fatura UBL-TR XML doğrulama hataları, dosyanın iyi biçimli olup olmadığı, şema kuralları, kod listeleri, iş kuralları, toplam hesapları ve imza durumu ayrı ayrı incelenerek araştırılır. Dosyanın tarayıcıda açılması, belgenin GİB tarafından kabul edildiğini göstermez.

İlk aşamada XML etiketlerinin kapanışı, özel karakterler, encoding ve kök Invoice yapısı kontrol edilir. İkinci aşamada zorunlu elemanların bulunup bulunmadığı ve veri tiplerinin uygunluğu incelenir. Üçüncü aşamada para birimi, ölçü birimi, vergi kodu ve senaryo değerleri karşılaştırılır.

Ardından taraf kimlikleri, fatura numarası, tarih, satır toplamları, vergi matrahı ve ödenecek tutar arasında mantıksal bağlantı aranır. Son aşamada imza doğrulaması ve uygulama yanıtı kontrol edilir. Hata mesajındaki alan yolu, hangi bölümden başlanacağını gösterir.

Kontrol sırasında aşağıdaki liste kullanılabilir:

• XML dosyasının kök Invoice yapısı ve namespace tanımları doğru görünmelidir.
• Fatura numarası, UUID, tarih, senaryo ve para birimi alanları birlikte kontrol edilmelidir.
• Satıcı ve alıcı kimlikleri, doğru taraf bölümlerinde ve uygun schemeID ile gösterilmelidir.
• Her InvoiceLine kaydındaki miktar, birim, fiyat ve satır tutarı birbirini desteklemelidir.
• TaxSubtotal, TaxTotal ve LegalMonetaryTotal değerleri aynı para birimiyle karşılaştırılmalıdır.
• İmza doğrulama sonucu ve uygulama yanıtı, yalnızca XML'in açılmasına göre değerlendirilmemelidir.

Yanlış: Hata mesajındaki ilk kelimeye göre XML'i rastgele değiştirmektir. Doğru: Hata kodunu, işaret edilen XML alanını ve bu alanın bağlı olduğu toplam veya taraf bilgilerini birlikte incelemektir.

Bir dosya şema kontrolünden geçse bile ticari olarak hatalı olabilir. Örneğin satıcı ve alıcı kimlikleri teknik biçimde dolu bulunabilir, fakat yanlış işletmelere ait olabilir. Bu nedenle teknik doğrulama ile muhasebe ve ticari kontrol ayrı aşamalar olarak yürütülmelidir.

Hata çözülemiyorsa orijinal XML, hata mesajı, uygulama yanıtı ve mümkünse PDF görünümü birlikte hazırlanmalıdır. Destek talebinde yalnızca “fatura çalışmıyor” demek yerine, ilgili alan adını ve alınan yanıtı paylaşmak incelemeyi hızlandırır. Kişisel ve ticari verileri paylaşırken güvenlik kurallarına uyun.

Genel teknik sorular için e-belge sık sorulan sorular bölümü incelenebilir. Belgeye özel bir uyuşmazlıkta ise sistem kayıtlarıyla birlikte mali müşavir veya ilgili entegrasyon desteği değerlendirilmelidir.

XML ile PDF arasında fark varsa hangi belge esas alınır?

XML, e-Faturanın makine tarafından işlenen yapılandırılmış veri katmanıdır; PDF ise aynı bilgilerin insan tarafından okunabilir görsel sunumudur. XML ile PDF arasında fark varsa belge kabul durumu, orijinal XML, imza ve sistem yanıtı birlikte incelenmeli; görsel fark otomatik olarak yok sayılmamalıdır.

PDF tasarımı XSLT veya başka bir görüntüleme şablonuyla oluşturulabilir. Bu nedenle XML'deki bir alanın PDF'de farklı konumda görünmesi tek başına hata değildir. Ancak fatura numarası, taraf kimliği, miktar, vergi ve ödenecek tutar gibi temel bilgiler iki görünümde çelişiyorsa teknik inceleme gerekir.

Örneğin küçük bir kafenin sahibi, tedarikçiden gelen faturada PDF üzerinde üç ürün satırı görürken XML'de dört InvoiceLine bulunduğunu fark edebilir. Önce XML'in satır sayısı, LineCountNumeric alanı, toplamlar ve PDF oluşturma yöntemi karşılaştırılmalıdır. Eksik görünen satır sistemsel görüntüleme sorunundan kaynaklanabilir.

Bu durumda uygulanacak sıra şöyledir: Orijinal XML'i değiştirmeden saklayın, PDF'yi aynı dosyadan yeniden üretin, satır ve toplam alanlarını karşılaştırın, imza ve kabul yanıtını kontrol edin, ardından düzenleyici veya entegratör desteğine başvurun. Dosya adını değiştirerek yeni bir XML üretmeyin.

Yanlış: PDF daha okunaklı olduğu için XML'deki tutarsızlığı yok saymaktır. Doğru: PDF'yi görsel kontrol için, XML'i yapılandırılmış veri kontrolü için kullanmak ve farkın kaynağını kayıt altına almaktır.

Farkın belgeye mi, görüntüleme şablonuna mı, yoksa aktarım sürecine mi ait olduğu belirlenmeden muhasebe kaydı değiştirilmemelidir. Gerekirse destek iletişim kanalı üzerinden hata mesajı ve teknik kayıtlarla başvuru yapılabilir. Mevzuat yorumu gereken durumlarda mali müşavirinizden görüş alın.

Özet: 5 maddede e-Fatura UBL-TR XML yapısı

e-Fatura UBL-TR XML yapısını doğru okumak için alanları tek tek değil, belge içindeki ilişkileriyle değerlendirmek gerekir.

• UBL-TR, e-Fatura verilerini fatura numarası, taraflar, kalemler, vergiler, toplamlar ve imza gibi makine tarafından işlenebilir alanlarda taşıyan XML profilidir.
• cbc:ID fatura numarasını, cbc:UUID benzersiz belge tanımlayıcısını, cbc:IssueDate ise düzenlenme tarihini gösterir; bu alanlar dosya adı veya PDF metniyle ayrıca karşılaştırılmalıdır.
• AccountingSupplierParty ve AccountingCustomerParty satıcı ile alıcıyı gösterir; kimlik değeri, schemeID, unvan ve adres bilgileri birlikte kontrol edilmelidir.
• InvoiceLine, InvoicedQuantity, PriceAmount, TaxSubtotal ve LegalMonetaryTotal alanları kalem, vergi ve toplam hesabını birlikte açıklar; yalnızca tek bir tutar okunmamalıdır.
• XML'in açılması veya PDF'nin görüntülenmesi, belgenin kabul edildiğini tek başına kanıtlamaz; şema, iş kuralı, imza, uygulama yanıtı ve güncel GİB duyurusu birlikte incelenmelidir.

UBL-TR alanlarını düzenli kontrol etmek, muhasebe aktarımındaki hataları erken fark etmeye yardım eder. Emin olunmayan mevzuat, kod listesi veya belge geçerliliği konularında güncel GİB duyurusunu ve mali müşavirinizi kontrol edin.

efaturakontor.com'da tüm e-belgelerde geçerli havuz kontör paketleri 100'den 500.000 kontöre kadar sunulur; ücretsiz e-Fatura portalı ve Sovos altyapısına aynı gün tanımlama seçenekleri bulunur. Gelen ve giden belgelerin her biri 1 kontör düşürür.

Kontörlerin kullanım süresi 12-18 ay arasındadır. Güncel paket kapsamını ve koşulları satın almadan önce kontrol edin.