Cari Mutabakat Yazılımı: ERP, Ekstre, Fark ve Onay Akışı Rehberi

Cari mutabakat yazılımı, iki şirketin aynı döneme ait borç, alacak, fatura, tahsilat ve mahsup kayıtlarını karşılaştırmasını kolaylaştırır. İyi planlanan sistem yalnızca ekstre gönderen bir ekran değildir; hangi kaydın hangi kaynağa dayandığını, farkın neden oluştuğunu, kim tarafından incelendiğini ve mutabakatın hangi kapsamla kapatıldığını gösteren bir kontrol katmanıdır.

Bu nedenle proje “PDF üretelim ve e-posta atalım” cümlesiyle başlamamalıdır. Önce muhasebe kaynağı, karşılaştırma anahtarları, toleranslar, itiraz akışı, yetkiler ve denetim izi tanımlanmalıdır. Aksi hâlde manuel sürecin belirsizliği yalnızca yeni bir arayüze taşınır.

Cari mutabakat yazılımı hangi problemi çözmelidir?

Temel görev, iki tarafın belirli bir kesim tarihinde aynı ticari bakiyeyi ve bu bakiyeyi oluşturan hareketleri görüp görmediğini kanıtlamaktır. “Bakiyeler eşit” sonucu tek başına yeterli değildir. Açılış bakiyesi, dönem hareketleri, kapanış bakiyesi, para birimi, vade, belge numarası ve mahsup ilişkisi birlikte açıklanabilmelidir.

Otomasyonun değeri her farkı kendiliğinden kapatmasında değil, güvenli eşleşmeleri ayırıp belirsiz kayıtları doğru kişiye yönlendirmesindedir. Microsoft’un hesap mutabakatı yaklaşımı da otomatik eşleşen kayıtları ve çözülmesi gereken istisnaları ayrı izler; kapanıştan önce farkların ele alınmasını gerektirir (Microsoft Learn hesap mutabakatı dokümantasyonu).

Kumsal cari mutabakat kontrol modeli

Kapsamı yedi kontrol alanına ayırmak, tekliflerin ve kabul testlerinin karşılaştırılmasını kolaylaştırır:

1. Kaynak: ERP, muhasebe, banka veya tahsilat sistemi hangi kaydın sahibidir?
2. Kesim: Dönem, saat dilimi, kapanış anı ve sonradan gelen kayıt nasıl ele alınır?
3. Normalizasyon: Belge numarası, cari kod, para birimi ve işaret kuralları nasıl ortaklaştırılır?
4. Eşleştirme: Kesin, toleranslı, çoktan-bire ve manuel eşleşme hangi kurallarla yapılır?
5. İstisna: Eksik belge, kur farkı, mükerrer kayıt veya kısmi tahsilat kime atanır?
6. Onay: Karşı tarafın yetkisi, kapsamı ve beyan zamanı nasıl doğrulanır?
7. Kanıt: Veri sürümü, bildirim, yanıt, açıklama ve değişiklik geçmişi nasıl saklanır?

ERP ve muhasebe verisi nasıl hazırlanır?

İlk karar, sistemin hangi kayıtları okuyacağıdır. Cari hareket, fatura, tahsilat, iade, kur farkı ve mahsup farklı tablolarda tutulabilir. Entegrasyon her tabloyu doğrudan portal mantığına taşımak yerine değişmez bir mutabakat veri sözleşmesine dönüştürmelidir. Bu sözleşmede kaynak kimliği, şirket, cari hesap, belge türü, belge tarihi, vade, para birimi, borç/alacak yönü, tutar, açık tutar ve kaynak güncelleme zamanı bulunmalıdır.

Dönem kapandıktan sonra değişen hareketler sessizce eski ekstreyi değiştirmemelidir. Her gönderim, kullanılan veri anının sürümünü taşımalıdır. Sonradan gelen kayıt yeni sürüm veya bir sonraki dönem kuralıyla işlenmelidir. Böylece taraflar farklı veri anlarına bakarken aynı bakiyeyi tartıştıklarını sanmaz.

Eşleştirme kuralları açıklanabilir olmalıdır

Belge numarası ve tutar bire bir eşleşiyorsa sonuç güçlüdür; ancak gerçek hayatta boşluk, ön ek, yuvarlama, toplu ödeme ve kısmi mahsup vardır. Bu nedenle kurallar güven düzeyine göre sınıflandırılmalıdır:

• Kesin eşleşme: benzersiz kaynak veya belge kimliği aynıdır.
• Kurallı eşleşme: cari, para birimi, tutar ve tarih penceresi birlikte uyumludur.
• Toleranslı eşleşme: onaylanmış yuvarlama veya kur farkı sınırı içindedir.
• Birleşik eşleşme: bir ödeme birden fazla faturayı ya da bir fatura birden fazla ödemeyi karşılar.
• İnceleme gerekli: birden çok olası aday vardır veya mali etkisi belirlenen eşiği aşar.

Otomatik kararın yanında kullanılan kural ve girdiler gösterilmelidir. Kullanıcı eşleşmeyi bozduğunda gerekçe istenmeli; bu geri bildirim kural kalitesini ölçmek için kullanılmalıdır. Bir model veya benzerlik skoru kullanılıyorsa sonuç “kesin doğru” gibi sunulmamalıdır.

Fark yönetimi ayrı bir iş kuyruğudur

Mutabakat ekranındaki en önemli bölüm çoğu zaman “eşleşmeyenler” listesidir. Fark nedeni seçilebilir, açıklanabilir ve belgeyle desteklenebilir olmalıdır. Eksik fatura, yanlış cari, kısmi ödeme, vade farkı, iade beklemesi, kur farkı ve mükerrer kayıt aynı statü altında bırakılmamalıdır.

Her istisnanın sahibi, hedef tarihi, son hareketi ve beklediği taraf görünmelidir. Finans ekibi kendi iç düzeltmesini yaparken satış ekibi müşteriden belge isteyebilir; portal bu görevleri tek onay kutusuna sıkıştırmamalıdır. İş tamamlandığında kayıt yeniden eşleştirme motoruna girmeli veya yetkili kullanıcı tarafından gerekçeli biçimde kapatılmalıdır.

Karşı taraf deneyimi nasıl tasarlanmalıdır?

Alıcı, uzun bir tabloyu incelemeye zorlanmadan önce dönem, para birimi, açılış ve kapanış bakiyesini görmelidir. Ardından hareketlere, eşleşmeyen kayıtlara ve destekleyici belgelere inebilmelidir. “Mutabıkız” ve “Mutabık değiliz” seçenekleri kapsamı açık bir beyana bağlanmalıdır.

Yetkili kişi davet bağlantısıyla geliyorsa bağlantı tek başına sınırsız erişim sağlamamalıdır. Kurum ilişkisi, kullanıcı rolü, oturum süresi ve gerekiyorsa ek doğrulama uygulanmalıdır. Finansal ekstreler kişisel veya hassas ticari alanlar içerebileceğinden erişim, log, maskeleme ve saklama kararları riskle orantılı ele alınmalıdır. KVKK, tek tip önlem yerine işlenen verinin niteliğine ve kuruluşun riskine uygun teknik ve idari tedbirler öngörür (KVKK veri güvenliği yükümlülükleri).

Bildirim ile hukuki beyanı birbirine karıştırmayın

E-posta, SMS veya uygulama bildirimi kullanıcıyı sürece çağırır; mutabakat kararının kendisi değildir. Sistem gönderim, teslim, görüntüleme ve yanıt olaylarını ayrı kaydetmelidir. Elektronik onayın hukuki niteliği; kullanılan yöntem, taraflar arasındaki sözleşme, sektör ve somut uyuşmazlığa göre değişebilir. Bu nedenle makale veya yazılım ekranı genel bir “kesin delildir” iddiası taşımamalı; şirketin hukuk ve mali müşavirlik değerlendirmesine göre beyan metni yapılandırılmalıdır.

MVP kapsamı ne olmalıdır?

İlk sürümde her muhasebe senaryosunu otomatikleştirmek yerine yüksek hacimli ve tanımlı bir cari grubu seçmek daha güvenlidir. Önerilen MVP; tek ERP şirketi, sınırlı belge türü, birincil para birimi, sürümlü ekstre, kesin eşleşme, manuel istisna kuyruğu, yetkili karşı taraf onayı ve değiştirilemez olay günlüğünden oluşabilir.

İkinci aşamada çoklu şirket, döviz, grup şirketi mahsupları, toplu tahsilat, gelişmiş tolerans ve ERP’ye geri yazma eklenebilir. Geri yazma başlamadan önce mükerrer işlem koruması, tekrar deneme, kısmi hata ve ters kayıt senaryoları test edilmelidir.

Kabul testleri gerçek farkları kapsamalıdır

Başarı yalnızca iki eşit ekstreyle ölçülmemelidir. En az şu senaryolar denenmelidir: kesim anından sonra gelen fatura, aynı numaralı farklı belge, birden fazla faturayı kapatan ödeme, farklı para birimi, kısmi tahsilat, yanlış cari kodu, geri alınan onay, süresi dolan davet, yetkisiz dosya erişimi ve ERP bağlantısı kesilirken yeniden deneme.

Ayrıca mutabakat tamamlandıktan sonra kaynak kaydın değişmesi test edilmelidir. Sistem eski onayı sessizce geçerli saymamalı; etkilenen kapsamı yeniden açmalı veya yeni sürüm oluşturmalıdır.

Veri modeli ve raporlama hangi soruları cevaplamalıdır?

Mutabakat kaydı yalnızca cari hesap ve dönemden oluşursa operasyon kısa sürede tekrar tablolara döner. Dönem başlığı altında veri sürümü, gönderim kapsamı, taraflar, para birimleri ve durum bulunmalıdır. Hareket seviyesinde kaynak kimliği, belge ilişkisi, eşleşme grubu, kullanılan kural, güven düzeyi ve fark nedeni tutulmalıdır. Görev seviyesinde ise sorumlu ekip, kullanıcı, hedef tarih, beklenen taraf ve kapanış gerekçesi ayrı alanlar olmalıdır.

Yönetim raporu “kaç mutabakat gönderildi?” sorusunun ötesine geçmelidir. İlk gönderimde eşleşme oranı, fark nedenlerinin dağılımı, incelemede bekleme süresi, karşı taraf yanıt süresi, yeniden açılan dönem sayısı ve entegrasyon hataları birlikte izlenebilir. Bu metrikler bir tasarruf veya tahsilat garantisi değildir; darboğazın veri kalitesinde mi, süreç sahipliğinde mi yoksa karşı taraf iletişiminde mi olduğunu gösteren operasyon sinyalleridir.

Ölçümlerde payda açık yazılmalıdır. Örneğin otomatik eşleşme oranı; tüm hareketler, yalnızca eşleşmeye uygun hareketler veya tutar toplamı üzerinden hesaplanabilir. Aynı isimle farklı hesap yapmak yanıltıcı sonuç üretir. Rapor tanımı, kural değiştiğinde sürümlenmeli ve geçmiş dönemlerle karşılaştırmanın sınırı belirtilmelidir.

Teklifleri hangi ölçütlerle karşılaştırabilirsiniz?

Teklifte ekran sayısından önce veri sahipliği, entegrasyon yönü, eşleştirme kuralları, istisna modeli, yetkilendirme, olay günlüğü, saklama, test ve işletme sorumluluğunu arayın. “Yapay zekâ ile otomatik mutabakat” gibi geniş ifadeler; hangi alanların kullanıldığı, hangi eşikte insan incelemesi gerektiği ve yanlış eşleşmenin nasıl geri alınacağı açıklanmıyorsa yeterli kapsam değildir.

Mutabakat portalı mevcut B2B satış ve ödeme akışının parçası olacaksa Kumsal Ajans web yazılım hizmetleri kapsamında ERP, finans, güvenlik ve kullanıcı deneyimi birlikte ele alınabilir. Sağlıklı başlangıç çıktısı ekran çizimi değil; örnek veri, fark nedenleri, rol matrisi ve kabul senaryolarıyla hazırlanmış bir kapsam belgesidir.