Cari Hesap Bakiyesi Yazılımda Nasıl Hesaplanır?

Cari hesap bakiyesi, bir müşteri ya da tedarikçiyle ilgili borç ve alacak hareketlerinin tarih sırasıyla toplanmasından çıkar. Yazılımda doğru çalışmasının tek koşulu, bakiyenin bir alanda tutulan sayı değil, hareketlerden her seferinde türetilen bir sonuç olmasıdır.

Bu ayrım küçük görünür ama cari hesapla ilgili şikâyetlerin çoğu buradan doğar. Bakiye bir alanda saklandığında, o alanı güncellemeyi atlayan tek bir kod yolu bakiyeyi kalıcı olarak yanlış bırakır. Hareketlerden türetilen bakiyede ise hareket neredeyse bakiye de oradadır.

Bakiye saklanan değer değil, türetilen değerdir

Doğru kurulum şöyle işler: cari hesap hareket tablosu tek kaynaktır, bakiye bu tablonun toplamıdır. Hareket sayısı büyüdüğünde her ekranda baştan toplamak yavaşlar; bunun çözümü bakiyeyi ayrı bir alana yazmak değil, dönem bazlı özet satırı tutmaktır. Özet satırı kapanan dönemin devrini taşır, güncel dönem yine hareketlerden toplanır.

Özet kullanılıyorsa iki şey şart olur. Birincisi, özeti hareketlerden yeniden üretebilen bir yeniden hesaplama işi bulunmalıdır; şüphe durumunda tek düğmeyle çalıştırılır. İkincisi, geçmiş döneme geriye dönük hareket girildiğinde ilgili dönemin özeti geçersiz işaretlenmelidir. Bu iki kural yoksa özet, zamanla sessizce yanlışa kayar.

Hangi hareket bakiyeye girer

Cari hareket listesi şirketten şirkete değişir ama çekirdek aynıdır. Yazılımda her hareket türünün yönü tek bir yerde tanımlanmalıdır; yön kararı ekran kodunun içine dağılırsa bir ekrandan girilen iade bakiyeyi azaltır, diğerinden girilen artırır.

Tabloda dikkat edilmesi gereken satır çek ve senettir: alınan çek elde dururken borç kapanmış sayılmaz. Yazılımda bu iki durumu tek hareketle yönetmek, mutabakatta en sık görülen uyuşmazlığı üretir.

Tahsilatı faturaya eşlemek

Bakiye toplamının doğru olması yetmez; borcun hangi faturadan kaldığı da bilinmelidir. Bunu sağlayan şey ödeme eşlemesidir. Eşleme yapılmayan sistemde bakiye doğru görünür ama vadesi geçen tutar hesaplanamaz.

• Tam eşleme: Tahsilat tutarı faturaya birebir eşittir, fatura kapanır.
• Kısmi eşleme: Tahsilat faturanın bir kısmını kapatır; faturada kalan tutar alanı tutulur.
• Çoklu eşleme: Tek tahsilat birkaç faturaya bölünür. Eşleme satırları tahsilat kaydının altında saklanır.
• Avans: Henüz faturası olmayan tahsilat, eşlenmemiş alacak olarak bekler ve faturası kesildiğinde eşlenir.
• Eşlemeyi bozma: Yanlış eşleme geri alınabilir olmalı; geri alma işlemi iz kaydına yazılır.

Eşleme ekranının en kritik kuralı şudur: eşlenen tutarların toplamı tahsilat tutarını aşamaz ve her eşleme satırı kendi faturasının kalan tutarıyla sınırlıdır. Bu iki kontrol yazılımda değil kullanıcıda bırakılırsa, aynı ödemenin iki faturaya düştüğü kayıtlar ortaya çıkar.

Vade, yaşlandırma ve risk limiti

Yaşlandırma, açık bakiyenin vade tarihine göre dilimlere ayrılmasıdır. Dilim aralıklarını şirket belirler; yazılımın işi aralıkları ekrandan tanımlanabilir yapmaktır. Yaşlandırmanın çalışması için üç alanın dolu olması gerekir: fatura tarihi, vade tarihi ve kalan tutar. Vade tarihi boş bırakılan faturalar her raporda yanlış dilime düşer.

Risk limiti ise cari hesabın ileriye bakan tarafıdır. Limit kontrolü yalnızca bakiyeye bakarsa eksik kalır; açık siparişler, sevk edilmiş ama faturalanmamış irsaliyeler ve portföydeki çekler de riskin parçasıdır. Limit aşımında sistemin ne yapacağı yazılı olmalıdır: uyarı mı verecek, siparişi onaya mı düşürecek, tamamen mi engelleyecek.

Mutabakat: iki tarafın ekstresi neden tutmaz

Mutabakat, iki şirketin aynı hesaba ait kayıtlarını karşılaştırmasıdır ve ilk denemede neredeyse hiç tutmaz. Nedenler genellikle şu kısa listedendir:

1. Kesim tarihi farkı: Taraflardan biri ayın son günü, diğeri ertesi gün kesim yapmıştır.
2. Kayıt gecikmesi: Fatura karşı tarafa ulaşmış ama henüz kaydedilmemiştir.
3. İade ve iskontonun zamanlaması: Aynı iade iki tarafta farklı aylara yazılmıştır.
4. Çek durumu: Bir taraf çeki ödeme sayarken diğeri tahsil edilmediği için açık tutmaktadır.
5. Eşlenmemiş tahsilat: Ödeme yapılmış, hangi faturaya ait olduğu yazılmamıştır.
6. Kur çevrimi: Dövizli hareket iki tarafta farklı kur tarihiyle çevrilmiştir.

Yazılım tarafında mutabakatı kolaylaştıran şey, ekstrenin belge numarasıyla dışa aktarılabilmesidir. Karşı tarafın dosyasıyla belge numarası üzerinden eşleşen satırlar ayıklanır, kalan satırlar incelenir. Bu ayıklamayı yazılım yapıyorsa mutabakat yarım güne iner; elle yapılıyorsa haftaya yayılır ve her ay baştan başlar.

Kısa kontrol listesi

1. Bakiye hareketlerden mi türetiliyor, bir alanda mı saklanıyor?
2. Özet kullanılıyorsa yeniden hesaplama işi var mı?
3. Hareket türlerinin borç alacak yönü tek yerde mi tanımlı?
4. Tahsilat faturaya eşleniyor mu, kısmi ve çoklu eşleme destekli mi?
5. Vade tarihi zorunlu alan mı?
6. Risk limiti açık sipariş ve portföy çeki içeriyor mu?
7. Ekstre belge numarasıyla dışa aktarılabiliyor mu?

KAV Yazılım, cari hesap ve mutabakat akışını muhasebe tarafındaki hesap planıyla uyumlu kurar; hareket türleri ve yaşlandırma dilimleri şirketin kendi tanımlarından yönetilir.