# 2026’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?

- “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

- 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)

- 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?

- 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)

- Ş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)

- 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

## İlgili kaynaklar

- [AB e‑faturalama zorunluluğu genel bakış](/resources/compliance/european-e-invoicing-mandate)
- [PEPPOL ağ rehberi](/resources/compliance/peppol-network-guide)
- [Fatura kod listeleri (KDV, birimler, ödeme)](/resources/code-lists)
- [E‑faturalama sözlüğü](/resources/glossary)