Rehber
Markdown dışa aktar2026’da AB e‑faturalama: neyi uygulamalısınız (ve neden)
AB genelinde faturalama, “PDF faturadır” yaklaşımından yapılandırılmış ve makine tarafından okunabilir veriye doğru kayıyor. Ülkeye göre ayrıntılar değişse de yapı taşları benzer: uyumlu bir veri modeli (çoğunlukla EN 16931), bir sözdizimi (UBL veya CII), doğru tanımlayıcılar ve güçlü doğrulama.
AB’de “e‑faturalama” pratikte ne demek?
AB’de çoğu senaryoda e‑fatura sadece PDF değildir. Yazılımların ayrıştırıp doğrulayabildiği (genellikle XML) yapılandırılmış fatura verisidir; bazen görsel PDF ile birlikte gelir.
Bu, otomasyon (AP/AR akışları), uyumluluk (zorunlu iş kuralları) ve sistemler arası güvenilir aktarım için kritiktir.
Kontrol listesi: AB’de “e‑faturalama” pratikte ne demek?
Bu noktaları bu bölüm için pratik kontrol adımları olarak kullanın.
- “Yapılandırılmış fatura” = makine tarafından okunabilir alanlar (alıcı, satıcı, toplamlar, KDV, satırlar)
- “Sözdizimi” = verinin nasıl kodlandığı (UBL veya CII XML)
- “Doğrulama” = teknik + iş kuralları (şema + schematron, CIUS kuralları)
Sürekli karşınıza çıkacak standartlar
EN 16931, birçok AB e‑faturalama uygulamasının arkasındaki temel anlamsal modeldir. Fatura verisinin ne ifade ettiğini (iş terimleri) tanımlar; sadece teknik kodlamayı değil.
Yaygın iki XML sözdizimi UBL (OASIS) ve CII’dir (UN/CEFACT). Ülkeler ve ağlar, kuralları ve kod listelerini sıkılaştıran bir CIUS da tanımlayabilir.
Kontrol listesi: Sürekli karşınıza çıkacak standartlar
Bu noktaları bu bölüm için pratik kontrol adımları olarak kullanın.
- EN 16931 (anlamsal model)
- UBL (sözdizimi)
- CII (sözdizimi)
- CIUS (ülke/ağ kısıtları)
- ZUGFeRD/Factur‑X (PDF + gömülü XML)
İletim modelleri: PEPPOL vs portallar vs clearance (CTC)
Bazı ülkeler ağ üzerinden aktarımı (PEPPOL ile 4‑corner) öne çıkarırken, bazıları ulusal portallara dayanır; bazıları ise fatura tesliminden önce platform üzerinden raporlama/onay gerektiren clearance/CTC modellerini kullanır.
Uygulamada “fatura verisinin doğruluğunu” “iletim kanalı entegrasyonundan” ayırın. Aynı EN 16931 eşlemesi çoğu zaman birden fazla kanalda kullanılabilir.
Kontrol listesi: İletim modelleri: PEPPOL vs portallar vs clearance (CTC)
Bu noktaları bu bölüm için pratik kontrol adımları olarak kullanın.
- PEPPOL (4‑corner): participant ID ile adresleme; access point’ler yönlendirir
- Portallar: devlet/ sektör platformuna yükleme veya API
- Clearance/CTC: platform onayı, yasal düzenleme sürecinin parçası olabilir
Tanımlayıcılar ve ana veriler: projeler nerede zorlanır?
Doğrulama hatalarının çoğu “XML problemi” değildir; ana veri problemidir: eksik adresler, tutarsız KDV bilgileri, yanlış alıcı referansları veya geçersiz kod listesi değerleri.
Kod listelerini (para birimi, birim kodları, KDV kategorileri, ödeme yöntemleri) dokümantasyon değil ürünün parçası olarak yönetin.
Kontrol listesi: Tanımlayıcılar ve ana veriler: projeler nerede zorlanır?
Bu noktaları bu bölüm için pratik kontrol adımları olarak kullanın.
- Satıcı/alıcı kimliklerini ve adres tamlık kurallarını standardize edin
- Kod listelerini girişte doğrulayın (sadece XML export’ta değil)
- Yuvarlama ve KDV kırılım mantığını tutarlı uygulayın
Doğrulama: şema vs iş kuralları (ve neden ikisi de önemli)
Bir dosya iyi biçimlendirilmiş XML olabilir ve yine de reddedilebilir. Doğrulayıcılar genellikle birden çok katman çalıştırır: XML şeması (yapı), schematron (kurallar) ve bazen ağ/ülke profilleri.
Hızlı geri bildirim döngüsü kurun: erken doğrulayın, hataları arayüzde gösterin ve doğrulanmış XML’i tekrarlanabilir bir çıktı olarak saklayın.
Kontrol listesi: Doğrulama: şema vs iş kuralları (ve neden ikisi de önemli)
Bu noktaları bu bölüm için pratik kontrol adımları olarak kullanın.
- Şema hataları = eksik/geçersiz elemanlar
- Schematron hataları = iş kuralları (örn. KDV kırılımı)
- Profil hataları = CIUS/ağ kısıtları
Uygulama kontrol listesi (iş + geliştirme için)
Başarılı bir geçiş, XML üretmekten çok tutarlı ve doğrulanmış fatura verisi üretmekle ilgilidir.
Bu kontrol listesini sıralama rehberi olarak kullanın—çoğu ekip bunu birkaç kez yineleyerek tamamlar.
Kontrol listesi: Uygulama kontrol listesi (iş + geliştirme için)
Bu noktaları bu bölüm için pratik kontrol adımları olarak kullanın.
- Hedef ülke/kanalları (PEPPOL, portal, clearance) ve kestiğiniz “fatura türlerini” belirleyin
- Veri modelinizi EN 16931’e (veya gerekli CIUS’a) eşleyin, UBL mi CII mı karar verin
- Tanımlayıcıları (alıcı referansları, yönlendirme ID’leri) ve kod listelerini (para birimi, birim, KDV kategorisi, ödeme yöntemi) netleştirin
- XML üretin ve göndermeden önce yerelde doğrulayın
- Gerçekçi faturalarla uçtan uca test edin (iskonto, KDV oranları, karışık kalemler, yuvarlama)
- Operasyon: hata yönetimi, yeniden deneme, denetim izi, gönderilen faturaların saklanması/erişimi