Apartman yönetim programı yaptırmak, yalnız daire listesi ve aidat tablosu hazırlamak değildir. Gerçek bir yönetim sistemi; bağımsız bölüm, malik-kiracı ilişkisi, dönemsel aidat, ek borçlandırma, tahsilat, gelir-gider, borç bakiyesi, duyuru ve yetkilendirme gibi birbirine bağlı süreçleri doğru veri modeliyle yönetmelidir. 2026'da özel bir aidat ve daire takip sistemi geliştirilecekse fiyatı belirleyen temel unsur, kaç ekran yapılacağı değil bu kuralların ne kadar ayrıntılı olduğudur.
On daireli tek apartmanın ihtiyacıyla yüzlerce bağımsız bölümü ve birden fazla blok veya siteyi yöneten yapının ihtiyacı aynı değildir. Bu nedenle proje analizi “aidat modülü olsun” seviyesinde bırakılmamalı; aidatın nasıl oluştuğu, kimin borçlandığı, ödemenin hangi borca kapandığı ve geçmiş dönemlerin nasıl korunacağı açık biçimde tanımlanmalıdır.
Apartman yönetim yazılımının veri modeli nereden başlamalı?
Temel varlık genellikle bağımsız bölümdür. Daire, ofis, dükkân veya başka bir bağımsız bölüm için blok, kapı numarası, bölüm tipi, arsa payı gibi bilgiler tutulabilir. Malik ve kiracı ise bağımsız bölümden ayrı kişiler olarak modellenmelidir. Çünkü aynı daire zaman içinde farklı malik veya kiracılarla ilişkilendirilebilir.
Bu ayrım yapılmazsa kişi değiştiğinde geçmiş borç ve tahsilat kayıtları karışabilir. Yazılım, “şu anda kim oturuyor?” sorusuyla “bu borç hangi dönemde hangi sorumluluk kapsamında oluştu?” sorusunu birbirinden ayırabilmelidir. Geçmiş kayıtların sonradan yeni kullanıcı bilgileriyle değişmemesi finansal izlenebilirlik açısından önemlidir.
Aidat oluşturma sistemi nasıl çalışmalı?
En basit senaryoda tüm bağımsız bölümlere her ay aynı tutarda aidat oluşturulur. Ancak gerçek hayatta farklı daire tipleri, farklı bloklar, arsa payına göre dağıtımlar, daireye özel borçlar veya belirli dönemlerde ek ödeme ihtiyaçları olabilir. Bu nedenle aidat motoru tek bir “toplu borç ekle” butonundan daha esnek tasarlanmalıdır.
Sistemde örneğin şu senaryolar desteklenebilir:
- Tüm bağımsız bölümlere eşit aidat
- Daire tipine veya gruba göre farklı tutar
- Belirli bir bağımsız bölüme özel borçlandırma
- Geçmiş dönem için borç oluşturma
- Gelecek aylar için planlı veya otomatik tahakkuk
- Son ödeme tarihi ve gecikme durumu
- Avans veya fazla ödemenin bakiyede tutulması
- Açıklama ve borç türü bazında raporlama
Burada en kritik karar, borcun sonradan düzenlenip düzenlenemeyeceğidir. Tahsilat yapılmış bir borcun tutarını sessizce değiştirmek finansal geçmişi bozabilir. Bunun yerine düzeltme hareketi, iptal veya yeni tahakkuk gibi izlenebilir yöntemler tasarlanması daha güvenlidir.
Tahsilat bir borca nasıl kapatılmalı?
Kullanıcı 3.000 TL ödeme yaptığında sistemin yalnız toplam bakiyeyi azaltması yeterli değildir. Bu ödemenin hangi aidat veya ek borç kalemlerine dağıtıldığı bilinmelidir. Aksi halde geçmiş ay raporları ve gecikmiş borç hesapları tutarsızlaşabilir.
Ödeme en eski borçtan başlayarak otomatik kapatılabilir veya yönetici belirli borçları seçebilir. Fazla ödeme varsa bakiye olarak tutulup sonraki tahakkuklara aktarılabilir. Kısmi ödeme de desteklenmelidir; çünkü bir borcun tamamı tek seferde tahsil edilmeyebilir.
Bu yapı, daha sonra online ödeme entegrasyonu eklendiğinde de önem kazanır. Ödeme sağlayıcısından başarılı işlem bildirimi geldiğinde ilgili tahsilatın bir kez oluşturulması, tekrarlanan webhook mesajlarının mükerrer ödeme üretmemesi gerekir. Bu tip bağlantılar API entegrasyonu kapsamında ayrıca tasarlanmalıdır.
Gelir-gider takibi muhasebe programı yerine geçer mi?
Apartman yönetim yazılımında kasa/banka hareketleri, aidat tahsilatları ve ortak giderler takip edilebilir. Ancak bu özelliklerin kapsamı profesyonel muhasebe veya yasal defter süreçleriyle karıştırılmamalıdır. Sistem yönetim amaçlı finansal görünürlük sağlayabilir; işletmenin veya yönetimin tabi olduğu muhasebe ve hukuki yükümlülükler ayrıca değerlendirilmelidir.
Gider kaydında kategori, açıklama, tarih, tutar, ödeme yöntemi ve belge bilgisi tutulabilir. Asansör bakımı, temizlik, elektrik, güvenlik veya bakım-onarım gibi giderler ayrı kategorilerde raporlanabilir. Yöneticinin dönem sonunda toplam tahsilat, toplam gider ve açık bakiye durumunu görebilmesi günlük yönetimi kolaylaştırır.
Malik, kiracı ve yönetici panelleri aynı olmamalı
Rol bazlı yetkilendirme, apartman yazılımının temel güvenlik gereksinimlerinden biridir. Yönetici tüm bağımsız bölümlerin borçlarını görebilirken bir sakin yalnız kendisiyle ilişkili bağımsız bölümün bilgilerine erişmelidir. Denetçi veya muhasebe sorumlusu gibi ek roller gerekiyorsa yetkiler ayrıca tanımlanabilir.
Bir kullanıcının yalnız ekranı görmemesi yeterli güvenlik değildir; backend tarafında da her isteğin yetkisi kontrol edilmelidir. URL değiştirerek başka dairenin ödeme veya kişi bilgisine erişilememesi gerekir. Özel yönetim ekranları için yönetim paneli yazılımı tasarımında bu rol modeli baştan kurulmalıdır.
Duyuru, belge ve iletişim özellikleri nasıl planlanmalı?
Yönetim panelinden tüm sakinlere veya belirli bloklara duyuru gönderilebilir. SMS, e-posta veya uygulama içi bildirim seçenekleri kullanılabilir. Ancak her mesajın her kanaldan gönderilmesi hem maliyet hem kullanıcı deneyimi açısından gereksiz olabilir. Acil duyuru, ödeme hatırlatma ve genel bilgilendirme için farklı kanallar seçilebilir.
Toplantı tutanağı, yönetim planı veya ortak dokümanlar sisteme yüklenecekse dosya erişim yetkileri de düşünülmelidir. Hassas belge URL'lerinin tahmin edilebilir ve herkese açık biçimde sunulması yerine yetkili oturum üzerinden indirme yapılması daha güvenlidir.
KVKK ve veri güvenliği açısından nelere dikkat edilmeli?
Apartman veya site yönetim sistemi isim, telefon, e-posta, adres ilişkisi ve ödeme hareketleri gibi kişisel veriler işleyebilir. Bu nedenle yalnız güçlü şifre kullanmak yeterli değildir. Gereksiz veri toplamama, rol bazlı erişim, işlem logları, güvenli yedekleme, oturum güvenliği ve personel yetkilerinin düzenli gözden geçirilmesi önemlidir.
Yazılım teknik önlemleri destekleyebilir; fakat hangi verinin hangi hukuki sebeple işlendiği, saklama süresi ve aydınlatma süreçleri veri sorumlusunun organizasyonel yükümlülükleriyle birlikte değerlendirilmelidir. Sistemin “KVKK uyumlu” diye etiketlenmesi tek başına hukuki uyum garantisi değildir.
Tek apartman mı, çoklu site yönetimi mi?
Yazılım yalnız tek yönetim tarafından kullanılacaksa mimari daha sade olabilir. Bir yönetim şirketinin onlarca apartman veya siteyi yöneteceği SaaS modelinde ise her organizasyonun verisinin birbirinden ayrılması, kullanıcıların yalnız yetkili oldukları yapılara erişmesi ve raporların yönetim bazında filtrelenmesi gerekir.
Çok müşterili ürün geliştirilecekse abonelik, paket, kullanım limitleri, deneme süresi ve tenant izolasyonu gibi konular da proje kapsamına girer. Böyle bir ürün için SaaS yazılım geliştirme mimarisi, tek bir apartmana özel panelden farklı değerlendirilmelidir.
Banka hareketleri ve otomatik eşleştirme gerekli mi?
Yönetim çok sayıda havale/EFT alıyorsa ödemeleri manuel işlemek zaman kaybettirebilir. Bankanın veya kullanılan ödeme hizmetinin uygun entegrasyon imkânı varsa gelen hareketler açıklama, tutar veya referans bilgisine göre dairelerle eşleştirilebilir. Ancak otomatik eşleştirme kesin kabul yerine öneri mantığıyla da tasarlanabilir; belirsiz hareketler yöneticinin onayına bırakılır.
Bu özellikte en önemli konu aynı banka hareketinin iki kez tahsilat oluşturmamasıdır. Harici işlem kimliği saklanmalı, tekrar gelen kayıtlar idempotent biçimde işlenmeli ve manuel düzeltmeler loglanmalıdır. Böylece banka entegrasyonu finansal kayıtları hızlandırırken yeni tutarsızlıklar üretmez.
Mobil uygulama gerekli mi?
Sakinlerin temel ihtiyacı borç görüntülemek, ödeme yapmak, duyuru okumak veya talep iletmekse iyi hazırlanmış mobil uyumlu web uygulaması çoğu senaryoda yeterli olabilir. Uygulama mağazasından indirilecek native uygulama; push notification, cihaz entegrasyonu veya özel mobil deneyim gerçekten ihtiyaçsa sonraki fazda eklenebilir.
Yönetici tarafında da aidat oluşturma gibi karmaşık işlemler masaüstünde daha rahatken tahsilat kontrolü veya duyuru paylaşımı mobilde yapılabilir. Bu nedenle tek arayüzü her cihaza sıkıştırmak yerine görev bazlı responsive tasarım tercih edilmelidir.
2026'da apartman yönetim programı maliyeti nasıl çıkarılır?
Fiyat; bağımsız bölüm sayısından çok sistemin modülleri ve işletme modeliyle ilişkilidir. Aidat ve tahsilat, gelir-gider, malik/kiracı yönetimi, online ödeme, banka entegrasyonu, bildirim, belge yönetimi, destek talebi, çoklu site ve mobil uygulama gibi özellikler geliştirme eforunu değiştirir.
İlk sürüm için finansal çekirdeği doğru kurmak genellikle daha değerlidir: bağımsız bölüm, kişi ilişkileri, borçlandırma, tahsilat, bakiye ve raporlama. Duyuru, arıza-talep, rezervasyon veya gelişmiş entegrasyonlar daha sonra eklenebilir. Böylece kritik muhasebe mantığı oturmadan çok sayıda yan modül geliştirilmez.
Teklif almadan önce hangi senaryoları yazmalısınız?
Yazılım firmasına kaç daire olduğu bilgisinden fazlasını verin. Aidatların nasıl belirlendiğini, kiracı değiştiğinde ne yapıldığını, geçmiş borçların nasıl takip edildiğini, fazla ödemenin nasıl işlendiğini, kaç yöneticinin sisteme gireceğini ve online ödeme isteyip istemediğinizi örneklerle anlatın.
CoreSoft Digital üzerinden özel apartman/site yönetim yazılımı geliştirme hakkında bilgi alabilirsiniz. Proje kapsamı gerçek aidat ve tahsilat senaryolarıyla çıkarıldığında hem fiyatlandırma hem veri modeli daha sağlıklı olur. Özellikle finansal hareketlerin kuralları proje başlamadan örnek kayıtlarla test edilmelidir; bu çalışma sonradan çıkabilecek bakiye ve geçmiş dönem sorunlarını önemli ölçüde azaltır. Genel geliştirme yaklaşımı için özel yazılım geliştirme hizmeti de incelenebilir.
