Bu sayfada
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.
- “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.
- 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.
- 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.
- 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.
- Ş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.
- 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