E-fatura entegrasyonu: köprü, muhasebe aktarımı, hata senaryoları ve mutabakat

Sipariş kapanıyor, sevkiyat çıkıyor, muhasebe faturayı ayrı bir ekranda yeniden yazıyor. Aynı bilgi iki kez giriliyor ve ikisi arasındaki en küçük fark ay sonunda mutabakat toplantısına dönüşüyor. Fatura sayısı ayda 200’ü geçtiğinde bu ikinci giriş bir kişinin tam zamanlı işine dönüşür ve hataların çoğu ancak beyanname döneminde ortaya çıkar. E-fatura entegrasyonu bu tekrarın ortadan kalkması demektir: fatura, işin bittiği yerde doğar.

Türkiye’de e-fatura belirli ciro eşiklerinin üzerindeki mükellefler için yıllardır zorunlu ve portal üzerinden elle kesim küçük hacimlerde çalışıyor. Sorun zorunluluğun kendisi değil, faturanın operasyon sisteminizden kopuk doğması. Bu rehber entegrasyonun iki yüzünü birlikte anlatıyor: köprünün nasıl kurulduğu, hangi hataların çıktığı ve mutabakatın nasıl kendiliğinden çalıştığı — ve kesilen belgenin muhasebe programına nasıl aktığı.

Üç katman: operasyon, köprü, muhasebe

Çalışan bir entegrasyonun üç ayrı katmanı vardır ve bunları birbirine karıştırmak, sonradan düzeltilmesi en pahalı hatadır.

Katman	Ne yapar	Sahibi	Değişme sıklığı
1. Operasyon	Siparişi, irsaliyeyi, hakedişi doğurur; faturanın tetikleyicisi buradadır	Sizin sisteminiz	Sık — iş kuralı değişir
2. Köprü	UBL-TR belgesini üretir, entegratöre gönderir, durum yanıtını okur, kuyruğu yönetir	Entegratör + köprü kodu	Nadir — mevzuat değişince
3. Muhasebe	Kesilen belgeyi muhasebe fişine çevirir, cari ve KDV kayıtlarını besler	Muhasebe programı	Nadir — hesap planı değişince

Katmanları ayrı tutmanın karşılığı şu: entegratörünüzü değiştirdiğinizde yalnız ikinci katmanı elden geçirirsiniz. Üçünü tek kod bloğunda birleştiren projelerde entegratör değişikliği baştan yazım anlamına gelir.

Köprü katmanının içinde de üç taraf vardır ve hangi hatanın kimde çözüleceği ancak ayrıldığında netleşir:

Taraf	Sorumluluğu	Sizden beklediği
Sizin sisteminiz	Belgeyi üretmek, senaryoyu seçmek, durumu izlemek, hatayı göstermek	Doğru vergi kimliği, doğru birim ve vergi kodları
Entegratör	Belgeyi zarflayıp GİB'e iletmek, yanıtı geri döndürmek, saklamak	Geçerli mali mühür ve sözleşme, geçerli belge biçimi
GİB	Belgeyi kabul veya reddetmek, alıcıya iletmek	Biçim ve senaryo kurallarına uyum

Doğru kurgunun dört kuralı

1. Fatura tek bir yerde doğar. Tetikleyici tek olmalı: sevkiyat onayı, hakediş kabulü ya da sipariş kapanışı. İki farklı ekrandan fatura kesilebiliyorsa mükerrer belge kaçınılmazdır.

2. Her belge önce sizde, sonra dışarıda. Belge kendi veritabanınıza taslak olarak yazılır, sonra kuyruğa girer. Böylece entegratör yanıt vermediğinde kayıt kaybolmaz, bekler.

3. Durum geri bildirimi ekrana yazılır. Gönderildi, kabul edildi, reddedildi, iptal edildi — bu durumları operasyon ekranında gören kişi, muhasebeciyi aramadan işini yapar.

4. Hata kuyruğunun bir sahibi vardır. Kuyruğu kimin, hangi sıklıkla açacağı isim olarak belirlenir. Sahipsiz kuyruk, dolu kuyruktur.

Senaryo seçimi: e-fatura mı, e-arşiv mi

Belgenin hangi kanaldan gideceğini alıcının sistemde kayıtlı olup olmaması belirler. Fatura kesilmeden önce alıcının vergi kimlik numarası mükellef listesiyle karşılaştırılır; listede varsa e-fatura, yoksa e-arşiv üretilir.

Bu kontrolün otomatik ve her belgede canlı olması şart. Müşteri kartına bir kez yazılıp bırakılırsa mükellefiyeti değişen firmaya yanlış belge türü gider ve belge reddedilir. Elle yapıldığında iki hata düzenli olarak tekrarlanır: mükellef olan bir alıcıya e-arşiv göndermek ve listeden yeni çıkmış bir alıcıya e-fatura göndermek. İkisi de ret üretir, ret düzeltme işi doğurur, düzeltme muhasebede ek kayıt demektir. Mükellef listesini günlük tazeleyen bir arka plan işi bu hataların büyük bölümünü baştan keser.

Belgenin geçtiği durumlar

Entegrasyonun kalbi, faturanın yaşam döngüsünü sistemde görünür kılmaktır. Aşağıdaki durum listesi olmadan kullanıcı “fatura gitti mi” sorusuna cevap veremez.

Durum	Anlamı	Kullanıcı ne yapar
Taslak	Belge üretildi, henüz gönderilmedi	Kontrol eder, gönderime alır
Kuyrukta	Gönderim sırası bekliyor	Bekler
Gönderildi	Köprü belgeyi teslim aldı	Yanıtı bekler
Kabul edildi	Karşı taraf belgeyi aldı	İşlem tamam; muhasebe fişi oluşur
Reddedildi	Biçim, senaryo veya içerik hatası	Sebebi okur, düzeltir, yeniden gönderir
Hata kuyruğunda	Teknik sebeple gönderilemedi	Sebebi görür, yeniden dener

Durum bilgisi faturanın kendi ekranında görünmelidir. Ayrı bir yönetim ekranına saklanan durum, hiç kimsenin bakmadığı bir bilgidir.

Hata senaryoları ve bunları kimin göreceği

Sahada tekrar eden hatalar sınırlı sayıdadır ve hepsi öngörülebilir. Entegrasyonu ayıran şey hataların olmaması değil, hatanın kime, ne zaman ve hangi cümleyle gösterildiğidir.

Senaryo	Ne olur	Doğru kurgu
Köprü geçici olarak cevap vermiyor	Belge gönderilmiş görünür ama gitmemiştir	Yanıt alınana kadar durum "kuyrukta" kalır, otomatik yeniden deneme yapılır
Ağ koptu, işlem tekrarlandı	Aynı fatura iki kez oluşur	Her belgeye tek gönderim kimliği; tekrar denemede yeni belge doğmaz
Alıcının vergi kimliği hatalı	Belge reddedilir	Kayıt açılırken doğrulama, fatura öncesi ikinci kontrol
Yanlış senaryo seçildi	Ret ve düzeltme belgesi gerekir	Mükellef listesi güncel tutulur, seçim otomatik yapılır
Birim veya vergi kodu tanımsız	Biçim hatası döner	Ürün kartında kod zorunlu alan, kaydederken doğrulanır
Mali mühür süresi doldu	Gönderim tamamen durur, sebebi ilk gün anlaşılmaz	Bitiş tarihi sistemde tutulur, süre dolmadan önce uyarı çıkar
Yuvarlama farkı	Satır ve toplam yuvarlaması farklı, kuruş farkı birikir	Yuvarlama kuralı tek yerde tanımlanır, muhasebe aktarımı aynı kuralı kullanır
İade veya iptal talebi geldi	Elle takip edilir, kaçar	Gelen itiraz, iade ve düzeltme akışı da sisteme bağlanır

İkinci satır özellikle önemli. Çift gönderim koruması, entegrasyonun en sessiz ama en gerekli parçasıdır: her faturaya sistemde tek bir gönderim kimliği verilir, köprüye yapılan her çağrı bu kimliği taşır. Bağlantı koptuğunda işlem tekrarlanır ama köprü aynı kimliği gördüğü için ikinci belge oluşmaz. Bir de test kuralı: reddedilen faturanın ekranda ne olacağını canlıda öğrenmeyin — test ortamında ret senaryosu bilinçli tetiklenir.

Muhasebe aktarımı: fiş, cari, KDV

Belge kabul edildiğinde üçüncü katman devreye girer. Kabul edilen fatura muhasebe programının beklediği biçimde fişe çevrilir: cari hesap, KDV kırılımı, hesap planı kodları ve belge tarihi. Aktarım yolu programa göre değişir — dosya aktarımı ya da API — ama kural aynıdır: fiş, kabul durumuna bağlıdır. Reddedilen belge muhasebeye düşmez; iptal edilen belgenin fişi ters kayıtla kapanır.

Programa göre bağlantı yolları ayrı yazılarda: Logo, Netsis REST API, Mikro, DİA Web Servis API (e-belge servisleri efa_ ön ekiyle modülün içinde), SAP Business One Service Layer (e-belge yerelleştirme eklentisinde) ve Paraşüt API (fatura Paraşüt’te doğar, e-belge oradan gider). Muhasebe programınız bu listede yoksa aktarım, programın kabul ettiği dosya biçimiyle kurulur.

Gelen fatura tarafı: entegrasyonun yarım kaldığı yer

Projelerin çoğu giden faturayı otomatikleştirip durur. Gelen taraf elde kaldığında satın alma faturaları hâlâ tek tek girilir; bu ikinci yazım iki yerde bozulur: stok maliyeti gerçek alış fiyatını göstermez ve cari bakiye tedarikçiyle mutabakat gününe kadar sallanır.

Gelen tarafın doğru kurgusu üç adımdır. Belgeler köprüden düzenli olarak okunur ve satır satır sisteme yazılır. Belge, açık satın alma siparişi veya irsaliye ile eşleştirilir; adet veya fiyat tutmuyorsa kayıt onay bekleyen kutusuna düşer. Onay verilince stok girişi ve muhasebe fişi aynı anda oluşur. Ret süresi de burada takip edilir: itiraz penceresi kaçırılan fatura, istemediğiniz bir maliyeti defterinize kalıcı olarak yazar. Sevkiyat belgesi tarafı için e-irsaliye entegrasyonu, eşleştirme kuralları için fatura eşleştirme otomasyonu yazılarına bakın.

Mutabakat: günlük üç sayı, aylık karşılaştırma

Mutabakatı ay sonuna bırakmak, farkın kaynağını bulmayı en zor hâle getirmektir. İşe yarayan düzen iki katmanlıdır.

Günlük sayım. Gün sonunda üç sayı karşılaştırılır: sistemde kesilen belge sayısı, entegratörde kabul edilen belge sayısı ve muhasebeye düşen fiş sayısı. Üçü eşit değilse fark aynı gün araştırılır. Bu kontrol otomatik yapılır ve sonucu bir ekranda görünür.

Aylık karşılaştırma. Muhasebe kayıtlarındaki fatura toplamı ile portal kayıtları karşılaştırılır. Fark çıkarsa sebebi genellikle üç yerdedir: iptal edilmiş ama sistemde kapatılmamış belge, elle girilmiş fatura, ya da iade sürecinde takılı kalmış kayıt.

Denetimli devreye alma: altı adım

1. Akış haritası (2-3 gün). Hangi belge hangi tetikleyiciyle doğacak, kim onaylayacak, hangi durumda elle müdahale gerekecek?
2. Entegratör sözleşmesi ve test erişimi. Geliştirmeyle paralel yürür; mali mühür ve ön kayıt işlemleri tamamlanır.
3. Geliştirme (1-2 hafta). Belge üretimi, senaryo seçimi, durum takibi, hata kuyruğu ekranı, çift gönderim koruması ve muhasebe aktarımı.
4. Test ortamı (3-5 gün). Her belge türü ve her senaryo bir kez üretilir; ret senaryosu bilinçli tetiklenir, hata kuyruğunun çalıştığı görülür.
5. Dar pilot (1 hafta). Tek bir müşteri grubunun ya da tek bir şubenin faturaları yeni akıştan geçer, kalan hacim eski yöntemle devam eder. Her akşam üç sayı karşılaştırılır; üçü eşit değilse gün kapanmaz.
6. Hacmi açma ve eski yolu kapatma. İki hafta üst üste üç sayı tuttuğunda tüm hacim yeni akışa alınır ve portaldan elle kesim yetkisi kaldırılır. Bu son adım atlanırsa bir kişi alışkanlıkla elle kesmeye devam eder ve mükerrer belge doğar.

Aynı disiplini stok tarafında da kurmak isterseniz WMS depo yönetim sistemi rehberi sevkiyattan faturaya giden zinciri anlatıyor.

Ne zaman özel entegrasyon gerekmez

Dürüst sınır: faturanız muhasebe programında doğuyorsa ve sipariş akışınız zaten orada yürüyorsa, paketin kendi e-fatura modülü yeterlidir. Özel entegrasyon, fatura sizin kendi sisteminizde doğduğunda anlamlıdır: sipariş, sevkiyat, hakediş veya servis kapanışı faturayı tetikliyorsa, aradaki elle aktarımı kaldırmak kalıcı bir kazançtır.

Maliyet ve geri dönüş

Maliyet üç kalemden oluşur: entegratörün belge başına aldığı bedel, geliştirme ve bakım. Geliştirme tarafı iki bantta ilerler:

• Fatura zaten sizin sisteminizde doğuyorsa köprü ve muhasebe aktarımı ek modül bandına girer: 8.000 - 45.000 ₺, kapsama göre.
• Sipariş kapanışından e-faturaya giden akış sıfırdan kuruluyorsa tek süreç bandı geçerlidir: 80.000 - 150.000 ₺ ve 2-4 hafta.

Entegratörün kontör ücreti sizinle entegratör arasındaki sözleşmeye göre ayrıca işler. Bant tanımlarının tamamı fiyat sayfasında yazılı; yatırımı elle harcanan saate karşı ölçmek için ROI hesaplama rehberi birlikte okunmalı.

Muhasebe ve ERP tarafındaki bağlantı kurgularını entegrasyon sayfasında topladık. Fatura akışınızı nerede elle taşıdığınızı bir cümleyle yazın; hangi katmanın eksik olduğunu ve ilk fazın süresini birlikte çıkaralım — teklif formundan başlayabilirsiniz.

---

İlgili Depo Rehberleri ve Hesaplayıcılar

• Sevkiyat Hatası ve İade Maliyeti Hesaplayıcı — Deponuzdaki yanlış ürün gönderimlerinin yıllık çift kargo maliyetini hesaplayın.
• En İyi WMS ve Barkodlu Depo Yönetim Programları — Logo, Mikro, Nebim, DİA ve özel WMS sistemleri karşılaştırması.
• Depo Sevkiyat ve Barkod Kontrol Fiyatları — Paketleme masası ve doğrulama istasyonu bütçe rehberi.
• WMS Depo Yazılımı Fiyatları 2026 — Depo otomasyonu ve adresli raf yönetimi maliyetleri.

Sıkça sorulan sorular

Entegratör kullanmak zorunda mıyım?

Zorunlu değil ama pratikte en yaygın yol budur. Özel entegratör, GİB tarafındaki iletişimi, saklamayı ve zarf takibini üstlenir; siz yalnız belgeyi doğru üretip köprüye vermekle ilgilenirsiniz. KodDelta projelerinde entegratör seçimi müşterinin, köprünün yazımı ve hata yönetimi bizim tarafımızdadır.

Entegratörü biz mi seçiyoruz, siz mi?

Entegratör sözleşmesi sizin adınıza yapılır, seçim sizindir. Köprü katmanı entegratör değiştirilebilir olacak şekilde kurgulanır: fatura üretimi ve gönderim ayrı katmanlarda durduğu için entegratör değişikliği sistemin tamamını değil, yalnız köprüyü etkiler.

e-Fatura ile e-arşiv arasındaki farkı sistem nasıl bilir?

Alıcının sistemde kayıtlı olup olmamasına bakarak. Fatura kesilmeden önce alıcının vergi kimlik numarası mükellef listesiyle karşılaştırılır; listede varsa e-fatura, yoksa e-arşiv üretilir. Bu kontrol otomatik yapılmazsa yanlış senaryo gönderilir ve belge reddedilir. Mükellef listesi düzenli olarak güncellenmelidir.

Aynı fatura iki kez gönderilirse ne olur?

Çift belge, ret veya mükerrer kayıt üretir ve düzeltmesi elle yapılır. Bunu önlemenin yolu, her faturaya sistemde tek bir gönderim kimliği vermek ve köprüye yapılan çağrının bu kimlikle tekrarlanabilir olmasıdır. Ağ hatası sonrası tekrar denendiğinde köprü aynı kimliği görür ve ikinci bir belge oluşturmaz.

Gönderim başarısız olursa fatura kaybolur mu, kullanıcı bunu nereden görür?

Doğru kurguda kaybolmaz. Her belge önce kendi veritabanınıza taslak olarak yazılır, sonra kuyruğa alınır; entegratör yanıt vermezse belge kuyrukta bekler. Başarısız her belge sebebiyle birlikte hata kuyruğu ekranında durur, sorumlusuna bildirim gider ve düzeltilip tek tuşla yeniden gönderilir. Bu ekran olmadan kurulan entegrasyonlarda gönderilmemiş fatura aylarca fark edilmez.

Muhasebe programımızı değiştirmemiz gerekir mi?

Hayır. Aktarım katmanı muhasebe programınızın kabul ettiği formatta — dosya aktarımı veya API — çalışır. Amaç muhasebeyi değiştirmek değil, aynı kaydın operasyonda ve muhasebede ikinci kez elle girilmesini bitirmektir. Logo, Netsis, Mikro, DİA, SAP Business One ve Paraşüt için ayrı bağlantı rehberlerimiz var.

Gelen faturalar da sisteme işlenmeli mi?

Evet, yoksa entegrasyon yarım kalır. Yalnız giden tarafı otomatikleştiren kurulumlarda satın alma faturaları elle girilmeye devam eder ve stok ile muhasebe arasındaki fark büyür. Gelen belgeler köprüden okunup sipariş veya irsaliye ile eşleştirildiğinde mutabakat kendiliğinden çıkar.

Mutabakat ne sıklıkta yapılmalı?

Günlük bir sayım ve aylık bir karşılaştırma yeterlidir. Günlük kontrol üç sayıyı eşleştirir: sistemde kesilen belge, entegratörde kabul edilen belge, muhasebeye düşen fiş. Aylık kontrol muhasebe kayıtlarıyla portal kayıtlarını tutar. Fark sıfır değilse sebebi aynı gün araştırılır; biriken farkın kaynağını ay sonunda bulmak çok daha zordur.

İlgili rehberler

• Logo ve Netsis entegrasyon rehberi: REST API, Objects ve özel web/mobil arayüz köprüsü
• DİA Web Servis API: kendi yazılımınızı DİA'ya nasıl bağlarsınız?
• Nebim V3 Entegratör REST API: perakende ERP'nizi dış sistemlere nasıl bağlarsınız?

Hizmet sayfası: Entegrasyon hizmeti