SAP Business One e-Fatura Entegrasyonu: Mimari Rehber

SAP Business One'da e-Fatura, standart ürünün değil Türkiye lokalizasyon katmanının işidir: B1'de kesilen fatura, lokalizasyon add-on'u tarafından GİB'in UBL-TR formatına dönüştürülür, özel entegratör üzerinden Gelir İdaresi Başkanlığı'na iletilir ve alıcının posta kutusuna düşer. Gelen faturalar da aynı kanaldan ters yönde akar. Yani mimaride üç aktör vardır — B1 + lokalizasyon add-on'u, özel entegratör, GİB — ve projenin başarısı bu üçünün arasındaki akışın ve hata senaryolarının baştan tasarlanmasına bağlıdır.

Bu rehber, SAP entegrasyon projelerimizde e-Fatura devreye alırken izlediğimiz mimariyi anlatıyor. Hedef okur, e-Fatura geçişi planlayan ya da mevcut kurulumunda sorun yaşayan finans ve BT yöneticisi.

Mimarinin üç katmanı

1. B1 + lokalizasyon add-on'u. Faturanın ticari kaynağı B1'dir: müşteri kartı, kalemler, KDV oranları, döviz bilgisi burada oluşur. Lokalizasyon add-on'u bu belgeyi alır, GİB'in zorunlu kıldığı UBL-TR XML şemasına dönüştürür ve senaryo bilgisini (temel/ticari fatura, e-Arşiv) ekler. Add-on ürünün parçası değildir; ayrı lisanslanır ve teklifinizde ayrı satır olmalıdır — bu konunun bütçe tarafını fiyat yazımızda açtık.

2. Özel entegratör. GİB ile doğrudan konuşmak yerine piyasadaki özel entegratörlerden biriyle sözleşme yaparsınız. Entegratör; imzalama (mali mühür), GİB'e iletim, yasal saklama ve portal hizmeti verir. Kontör (belge adedi) paketleri, saklama süreleri ve API yetenekleri entegratörden entegratöre değişir.

3. GİB. Faturanın hukuki olarak "kesilmiş" sayıldığı yer. Alıcı e-Fatura mükellefiyse belge GİB üzerinden alıcının entegratörüne, değilse e-Arşiv senaryosuyla mail/portal kanalına gider.

Sahada en sık düzelttiğimiz kavram yanılgısı şu: "e-Fatura entegrasyonu" tek bir bağlantı değil, bu üç katman arasında durum takibi yapan bir süreçtir. XML'i üretmek işin kolay kısmı; zor kısım her belgenin GİB'deki akıbetini B1'e geri taşımaktır.

Giden fatura akışı

Tipik giden akışı şu adımlarla kurarız:

1. B1'de satış faturası kesilir; müşteri kartındaki VKN/TCKN üzerinden alıcının e-Fatura mükellefi olup olmadığı sorgulanır (mükellef listesi entegratörden güncellenir).
2. Add-on belgeyi UBL-TR'ye dönüştürür; senaryo (temel/ticari) ve profil bilgisi eklenir.
3. XML, entegratör API'sine gönderilir; entegratör mali mühürle imzalar ve GİB'e iletir.
4. GİB şema ve kural kontrolü yapar; belge alıcıya yönlenir.
5. Ticari faturada alıcının kabul/red cevabı beklenir; temel faturada iletim yeterlidir.
6. Her adımın durumu (gönderildi, GİB'de, teslim edildi, kabul, red) B1'e geri yazılır.

Altıncı adım, projelerin kalitesini ayıran yerdir. Durum geri beslemesi kurulmamışsa muhasebe ekibi entegratör portalı ile B1 arasında gidip gelerek gün kaybeder; ay sonunda "B1'de kesik görünüyor ama GİB'de yok" vakaları ancak mutabakatta fark edilir. Bizim standardımız: belge durumu B1 ekranından görülebilir olmalı, portal yalnızca istisna incelemesi için açılmalıdır.

Gelen fatura akışı

Gelen e-Faturalar entegratör posta kutunuza düşer; oradan B1'e taşınması üç seviyede kurgulanabilir:

Seviye	Ne yapılır	Kime uygun
Görüntüleme	Gelen fatura B1'de listelenir, kayıt elle açılır	Düşük belge hacmi
Yarı otomatik	XML'den satıcı/tutar/KDV okunur, taslak belge önerilir, kullanıcı onaylar	Orta hacim, kontrol ihtiyacı
Eşleştirmeli	Fatura satırları açık satın alma siparişi/irsaliyeyle eşleştirilir, üç yönlü kontrol yapılır	Yüksek hacim, satın alma disiplini olan şirketler

Projelerimizde önerdiğimiz desen ikinci seviyeden başlayıp üçüncüye evrilmek. Üç yönlü eşleştirme (sipariş-irsaliye-fatura) güçlü bir kontrol sağlar ama satın alma süreçleriniz B1'de disiplinle yürümüyorsa ilk günden dayatmak, muhasebeyi eşleşmeyen belgeler yığınıyla baş başa bırakır. Önce süreç, sonra otomasyon.

Hata senaryoları: ne ters gider, nasıl karşılanır

E-Fatura entegrasyonunun gerçek testi mutlu akış değil, istisnalardır. Baştan tasarlanmasını istediğimiz senaryolar:

• GİB şema/kural reddi: XML üretilir ama GİB reddeder — çoğu zaman eksik/yanlış VKN, hatalı KDV istisna kodu ya da birim kodu kaynaklı. Reddedilen belge B1'de "hatalı" statüsüyle görünmeli ve düzeltme-yeniden gönderme akışı tanımlı olmalı.
• Ticari faturada red cevabı: Alıcı faturayı reddederse muhasebede iade/iptal süreci tetiklenir. Bu cevabın B1'e düşmediği kurulumlarda red edilen fatura aylarca "açık alacak" olarak yaşar; sahada bu vakayı ilk mutabakat döneminde yakalıyoruz.
• Entegratör kesintisi: Entegratör API'si yanıt vermiyorsa belgeler kuyruklanmalı, kesinti bitince otomatik gönderilmelidir. Kuyruk yoksa kesinti anındaki faturalar "gönderildi sanılan" en tehlikeli sınıfa düşer.
• Mükellef listesi güncelliği: Alıcı dün e-Arşiv müşterisiyken bugün e-Fatura mükellefi olabilir. Liste güncellenmiyorsa belge yanlış senaryoyla kesilir; bu, düzeltmesi en yorucu hatalardan biridir.
• Numaralandırma ve seri yönetimi: e-Fatura serileri ile matbu/e-Arşiv serilerinin karışması, özellikle çok şubeli yapılarda görülür. Seri planını canlı geçişten önce yazılı netleştiririz.

Bu senaryoların ortak paydası şu: hata olması sorun değil, hatanın görünmez olması sorundur. Devreye alma kontrol listemizde her senaryonun bir "kim, hangi ekranda, nasıl fark eder" cevabı vardır.

Devreye alma: test ve geçiş planı

Canlı geçişten önce entegratörün test ortamında asgari şu setin koşulmasını isteriz: temel ve ticari senaryoda giden fatura, red cevabı, e-Arşiv senaryosu, iade faturası, döviz faturası ve gelen fatura kabulü. Test faturalarının gerçek kontör tüketmediği, ama gerçek şema kontrollerinden geçtiği bir ortam bu.

Geçiş tarihini ay başına, tercihen dönem kapanışından uzağa koyarız; ilk hafta boyunca giden her belgenin GİB durumunu günlük kontrol eden bir sahiplik tanımlarız. Kapsamlı bir KOBİ kurulumu içinde e-Fatura devreye alma tipik olarak projenin 2-8 haftalık genel takvimine sığar; mevcut çalışan bir B1'e sonradan eklemek de mümkündür ve ayrı, daha dar bir proje olarak planlanır.

Mevcut kurulumunuzda yukarıdaki istisna akışlarından biri eksikse — özellikle durum geri beslemesi ve kuyruklama — teknik destek ekibimizle mevcut yapının sağlık kontrolünü yapabiliriz.

e-Arşiv, e-İrsaliye ve e-Defter ile ilişkisi

E-Fatura projesi nadiren tek başına gelir; aynı lokalizasyon katmanı diğer e-Dönüşüm belgelerini de taşır ve kapsam kararı hepsini birlikte düşünmeyi gerektirir:

Belge	Ne zaman devreye girer	B1 tarafında kaynak
e-Fatura	Alıcı e-Fatura mükellefiyse	Satış faturası
e-Arşiv	Alıcı mükellef değilse (nihai tüketici dahil)	Satış faturası (senaryo farkı)
e-İrsaliye	Sevkiyatla birlikte, mevzuat kapsamına göre	Sevk irsaliyesi
e-Defter	Dönemsel yasal defter yükümlülüğü	Muhasebe kayıtlarının tamamı

Pratik önerimiz, giden fatura tarafını (e-Fatura + e-Arşiv) tek pakette devreye almak; ikisi aynı belge akışının iki senaryosudur ve ayrı projelere bölmek yapay bir sınırdır. e-İrsaliye, depo/sevkiyat sürecine dokunduğu için operasyon ekibiyle birlikte planlanır; e-Defter ise muhasebe kapanış düzeni oturduktan sonra en sağlıklı geçilen belgedir. Dört belgenin aynı add-on ailesinden ve aynı entegratörden yürümesi, hem sözleşme hem destek tarafını sadeleştirir.

Devreye alma kontrol listesi

Projeye başlamadan önce netleşmesini istediğimiz maddeler:

1. Entegratör sözleşmesi ve kontör paketi imzalandı mı; test ortamı erişimi alındı mı?
2. Mali mühür/sertifika başvurusu tamamlandı mı? (Tedarik süresi takvimi etkiler.)
3. Müşteri kartlarında VKN/TCKN alanları dolu ve doğrulanmış mı?
4. KDV istisna/tevkifat kodları gerçek satış senaryolarınızla eşleştirildi mi?
5. Seri planı (e-Fatura, e-Arşiv, matbu yedek) yazılı olarak onaylandı mı?
6. Red/iade/iptal akışlarının B1 karşılığı tanımlandı mı; kim, hangi ekranda müdahale edecek?
7. Kesinti kuyruğu ve yeniden gönderim davranışı test edildi mi?
8. İlk hafta için günlük GİB durum kontrolü sahipliği atandı mı?

Bu listenin yarısının teknik değil organizasyonel olduğuna dikkat edin; e-Fatura projelerinde gecikmenin tipik sebebi XML değil, sahipsiz kalan bu kararlardır.

Sahada en sık görülen GİB ret sebepleri

Devreye alma sonrası ilk aylarda destek taleplerinin büyük bölümü şu ret sebeplerinde toplanır:

• Müşteri kartında eksik/yanlış VKN-TCKN veya vergi dairesi bilgisi
• Hatalı KDV istisna/tevkifat kodu (özellikle ihracat ve tevkifatlı hizmet faturalarında)
• Birim kodu uyumsuzluğu — B1'deki serbest birim tanımının UBL-TR birim koduna eşlenmemesi
• Negatif satır veya sıfır tutarlı kalemlerin senaryo kurallarına takılması
• Aynı belgenin mükerrer gönderimi (kuyruk/yeniden deneme kurgusu hatası)
• Alıcının senaryo değişikliği — dün e-Arşiv olan müşterinin bugün e-Fatura mükellefi olması

Bunların ortak özelliği, tamamının ana veri ve kurgu disipliniyle önlenebilir olmasıdır. Devreye almada müşteri kartı doğrulama taraması ve KDV kod eşleme atölyesi yapmamızın sebebi bu listedir; ret oranını düşürmenin yolu XML'i değil, kaynak veriyi düzeltmektir.

Sık sorulan sorular

SAP Business One e-Fatura'yı kutudan çıkarır mı?

Hayır; e-Fatura, e-Arşiv ve e-İrsaliye Türkiye lokalizasyon add-on'larıyla sağlanır ve ayrı lisans kalemleridir. Teklifte "lokalizasyon dahil" tek satırıyla geçiştirilmişse hangi belgelerin kapsamda olduğunu satır satır sordurun.

Hangi özel entegratörle çalışmak gerekir?

Tek doğru cevap yok; API yetenekleri, kontör fiyatlaması, saklama ve destek kalitesi entegratöre göre değişir. Bizim kriterimiz teknik: sağlam API dokümantasyonu, test ortamı ve durum sorgulama uçları olmayan entegratörle entegrasyon kurmak zorlaşır.

Gelen faturaları otomatik muhasebeleştirmek mümkün mü?

Mümkün, ama koşullu: satıcı eşleştirmesi, masraf/stok ayrımı ve KDV kontrolü kurallaştırılabiliyorsa taslak kayıt otomatik önerilir. Tam otomatik kayıt yerine "öner + onayla" desenini tavsiye ediyoruz; kontrolü kaybetmeden hız kazandırır.

e-Fatura entegrasyonu ne kadar sürer?

Yeni bir B1 kurulumunun parçasıysa genel proje takvimi içinde çözülür (kapsamlı KOBİ kurulumu tipik olarak 2-8 hafta). Çalışan bir sisteme ekleme ise kapsama göre değişen daha dar bir iştir; süreyi asıl belirleyen, test senaryolarının ve seri planının netliğidir.

Entegratör değiştirmek mümkün mü?

Mümkün; add-on tarafında bağlantı ayarları yeni entegratöre yönlendirilir, ancak eski entegratördeki belgelerin yasal saklama süresi boyunca erişilebilirliği sözleşmeyle güvence altına alınmalıdır. Geçişi dönem başına planlamak ve bir süre iki portala da erişimi korumak, mutabakat dönemini rahatlatır.