Acentenin Defteri: Bir Sigorta Aracısının Gözünden Sıfırdan Muhasebe

1. Acente neyin muhasebesini tutar?

Bir sigorta acentesinin muhasebesini anlamak için, önce acentenin para akışındaki yerini anlamak gerekir. Bir bakkal düşünün: malı alır, üstüne kâr koyar, satar. Kasasına giren paranın tamamı, maliyet düşülmeden önce, onun cirosudur. Acente böyle çalışmaz. Acente, sigorta şirketinin ürününü (poliçeyi) müşteriye ulaştıran bir aracıdır. Müşteriden aldığı primin neredeyse tamamı kendisinin değildir; sigorta şirketine aittir. Acentenin kazancı, yalnızca bu işi yaptığı için sigorta şirketinden hak ettiği komisyondur.

Bu yüzden kapaktaki huni tesadüf değil. Müşteriden 13.500 TL prim girer, bunun belki 1.350 TL'si komisyon olarak acentede kalır, geri kalanı sigorta şirketine gider. Muhasebenin acente için en temel görevi, daha ilk günden şu iki parayı birbirine karıştırmamaktır: üzerinden geçen emanet para (prim) ile gerçekten kazandığı para (komisyon). Bu ayrımı 5. bölümde didik didik edeceğiz; ama bütün sistemin neden kurulduğunu en baştan bilmekte fayda var.

Hukuki bir parantez: acente parayı tutamaz

Bu sadece bir muhasebe inceliği değil, aynı zamanda bir kuraldır. Sigorta mevzuatında acente ve broker, sigorta şirketi adına serbestçe para tutup biriktiremez; aracılık eder, tahsilatı kolaylaştırır, ama primi kendi geliriymiş gibi hesaplarında bekletemez.¹ Pratikte bunun anlamı şudur: poliçenin parası, ya doğrudan müşterinin kartından/IBAN'ından sigorta şirketinin sistemine girer, ya da acente onu en kısa sürede şirkete aktarır. Bu nüans, ileride "neden acente parayı bankasından şirkete havale etmez de hep kartla kapatır" sorusunun cevabıdır.

Bu yazının yol haritası da bu mantığı izliyor. Önce muhasebenin evrensel dilini öğreneceğiz (borç, alacak, hesap planı, cari). Sonra bu dili sigortaya özgü gerçeklerle dolduracağız (prim, komisyon, tahsilat). En sonda da bütün bunları çalışan bir yazılım modülüne nasıl çevireceğimize bakacağız. Acele etmeden, kolaydan zora.

2. Al gülüm ver gülüm: borç ve alacak

Muhasebenin tamamı tek bir fikrin üzerine kuruludur ve o fikir aslında çok basittir: her işlemin iki yüzü vardır. Para yoktan var olmaz, yokken kaybolmaz; daima bir yerden bir yere hareket eder. Bir taraf verir, bir taraf alır. Bu yönteme çift taraflı kayıt (double-entry) denir ve bunu sahada işin içinde olanlar çok daha güzel özetliyor: "al gülüm, ver gülüm". Her kayıtta bir veren, bir alan olur; ve verilen ile alınan birbirine eşittir.

Borç ve alacak: kafa karıştıran iki kelime

Muhasebede her hesap, ortadan ikiye bölünmüş bir cetvele benzer. Sol tarafına "borç" (debit), sağ tarafına "alacak" (credit) denir. Buradaki en büyük tuzak şudur: bu kelimeler günlük dildeki "borçlu olmak / alacaklı olmak" anlamına gelmez. Muhasebede "borç" sadece "sol taraf", "alacak" sadece "sağ taraf" demektir.² İsimlerine değil, hangi hesabın hangi tarafla büyüdüğüne bakacağız.

Pratik bir sezgi, sahada işi yürütenlerin kullandığı kuraldır: bir hesaba para girdiyse o hesap borçlanır. Banka hesabınıza 2.400 TL girdiyse, o banka hesabı "bana 2.400 TL emanet edildi, bunu sana borçluyum" der gibi borç tarafına yazılır. Para çıkan, veren taraf ise alacaklanır. Kulağa ters gelebilir, ama bütün bilanço mantığı bunun üzerine oturur.

Daha sağlam bir kural, hesabın türüne bakar. Muhasebenin temel denklemi şudur ve hiçbir zaman bozulmaz:

Varlıklar = Borçlar + Özkaynaklar   (Aktif = Pasif)

Sahip olduğunuz her şeyin (varlık) bir kaynağı vardır: ya birine borçlusunuzdur, ya da kendi sermayenizdir. Denklemin iki yanını dengede tutmak için her hesap türü bir tarafla büyür:³

Tek cümlede: varlık hesapları borçla büyür; borç, özkaynak ve gelir hesapları alacakla büyür. Bir varlık hesabı (kasa gibi) asla alacak bakiyesi vermez; kasada eksi para olmaz.

Fiş, yevmiye, defter-i kebir

Bu ikili kaydın somut hali fiştir. Her fiş en az iki satırdan oluşur: en az bir borç, en az bir alacak. Ve fişin borç toplamı, alacak toplamına eşit olmak zorundadır. Bu eşitlik bozuluyorsa fiş kaydedilmemelidir; muhasebe yazılımının kalbindeki kural budur.

Aynı kayıtlar iki farklı düzende saklanır. Yevmiye defteri (günlük defter), işlemleri tarih sırasına göre, madde madde tutar. Defter-i kebir (büyük defter) ise aynı kayıtları hesap bazında toplar: "100 Kasa hesabının bütün hareketleri", "320 sigorta şirketinin bütün hareketleri" gibi.⁴ İkisi aynı verinin iki görünümüdür: biri zaman ekseninde, biri hesap ekseninde. Bir hesabın tek tek hareketlerini ve en sonda kalan bakiyesini gösteren döküme ekstre denir; bu kavram 4. bölümde merkeze oturacak.

3. Hesap planı: paranın yaşadığı çekmeceler

Borç ve alacak ne tarafa yazılacağını söyledi. Peki "ne"ye yazılacak? İşte burada hesap planı devreye girer. Hesap planı, paranın yaşadığı numaralı çekmecelerin listesidir: kasa bir çekmece, banka başka bir çekmece, her müşteri ayrı bir göz, her sigorta şirketi ayrı bir göz. Her hareket mutlaka bir çekmeceye girer.

Tek Düzen Hesap Planı (TDHP)

Türkiye'de bu çekmeceler keyfî değildir. 1994'ten beri, bilanço esasına göre defter tutan tüm işletmeler Tek Düzen Hesap Planı'nı kullanmak zorundadır.⁵ Kodlar 1'den 9'a kadar ana sınıflara ayrılır ve soldan sağa gittikçe detaylanır:

Kodun her hanesi bir kırılımdır: ilk hane sınıfı (1 = Dönen Varlıklar), sonraki haneler grubu ve ana hesabı (100 = Kasa), ondan sonrası ise alt hesapları verir. Bir acentede en çok ihtiyaç duyulan kırılım, ana hesabın altındaki cari/muavin seviyesidir: 320 Satıcılar altında her sigorta şirketi ayrı bir alt hesap (320.01 Anadolu, 320.02 Allianz...), 120 Alıcılar altında her müşteri ayrı bir göz olur.

Hiyerarşi, sıralı numara ve "global olması"

Her hesabın, tıpkı bir kimlik numarası gibi, sabit ve sıralı bir kodu vardır. Hesap açarken önce seviye seçilir (ana / ara / alt), sonra sistem o dalda en son kullanılan numaranın bir fazlasını verir: 100 → 100.01 → 100.01.01 → 100.01.01.001; ikinci hesap ...002 olur. Bu otomatik sıralı numara üreteci, yazılım tarafının ilk ciddi bileşenlerinden biridir.

Saha deneyiminin altını çizdiği bir karar var: bir CRM içinde hesap planı dinamik değil, sabit (global) tutulmalı. Çünkü bir acente sigorta şirketlerini 329'da, başka biri 309'da tutmaya kalkarsa, bütün acentelerin verisi birbirini tutmaz hale gelir. Doğru yaklaşım, mali müşavirle birlikte hazırlanmış tek bir global plan koymak; acenteye yalnızca alt hesap seviyesinde (kendi bankası, kendi kartı) esneklik bırakmaktır.

4. Cari hesap: hesabın borcu, poliçenin değil

Şimdi muhasebenin belki de en çok kafa karıştıran, ama bir kez oturunca her şeyi netleştiren kavramına geldik: cari hesap. "Cari", iş yaptığınız her gerçek veya tüzel kişidir: her müşteri bir cari, her sigorta şirketi bir cari, her banka bir cari. "Cari hesap" ise o kişiyle aranızdaki bütün borç-alacak hareketlerinin kalem kalem tutulduğu, sürekli güncellenen defterdir.⁶

En iyi benzetme banka ekstresidir. Banka hesabınıza bakarsınız: şu kadar girdi, şu kadar çıktı, dipte şu kadar bakiye kaldı. Cari hesap da aynen böyledir. Bir müşterinin carisine bakar ve dersiniz ki: "Bu yıl 45.000 TL borçlandı, 30.000 TL ödedi, demek ki bana hâlâ 15.000 TL borçlu."

Bakiyenin yönü: kim kime borçlu?

Bir carinin bakiyesi, o ilişkideki net pozisyonu söyler. Ama burada bir uyarı var: bakiyenin "borç" mu "alacak" mı olduğu, kimin defterinden baktığınıza göre değişir.

• Müşteri carisinde (120) borç bakiyesi: müşteri bize borçlu, tahsil etmemiz lazım.
• Sigorta şirketi carisinde (320) alacak bakiyesi: biz şirkete borçluyuz, ödememiz lazım.
• Sigorta şirketi carisinde (320) borç bakiyesi: şirket bize borçlu (hak ettiğimiz komisyon), tahsil ederiz.

Yazılım tarafında bunun pratik dersi nettir: cari bakiyeyi ekranda yalnızca "B" veya "A" harfiyle göstermeyin; "borç bakiyesi" / "alacak bakiyesi" diye açıkça yazın ve hangi tarafın esas alındığını belirtin. Aksi halde aynı ekran iki kişiye iki farklı şey söyler.

Bu noktada bir CRM'in klasik muhasebeden ayrışabileceği yer açılıyor. Sigortacıda çoğu zaman "şu poliçenin borcu ne kadar kaldı?" sorusunun cevabı gerçekten gerekir: yenileme yaparken, hasar anında, müşteriye geri dönerken. Yani sağlam mimari, cari bazlı klasik muhasebeyi temel almak, ama her tahsilatın hangi poliçeye gittiğini de arka planda izleyerek üstüne bir "poliçe bazlı borç" katmanı koymaktır. Altyapı zaten oradadır (her fiş satırı bir poliçeye bağlanabilir); mesele bunu bir ekrana çıkarmaktır. Bu, 10. bölümde InsurUp'ın bilinçli farkı olarak geri gelecek.

5. Sigortanın kalbi: prim mi, komisyon mu?

Buraya kadar öğrendiklerimiz her sektör için geçerliydi. Şimdi sigorta aracısını diğer her işten ayıran tek en önemli kurala geliyoruz. Bunu bir kez doğru oturtursanız, geri kalan her şey yerine oturur; yanlış oturtursanız bütün modül baştan bozuktur.

Komisyon neden 320 ile çalışır

Normal ticarette gelir, müşteriyle (120) karşılıklı yazılır; çünkü hizmeti müşteriye verirsiniz. Ama acente aracılık hizmetini müşteriye değil, sigorta şirketine verir. Bu yüzden komisyon geliri kaydı, müşteriyle değil, sigorta şirketi carisiyle karşılıklı çalışır: 320 borç / 600 alacak. Sigorta aracısı muhasebesinin en ayırt edici teknik detayı budur.⁷

Bir ayrıntı daha: komisyon geliri için acente fatura kesmez. Bunun yerine sigorta şirketi, ödediği komisyon için "Sigorta Komisyon Gider Belgesi" (kısaca SKGB, elektroniği e-SKGB) düzenler ve bu belge fatura yerine geçer.⁸ Acente bu belgeye dayanarak komisyonu gelir kaydeder. Ayrıca acentenin sigorta şirketine sunduğu aracılık hizmeti KDV'den istisnadır; sigorta işlemlerinde BSMV'nin mükellefi ise acente değil, sigorta şirketidir.⁹ (İki bağımsız acente kendi aralarında komisyon paylaşırsa bu istisna geçmez; o zaman fatura ve KDV devreye girer.)

Her transferde açılan iki fiş

Sahada işleyen sistemin altın kuralı şudur: bir poliçe sisteme girer girmez, ödemesine daha bakmadan, her satır için iki fiş otomatik açılır. Aşağıdaki araçta brüt primi ve komisyon oranını değiştirerek bu iki fişin nasıl üretildiğini görebilirsiniz. Dikkat edin: komisyon değiştikçe prim fişi (129/329) hiç değişmez; komisyon ayrı bir hatta durur.

6. Bir poliçenin yolculuğu: fişler ve senaryolar

İki tahakkuk fişini (prim borcu + komisyon alacağı) artık biliyoruz; bunlar her poliçede açılır. Asıl çeşitlilik, paranın nasıl tahsil edildiğinde ve sigorta şirketine nasıl ödendiğinde başlar. Bunları görmeden önce kısa bir sözlük gerekiyor, çünkü fişlerin de türleri vardır:

Modern programlarda temel fiş mahsup fişidir; tahsil ve tediye onun özelleşmiş halleridir. Bir iptal/zeyilde ise normal fişin borç ve alacağı yer değiştirir; buna ters kayıt (storno) denir.

Şimdi tek bir poliçeyi (Neova kasko, brüt prim 13.500 TL, komisyon 1.350 TL) alıp, farklı tahsilat senaryolarında muhasebenin nasıl aktığını izleyelim. Aşağıdan bir senaryo seçin; her seferinde önce iki tahakkuk fişi açılmış kabul edilir, sonra o senaryoya özgü tahsilat ve ödeme fişleri gelir.

Bu senaryolardan üç ders çıkar. Birincisi: müşteri kendi kartıyla doğrudan şirkete öderse iş en temizdir; acentenin kasası, bankası veya kartı hiç devreye girmez, sadece prim borcu kapanır. İkincisi: acente parayı elden veya IBAN'a aldığında, o para sigorta şirketine havale edilmez; poliçe her zaman ekrandan bir kartla (genelde acentenin şirket kartıyla) kapatılır, banka yalnızca sonradan o kart borcunu kapatmak için kullanılır. Bu, 1. bölümdeki "acente parayı tutamaz" ilkesinin muhasebedeki izdüşümüdür. Üçüncüsü ve en kritiği: iptal ve düzeltmeler kayıt silinerek değil, ters kayıtla (storno) yapılır. Defterde silgi kullanılmaz; yanlış varsa yeni bir satırla düzeltilir.

7. Kart kimin? Açık hesap, kapalı hesap

Senaryo seçicide gördüğünüz çeşitliliğin tek bir kaynağı var: parayı kim, nasıl ödedi? Bu sorunun cevabı, bir poliçenin muhasebesinin kendiliğinden mi kapanacağını yoksa insan eli mi gerektireceğini belirler. İşin kolay ve zor kısmı buradan ayrılır.

• Kapalı hesap: müşteri poliçenin parasını tam ve kendi (kendi kredi kartı veya IBAN'ı) öder. Sistem fişleri otomatik açar, kimse dokunmaz. İdeal durum.
• Açık hesap: mail order, senet, parça parça ödeme, nakit, ya da acentenin kendi (şirket) kartının kullanılması. İşin karışan, insan gerektiren kısmı burasıdır.

Önce "unit", sonra kartın sahibi

Bir poliçe tek bir satır değildir. Aslına bir zeyil eklenir (ek/değişiklik), ertesi yıl yenilenir. Muhasebenin izlediği en küçük birim, sahanın deyimiyle unit'tir: poliçe no + zeyil no + yenileme no. Her unit'in kendi ödemesi, kendi kartı vardır. Sıfır veya eksi primli satırlara (çoğu zeyil) kart gerekmez; ama bir kuruş bile artı primi olan her satırın kart numarası dolu olmalıdır. Kart sahibinin adı önemli değildir; önemli olan numaradır, çünkü o numaradan kartın acenteye mi yoksa müşteriye mi ait olduğu çözülür.

Neden bu ayrım her şeyi belirler? Çünkü müşteri kartı görülürse, para zaten müşteriden tahsil edilmiş demektir; sistem güvenle "kapalı hesap" deyip fişleri açar. Ama şirket kartı görülürse, poliçeyi acente kendi kartıyla kapatmış demektir; karşılığında müşteriden para alınıp alınmadığı henüz belli değildir. Bu yüzden bu kayıtlar "beklemede" bırakılır, bir insanın banka hesabına bakıp "evet, müşteriden bu para gelmiş" diye teyit etmesi gerekir.

Açık hesabın gerçek hayatı daha da çetrefildir: müşteri parça parça öder, bazı şirketler komisyondan mahsup yapar, bazıları tamamını tek seferde bekler. Bu yüzden bir muhasebe modülü kurarken doğru strateji, kapalı hesapla başlamaktır: müşterinin kendi ödediği, baştan sona otomatik akan senaryo. Açık hesap, şirket kartı ve komisyon mahsuplaşması ileri bir fazdır.

8. Tahsilattan fişe: otomatik muhasebeleşme

Şimdiye kadar fişleri elle yazıyormuş gibi konuştuk. Oysa iyi bir sistemde fişlerin neredeyse tamamı otomatik açılır. İnsanın işi, sadece otomatiğin açamadığı istisnaları kapatmaktır. Bunun nasıl olduğunu görmek için önce veriye, sonra mantığa bakalım.

Veri modeli: Collection, Fiş, Fiş Satırı

Muhasebenin hammaddesi, poliçeye bağlı tahsilat kaydıdır (Collection). Bu kayıt; brüt prim, net prim, komisyon, vergiler, döviz kuru, ödeme şekli, kart bilgisi gibi her şeyi taşır. En kritik üç alanı ise birer küçük durum makinesidir:

Bir tahsilat "posted" olduğunda, sistem bir Fiş (başlık: tarih, tip, no, açıklama) ve ona bağlı Fiş Satırları (her satır: hesap, borç, alacak, varsa döviz tutarı ve kur, ve bağlı olduğu poliçe) üretir. Yani "poliçe → tahsilat kaydı → fiş + fiş satırları" zinciri, otomatik muhasebeleşmenin boru hattıdır. Cari bakiyeler hiçbir zaman elle tutulmaz; daima bu fiş satırlarından türetilir.

Üç görev, üç durum

Çalışan bir sistemin özü şaşırtıcı derecede sade özetlenebilir: üç arka plan görevi (task), üç durum (statü).

1. Görev 1, kart ayıklama: kaydedilen acente kartlarıyla poliçedeki kart numaralarını (ilk 4 + son 4 hane) karşılaştırır. Kart acentenin kartıysa, kayıt "beklemede" bırakılır; değilse (müşteri kartı), kapalı hesaptır, fişler hemen açılır.
2. Görev 2, müşteri kartı fişleri: müşteri kartıyla eşleşen kayıtların cari ve kapanış fişlerini açar; sigorta şirketinin prim borcunu "müşteri kendi ödemiş" gibi kapatır.
3. Görev 3, şirket kartı ve nihai statü: şirket kartı işlemlerinin fişlerini açar ve her kayda son durumunu atar.

İş kuralları da nettir: aktif poliçede normal kayıt, iptal poliçede ters kayıt (storno), brüt primi sıfır olan satırlar ise hiç muhasebeleştirilmeden otomatik kapatılır. Günlük operasyonda bir kişi (çoğu zaman sigortacı bile olmayan bir muhasebe asistanı) "Tahsilat Kontrol" ekranında tarih aralığı seçip "Başlat"a basar; üç görev çalışır, açamadıklarını tabloda bırakır. Geriye kalanlar iki türdür: kart bilgisi hiç yakalanamayanlar (elle kart okunup müşteri/şirket kartı seçilir) ve şirket kartı olarak işaretlenip banka teyidi bekleyenler (banka hareketinden "evet, para gelmiş" denip "Banka ile kapat" ile kapatılır). Kısmi ödeme de buradan yönetilir: poliçe 14.276 TL ama hesaba 14.000 geldiyse, fiş 14.000 açılır, müşterinin carisinde 276 TL borç olarak kalır.

9. Ay sonu: mutabakat

Günlük akış doğru kurulduysa, ay sonu sürpriz olmaz. Ama yine de yapılması gereken bir tören vardır: mutabakat. Mutabakat, iki tarafın kendi defterlerindeki bakiyenin birbirini tutup tutmadığının karşılıklı teyididir.¹⁰ Acente için en kritiği, sigorta şirketiyle yapılan aylık komisyon ve cari mutabakatıdır.

Pratikte akış şöyle işler. Sistem, dönem için bir özet verir: "Ankara Sigorta'dan bu ay 439.000 TL üretim, 19.000 TL iptal, 43.400 TL komisyon; toplamda senin 42.000 TL alacağın var." Muhasebeci o ayın poliçe üretimini kontrol eder (kaçan, atlanan poliçe var mı). Sonra üç yoldan biri seçilir: mutabakatı onayla (rakam doğru, 42.000'i bekliyorum), uyuşmazlık (bende 45 görünüyor, sen 42 diyorsun) veya üretim yok. Para geldiğinde "Ödeme Alındı" denir; hangi banka hesabına, hangi belge numarasıyla geldiği girilir ve sistem komisyon alacağını kapatan fişi açar.

Ekranlardan görülen ince bir detay: aynı mutabakat mantığı hem sigorta şirketleri hem de kendi şubeleri/alt acenteleri için çalışır, ama para yönü terstir. Sigorta şirketinde acente komisyonu alır ("Ödeme Alındı"); şubeye veya alt acenteye ise komisyon payını öder ("Ödeme Gönderildi"). Mutabakat detayında bir KPI şeridi (poliçe adedi, iptal adedi, brüt prim, iptal brüt prim, komisyon, iade komisyon) sistemin hesabını şirketin beklentisiyle yan yana koyar.

10. InsurUp'ta nasıl yaparız?

Artık parçalar elimizde. Geriye onları bir ürün kararına çevirmek kalıyor. Bir CRM içinde muhasebe modülü kurmanın doğru sırası, bu yazının sırasının aynısıdır: önce sağlam temel, sonra otomasyon, en sonda incelikler.

MVP: nereden başlamalı

1. Önce veri, sonra muhasebe. Poliçe transferlerini ve kart bilgisini yüzde 99-100 eksiksiz almadan muhasebe modülü değersizdir. InsurUp'ın transfer altyapısı poliçe ve zeyili zaten çekiyor; eksik olan, her satırın kart numarasını şirket servisinden veya dosya import'undan tamamlamaktır.
2. Global hesap planı. Mali müşavir onaylı, sabit bir plan tohumlanmalı (tek seferde veritabanına yüklenebilir); acenteye yalnızca alt hesap esnekliği bırakılır.
3. Otomatik hesap açma motoru. Şirket, banka, kart veya müşteri tanımlandığında, hiyerarşide sıradaki numarayı üretip sabit hesapları açan bileşen. (Müşteriye cari, ancak ilk poliçesi geldiğinde açılır; her teklife açılırsa sistem şişer.)
4. Kapalı hesapla başla. Müşterinin kendi ödediği, baştan sona otomatik akan senaryo önce. Açık hesap, şirket kartı ve komisyon mahsuplaşması sonraki faz.
5. Üç görev, üç durum mimarisini devral. 8. bölümdeki otomatik muhasebeleşme reçetesi, doğrudan uygulanabilir bir başlangıçtır.

Yazılımcının kaçınması gereken tuzaklar

Bu kalıplar sigortaya özgü değil, bütün defter (ledger) sistemlerinin ortak dersidir; Uber'den Airbnb'ye, ödeme platformlarının tamamı "iki varlık (hesap, hareket) ve tek değişmez (her borcun eşit bir alacağı vardır)" modeli üzerine kuruludur.¹¹ Doğru kurulduğunda bu model, ileride şema değiştirmeden her tür değer alışverişini taşır.

Son bir not: resmî beyanı sırtlanma, dışa aktar

InsurUp'ın resmî muhasebe programı olmaya çalışmasına gerek yok. Doğru rol şudur: günlük muhasebenin yüzde 90'ını temiz bir arayüzde dijitalleştirmek, sonra veriyi standart bir formatta dışa aktarıp mali müşavirin kendi programına beslemesini sağlamak; resmî beyanı mali müşavir versin. Bu hem yasal sorumluluğu doğru yere koyar, hem de ürünü asıl güçlü olduğu yerde, kullanıcı deneyiminde, rakiplerinden ayırır.