Büyük defterde sonuçlanan CRM

Belge belge zincir

Potansiyel müşteriden tahsilata uzanan süreç bir mecaz değildir. Her birinin büyük defter üzerinde tanımlı bir etkisi olan bir belge dizisidir ve bunların çoğunun hiçbir etkisi yoktur. Hangisinin hangisi olduğu konusundaki karışıklık, paranın sızdığı yerdir.

Potansiyel müşteri, bir ilginin kaydıdır. Fırsat ise bir kişinin beklenen değer ve olasılık atadığı bir tahmin nesnesidir. İkisi de büyük deftere dokunmaz, dokunmamalıdır da. Teklif bir öneridir: fiyatı, kapsamı ve geçerlilik süresini bağlar, ama hiçbir şeyi rezerve etmeyebilir. Satış siparişi, müşterinin bu teklifi kabul etmesidir. Her iki taraf için de bir taahhüttür ve çoğu zaman satın almayı, planlamayı ya da üretimi tetikler; ancak yine de bir muhasebe kaydı değildir. Ne hasılat vardır ne de alacak.

Teslimat ya da hizmetin tamamlanması genellikle en önemli olaydır; çünkü malların ya da hizmetin kontrolü bu noktada devredilir. Fatura muhasebeleştirme noktasıdır: ticari alacakları borçlandırır, hasılatı alacaklandırır ve hesaplanan vergi yükümlülüğünü doğurur. Tahsilat, alacağı kasa ya da banka karşılığında kapatır; hasılat doğurmaz, yalnızca zaten var olan bir borcu öder. Alacak dekontu ise faturanın bir kısmını ya da tamamını tersine çevirir ve vergi hesaplanmışsa onu da iptal eder.

Siparişlerin fatura olmadığı ilkesinin pratikteki karşılığı budur. Yalnızca büyük deftere kaydedilmiş belgeler ödenir, takip edilir ve yaşlandırmada görünür. Bir sistem birinin satış siparişine ödeme uygulamasına izin veriyorsa ya da sipariş tutarını muhasebeleştirilmiş hasılatla aynı sütunda raporluyorsa, zinciri ay sonu başlamadan kırmış demektir.

• Potansiyel müşteri ve fırsat: satış hunisi kayıtları, büyük defter etkisi yok.
• Teklif: geçerlilik süresi olan fiyatlandırılmış bir öneri, büyük defter etkisi yok.
• Satış siparişi: karşılıklı bir taahhüt, büyük defter etkisi yok; ancak stoku, satın almayı ve planlamayı yönlendirir.
• İrsaliye ya da hizmet onayı: kontrolün devredildiğinin kanıtı; stoku ve satışların maliyetini hareket ettirebilir.
• Fatura: alacak borçlandırılır, hasılat alacaklandırılır, hesaplanan vergi doğar. Muhasebeleştirme burada gerçekleşir.
• Tahsilat: kasa ya da banka borçlandırılır, alacak alacaklandırılır. Hasılat değil, kapatmadır.
• Alacak dekontu: fatura tutarını ve vergiyi tersine çevirir, alttaki yükümlülüğü geri yükler ya da siler.

Ayrı sistemlerin gerçek maliyeti

CRM bir sistem, büyük defter başka bir sistem olduğunda ilk gün çarpıcı hiçbir şey olmaz. Zarar, insanların sessizce elle yaptığı ve sonra yapmayı bıraktığı küçük mutabakatlarda birikir.

Müşteri ana verisi yeniden girilir; aynı alıcı iki farklı yazılışla ve iki farklı ödeme vadesiyle iki kez var olur. Bir teklif CRM'de pazarlıkla düşürülür, fatura ise eski fiyat listesinden kesilir; ya müşteri itiraz eder ya da biri bunu düzeltmek için alacak dekontu düzenler. Satış müdürünün onayladığı bir indirim, yalnızca fatura ekranının hiç okumadığı bir CRM alanında yaşar. Prim, faturalanan ve tahsil edilen değer yerine kaydedilen sipariş değeri üzerinden hesaplanır; yani şirket, henüz muhasebeleştirmediği ve bazen hiç tahsil edemeyeceği hasılat için prim öder. Satış çeyrek için bir rakam açıklar, finans başka bir rakam; toplantı da bu farkla ilgili bir şey yapmak yerine onu açıklamakla geçer.

Bunların hepsinin kökü aynıdır: bir sisteme bir kez girilen bir değerin elle ya da içe aktarımla başka bir sisteme yeniden girilmesi. Ortadan kaldırılması gereken mekanizma farkın kendisi değil, yeniden giriştir.

Tek müşteri kaydı ve alacakların neden ilk etkilenen olduğu

Mükerrer bir müşteri genellikle bir satış düzeni sorunu olarak anlatılır. Oysa önce bir ticari alacaklar sorunudur. Kredi riski kayıt başına hesaplanır; iki kayıt olması, kimse onaylamadan kredi limitinin fiilen ikiye katlanması demektir. Yaşlandırma iki kayda bölünür, böylece hiçbiri takip edilecek kadar kötü görünmez. Ödemeler, iki ayrı hesapta tutulan faturaları kapsayan tek bir havaleyle gelir ve eşleştirmenin elle yapılması gerekir.

Müşteri kaydı, her iki fonksiyonun da dayandığı alanları bir kez tutmalı ve ikisi de bu alanları okumalıdır: yasal unvan ve ticari unvan, vergi kimlik numarası, kredi limiti, ödeme vadesi, atanmış fiyat listesi, para birimi, fatura ve teslimat adresleri ve her zaman satın alma yetkilisiyle aynı kişi olmayan tahsilat irtibat kişisi. Suudi Arabistan'da ve daha geniş Körfez bölgesinde vergi kimlik numarası bir incelik değildir; mevzuata uygun bir vergi faturasında zorunlu alandır ve yanlış ya da boş numarayla kesilen bir fatura bir biçim sorunu değil, bir uyum sorunudur.

Kredi kontrolü, söz verilmeden önce

Büyük defter, müşterinin ne kadar borcu olduğunu ve ne kadar geciktiğini zaten bilir. Yaşlandırma, faturalar kaydedildiği anda oluşur. Asıl soru, satış temsilcisinin bu bilgiyi davranışını değiştireceği anda, yani vadeler finans tarafından reddedildikten sonra değil, önerilmeden önce görüp göremediğidir.

Kaçınılması gereken örüntü tanıdıktır: vadesi geçmiş birkaç faturası olan bir müşteriye uzatılmış vade önerilir, anlaşma bu esasla kapatılır ve finans ya vadeyi geri çekip ilişkiye zarar vermek ya da kimsenin onaylamadığı bir riski kabullenmek durumunda kalır. O noktada iki sonuç da bir finans kararı değildir; satış temsilcisine bakiyenin gösterilmemiş olmasının sonucudur.

Sistemler tek olduğunda mekanizma basittir. Güncel bakiye, dilimlere göre vadesi geçmiş bakiye, kredi limiti ve kalan kullanılabilir limit hem cari hesapta hem de teklif ekranında gösterilir. Limiti aşan siparişler bir onay gerektirir ve bu onay koridorda kararlaştırılmak yerine siparişin üzerine kaydedilir. Skyline Nexus bu şekilde çalışır; çünkü CRM ve alacaklar defteri aynı müşteri hesabını okur, dolayısıyla satışa gösterilen risk, finansın baktığı bakiyenin bir kopyası değil, kendisidir.

Muhasebeleştirme zamanlaması CRM verisinde yaşar

UFRS 15 kapsamında hasılat, bir edim yükümlülüğü yerine getirildiğinde, yani taahhüt edilen mal ya da hizmetin kontrolü müşteriye devredildiğinde muhasebeleştirilir. Bu, teslimat gibi belirli bir anda ya da bir bakım sözleşmesi veya aşamalı bir inşaat projesi gibi zamana yayılarak gerçekleşebilir. Standart ayrıca işlem bedelinin bir sözleşmedeki ayrı edim yükümlülüklerine dağıtılmasını da gerektirir.

Tüm bunları belirleyen bilgi ticari belgelerde durur. Neyin taahhüt edildiği, sözleşmenin ayrı teslim edilebilir kalemleri bir araya getirip getirmediği, her birinin ne zaman teslim edildiği ya da kabul edildiği, neyin neye karşı indirimli satıldığı. CRM bu sözleşme ve teslimat verilerini tutuyor ama muhasebe sistemi bunları hiç görmüyorsa, biri dönem sonunda bunları bir elektronik tabloda yeniden kurar ve denetim izi o tabloda biter. Sipariş satırları yükümlülükleri, teslimat kayıtları da tarihleri taşıdığında, erteleme ve serbest bırakma takvimi hafızadan yeniden kurulmak yerine belgelerden türetilir.

Satış hunisi bir tahmindir, hasılat bir olgudur

Ağırlıklı satış hunisi, kapanabilecek işlerin olasılığa göre düzeltilmiş bir tahminidir. Muhasebeleştirilmiş hasılat ise büyük defterin bir dönemde kazanıldığını söylediği tutardır ve denetlenebilir. İkisi farklı sorulara yanıt verir ve asla tek bir rakam olarak görünmemelidir.

Bağlantılı bir sistem bunları birleştirmez; aralarında iz sürmenizi sağlar. Bir huni rakamından arkasındaki fırsatlara, sonra bunların dönüştüğü siparişlere, sonra bu siparişlerin ürettiği faturalara ve en sonunda tahsil edilen nakde ulaşabilirsiniz. Tahmini geliştirilebilir kılan da bu yoldur: sipariş değerinin geçmişte ne kadarının, ne kadar sürede faturalanmış hasılata dönüştüğünü ölçebilir ve tahmin yöntemini tartışmak yerine ayarlayabilirsiniz.

Neyin paylaşılması gerektiği ve ay sonunun nasıl hissettirdiği

Paylaşmak her şeyi kopyalamak anlamına gelmez. Bir kez var olan ve her iki fonksiyon tarafından okunan tanımlı bir kayıt seti ile bir belgeyi yeniden giriş olmadan bir sonraki aşamaya taşıyan tanımlı bir olay seti anlamına gelir.

Ay sonundaki kazanım dar ve somuttur. Yaşlandırma eksiksizdir; çünkü her fatura aynı sistemdeki bir siparişten gelmiştir. Satışın söylediği hasılat rakamı ile mizandaki hasılat rakamı aynıdır; çünkü yalnızca bir tane vardır. Ertelenmiş hasılat, birinin tuttuğu bir tabloyla değil, teslimat kayıtlarıyla desteklenir. Prim, büyük defter verilerinden hesaplanarak faturalanan ya da tahsil edilen değer üzerinden tahakkuk eder. Alacak dekontları tersine çevirdikleri faturalarla eşleştirilir; böylece anlaşmazlıklar, tahsilatların yavaş olduğu hissi olarak değil, bir rakam olarak görünür. Skyline Nexus bu nedenle CRM, satış, stok ve muhasebeyi tek bir veritabanında tutar: fatura ait olduğu siparişten üretilir, tahsilat da kapattığı faturaya uygulanır.

• Müşteri ana verisi: kimlik, vergi kimlik numarası, kredi limiti, vadeler, fiyat listesi, para birimi, adresler.
• Faturanın fiilen kullanacağı fiyat listeleri ve vergi uygulamalarıyla birlikte ürün ve hizmet ana verisi.
• Onaylanmış indirimler ve onaylayan kişi; bir notta değil, belgenin üzerinde saklanır.
• Yeniden yazılmadan fatura satırlarına aktarılan sipariş satırları.
• Muhasebeleştirme zamanlamasını belirledikleri için teslimat ve kabul tarihleri.
• CRM ekranlarından okunabilen canlı alacak bakiyesi ve yaşlandırma.
• Kaynak fırsata geri bağlanan fatura, tahsilat ve alacak dekontu referansları.