E-Ticarette Otomatik Faturalandırma

E-ticarette otomatik faturalandırma, bir sipariş kaydını tek tuşla PDF'e çevirmekten daha kapsamlıdır. Doğru olayın beklenmesi, alıcının güncel e-Fatura statüsünün belirlenmesi, ürün ve vergi alanlarının doğrulanması, yasal belgenin güvenli biçimde gönderilmesi, teknik ve ticari yanıtların izlenmesi, müşteriye iletim ve muhasebe mutabakatı aynı zincirin parçalarıdır. Zincirin herhangi bir halkası görünmez kalırsa hız artarken hata da ölçeklenebilir.

Bu içerikte “kesintisiz akış”, sıfır hata veya yüzde yüz çalışma süresi garantisi değildir. Siparişin kaybolmadığı, aynı olayın iki belge üretmediği, kesintinin kuyruğa alınabildiği, belirsiz sonucun sorgulandığı ve insan müdahalesinin denetlenebilir olduğu uçtan uca yönetim modelidir. Genel şirket ve ETBİS hazırlığı için e-ticaret için gerekli belgeler rehberi, burada anlatılan e-belge kararlarının daha geniş çerçevesini verir.

Siparişten E-Belgeye Kesintisiz Akış Ne Anlama Gelir?

Kesintisiz akış; kanal olayının dayanıklı kaydı, fatura adayının doğrulanması, tekil belge üretimi, dış durumların geri okunması ve finansal farkın kapatılması boyunca sahipliğin kaybolmamasıdır. Servis kesilebilir veya kayıt hata alabilir; önemli olan belgenin sessizce kaybolmaması, kontrolsüz tekrar edilmemesi ve toparlanma kanıtının bulunmasıdır.

Bu nedenle iş sürekliliği yalnız teknik erişilebilirlik değil; kuyruk, idempotency, manuel prosedür, müşteri iletişimi, mutabakat ve uzman kararını birlikte kapsar.

E-Ticarette Otomatik Faturalandırma Nedir?

Otomatik faturalandırma; sipariş, ödeme, sevkiyat veya onay gibi bir iş olayını, önceden tanımlanmış kurallarla e-Fatura ya da e-Arşiv Fatura sürecine bağlayan kontrollü sistemdir. Otomasyonun çıktısı yalnız belge değildir; hangi veriyle, hangi kural sürümüyle, hangi zamanda ve hangi yanıtla işlem yapıldığını gösteren izdir. Fatura ile sipariş, tahsilat, stok ve muhasebe kayıtları arasında kalıcı referanslar bulunmalıdır.

Aşağıdaki tablo, siparişten kapanışa kadar sorumluluğun nerede değiştiğini gösterir.

Aşama	Girdi	Temel kontrol	Çıktı	Sorumlu
Sipariş yakalama	Kanal siparişi	Kanal ve sipariş kimliği	Tekil sipariş kaydı	E-ticaret operasyonu
Tetikleme	Ödeme, onay veya sevkiyat olayı	İptal, risk ve durum	Fatura adayı	Finans ve operasyon
Doğrulama	Alıcı ve satırlar	Statü, vergi, toplam	Onaylı taslak	Finans
Belge üretimi	Onaylı taslak	Seri, ETTN, şema	UBL-TR belge	E-belge sistemi
Gönderim ve izleme	İmzalı belge	Teknik/ticari durum	Sonuç ve kanıt	Entegrasyon ekibi
Kapanış	Belge ve yanıt	Muhasebe, stok, cari farkı	Mutabık kayıt	Muhasebe

Karar çıkarımı: “Fatura oluşturuldu” tek başına bitiş durumu değildir; gönderim, yanıt, iletim ve mutabakat ayrı tamamlanma ölçütleri taşımalıdır.

Sipariş, Ödeme, Tahsilat, Sevkiyat ve Fatura Aynı Şey midir?

Sipariş müşterinin talebini, ödeme tahsilat olayını, sevkiyat fiziksel hareketi, fatura yasal belgeyi, muhasebe fişi ise finansal kaydı temsil eder. Bunların zamanları ve yaşam döngüleri farklıdır. e-ticaret operasyonu yönetimi genel akışı açıklar; fatura otomasyonu bu akıştan yalnız doğrulanmış olayları tüketmelidir.

Bu ayrım, tek bir “tamamlandı” alanına bağlı hatalı otomasyonu önler.

Kayıt	Ne kanıtlar?	Tekil kimlik	Değişebilir mi?	Faturayla bağ
Sipariş	Satın alma talebi	Kanal + sipariş no	İptal/satır değişimi olabilir	Kaynak referans
Ödeme	Tahsilat girişimi/sonucu	İşlem no	İade/chargeback olabilir	Tetikleyici veya mutabakat
Tahsilat	Finansal gerçekleşme	Sağlayıcı referansı	Parçalı olabilir	Cari kapama
Sevkiyat	Malın paket hareketi	Paket/sevkiyat no	Bölünebilir	Satır/miktar referansı
Fatura	Yasal satış belgesi	Belge no + ETTN	Silinmez; mevzuata uygun süreç izlenir	Merkez belge
Muhasebe fişi	Defter/kayıt işlemi	Fiş no	Düzeltme kaydı olabilir	Finansal kapanış

Karar çıkarımı: Her nesnenin kimliğini ayrı saklayın ve aralarındaki ilişkiyi kurun; birini silerek diğerinin durumunu düzeltmeye çalışmayın.

E-Fatura, E-Arşiv Fatura ve E-İrsaliye Arasındaki Fark Nedir?

Belge seçimi, müşterinin bireysel ya da kurumsal görünmesinden ibaret değildir. Alıcının güncel e-Fatura kayıt durumu, işlemin niteliği ve işletmenin yükümlülüğü birlikte değerlendirilir. GİB e-Fatura mevzuat ve teknik kaynakları ile güncel tebliğ esas alınmalı; kişisel işlem için mali müşavir görüşü alınmalıdır.

Aşağıdaki karşılaştırma kavramsal yönlendirme verir; kesin belge kararı değildir.

Belge	Ana amaç	Alıcı/kanal	Otomasyonda kritik kontrol	Karıştırılmaması gereken
e-Fatura	Faturanın elektronik ağda iletimi	Kayıtlı kullanıcılar arası uygun işlemler	UserList, alias, senaryo ve yanıt	PDF e-postası
e-Arşiv Fatura	e-Fatura dışındaki uygun fatura akışı	İşleme ve alıcı statüsüne göre	İnternet satış alanları ve raporlama	e-Fatura ret akışı
e-İrsaliye	Mal hareketinin elektronik belgesi	Mevzuat kapsamındaki sevkiyat	Sevkiyat ve satır eşleştirmesi	Satış faturası

Karar çıkarımı: Belge türünü sabit müşteri etiketiyle değil, işlem anındaki doğrulanmış kayıt ve kuralla belirleyin; e-İrsaliyeyi fatura yerine kullanmayın.

2026 Yılında E-Fatura ve E-Arşiv Yükümlülüğü Nasıl Doğrulanır?

14.07.2026 tarihinde güncel metin, 509 Sıra No.lu Vergi Usul Kanunu Genel Tebliği ile onu değiştiren düzenlemelerin birlikte okunmasını gerektirir. değişiklikler işlenmiş güncel 509 Tebliğ metni, 2026 tutar ve grup istisnalarını bağlamıyla gösterir. Bu nedenle eski “belirli eşiğin altı kâğıt olabilir” özeti veya “2026'da istisnasız herkes” iddiası tek başına kullanılmamalıdır.

Doğrulama, aşağıdaki adımları belgeleyen bir karar kaydı üretmelidir.

Adım	Soru	Kaynak	Kanıt	Uzman kontrolü
1	Satıcı hangi e-belge kapsamlarında?	GİB kayıtları ve güncel Tebliğ	Tarih damgalı kayıt	Mali müşavir
2	Alıcı e-Fatura kullanıcısı mı?	Güncel UserList	Sorgu zamanı ve alias	Gerekirse entegratör
3	İşlem hangi gruba giriyor?	509 ve değişiklikleri	İşlem sınıfı	Vergi uzmanı
4	Tutar/tarih/geçiş kuralı nedir?	Güncel konsolide metin	Kural sürümü	Mali müşavir
5	İstisna veya özel belge var mı?	İlgili mevzuat/kılavuz	Onay notu	Uzman görüşü

Karar çıkarımı: Otomasyon kuralına yalnız sonuç değil, dayanak, yürürlük tarihi, sürüm ve onaylayan rol de yazılmalıdır.

GİB Portal, Doğrudan Entegrasyon ve Özel Entegratör Nasıl Karşılaştırılır?

Üç yöntem de farklı işletim yükü taşır. GİB Portal daha fazla manuel iş gerektirebilir; doğrudan entegrasyon teknik, güvenlik ve süreklilik sorumluluğunu büyütür; özel entegratör hazır hizmet sunabilir fakat sözleşme, veri taşınabilirliği ve ücret kuralları ayrıca incelenir. GİB e-Belge ana sayfası kayıtlı kullanıcı, özel entegratör, portal ve duyuru bağlantıları için başlangıç noktasıdır.

Kararı yalnız işlem başı fiyata göre vermeyin.

Yöntem	Otomasyon	İç sorumluluk	Ölçek uygunluğu	Başlıca risk
GİB Portal	Sınırlı/manuel ağırlıklı	Operasyon kullanıcıları	Düşük hacim ve basit süreç	İş gücü ve gecikme
Doğrudan entegrasyon	Yüksek özelleştirme	Teknik altyapı, sertifika, izleme	Yetkin ekip ve uygun hacim	Bakım ve süreklilik yükü
Özel entegratör	API/hazır bağlantıya göre	Paylaşılan sorumluluk	Değişken hacim ve hızlı kurulum	Kapsam, bağımlılık, çıkış

Karar çıkarımı: İşlem hacmi kadar istisna çeşitliliği, iç teknik yetkinlik, destek ve veri çıkış planı yöntemi belirlemelidir.

Özel Entegratör Seçerken Neler Doğrulanmalıdır?

“Entegrasyonumuz var” sözü, hangi belgeyi, hangi kanalı ve hangi hata davranışını kapsadığını göstermez. GİB'in e-Fatura Özel Entegrasyon Kılavuzu v1.14; test, işlem kaydı, kapasite, iş sürekliliği ve güvenlik gibi işletim alanlarının önemini gösterir.

İlk eleme için kanıt odaklı matris kullanın.

Kriter	Beklenen kanıt	İyi işaret	Kırmızı bayrak
GİB yetkisi	Güncel resmî liste kaydı	Unvan ve hizmet eşleşiyor	Yalnız logo gösterimi
API kapsamı	Sürümlemeli teknik doküman	Durum, hata ve idempotency açık	Sadece demo
İş sürekliliği	RTO/RPO ve test özeti	Rol ve bildirim tanımlı	“Hiç kesilmez” vaadi
Arşiv/çıkış	Örnek dışa aktarım	XML, metadata ve bütünlük	Sözleşme sonunda belirsizlik
Güvenlik	Bağımsız denetim ve politika	Bulgular için kapanış süreci	Yalnız “TLS var” cevabı

Karar çıkarımı: Demo davranışını sözleşme eki, teknik doküman ve kabul testiyle bağlamadan üretim kararı vermeyin.

Fatura Hangi Sipariş Durumunda Tetiklenmelidir?

Tetikleyici, “sipariş geldi” olayından daha hassas bir iş kararıdır. Ödeme yöntemi, iptal penceresi, stok teyidi, sevkiyat politikası, hizmetin ifası ve mevzuat birlikte değerlendirilir. Tetikleyicinin gecikme, yanlış belge ve müşteri deneyimi riskleri finans, operasyon ve mali müşavir tarafından onaylanmalıdır.

Durum matrisi, her siparişin otomatik geçip geçmeyeceğini açıklar.

Karar çıkarımı: Tetikleyiciyi tek statü yerine ön koşullar, istisnalar ve geri alınamaz belge etkisiyle tanımlayın.

Ödeme Yöntemine Göre Fatura Tetikleyicisi Nasıl Değişir?

Ödeme yönteminin adı, tahsilatın kesinleştiğini tek başına göstermez. Sanal POS yetkilendirmesi, havalenin hesaba geçmesi, kapıda ödemenin teslim sonucu ve açık hesap onayı farklı olaylardır. Tahsilat mimarisinin genel çerçevesi için e-ticaret ödeme sistemleri rehberine bakılabilir.

Aşağıdaki kararlar temsili politikadır; işletme ve işlem özelinde onaylanmalıdır.

Karar çıkarımı: “Ödendi” alanının kaynağını ve geri dönüşlerini belgeleyin; ödeme adı üzerinden varsayım yapmayın.

Ön Sipariş, Backorder ve Kısmi Ödeme Nasıl Faturalandırılır?

Ön siparişte teslim veya ifa henüz gerçekleşmemiş olabilir; backorder kaydında stok sonraki tarihte tamamlanır; kısmi ödemede tahsilat sipariş toplamının yalnız bölümünü karşılar. Bu üç durum normal “ödendi ve hazır” akışına düşürülmemeli, ayrı durum ve tetikleyici politikasıyla yönetilmelidir.

Belgenin zamanı, tutarı ve satır kapsamı güncel mevzuat ile mali müşavir görüşüne göre onaylanmalı; kalan ödeme, kalan miktar ve sonraki sevkiyat referansları kaybolmamalıdır.

Alıcının E-Fatura Kullanıcısı Olup Olmadığı Nasıl Belirlenir?

Alıcı e-Fatura kaydı zaman içinde değişebilir. Bu nedenle müşteri kartındaki eski bir bayrak yerine güncel kullanıcı listesi sorgulanmalı, sorgu zamanı ve kullanılan alias saklanmalıdır. UserList Kullanıcı Listeleri Kılavuzu v1.0 teknik veri modelini ve güncel yaklaşımı açıklar.

Karar ağacını kişi/şirket etiketiyle sınırlamayın.

Karar çıkarımı: Sorgu başarısızsa varsayılan belge basmak yerine kaydı istisna kuyruğuna alın.

UserList, Etiket ve Posta Kutusu Kavramları Neden Önemlidir?

UserList kayıtlı e-Fatura kullanıcılarını, etiket/alias ise gönderici veya alıcı posta kutusu yönlendirmesini anlamaya yardımcı olur. Kullanıcının birden fazla etiketi bulunabilir ve bu bilgi değişebilir; entegrasyon liste sürümünü, sorgu zamanını ve seçilen etiketi saklamalıdır.

Eski alias'a gönderim veya geçici sorgu hatasında yanlış belge türü seçimi, güncel liste ve kontrollü istisna davranışıyla önlenir.

Bireysel ve Kurumsal Alıcı Ayrımı Nasıl Yapılır?

Checkout'taki “bireysel/kurumsal” seçimi veri toplama ve doğrulama için yararlıdır ancak tek başına yasal belge kararını vermez. Kimlik türü, alıcının güncel e-Fatura kaydı, işlemin niteliği ve geçerli mevzuat birlikte değerlendirilir.

Kurumsal seçimde VKN/unvan ve gerekebilecek diğer alanlar; bireysel seçimde ilgili kimlik/adres alanları doğrulanır. Kararsız veya çelişkili kayıt otomatik varsayımla değil, insan incelemesiyle çözülür.

Otomatik Fatura İçin Hangi Müşteri Verileri Gereklidir?

Otomasyon, eksik veriyi hızla hatalı belgeye dönüştürmemelidir. VKN/TCKN, unvan/ad, adres, vergi dairesi, ülke, e-posta ve alıcı kimliği için biçim, zorunluluk ve kaynak kontrolleri ayrılmalıdır. Checkout tasarımında veri toplama amacı, zorunluluk ve müşteri deneyimi birlikte değerlendirilmelidir.

Alan bazında doğrulama sözlüğü kurun.

Karar çıkarımı: Hatalı kimliği “diğer” değerle geçmek yerine belgeyi kontrollü bekletmek daha güvenlidir.

E-Arşiv İnternet Satış Bilgileri Nasıl Doldurulur?

İnternet satışında web adresi, ödeme bilgileri, ödeme aracısı, ödeme tarihi ve taşıyıcı gibi alanlar işlem bağlamına göre önem taşır. e-Arşiv Teknik Kılavuzu v1.18 güncel teknik alanları açıklar. Alanları sağlayıcı ekranındaki tek metin kutusuna bırakmak yerine kaynak sistem ve doğrulama kuralı belirlenmelidir.

İnternet satış veri sözlüğü aşağıdaki gibi kurulabilir.

Karar çıkarımı: Kanal, ödeme ve kargo alanlarını sipariş anında snapshot olarak koruyun; sonradan değişen mağaza ayarı geçmiş belgeyi etkilemesin.

Ürün, SKU, Birim ve Vergi Verileri Nasıl Eşleştirilir?

Fatura satırı, ürün adını kopyalamaktan ibaret değildir. Satılan varyantın SKU'su, miktar birimi, net/brüt tutar, vergi oranı, istisna/tevkifat gibi koşullu alanlar, iskonto ve kargo satırı aynı toplamı yeniden üretmelidir. Veri hazırlığının genel çerçevesi için e-ticaret ürün hazırlama rehberi kullanılabilir.

Önce ürün alanlarının tekil sahiplerini belirleyin.

Karar çıkarımı: Eksik mapping'i genel bir varsayılan KDV veya birimle kapatmayın; finans onaylı veri sözlüğü oluşturun.

KDV, İstisna, Tevkifat ve Özel Vergi Alanları Nasıl Yönetilir?

Vergi kararı yalnız SKU üzerindeki tek bir oran alanından gelmemelidir. Ürün/hizmet, alıcı, teslim veya ifa tarihi, işlem türü ve geçerli istisna/tevkifat koşulları sürümlü kuralda değerlendirilir; gerekçe ve ilgili alanlar güncel UBL-TR yapısına taşınır.

Özel vergi kuralı varsayılan orana düşmemeli, finans ve mali müşavir onayı olmadan üretime alınmamalıdır. Değişiklikte geçmiş belge yeniden yazılmaz; yeni yürürlük tarihli kural ve regresyon testi uygulanır.

İskonto, Kupon, Hediye Çeki ve Sadakat Puanı Faturaya Nasıl Yansıtılır?

Kampanya bileşenleri ayrı satır ve dağıtım kuralları gerektirir; fiyat stratejisi için e-ticarette fiyatlandırma rehberi, burada ise belge eşleştirmesi esas alınır.

Karar çıkarımı: Kuponu tek negatif satıra çevirmeden önce vergi ve dağıtım kuralını onaylatın; kampanya kurgusu değiştiğinde mapping sürümünü de değiştirin.

Kargo ve Diğer Hizmet Bedelleri Nasıl Faturalanır?

Kargo, paketleme, kurulum veya başka hizmet bedelleri sipariş toplamında görünse de ürün satırına gizlice eklenmemelidir. Bedelin tarafı, vergi kuralı, ücretsiz kargo indirimi ve pazaryeri desteği ayrı bileşenler olarak hesaplanmalı; belge satırları sipariş toplamını yeniden üretmelidir.

İade sırasında hizmet bedelinin etkisi de otomatik varsayılmamalı; işletmenin onaylı iade ve vergi politikasına bağlanmalıdır.

Döviz, Kur Tarihi ve Yuvarlama Farkları Nasıl Yönetilir?

Farklı sistemlerin satır, vergi ve toplam düzeyinde ayrı yuvarlama yapması kuruş farklarına yol açar. Kur kaynağı, kur zamanı, fiyatın net/brüt oluşu, ondalık hassasiyet ve dağıtım algoritması sözleşmeye bağlanmalıdır.

Hesaplama sırasını örnek belgeyle kabul testine alın.

Karar çıkarımı: Tutar farkını toleransla gizlemek yerine aynı hesaplama sırasını paylaşın; tolerans yalnız inceleme eşiğidir.

UBL-TR Nedir ve Sipariş Verisi Faturaya Nasıl Dönüşür?

UBL-TR, e-belge verisinin standart yapısını ifade eder. İşletmenin sipariş modeli doğrudan UBL-TR değildir; arada sürümlenen, test edilen ve sahipliği belirli bir mapping katmanı gerekir. Genel API ve veri sahipliği mimarisi e-ticaret ERP entegrasyonu rehberinde daha geniş ele alınır.

Kavramsal mapping, teknik alan adından önce iş anlamını sabitler.

Karar çıkarımı: Mapping'i kodun içine dağılmış koşullar olarak değil, sürümü ve onay kaydı olan veri sözlüğü olarak yönetin.

Şema ve Schematron Doğrulaması Neden Gönderimden Önce Yapılmalıdır?

Şema yapısal biçimi, Schematron ise belge içindeki bağlamsal iş kurallarını denetlemeye yardımcı olur. Doğrulamayı yalnız dış sistem hatasına bırakmak gereksiz gönderim, gecikme ve zor yorumlanan hata yanıtları üretir.

Belge adayı üretildiğinde güncel sürümle iki kontrol de çalıştırılmalı, hata alanı kullanıcıya iş diliyle gösterilmeli ve mapping sürümü test kanıtına yazılmalıdır.

Fatura Seri/Sıra Numarası ve ETTN/UUID Nasıl Yönetilir?

Sipariş numarası, fatura numarası ve ETTN aynı kimlik değildir. Seri/sıra planı yasal ve operasyonel gereksinimlere göre yönetilir; ETTN/UUID belgenin tekil elektronik kimliğidir; kanal numarası ise kaynak siparişi bulur. Hiçbiri diğerinin üzerine yazılmamalıdır.

Kimlik sözlüğü, mükerrerlik araştırmasını hızlandırır.

Karar çıkarımı: Taşıma veya sağlayıcı değişiminde seri, numara ve ETTN sürekliliğini test edin; site taşıma rehberi geçiş bağlamını tamamlar.

Idempotency Nedir ve Mükerrer Fatura Nasıl Önlenir?

Mükerrerlik çoğu zaman aynı webhook'un tekrar gelmesi, timeout sonrası kör yeniden gönderim, iki sistemin aynı siparişi faturalaması veya operatörün bekleyen kaydı manuel oluşturmasıyla doğar. Idempotency, aynı iş olayının tekrar işlenmesinde aynı sonucu döndürmeyi veya yeni belge üretmemeyi sağlayan tasarımdır.

Önleme katmanları birlikte çalışmalıdır.

Karar çıkarımı: Idempotency'yi yalnız API başlığı değil, belge üreticisi, veri tabanı tekilliği ve operasyon ekranı boyunca uçtan uca kural yapın.

Timeout Sonrası “Fatura Gönderildi mi?” Belirsizliği Nasıl Çözülür?

Timeout, karşı tarafın işlemi yapmadığını kanıtlamaz; yanıt kaybolmuş olabilir. Bu “sonucu bilinmeyen” durumda aynı belgeyi hemen yeniden göndermek mükerrerlik doğurabilir. Önce ETTN, fatura adayı veya işlem anahtarıyla durum sorgulanmalı; sonuç bulunamıyorsa kontrollü retry uygulanmalıdır.

Karar tablosu, kör tekrarın yerini alır.

Karar çıkarımı: Retry politikası hata sınıfına bağlı olmalı; doğrulama ve yetki hataları teknik tekrar değil düzeltme gerektirir.

Retry, Backoff ve Dead-Letter Queue Nasıl Tasarlanır?

Retry yalnız geçici hatalarda, sınırlı deneme ve artan bekleme aralığıyla uygulanır; jitter aynı anda yığılan istemcileri dağıtır. Deneme veya kayıt yaşı sınırını aşan olay DLQ/istisna kuyruğuna geçer ve otomatik dolaşıma sonsuza kadar dönmez.

DLQ kaydı orijinal olay, son hata, deneme geçmişi ve idempotency anahtarını korur. Replay yalnız kök neden düzeltildikten sonra yetkili, gerekçeli ve tekillik kontrollü yapılır.

Transactional Outbox Fatura Akışında Ne Sağlar?

Transactional outbox, siparişin iş durumu güncellenirken yayımlanacak fatura olayını aynı yerel işlem içinde dayanıklı kaydetmeye yarayan bir desendir. Böylece veri tabanı güncellenip mesajın kaybolması veya mesaj yayımlanıp iş kaydının oluşmaması riski azaltılır.

Outbox tek başına uçtan uca exactly-once garantisi vermez; yayıncı tekrarları için tüketicide idempotency, izleme, temizleme ve geciken kayıt alarmı yine gerekir.

İstisna Kuyruğu ve Manuel İnceleme Ekranı Nasıl Kurulur?

Otomasyonun durduğu kayıtlar e-posta zincirlerinde değil, sahipliği ve yaşı görünen bir iş kuyruğunda tutulmalıdır. Kuyruk; sipariş, belge adayı, son hata, deneme sayısı, etkilenen müşteri, sorumlu, öncelik ve çözüm kanıtını bir araya getirir. Manuel düzeltme orijinal sipariş snapshot'ını değiştirmemeli; yeni değer ve gerekçe ayrı kaydedilmelidir.

Hata sınıfı, otomatik ve insan aksiyonunu ayırır.

Karar çıkarımı: Kapanış, “çözüldü” düğmesi değil; düzeltme, yeniden işlem ve sonuç kanıtının birlikte kaydıdır.

E-Fatura Durumları Nasıl Modellenmelidir?

İşletme içi durum ile GİB veya entegratör teknik durumu ayrı saklanmalıdır. “Taslak doğrulandı” iç iş adımıdır; “zarf işlendi” teknik bir sonuç; ticari kabul/ret ise farklı bir yaşam döngüsüdür. Güncel kılavuzda doğrulanmayan kodları kullanıcı ekranına ham biçimde taşımak yerine anlamlı gruplara map edin.

İzin verilen geçişler bir durum makinesiyle yönetilebilir.

Karar çıkarımı: Durum geçişini serbest metin güncellemesi değil, kanıt ve rol kontrolü olan işlem yapın.

Sistem Yanıtı ile Uygulama Yanıtı Arasındaki Fark Nedir?

Sistem yanıtı belgenin teknik olarak alındığı, işlendiği veya teknik bir hata gördüğü hakkında bilgi verir. Uygulama yanıtı ise uygun senaryoda alıcının ticari kabul veya ret davranışını temsil edebilir. Bu nedenle “GİB'e gönderildi” ifadesi “alıcı kabul etti” veya “muhasebeleşti” anlamına gelmez.

Operasyon ekranı ham kodun yanında iş anlamını göstermelidir.

Karar çıkarımı: Teknik teslim, ticari yanıt, müşteriye iletim ve muhasebe kaydını dört ayrı izleme boyutu yapın.

GİB veya Özel Entegratör Kesintisinde Ne Yapılmalıdır?

Kesintide sipariş kaydı ve fatura adayı güvenli kuyrukta kalmalı, kontrolsüz sonsuz retry yapılmamalıdır. Müşteri etkisi, yasal süre riski, kuyruk yaşı ve servis duyuruları izlenir. RTO hizmetin hedeflenen toparlanma süresini, RPO ise kabul edilebilir veri kaybı noktasını ifade eder; bunlar garanti değil planlama hedefidir.

Fallback, normal akış kadar test edilmelidir.

Karar çıkarımı: Kesinti sonrasında başarı yalnız servisin açılması değil, bekleyenlerin tekil işlenmesi ve farkların kapanmasıdır.

Sertifika, Endpoint ve API Sürümü Değişiklikleri Nasıl Yönetilir?

GİB, 13.07.2026 duyurusunda ilgili alan adlarının SSL/TLS sertifikalarının 14.07.2026 saat 14.00'te yenileneceğini bildirdi. Bu güncel örnek; trust store, sertifika zinciri, endpoint, IP izin listesi ve istemci uyumluluğunun değişiklik takviminde izlenmesi gerektiğini gösterir. Sertifikayı kod içine sabitlemek veya doğrulamayı kapatmak güvenli çözüm değildir.

• Duyuru sahipliği ve günlük kontrol sıklığı belirleyin.
• Staging ortamında zincir, DNS, TLS ve istemci testini yapın.
• API/kılavuz sürümünün yürürlük tarihini ve geri dönüş planını kaydedin.
• Değişiklik sonrası gönderim, callback ve durum sorgusunu uçtan uca doğrulayın.

Web Sitesi ve Pazaryeri Siparişleri Aynı Akışta Nasıl Yönetilir?

Ortak çekirdek model; sipariş, alıcı, satır, ödeme, sevkiyat ve belge referanslarını standartlaştırır. Kanal özgü web adresi, mağaza kimliği, ödeme aracısı, fatura yükleme yöntemi ve zorunlu alanlar ayrı uzantıda tutulur. çok kanallı e-ticaret yaklaşımı kanal görünürlüğünü açıklar; burada hedef aynı siparişin farklı bağlantılardan iki kez faturalanmasını önlemektir.

Kanal mapping'i her mağaza için sürümlenmelidir.

Karar çıkarımı: Kanal siparişini ortak modele dönüştürün fakat yasal ve platforma özgü alanları kaybetmeyin.

Pazaryerine Fatura Yüklemek ile Fatura Kesmek Aynı İşlem midir?

Hayır. Faturanın e-belge sistemi üzerinden yasal olarak oluşturulması ve uygun kanaldan iletilmesi bir süreçtir; belgenin PDF, URL veya numarasının pazaryeri paneline/API'sine yüklenmesi ayrı kanal işlemidir. Yükleme hatası, GİB tarafındaki belgeyi kendiliğinden iptal etmez; GİB başarısı da pazaryerinde görünürlük garantisi vermez.

İki durum kümesini ayrı saklayın.

Karar çıkarımı: Kanal yüklemesi için ayrı SLO, retry ve günlük eksik yükleme raporu kurun; hakediş ve komisyon mutabakatını bu akışla karıştırmayın.

B2B ve Bayi Siparişleri Nasıl Farklılaşır?

B2B siparişinde kurumsal alıcı kimliği, e-Fatura kaydı ve alias, senaryo, sipariş onayı, vade veya açık hesap referansı önem kazanır. Teklif ve proforma yasal fatura değildir. Cari limit ve bayi fiyatı tasarımı B2B e-ticaret sitesi kurma rehberinde ele alınır; fatura otomasyonu yalnız onaylı sipariş ve tahsilat/cari bağını kullanmalıdır.

• Kurumsal müşteri kartı değiştiğinde sipariş snapshot'ını ve güncel alıcı statüsünü birlikte değerlendirin.
• Açık hesap siparişinde ödeme beklemek yerine yetkili onay olayını tanımlayın.
• Ticari senaryo ve yanıt süreleri için güncel kaynak ve mali müşavir kontrolü uygulayın.
• Cari hesaba kayıt ile yasal belgenin iletilmesini ayrı durumlarda izleyin.

Kısmi Sevkiyat ve Parçalı Faturalandırma Nasıl Yönetilir?

Kısmi sevkiyatta sipariş satırı, sevkiyat satırı ve fatura satırı arasında miktar bağı gerekir. Kalan, iptal edilen, geri siparişteki ve daha önce faturalanan miktarlar ayrı tutulmazsa toplam sipariş aşılabilir. Yasal ve muhasebesel uygunluk işletmenin uzmanlarıyla onaylanmalıdır.

Satır düzeyindeki ilişki aşağıdaki senaryoları yönetir.

Karar çıkarımı: Belgeyi sipariş başlığından değil, uygun sevkiyat satırlarından üretin ve kümülatif miktar kontrolü yapın.

Bir Siparişten Birden Fazla Fatura Ne Zaman Oluşabilir?

Kısmi sevkiyat, farklı satıcı veya şube, ürün/hizmet ayrımı ya da onaylı iş kuralı birden fazla belgeye yol açabilir. Bunun uygunluğu işlem özelinde doğrulanmalıdır. Her belge orijinal sipariş ve satır referansını taşımış, belge toplamlarının birleşimi onaylı sipariş tutarını aşmamış olmalıdır.

Ters yönde, birden çok siparişi tek faturada birleştirmek de müşteri, para birimi, vergi, sevkiyat ve izlenebilirlik kurallarını gerektirir; varsayılan davranış olmamalıdır.

Sipariş İptali Fatura Öncesi ve Fatura Sonrası Nasıl Ayrılır?

Fatura oluşmamış siparişin kuyruğunu durdurmak, düzenlenmiş yasal belgeyi geri almakla aynı değildir. İptal talebinin zamanı ile belge üretim, gönderim ve kanal yükleme zamanları karşılaştırılır. Belge düzenlenmişse kaydı silmek yerine statüye ve senaryoya uygun ret, iptal, itiraz veya iade yolu uzman kontrolüyle seçilir.

Karar matrisi ortak dili kurar.

Karar çıkarımı: “İptal” tek bir API çağrısı değildir; belge türü, durum, süre ve taraf rolüne göre seçilen denetlenebilir süreçtir.

E-Fatura İptal, İtiraz ve Ret Süreçleri Nasıl Yönetilir?

Ret, iptal talebi ve itiraz aynı kavram değildir. Ticari/temel senaryo, belgenin güncel durumu, tarafların işlemi ve mevzuattaki yöntemler ayrı değerlendirilir. Süre ve koşullar değişebileceğinden otomasyon sabit gün sayısını kod içine gömmemeli; güncel GİB kılavuzu ve mali müşavir onayıyla sürümlenmiş politika kullanmalıdır.

Sistem kullanıcıya mevcut durumu, izin verilen olası aksiyonları, gereken kanıtı ve onay rolünü göstermeli; hukukî sonucu kendiliğinden seçmemelidir.

E-Arşiv İptal ve İtiraz Süreci Nasıl Yönetilir?

E-Arşiv iptal/itiraz bildirimi, e-Fatura uygulama yanıtı değildir. Belge numarası, tarih, yöntem, bildirim ve rapor durumu birlikte izlenir. İşletme güncel e-Arşiv İptal, İhtar/İtiraz Bildirim Kılavuzunu GİB'den kontrol etmeli; müşteri iletişimi, muhasebe kaydı ve rapor mutabakatını aynı vaka altında bağlamalıdır.

Otomasyon, süre yaklaşımında alarm üretebilir ancak uygun hukukî işlemi uzman onayı olmadan seçmemelidir.

Tam İade, Kısmi İade ve Ürün Değişimi Faturayı Nasıl Etkiler?

İade olayı orijinal belgeye, satıra, miktara ve tutara bağlanmalıdır. Kısmi iadede yalnız dönen miktar işlenir; ürün değişimi ise çoğu kurguda iade ve yeni satış gibi iki ayrı iş olayı doğurabilir. Bireysel ve kurumsal alıcıların belge yolu farklılaşabileceğinden kesin genelleme yerine güncel mevzuat ve mali müşavir kontrolü gerekir.

İade kararını müşteri hizmetleri notundan yasal belgeye kadar izleyin.

Karar çıkarımı: İade belgesini yeni, bağımsız satış kaydı gibi değil; orijinal belge ve fiziksel/finansal hareketlerle bağlı vaka olarak üretin. Müşteri deneyimi boyutu için satış sonrası süreçler rehberi kullanılabilir.

Fatura Müşteriye Nasıl İletilmelidir?

Elektronik ağ iletimi, e-posta, güvenli müşteri portalı bağlantısı ve gerektiğinde çıktı farklı kanallardır. E-posta servisinin “gönderildi” demesi müşterinin belgeyi aldığı veya okuduğu garantisi değildir. Kimlik doğrulama, bağlantı süresi, erişim logu ve kişisel veri riski değerlendirilmelidir.

Belge biçimi ile iletim ve saklama amacını ayırın.

Karar çıkarımı: XML, görsel ve müşteri iletim durumunu birlikte saklayın fakat birbirinin yerine geçmiş saymayın.

PDF, XML ve Görsel Fatura Arasındaki Fark Nedir?

XML/UBL-TR makine tarafından işlenebilen yapılandırılmış belge verisini, XSLT bu verinin görsel sunum kuralını, PDF ise kullanıcıya sunulan sabit görsel çıktıyı temsil eder. PDF'in görüntülenmesi XML'in bütünlüğünü veya e-belge durumunu tek başına kanıtlamaz.

Müşteri erişimi için görsel, entegrasyon ve denetim için özgün XML/metadata birlikte yönetilmelidir. Sağlayıcıdan hangi formatları, imza/bütünlük bilgisini ve durum geçmişini dışa aktarabildiğini test etmesi istenmelidir.

E-Belge Arşivleme, Yedekleme, Muhafaza ve İbraz Nasıl Ayrılır?

Arşivleme belgeyi erişilebilir düzenle saklama, yedekleme kayba karşı kopya üretme, muhafaza mevzuat kapsamında koruma, ibraz ise istendiğinde uygun biçimde sunabilme sorumluluğudur. Özel entegratörün arşiv hizmeti, mükellefin muhafaza ve ibraz sorumluluğunu otomatik kaldırdığı varsayımına dönüştürülmemelidir. Sabit saklama süresi yazmadan güncel mevzuat ve uzman görüşü doğrulanmalıdır.

Sağlayıcı değişikliği öncesi gerçek dışa aktarım testi yapın.

Karar çıkarımı: Sözleşmede format, bütünlük, erişim süresi, ücret, silme ve hizmet sonu veri teslimini açıkça düzenleyin.

Muhasebe, Cari, Tahsilat ve Stok Kayıtları Nasıl Mutabık Tutulur?

Belgenin oluşması muhasebe kaydının, cari kapamanın veya stok hareketinin tamamlandığını kanıtlamaz. Sipariş no, ödeme işlem no, fatura no/ETTN, fiş no ve stok hareket no ortak vaka altında eşleştirilmelidir. Stok stratejisinin bütünü için e-ticarette stok yönetimi rehberi; burada ise yalnız belge-hareket bağı önemlidir.

Mutabakat hem başlık hem satır düzeyinde yapılır.

Karar çıkarımı: Fark kaydına neden kodu, sahip ve hedef çözüm zamanı ekleyin; toplam adet eşitliğiyle yetinmeyin.

Günlük Mutabakat Neden Gerçek Zamanlı Otomasyonun Yerini Değil Tamamlayıcısıdır?

Gerçek zamanlı akış sessizce atlanan callback, yanlış mapping veya muhasebe kuyruğu gibi hataları her zaman görünür kılmaz. Günlük kapanış; sipariş var/fatura yok, fatura var/muhasebe yok, tutar farkı, mükerrer belge ve durum uyuşmazlığını kimlik bazında bulur. e-ticaret raporlama rehberi genel ölçüm çerçevesini verir.

• Kanal ve tarih bazında beklenen fatura adaylarını sayın.
• Belge no ve ETTN tekilliğini kontrol edin.
• Sipariş, belge, tahsilat ve muhasebe toplamlarını satır düzeyinde karşılaştırın.
• Farkları otomatik kapatmayın; neden kodu ve sorumlu atayın.

Kontör Bakiyesi ve Belge Tüketimi Nasıl Yönetilir?

Kontör, sağlayıcının ticari tüketim birimidir; her belge ve işlemde aynı sayıda harcandığı varsayılamaz. İptal, iade, yeniden gönderim, gelen belge, e-İrsaliye, arşiv veya saklama etkisi yazılı teklif ve sözleşmeden doğrulanmalıdır. işletmenize uygun e-Fatura kontörünü karşılaştırırken yalnız birim fiyatı değil tüketim kapsamını da sorun.

Kapasite planı hacim ve kampanya dalgalanmasını kapsar.

Karar çıkarımı: Kontör bitmesini teknik sürpriz değil, tahmin ve satın alma sahipliği olan önlenebilir operasyon riski olarak yönetin.

Otomatik Faturalandırma Maliyeti Hangi Kalemlerden Oluşur?

SoloCommerce lisansı, Solofor e-Fatura/kontör maliyeti ve otomatik faturalandırma toplam proje maliyeti aynı değildir. Kurulum ve veri temizliği çoğunlukla tek seferlik; lisans, destek, arşiv ve bakım dönemsel; kontör, API ve iletim hacme bağlı olabilir. Sabit fiyat vermek yerine teklif kapsamını aynı varsayımlarla karşılaştırın.

Toplam sahip olma maliyeti görünmeyen iç iş gücünü de içerir.

Karar çıkarımı: En ucuz kontör, hata iş gücü, entegrasyon bakımı ve çıkış maliyeti eklendiğinde en düşük TCO olmayabilir.

Hazır Bağlantı, Özel Entegrasyon ve ERP Üzerinden Faturalandırma Nasıl Karşılaştırılır?

Hazır bağlantı hızlı olabilir fakat kısmi sevkiyat, özel vergi, B2B onayı veya çoklu şirket gibi senaryolar kapsam dışı kalabilir. Özel entegrasyon esneklik sağlar ama geliştirme ve bakım sorumluluğu doğurur. ERP üzerinden akış finansal otoriteyi güçlendirebilir; kanal olaylarının gecikmesi ve konektör sınırı incelenmelidir. Doğrudan veritabanına yazmak audit, destek ve veri bütünlüğü açısından riskli anti-pattern'dir.

Seçenekleri aynı kabul senaryolarıyla karşılaştırın.

Karar çıkarımı: En iyi yöntem, zor senaryoları kanıtlayan ve veriyi taşınabilir bırakan yöntemdir.

Otomatik Faturalandırmada Güvenlik Nasıl Sağlanır?

API secret, erişim token'ı, kullanıcı şifresi, mali mühür/e-imza bileşenleri ve TLS sertifikası aynı sır değildir; farklı saklama, rotasyon ve erişim politikaları ister. GİB de imzalama araçları ile kullanıcı bilgilerinin korunmasının mükellefin sorumluluğunda olduğunu hatırlatır. OWASP API Security riskleri; nesne ve işlev düzeyi yetki, oran sınırlama, envanter ve güvenli tüketim kontrolleri için birincil teknik çerçeve sunar.

Kontroller katmanlı uygulanmalıdır.

Karar çıkarımı: “TLS kullanıyoruz” yeterli değildir; kimlik, yetki, sır, veri, ağ ve denetim birlikte korunmalıdır.

Rol Bazlı Yetki ve Dört Göz Kontrolü Ne Zaman Gerekir?

Taslak oluşturma, vergi alanını değiştirme, gönderim, iptal/itiraz, toplu yeniden işleme ve kontör satın alma yetkileri ayrılmalıdır. Yüksek tutar, tevkifat/istisna, manuel vergi değişikliği veya toplu replay gibi risklerde ikinci onay uygulanabilir. Her faturayı manuel onaya bağlamak otomasyon değerini düşürür; risk bazlı eşik ve istisna kuralı daha dengelidir.

• Rol değişikliklerini ve geçici yetkileri süreli, onaylı ve loglu yapın.
• Aynı kişinin kuralı değiştirip toplu belgeyi onaylamasını kısıtlayın.
• Acil erişimi gerekçeli verin ve olay sonrası gözden geçirin.
• Toplu iptal veya yeniden gönderimde etkilenecek belge listesini ön izletin.

KVKK Açısından Fatura Otomasyonunda Nelere Dikkat Edilmelidir?

VKN/TCKN, ad, adres, iletişim, sipariş ve fatura içeriği kişisel veri boyutu taşıyabilir. Amaçla sınırlılık, veri minimizasyonu, erişim, saklama, aktarım ve ihlal yönetimi birlikte ele alınmalıdır. Kişisel Verileri Koruma Kurumu kaynakları ve işletmenin hukuk danışmanı güncel yükümlülük için esas alınmalıdır.

Özellikle test, log ve yapay zekâ kullanımında gereksiz kopyaları azaltın.

Karar çıkarımı: Test ve destek kolaylığı, gerçek fatura verisini kontrolsüz çoğaltma gerekçesi olamaz.

Audit Log ve Denetlenebilirlik Neden Önemlidir?

Audit log; kim, ne zaman, hangi sipariş snapshot'ı ve mapping sürümüyle hangi kararı verdi sorusunu yanıtlar. Normal uygulama logu performans ve hata ayıklamaya odaklanırken audit kaydı iş kararının değiştirilemez izini tutar. Tetikleyici, kullanıcı/servis hesabı, önceki-yeni değer, API işlem kimliği, yanıt, retry ve manuel gerekçe kaydedilmelidir.

Audit loga tam TCKN, token veya gereksiz XML yazmayın. Hassas alanı maskeleyin; bütünlüğü koruyun; yetkili sorgu ve saklama politikasını tanımlayın.

Otomatik Faturalandırma Hangi Metriklerle İzlenmelidir?

Ortalama süre tek başına güvenilirlik ölçüsü değildir; az sayıdaki çok yaşlı kayıt ortalamada kaybolabilir. İlk denemede başarı, bekleyen yaş dağılımı, mükerrer engelleme, retry, fark ve kontör birlikte izlenmelidir. Eşikler aşağıda temsili olup işletmenin hacim ve risk baz çizgisine göre ayarlanır.

KPI, doğrudan sahip ve aksiyonla bağlanmalıdır.

Karar çıkarımı: Metrikleri kanal, belge türü, entegratör ve hata nedeni kırılımıyla gösterin; toplam başarı oranı sorunu gizlemesin.

Dashboard ve Alarm Sistemi Nasıl Kurulur?

Operasyon ekranı kayıt yaşı, müşteri etkisi ve çözüm rolünü; finans ekranı tutar, vergi, kontör ve mutabakatı; teknik ekran kuyruk, callback, hata kodu ve gecikmeyi göstermelidir. Kuyruk büyümesi, durum dönmemesi, düşük kontör, sertifika yaklaşması ve açık fark için seviye, sahip ve yükseltme yolu tanımlanır.

Alarm yorgunluğunu azaltmak için aynı kök nedenden gelen kayıtları gruplayın, önem derecesini müşteri/yasal süre etkisiyle belirleyin ve alarm kapanışında kanıt arayın.

Test Ortamı ve Test Verisi Nasıl Hazırlanır?

GİB veya entegratör test ortamı, e-ticaret staging, ERP/muhasebe testi ve kanal sandbox'ı aynı şey değildir. Endpoint, test şirketi/alias, sertifika, seri, callback ve secret'lar ortam bazında ayrılır. Üretim VKN/TCKN ve müşteri verisi kontrolsüz kopyalanmaz; sentetik veya maskeli veri kullanılır.

Test veri matrisi olumlu örnek kadar sınır ve hata örneği içermelidir.

Karar çıkarımı: Başarılı örnek belge üretmek testin başlangıcıdır; tekrar, kesinti ve düzeltme davranışı kabul edilmeden canlıya geçmeyin.

Canlıya Geçmeden Önce Hangi Testler Yapılmalıdır?

Aşağıdaki 48 senaryo iş, teknik, güvenlik ve mutabakat kabulünü birlikte ölçer. Her testte giriş verisi, beklenen çıktı, dış sistem kanıtı ve veri temizliği kaydedilmelidir.

Karar çıkarımı: Go kararı, 48 testin yalnız “geçti” işaretine değil; kanıtına, açık riskine ve kabul eden iş sahibine dayanmalıdır.

Pilot, Go/No-Go ve Canlıya Geçiş Nasıl Planlanır?

İlk pilot, hacmi ve senaryo çeşitliliği yönetilebilir tek kanal/mağaza ya da sınırlı sipariş grubu olabilir. Çok kolay örnek seçmek gerçek riskleri gizler; kısmi sevkiyat, iade ve hatalı veri gibi en az birer senaryo pilota dahil edilmelidir. Eski ve yeni sistemin aynı siparişi üretmesini önleyen tek-üretici kilidi geçişin kritik kontrolüdür.

Go/no-go tablosu sözlü iyimserliğin yerini alır.

Karar çıkarımı: Kritik bir no-go açıkken tarih baskısıyla tam hacme çıkmak yerine kapsamı küçültün veya geçişi erteleyin.

Rollback, Roll-Forward ve Hypercare Nasıl Yönetilir?

Teknik dağıtımı geri almak, düzenlenmiş yasal belgeyi yok etmez. Kod/config rollback'i ile belge düzeltme süreci ayrılmalıdır. Veri etkili bir hata varsa çoğu durumda onaylı roll-forward, yani mapping'i düzeltip bekleyen kayıtları kontrollü yeniden işlemek gerekebilir.

İlk ayın izleme yoğunluğu kademeli azaltılır.

Karar çıkarımı: Hypercare, yalnız daha çok kişi bekletmek değil; farkı hızla bulup kalıcı kök neden düzeltmesi yapmaktır.

Sağlayıcıya Hangi Sorular Sorulmalıdır?

Aşağıdaki 48 soru, demo vaadini doğrulanabilir teknik belgeye ve sözleşme maddesine dönüştürür. Yanıtları aynı senaryo ve hacim varsayımıyla yazılı alın.

Karar çıkarımı: En iyi yanıt kısa “evet” değil, test edilebilir kapsam, sorumluluk, sınır ve çıkış koşuludur.

Yapay Zekâ Otomatik Faturalandırmada Nasıl Kullanılabilir?

Yapay zekâ hata mesajlarını sınıflandırabilir, olağandışı tutar veya retry desenini işaretleyebilir, mapping önerisi ve test senaryosu üretebilir, operasyon özetini hazırlayabilir. Belge türü, vergi oranı, istisna, iptal veya itiraz kararını tek başına vermemeli; finans, mali müşavir veya hukuk rolünün onayı korunmalıdır.

VKN/TCKN, adres, ham XML, token, secret ve mali mühür verisi genel amaçlı yapay zekâ aracına gönderilmemelidir. Kullanılan model/sürüm, giriş sınıfı, öneri ve insan onayı audit kaydına bağlanmalıdır. yapay zekâ destekli e-ticaret rehberi daha geniş kullanım çerçevesini verir.

E-Ticaret Paketi Seçerken Otomatik Faturalandırma İçin Nelere Bakılmalıdır?

Paket karşılaştırmasında e-Fatura/e-Arşiv satırının “var” görünmesi; kontör, entegrasyon, kanal, özel senaryo, test ve desteğin tamamının dahil olduğu anlamına gelmez. Tetikleyici, taslak/onay, alıcı sorgusu, ürün/vergi mapping'i, durum takibi, iade, arşiv, sandbox, idempotency, veri ihracı ve destek tek tek sorulmalıdır. e-ticaret paketi seçim kriterleri genel teknik ve ticari değerlendirmeyi tamamlar.

İşlem hacmi, finans görünürlüğü ve özel otomasyon ihtiyacına göre SoloCommerce paket uygunluğu rehberi incelenebilir; karar canlı teklif ve kabul senaryolarıyla doğrulanmalıdır.

SoloCommerce Otomatik Faturalandırma ve E-Belge Süreçlerinde Nasıl Konumlanır?

SoloCommerce'i yalnız otomatik fatura kesen modül olarak değerlendirmek eksik kalır. Canlı paket sayfası; markalı e-ticaret sitesi, ürün/kategori/varyant, sepet, kanal sipariş görünürlüğü ve paket seviyesine göre operasyon/finans yetenekleri sunar. Otomatik faturalandırma değer önerisi bulunsa da e-Fatura/e-Arşiv satırı Başlangıç, Büyüme ve Profesyonel kapsamlarında opsiyonel; Enterprise için teklif yaklaşımı gösterebilir. Güncel SoloCommerce paketlerini karşılaştırırken tarihli teklif alınmalıdır.

Profesyonel seviyede canlı sayfada satış dokümanları, cari/tahsilat ve stok/depo görünürlüğü doğrulanırken Enterprise tarafında özel entegrasyon, otomasyon, ERP/muhasebe bağlantısı ve SLA proje/teklif kapsamına girebilir. Solofor e-Fatura portalı ve kontörü, SoloCommerce yıllık lisansıyla aynı ürün veya otomatik olarak ücretsiz dahil hizmet değildir. Solofor e-Fatura çözümlerinin portal, entegrasyon ve kontör koşulları ayrıca doğrulanmalıdır.

Solofor e-Fatura canlı sayfasında 14.07.2026 tarihinde Turkcell iş birliği ile REST API ve webhook ifadeleri de doğrulandı. Bu ifadeler belirli ERP, kanal, alan, hacim veya SLA kapsamının otomatik olarak dahil olduğu anlamına gelmez; teknik doküman, kabul testi ve yazılı teklif ile sınırlar netleştirilmelidir.

Kapsamı üç katmanda okuyun.

Karar çıkarımı: İşletme veri kalitesi, vergi kuralı, test ve kabul sorumluluğunu korur. Ürün sayfasındaki değer önerisini mevzuat, süre, başarı, ceza önleme veya sıfır kesinti garantisi olarak yorumlamayın.

E-Ticarette Otomatik Faturalandırma Kontrol Listesi

Aşağıdaki 133 benzersiz madde, proje keşfinden canlı işletime kadar evet/hayır veya tamamlandı biçiminde doğrulanabilir. Her “evet” için belge, ekran görüntüsü, test sonucu ya da onay kaydı tutulmalıdır.

Mevzuat ve güncellik — 8 kontrol

• □ İşletmenin e-Fatura/e-Arşiv kapsamı güncel 509 metninden doğrulandı mı?
• □ 573 ve 589 değişikliklerinin etkisi konsolide metin üzerinden incelendi mi?
• □ Alıcı ve işlem özelindeki istisnalar mali müşavirle onaylandı mı?
• □ Vergi ve belge kurallarının yürürlük tarihleri kaydedildi mi?
• □ GİB duyurularını izleyecek rol ve sıklık tanımlandı mı?
• □ Kılavuz/API/UBL-TR sürümleri envantere yazıldı mı?
• □ Hukukî süreler koddan bağımsız, sürümlenebilir politika olarak tutuluyor mu?
• □ Mevzuat değişikliğinde etki analizi ve yeniden test süreci var mı?

GİB yöntemi ve sağlayıcı — 8 kontrol

• □ Portal, doğrudan entegrasyon ve özel entegratör yöntemleri karşılaştırıldı mı?
• □ Özel entegratörün güncel GİB liste kaydı doğrulandı mı?
• □ Üretim ve test ortamlarının kapsam farkları yazıldı mı?
• □ API sürüm ve kullanım sonu politikası alındı mı?
• □ SLA, RTO, RPO ve bakım bildirimi sözleşmede mi?
• □ Alt sağlayıcılar ile veri/işlem zinciri açıklandı mı?
• □ Veri dışa aktarımı gerçek örnekle test edildi mi?
• □ Sağlayıcı değiştirme ve hizmet sonu silme planı var mı?

Süreç ve fatura tetikleyicisi — 10 kontrol

• □ Sipariş, ödeme, tahsilat, sevkiyat ve fatura olayları ayrıldı mı?
• □ Her kanal için fatura adayını doğuran olay tanımlandı mı?
• □ Ödeme yöntemi bazında kesinleşme olayı belirlendi mi?
• □ Ön sipariş ve havale bekleme davranışı tanımlandı mı?
• □ Kapıda ödeme için sevk/teslim politikası onaylandı mı?
• □ Fatura öncesi iptal tüm ilgili kuyrukları durduruyor mu?
• □ B2B açık hesapta yetkili onay olayı kaydediliyor mu?
• □ Tetikleyici kuralının sürümü ve sahibi bulunuyor mu?
• □ Manuel tetikleme yetkisi ve gerekçe alanı sınırlandı mı?
• □ Tetikleyiciden belge oluşumuna kadar geçen süre izleniyor mu?

Müşteri ve alıcı verisi — 8 kontrol

• □ VKN/TCKN biçim ve zorunluluk kontrolleri uygulanıyor mu?
• □ Unvan/ad alanı sipariş snapshot'ında korunuyor mu?
• □ Fatura adresi bileşenleri işlem türüne göre doğrulanıyor mu?
• □ Kurumsal profil değişikliği geçmiş siparişi bozmuyor mu?
• □ E-posta biçimi ve iletim amacı kontrol ediliyor mu?
• □ Eksik kimlik varsayılan değerle geçilmeyip kuyruğa alınıyor mu?
• □ Müşteri düzeltmesinde önceki/yeni değer audit logda mı?
• □ Hassas kimlik alanları ekran ve loglarda maskeleniyor mu?

Ürün, birim, vergi ve iskonto — 10 kontrol

• □ Her varyantın benzersiz ve aktif SKU'su var mı?
• □ Sipariş birimleri onaylı UBL-TR birim kodlarına eşlendi mi?
• □ Eksik birim mapping'i otomatik varsayılanla kapatılmıyor mu?
• □ Vergi oranı ürün, alıcı, tarih ve işleme göre belirleniyor mu?
• □ İstisna/tevkifat gibi özel kurallar uzman onaylı mı?
• □ Satır indirimi yalnız ilgili satıra yansıyor mu?
• □ Sepet kuponunun satır dağıtımı deterministik mi?
• □ Hediye çeki ödeme/indirim niteliği onaylandı mı?
• □ Kargo ücreti ve vergisi ayrı kural olarak test edildi mi?
• □ Satır, vergi ve genel toplam yeniden üretilebiliyor mu?

İnternet satış ve e-Arşiv alanları — 6 kontrol

• □ Gerçek satış kanalı/web adresi mağaza sözlüğünden geliyor mu?
• □ Ödeme yöntemi serbest metin yerine mapping ile aktarılıyor mu?
• □ Ödeme aracısı ve işlem referansı korunuyor mu?
• □ Ödeme tarihi sipariş tarihinden ayrılıyor mu?
• □ Taşıyıcı bilgileri kargo kaynağından doğrulanıyor mu?
• □ e-Arşiv iptal/itiraz ve rapor durumu izleniyor mu?

Kanal, pazaryeri ve B2B — 7 kontrol

• □ Kanal + mağaza + sipariş no bileşik olarak tekil mi?
• □ Aynı siparişin iki konektörden gelmesi engelleniyor mu?
• □ Kanal özgü alanlar ortak modelde kaybolmuyor mu?
• □ Pazaryeri fatura yükleme durumu GİB durumundan ayrı mı?
• □ Yükleme hatası için bağımsız retry ve manuel yol var mı?
• □ B2B alıcı alias ve senaryo kontrolü güncel mi?
• □ Teklif/proforma ile yasal fatura ayrımı korunuyor mu?

Belge kimliği, seri ve mükerrerlik — 8 kontrol

• □ Sipariş no, fatura no ve ETTN ayrı alanlarda mı?
• □ Seri/sıra planı finans ve mali müşavir tarafından onaylı mı?
• □ Fatura numarası silinmiyor veya yeniden kullanılmıyor mu?
• □ Her fatura adayının kalıcı idempotency anahtarı var mı?
• □ Webhook/olay kimliği tekil kısıtla korunuyor mu?
• □ Manuel fatura öncesi sipariş/ETTN araması yapılıyor mu?
• □ Eski ve yeni sistem arasında tek üretici kilidi var mı?
• □ Mükerrer engelleme olayları raporlanıyor mu?

Durum, retry ve istisna — 10 kontrol

• □ İç iş durumu ile GİB/entegratör durumu ayrı mı?
• □ İzin verilen durum geçişleri tanımlı mı?
• □ Sistem yanıtı ve uygulama yanıtı ayrılıyor mu?
• □ Timeout sonucu bilinmeyen işlem olarak ele alınıyor mu?
• □ Yeniden göndermeden önce durum sorgulanıyor mu?
• □ Retry hata sınıfına göre sınırlı ve artan aralıklı mı?
• □ Doğrulama hatası otomatik retry edilmiyor mu?
• □ Dead-letter/istisna kuyruğunun sahibi ve yaş alarmı var mı?
• □ Manuel replay yetkili, gerekçeli ve denetlenebilir mi?
• □ Kapanışta sonuç ve kök neden kanıtı aranıyor mu?

İptal, itiraz, iade ve kısmi sevkiyat — 10 kontrol

• □ Fatura öncesi sipariş iptali ayrı akış mı?
• □ Fatura sonrası kayıt silme teknik olarak engelli mi?
• □ Ret, iptal talebi ve itiraz ayrı durumlar mı?
• □ e-Fatura ve e-Arşiv düzeltme süreçleri karıştırılmıyor mu?
• □ Süre/koşul kuralları güncel resmî kaynağa bağlı mı?
• □ Tam iade orijinal belgeye bağlanıyor mu?
• □ Kısmi iade satır ve miktar düzeyinde mi?
• □ Ürün değişimi iade ve yeni satış olarak izlenebiliyor mu?
• □ Kısmi sevkiyat fatura miktarı toplamı siparişi aşmıyor mu?
• □ Kalan/iptal/geri sipariş miktarları ayrı tutuluyor mu?

Müşteriye iletim, arşiv ve ibraz — 6 kontrol

• □ XML ve görsel/PDF birlikte ve eşleşmiş saklanıyor mu?
• □ E-posta gönderim ile teslim/okuma durumu ayrılıyor mu?
• □ Portal bağlantısı yetkili ve süreli erişim sağlıyor mu?
• □ Arşiv, yedek, muhafaza ve ibraz sorumluları tanımlı mı?
• □ Yedekten geri yükleme periyodik test ediliyor mu?
• □ Toplu ibraz/dışa aktarım provası yapıldı mı?

Muhasebe, cari, tahsilat ve stok mutabakatı — 8 kontrol

• □ Sipariş-fatura kimlik ve tutarı günlük karşılaştırılıyor mu?
• □ Fatura-ödeme işlem referansı eşleniyor mu?
• □ Fatura-muhasebe fişi bağı kuruluyor mu?
• □ Fatura satırı-stok hareketi miktarı eşleniyor mu?
• □ İade-cari kapama kontrol ediliyor mu?
• □ Sipariş var/fatura yok raporu üretiliyor mu?
• □ Fatura var/muhasebe yok raporu üretiliyor mu?
• □ Her farkın neden kodu, sahibi ve kapanış süresi var mı?

Güvenlik, KVKK ve audit — 10 kontrol

• □ Secret ve token'lar güvenli kasada mı?
• □ Token/anahtar rotasyonu test edildi mi?
• □ Mali mühür/e-imza erişimi yetkili süreçle sınırlı mı?
• □ MFA ve en az yetki uygulanıyor mu?
• □ Tenant izolasyonu negatif testle doğrulandı mı?
• □ Fatura verisi aktarımda ve saklamada şifreli mi?
• □ Loglarda kimlik, XML ve token redaksiyonu var mı?
• □ Test verisi sentetik veya maskeli mi?
• □ Audit log önceki/yeni değer ve kural sürümünü tutuyor mu?
• □ İhlal bildirim ve olay müdahale runbook'u hazır mı?

Test, pilot ve canlıya geçiş — 12 kontrol

• □ Test ve üretim endpoint/secret/seri ayrıldı mı?
• □ Pozitif alıcı ve belge türü testleri geçti mi?
• □ Eksik/hatalı müşteri veri testleri geçti mi?
• □ Vergi, iskonto, döviz ve yuvarlama testleri geçti mi?
• □ Çift webhook ve idempotency testi geçti mi?
• □ Timeout, kesinti ve callback kaybı testi geçti mi?
• □ Kısmi sevkiyat, iptal ve iade testleri geçti mi?
• □ Pazaryeri yükleme ve müşteri iletim testi ayrı yapıldı mı?
• □ Güvenlik/yetki negatif testleri geçti mi?
• □ Sınırlı pilot ve manuel paralel kontrol planlandı mı?
• □ Go/no-go sahipleri ve kanıtları imzaladı mı?
• □ Rollback/roll-forward ve hypercare runbook'u prova edildi mi?

İzleme, kontör ve maliyet — 8 kontrol

• □ İlk denemede başarı ve bekleyen yaş dağılımı izleniyor mu?
• □ Mükerrer engelleme ve belirsiz gönderim alarmı var mı?
• □ Kontör tüketim kuralları yazılı alındı mı?
• □ Düşük bakiye ve satın alma süresi alarmı var mı?
• □ Kampanya tepe hacmi kapasite planına eklendi mi?
• □ Lisans, kontör, proje ve iç iş gücü ayrı hesaplandı mı?
• □ SLA/on-call/arşiv ve bakım maliyetleri TCO'da mı?
• □ Çıkış ve veri taşıma maliyeti tekliflerde karşılaştırıldı mı?

Yapay zekâ ve insan onayı — 4 kontrol

• □ AI aracına VKN/TCKN, XML, token veya mali mühür verisi gitmiyor mu?
• □ AI yalnız öneri/sınıflandırma yapıyor, hukukî-vergi kararını vermiyor mu?
• □ Model/sürüm, girdi sınıfı ve çıktı audit kaydında mı?
• □ Vergi, belge türü ve iptal kararında yetkili insan onayı var mı?

Karar çıkarımı: Kontrol listesinin değeri madde sayısında değil, her maddenin sahibi, kanıtı ve eksik olduğunda açılan aksiyondadır.

Otomatik Faturalandırmada Sık Yapılan Hatalar

Aşağıdaki 32 hata, küçük veri kusurlarının neden büyük finansal ve operasyonel sonuca dönüştüğünü gösterir. Erken sinyal ve önlemi birlikte izlemek, yalnız sonuçta hata saymaktan daha etkilidir.

Karar çıkarımı: Hata oranını azaltmanın en etkili yolu, yanlış kaydı yalnız engellemek değil; nedenini sınıflandırıp veri veya kural sahibine geri beslemektir.

Sıkça Sorulan Sorular

E-ticarette otomatik faturalandırma nedir?

Otomatik faturalandırma; sipariş, ödeme, sevkiyat veya onay gibi bir iş olayını, önceden tanımlanmış kurallarla e-Fatura ya da e-Arşiv Fatura sürecine bağlayan kontrollü sistemdir.

Otomatik fatura kesme nasıl çalışır?

Elektronik ağ iletimi, e-posta, güvenli müşteri portalı bağlantısı ve gerektiğinde çıktı farklı kanallardır. E-posta servisinin “gönderildi” demesi müşterinin belgeyi aldığı veya okuduğu garantisi değildir.

Otomatik faturalandırma maliyeti ne kadardır?

SoloCommerce lisansı, Solofor e-Fatura/kontör maliyeti ve otomatik faturalandırma toplam proje maliyeti aynı değildir. Kurulum ve veri temizliği çoğunlukla tek seferlik; lisans, destek, arşiv ve bakım dönemsel; kontör, API ve iletim hacme bağlı olabilir.

Otomatik faturalandırma testleri nasıl yapılır?

SoloCommerce'i yalnız otomatik fatura kesen modül olarak değerlendirmek eksik kalır. Canlı paket sayfası; markalı e-ticaret sitesi, ürün/kategori/varyant, sepet, kanal sipariş görünürlüğü ve paket seviyesine göre operasyon/finans yetenekleri sunar.

Otomatik faturalandırma hangi metriklerle izlenir?

Ortalama süre tek başına güvenilirlik ölçüsü değildir; az sayıdaki çok yaşlı kayıt ortalamada kaybolabilir. İlk denemede başarı, bekleyen yaş dağılımı, mükerrer engelleme, retry, fark ve kontör birlikte izlenmelidir.

Bundan Sonra Ne Yapılmalı?

Güvenilir otomasyon, sipariş geldiğinde en hızlı belgeyi üretmek değil; doğru belge türünü doğru olay ve veriyle üretip son durumuna kadar izlemektir. Alıcı statüsü, tetikleyici, UBL-TR mapping'i, idempotency, durum geri okuma, istisna kuyruğu, iptal/iade ve günlük mutabakat birlikte kurulmadığında hız, hatayı yalnız daha erken ve daha çok üretir.

“Kesintisiz” akış sıfır hata veya sıfır kesinti garantisi değildir. Kesintide siparişin kaybolmadığı, belirsiz sonucun sorgulandığı, tekrarın yeni belge doğurmadığı, insan kararının audit izine girdiği ve farkların kapatıldığı yönetilebilir süreçtir. Başlangıçta süreç/veri envanterinizi ve tetikleme politikanızı çıkarın; ardından paket lisansı, e-belge hizmeti, kontör ve özel proje kapsamını ayrı karşılaştırın.

İhtiyaçlarınız netleştiğinde sipariş ve operasyon ihtiyacına uygun e-ticaret paketlerini ve siparişten e-belgeye geçiş için e-Fatura çözümünü aynı kabul senaryolarıyla değerlendirebilirsiniz. Nihai kural, maliyet ve sorumlulukları güncel resmî kaynak, yazılı teklif, teknik test ve mali müşavir onayıyla kesinleştirin.