Sipariş, ödeme, e-belge, muhasebe fişi ve banka hareketi aynı kaydı taşımalıdır. Bu rehber, e-ticaret satışlarında veri eşlemesini, hata yönetimini ve mutabakat kontrolünü adım adım açıklar.
Sipariş ekranındaki toplam, e-belge tutarı, muhasebe fişi ve banka tahsilatı aynı kaydı anlatmalıdır. Bu dört kayıt ayrıştığında ekipler hesap aramakla zaman kaybeder ve mali dönem kapanışları zorlaşır.
E-ticaret muhasebe entegrasyonu, satış verisini tanımlı kurallarla e-belge uygulamasına ve muhasebe programına aktarır. Ancak bağlantıyı kurmak tek başına yeterli değildir. Ödeme durumu, indirim, kargo bedeli, iade ve komisyon için açık kararlar gerekir.
E-ticaret muhasebe entegrasyonu hangi kayıtları bağlar?
Entegrasyon, API üzerinden e-ticaret siteniz, pazaryerleri, ödeme kuruluşları, e-belge çözümünüz ve muhasebe programınız arasında veri akışı kurar. Sağlıklı e-ticaret muhasebe entegrasyonu, her sistemde aynı sipariş numarasını veya eşsiz kayıt referansını korur.
Bu yapı, her işlemi sorgusuz biçimde muhasebeleştirmez. İşletme önce hangi siparişin belge kuyruğuna gireceğini, hangi indirimlerin satırlara dağılacağını ve hangi hesabın kullanılacağını belirler. Entegrasyon bu kuralları tutarlı biçimde uygular.
- Her siparişin kaynağını ve işlem tarihini izlemeyi kolaylaştırır.
- Aynı sipariş için iki kez belge veya fiş oluşması riskini düşürür.
- Satış, tahsilat, iade ve komisyon farklarını daha erken görmenizi sağlar.
Siparişten faturaya beş aşamalı iş akışı
1. Sipariş verisini sabitleyin
Satış platformu yeni sipariş için benzersiz bir numara üretir. Entegrasyon; ürün satırlarını, adetleri, birim fiyatları, indirimleri, vergi bilgilerini, kargo bedelini, fatura bilgilerini ve satış kanalını bu numaraya bağlar. Müşteri daha sonra adresini değiştirirse sistem ilk sipariş kaydını korur.
Özellikle pazaryeri ve kendi siteniz birlikte satış yapıyorsa kanal bilgisini ayrı bir alan olarak tutun. Bu alan, komisyonları ve satış raporlarını doğru değerlendirmeyi kolaylaştırır.
2. Ödeme durumunu belge kuralından ayırın
Ödeme kuruluşu başarılı, başarısız, bekleyen veya iade edilen işlem bilgisini iletir. İşletme, her ödeme durumunda nasıl ilerleyeceğini önceden tanımlamalıdır. Örneğin kapıda ödeme, havale ve kart ödemesi için farklı operasyon kuralları oluşabilir.
Mali müşaviriniz, satış modelinize ve güncel yükümlülüklerinize göre belge oluşturma anını belirlemelidir. Sistem, tahsil edilmemiş veya sorunlu işlemler için işletmenin onayı olmadan belge kuyruğu açmamalıdır.
3. E-belge kuyruğunu kontrol edin
Sistem belgeye hazır siparişleri e-Fatura veya e-Arşiv senaryosuna göre ayırır. Belge türünü; müşteri bilgileri, mükellefiyet durumu, satışın niteliği ve güncel GİB duyuruları etkiler. Mali müşaviriniz bu karar ağacını e-belge sağlayıcınızla birlikte netleştirmelidir.
Eksik vergi numarası, uyumsuz tutar veya zorunlu alan eksikliği varsa sistem siparişi hata kuyruğuna almalıdır. Operasyon ekibi hatayı düzeltir, ardından aynı sipariş numarasıyla yeniden işlem başlatır.
4. Muhasebe fişini hesap planına göre oluşturun
Belge numarası oluştuğunda entegrasyon satış kaydını muhasebe programına iletir. Satış geliri, hesaplanan vergi, müşteri veya banka alacağı, kargo geliri ya da gideri ve pazaryeri komisyonu ayrı hesaplarda izlenebilir.
Hesap kodlarını yazılım içinde gelişigüzel sabitlemeyin. Mali müşaviriniz hesap planını oluşturmalı, işletme de hangi satış kanalının hangi kayıtla eşleşeceğini onaylamalıdır. Bu adım, dönem sonunda gelir ve komisyon farklarını araştırma yükünü azaltır.
5. Belge sonucunu sipariş ekranına geri gönderin
Entegrasyon, belge numarasını, belge durumunu ve hata bilgisini sipariş ekranına geri aktarmalıdır. Böylece müşteri hizmetleri ekibi, sipariş ekranından belge sürecini kontrol eder. Ayrıca destek ekibi belge numarasını aramak için farklı paneller arasında geçiş yapmaz.
Veri eşleştirme listesi olmadan bağlantı kurmayın
Entegrasyon projelerinde sorunların çoğu API bağlantısından değil, alan eşleştirmesinden çıkar. Aynı veri, bir sistemde farklı adla veya farklı hesaplama yöntemiyle yer alabilir. Örneğin sipariş toplamı kargo bedelini içerirken muhasebe kaydı bu bedeli ayrı takip edebilir.
Kurulumdan önce her kaynak alan için kısa bir veri eşleştirme listesi hazırlayın. Bu liste, yazılım ekibi ile mali müşavir arasındaki kararları görünür hale getirir.
- Kaynak alanı ve hedef alanı belirtin.
- Her tutar için hesaplama ve yuvarlama kuralını yazın.
- İndirim, kupon, hediye çeki ve kargo bedelini ayrı değerlendirin.
- Satır bazındaki vergi bilgisini toplam tutarla karşılaştırın.
- Eksik veride sistemin hata kuyruğuna mı, onay kuyruğuna mı gireceğini tanımlayın.
- Her kuralın operasyon sorumlusunu ve mali onay sahibini belirleyin.
Satış altyapınızın API kapasitesi, veri alanları ve pazaryeri bağlantıları bu aşamayı doğrudan etkiler. Platform kararını verirken e-ticaret altyapısı seçimi rehberindeki entegrasyon kriterlerini incelemek fayda sağlar.
E-belge, iptal ve iade kayıtlarını ayrı yönetin
E-belge akışında en kritik risk, tekrar denemelerde mükerrer belge oluşmasıdır. Bu nedenle sistem, idempotent bir yapı kullanmalıdır. İdempotent yapı, aynı isteği tekrar aldığında yeni bir belge üretmek yerine önceki işlemin sonucunu kontrol eder.
Müşterinin iade ettiği veya işletmenin iptal ettiği siparişlerde mevcut belgeyi silmeye çalışmayın. İşletme, mevcut belgeye bağlı düzeltme veya iade adımını tanımlı mali süreçle yürütmelidir. Müşteri bildirimi, ürünün geri gelişi, ödeme iadesi ve belge kaydı aynı tarihte tamamlanmayabilir.
Bu yüzden iade akışı hem müşteri deneyimini hem de finansal kaydı kapsar. E-ticarette iade ve cayma hakkı rehberindeki operasyon adımlarını, belge ve muhasebe kurallarınızla birlikte değerlendirin.
Mutabakatı sadece banka tutarıyla sınırlamayın
Mutabakat, sipariş raporundaki tahsilatları ödeme kuruluşu raporları, pazaryeri hakedişleri, banka hareketleri ve muhasebe fişleriyle karşılaştırma sürecidir. Bankaya yatan net tutar tek başına yeterli bilgi vermez. Komisyon, iade, kampanya katkısı ve diğer kesintiler fark yaratabilir.
Basit bir kontrol mantığı kurun: brüt tahsilat eksi iade, komisyon ve diğer kesintiler beklenen net ödemeyi verir. Ardından beklenen net ödeme ile banka hareketini karşılaştırın. Her farkı sipariş numarası, ödeme işlem kimliği ve ödeme referansıyla açıklayın.
- Başarılı görünüp banka hareketinde yer almayan tahsilatlar
- Banka hesabına geçen ancak sipariş kaydı bulunmayan tutarlar
- Pazaryeri raporundaki komisyon ile muhasebe kaydındaki komisyon farkları
- İade edilen ama belge veya ödeme kaydı açık kalan siparişler
İşlem hacminize göre günlük veya haftalık kontrol düzeni kurun. Dönem sonunu beklemek yerine farkları oluştuğu gün incelemek, düzeltme sürecini daha yönetilebilir hale getirir.
Kurulumdan önce test senaryolarını planlayın
İlk kurulumda canlı siparişlerle deneme yapmak gereksiz risk yaratır. Önce test ortamında veya sınırlı bir sipariş grubunda akışı doğrulayın. Her testte hem ekran sonuçlarını hem de muhasebe fişlerini mali müşavirinizle kontrol edin.
- Tek ürünlü, indirimli ve kargo ücretli bir siparişi test edin.
- Birden fazla vergi oranı veya farklı ürün türü içeren siparişi deneyin.
- Başarısız ödeme, bekleyen ödeme ve kapıda ödeme senaryolarını çalıştırın.
- Pazaryeri siparişi ile kendi sitenizdeki siparişi ayrı kaynaklar olarak inceleyin.
- İptal, kısmi iade ve tam iade akışını belge referanslarıyla kontrol edin.
- Tekrar gönderilen bir API isteğinde sistemin ikinci belge üretmediğini doğrulayın.
Sipariş ile stok verisi de aynı anda ilerlemelidir. Aksi halde muhasebe kaydı doğru olsa bile satışa açık ürün miktarı yanlış kalabilir. Bu bağlantıyı e-ticaret stok yönetimi rehberi ile birlikte planlayın.
Güvenlik tarafında rol bazlı erişim tanımlayın. API anahtarlarını açık dosyalarda paylaşmayın, erişim kayıtlarını takip edin ve ayrılan ekip üyelerinin yetkilerini hemen kaldırın. Operasyon sorumlusu hata kuyruğunu düzenli incelemeli, mali sorumlu da hesap eşleştirmelerini dönemsel olarak gözden geçirmelidir.
Antalya ilçelerindeki e-ticaret işletmeleri için kapsam
KepezWeb; Akseki, Aksu, Alanya, Demre, Döşemealtı, Elmalı, Finike, Gazipaşa, Gündoğmuş ve İbradı'nda faaliyet gösteren işletmelerin entegrasyon süreçlerini dijital kanallardan planlar. Kaş, Kemer, Kepez, Konyaaltı, Korkuteli, Kumluca, Manavgat, Muratpaşa ve Serik'teki e-ticaret işletmeleri de satış kanalları, e-belge yapıları ve muhasebe programları için aynı analiz akışından yararlanabilir.
İlçe fark etmeksizin önce mevcut sistemleri, sipariş hacmini, satış kanallarını ve mali kayıt düzenini inceleriz. Ardından veri eşleştirme listesi, test senaryoları ve hata yönetim planı üzerinden ilerleriz.
Sıkça Sorulan Sorular
E-ticaret muhasebe entegrasyonu her işletme için gerekli mi?
Az sipariş alan işletmeler manuel kayıtla başlayabilir. Ancak satış kanalı, ödeme yöntemi veya sipariş sayısı arttıkça tekrar eden veri girişi hata riskini yükseltir. Entegrasyon kararı için iş yükünü, hata maliyetini ve raporlama gereksinimini birlikte değerlendirin.
Hangi e-belge türünü kullanacağımı kim belirler?
Mali müşaviriniz, mükellefiyet durumunuzu, satış biçiminizi ve güncel GİB kurallarını değerlendirerek belge türünü belirlemelidir. Yazılım ekibi bu kararı sistemdeki kural setine dönüştürür.
Pazaryerleri ve kendi e-ticaret sitem aynı muhasebe akışında çalışabilir mi?
Evet. Sistem, her satış kanalını ayrı kaynak olarak işaretlediğinde verileri ortak muhasebe planına aktarabilir. Pazaryeri komisyonları, hakediş tarihleri ve ödeme referansları için ayrı eşleştirme kuralları gerekir.
Entegrasyon hata kaydı oluşturursa ekip ne yapmalı?
Önce sipariş numarası, hata açıklaması ve kaynak sistem kaydını kontrol edin. Eksik veya hatalı veriyi düzeltin, ardından işlemi aynı eşsiz referansla yeniden deneyin. Sistem logları, tekrar eden sorunları tespit etmenize yardımcı olur.
E-ticaret muhasebe entegrasyonu projenizde sipariş, e-belge ve mutabakat kurallarını tek akışta toplamak istiyorsanız teklif formunu kullanın. KepezWeb, veri haritanızı ve test senaryolarınızı proje kapsamına göre birlikte netleştirir.
