Site Yönetim Programı: Aidat Takibi Nasıl Seçilir?

Kısa cevap: site yönetim programı bir aidat listesi değil, bir tahakkuk ve tahsilat sistemidir. Bir programı değerlendirirken sorulacak ilk soru ekran görüntüsü değil şudur: kayıt kişiye mi yoksa bağımsız bölüme mi açılıyor, her ayın borcu tahsilattan ayrı bir kayıt olarak mı üretiliyor ve banka ekstresi sisteme okunup ödemelerle eşleştiriliyor mu? Bu üç soru hazır paketlerin büyük kısmını ilk toplantıda eler; geri kalanını da sakinlerin her ay gördüğü rapor eler.

Kayıt kişiye değil bağımsız bölüme açılır

Bir sitenin asıl varlığı sakin listesi değil, daire ve dükkânların geçmişidir. Aynı dairede beş yılda üç kiracı oturur, daire iki kez el değiştirir, bir dönem boş kalır. Kayıt kişiye açılmışsa her taşınmada geçmiş kopar: eski kiracının borcu havada kalır, yeni malik önceki dönemin gider paylaşımını göremez. Kayıt bağımsız bölüme açılmışsa dairenin defteri tektir; kişiler o deftere tarih aralığıyla bağlanır.

Bunun veri modeli sonucu nettir: bağımsız bölüm ana kayıttır, malik ve kiracı ona başlangıç-bitiş tarihiyle bağlı iki ayrı ilişkidir. Aynı daire için aynı anda bir malik ve bir kiracı olabilir, malik değişince kiracı ilişkisi bozulmaz. Bir borcun kime yansıtılacağı yönetim planına ve kat malikleri kurulu kararına bağlıdır; yazılım bu kararı sabit bir kural olarak gömmez, tahakkuk türü başına kimin muhatap olduğunu alan olarak taşır. Arsa payı da bağımsız bölümün alanıdır, çünkü ortak giderlerin paylaşımında kullanılır.

Daire kişiye göre kaydedildiyse, malik değişimi geçmişi sıfırlar. Üç yıl önceki çatı onarımının kim tarafından ödendiği sorusunun cevabı sistemde değil, eski yöneticinin klasöründedir.

Tahakkuk ile tahsilat ayrı kayıttır

Aidat takibinde en yaygın hata, borcu ödeme geldiğinde oluşturmaktır. Doğru sıra tersidir: her ayın başında işletme projesinden tahakkuk üretilir, sonra gelen ödemeler bu tahakkuklara kapatılır. Tahakkuk olmayan sistemde borç raporu yoktur, yalnızca ödeme listesi vardır; kimin ne kadar geride kaldığı elle hesaplanır. Aynı ayrım spor salonu üyelik yazılımında tekrarlayan tahsilat için de geçerlidir, ama sitede bir fark daha vardır: tahakkuk türleri birden fazladır. Aylık aidat, demirbaş payı, ek gider ve yakıt payı ayrı türlerdir; her birinin paylaşım kuralı (eşit, arsa payı, bloğa özel) ve muhatabı farklı olabilir.

İkinci kritik nokta kısmi ödemedir. Sakin üç aylık borcunun bir kısmını yatırdığında o para hangi aya sayılacak? Kural baştan yazılır ve makine uygular; çoğu yönetimde kural en eski borçtan başlamaktır. Gecikme hesabı da buna bağlıdır: gecikme gün sayısı ödemenin yapıldığı güne göre kapatılan tahakkuktan hesaplanır. Gecikme oranını kat malikleri kurulu belirler ve mevzuatta bir üst sınır vardır; oranı programın içine gömmek yerine dönem bazlı ayar olarak tutun ve güncel sınırı yönetim danışmanınıza teyit ettirin.

type Tahakkuk = {
  id: string;
  donem: string; // '2026-03'
  vade: Date;
  tutar: number;
  kalan: number;
};

type Kapama = { tahakkukId: string; tutar: number; gecikmeGun: number };

/** Kısmi ödemeyi en eski vadeden başlayarak açık tahakkuklara dağıtır. */
export function odemeyiDagit(
  odemeTarihi: Date,
  odemeTutari: number,
  acikTahakkuklar: Tahakkuk[],
): { kapamalar: Kapama[]; artan: number } {
  const sirali = [...acikTahakkuklar]
    .filter((t) => t.kalan > 0)
    .sort((a, b) => a.vade.getTime() - b.vade.getTime());

  const kapamalar: Kapama[] = [];
  let kalanPara = odemeTutari;

  for (const t of sirali) {
    if (kalanPara <= 0) break;
    const kapanan = Math.min(kalanPara, t.kalan);
    // Gecikme, vadeden ödeme gününe kadar geçen tam gün sayısıdır;
    // vadesinden önce ödenen tahakkuk için sıfırdır.
    const gun = Math.floor(
      (odemeTarihi.getTime() - t.vade.getTime()) / 86400000,
    );
    kapamalar.push({
      tahakkukId: t.id,
      tutar: kapanan,
      gecikmeGun: Math.max(0, gun),
    });
    kalanPara -= kapanan;
  }

  // Artan para borç olmayan bir aya "peşin" yazılmaz; avans olarak
  // ayrı durur ve bir sonraki tahakkukta otomatik kapatılır.
  return { kapamalar, artan: kalanPara };
}

Buradaki iki karar bilinçlidir. Artan para gelecek aya peşin yazılmaz, avans olarak ayrı tutulur; çünkü o ayın tahakkuku henüz yoktur ve tutarı değişebilir. Gecikme günü ise kapatılan her tahakkuk için ayrı hesaplanır; tek bir toplam borca tek bir gecikme uygulamak, üç ay geciken ile bir ay geciken borcu aynı kefeye koyar.

Banka mutabakatı: dekont değil ekstre

Aidatların çoğu havale ve EFT ile gelir, açıklama alanına ne yazıldığı ise sakine kalmıştır. Programın işi banka ekstresini içeri alıp her satırı bir bağımsız bölüme eşleştirmektir. Eşleştirme sırayla üç yolu dener: gönderenin daha önce kayıtlı IBAN’ı, açıklamadaki daire numarası ya da isim, en son da tutar ve tarih yakınlığı. Eşleşmeyen satır silinmez, ayrı bir kuyrukta bekler ve yönetici elle bağlar; bir kez bağlanan IBAN bir sonraki ayda otomatik tanınır.

Online ödeme bu yükü baştan azaltır: sakin kendi borcunu görüp kartla ödediğinde ödeme doğru bağımsız bölüme zaten bağlı gelir. Kurulum ve komisyon tarafı için web sitesine ödeme entegrasyonu ve sanal POS komisyon oranları yazılarına bakın; sitelerde tutarlar küçük ve sayısı çok olduğu için işlem başına sabit ücret toplamı belirler.

Asıl ürün sakinin gördüğü rapordur

Yönetim yazılımının başarı ölçüsü yöneticinin ekranı değil, sakinin her ay gördüğü rapordur: gelir ve gider kalemleri, kasa ve banka bakiyesi, geçen aya göre değişim ve kendi bağımsız bölümünün borç durumu. Bu rapor ekstredeki her satırı bir gider kalemine bağlamadan üretilemez; yani banka mutabakatı yalnızca tahsilat için değil, gider tarafı için de yapılır. Kasa ve banka bakiyesi ekstreyle birebir tutmayan bir rapora sakinler ikinci ay bakmaz.

Kişisel veri tarafında tek bir kural yeter: herkes kendi borcunu görür, komşusununkini görmez. Borçlu listesini panoya asmak ya da toplu mesajla göndermek yerine kişiye özel bildirim kullanılır. Sakinlerin ad, telefon, TC ve IBAN bilgisi kişisel veridir; toplama amacı, saklama süresi ve erişim yetkisi baştan yazılır. Ayrıntılar KVKK uyumlu web sitesi yazısındaki ilkelerle aynıdır ve bu yazı hukuki danışmanlık değildir.

Personel, arıza talebi ve periyodik bakım

Aidat çekirdektir ama tek modül değildir. Kapıcı, güvenlik ve temizlik personelinin giriş çıkışı ve puantajı PDKS mantığıyla tutulur; site yazılımı bunu yeniden icat etmez, mevcut sistemden alır ya da basit bir vardiya kaydıyla sınırlar. Sakinlerin arıza ve şikâyet talepleri bir destek talep sistemi gibi kuyrukta yaşar: kim açtı, kime atandı, ne zaman kapandı. Asansör, jeneratör ve yangın sistemi gibi periyodik bakımlar ise bir sonraki bakım tarihi hesaplanan demirbaş kayıtlarıdır; bakım tarihi geçmiş demirbaş listesi yöneticinin ilk baktığı ekran olmalıdır.

Hazır paket mi özel yazılım mı?

Tek bir site için hazır bulut paket çoğu zaman yeter. Karar, aşağıdaki üç testin en az ikisinde evet cevabı varsa değişir; genel çerçeve için özel yazılım mı hazır çözüm mü yazısına bakın.

• Birden çok site yönetiyorsunuz ve siteler arası toplu raporlama, ortak tedarikçi ve tek kasa mantığı istiyorsunuz (profesyonel yönetim firmaları).
• Paylaşım kuralınız standart dışı: bazı giderler bloğa, bazıları arsa payına, bazıları eşit bölünüyor ve dükkânlar ayrı kurala tabi.
• Muhasebe programınızla ya da bankanızla otomatik veri alışverişi şart; elle dosya yükleme sizin ölçeğinizde çalışmıyor. Bu tarafın nasıl kurulduğu muhasebe programı entegrasyonu yazısında.
• Dördüncü soru her durumda sorulur: veriyi tahakkuk, tahsilat ve mutabakat ayrıntısıyla dışa aktarabiliyor musunuz? Aktaramıyorsanız yönetici değişiminde geçmiş kilitli kalır.

Projeyi bozan beş hata

• Kaydı kişiye açmak: malik ya da kiracı değişince dairenin geçmişi kopar.
• Borcu ödeme geldiğinde oluşturmak: tahakkuk yoksa borç raporu da yoktur.
• Gecikme oranını koda gömmek: kurul kararı değiştiğinde geçmiş dönemler yeniden hesaplanamaz.
• Banka ekstresini dışarıda bırakmak: ödemeler dekonttan elle işlenir, mutabakat hiç tutmaz.
• Borçlu listesini toplu yayınlamak: kişisel veri ihlali ve gereksiz gerginlik; herkes yalnızca kendi borcunu görmeli.

Sonuç

Site yönetim programı seçerken özellik sayısına değil üç şeye bakın: kayıt bağımsız bölüme mi açılıyor, tahakkuk tahsilattan ayrı mı ve banka ekstresi sisteme okunuyor mu. Bu üçü doğruysa sakin raporu ve gecikme hesabı kendiliğinden anlamlı olur. Birden çok site yönetiyorsanız ya da paylaşım kuralınız paketlere sığmıyorsa kurumsal çözümler ekibimizle konuşun; mevcut sürecinizi çıkarır, hangi kısmın hazır araçla, hangisinin özel geliştirmeyle karşılanacağını birlikte belirleriz. Teklif almak için yazın.