Hakediş yönetimi; yapılan işin, teslim edilen hizmetin veya gerçekleşen üretimin sözleşmedeki koşullara göre ölçülmesi, onaylanması ve ödemeye dönüştürülmesi sürecidir. İnşaat ve taahhüt projelerinde metraj ve imalat ilerlemesiyle sık görülse de taşeron, bakım, saha hizmeti, proje bazlı danışmanlık ve dönemsel hizmet sözleşmelerinde de benzer bir mantık vardır. Excel, e-posta ve WhatsApp ile yürütülen süreç büyüdükçe hangi revizyonun geçerli olduğu ve hangi tutarın neden kesildiği belirsizleşebilir.
Hakediş yönetim yazılımının amacı yalnız toplam tutarı hesaplamak değildir. Sözleşme kalemleri, gerçekleşen miktarlar, onay akışı, avans ve kesintiler, revizyon geçmişi, ek belgeler ve ödeme durumunun tek kayıtta izlenmesini sağlar. İyi tasarlanmış sistem finans, proje ekibi ve yüklenici arasında aynı veriye bakılmasını kolaylaştırır.
Hakediş Sürecini Önce İş Akışı Olarak Modelleyin
Yazılıma geçmeden mevcut süreci adımlara ayırın: sözleşme açılışı, iş kalemleri, dönem hakedişi, saha doğrulaması, kontrol, revizyon, onay, fatura ve ödeme. Her işletmede bu adımların isimleri ve yetkileri farklı olabilir.
“Hazırlanıyor → Kontrolde → Revizyon İstendi → Onaylandı → Ödendi” gibi net durumlar raporlamayı kolaylaştırır. Kullanıcıların serbest metinle durum yazması yerine kontrollü lifecycle kullanılması gerekir.
Sözleşme ve İş Kalemleri Tek Kaynakta Tutulmalı
Her hakediş hangi sözleşmeye ve hangi iş kalemlerine bağlı olduğunu bilmelidir. Birim, birim fiyat, sözleşme miktarı, revize miktar ve gerçekleşen toplam değer ayrı alanlarda tutulabilir. Böylece dönemler toplandığında sözleşme limitinin aşılması otomatik kontrol edilebilir.
Sözleşme revize olduğunda eski değeri overwrite etmek yerine versiyon geçmişi tutulması anlaşmazlıkları azaltır. Hangi tarihte hangi kullanıcının fiyat veya miktar değiştirdiği audit log’da görülebilir.
Metraj ve Gerçekleşen Miktar Dönem Bazında Girilmeli
İnşaat gibi senaryolarda aynı iş kalemi birden fazla hakediş döneminde ilerler. Sistem önceki kümülatif miktarı, bu dönem gerçekleşeni ve yeni toplamı ayrı hesaplamalıdır. Kullanıcının her ay toplam rakamı elle yeniden yazması hata riskini artırır.
Miktar kaynağı saha formu, ölçüm dosyası veya başka bir sistemse entegrasyonla getirilebilir. Yine de onaylanmadan finansal hakedişe dönüşmemesi için doğrulama adımı korunmalıdır.
Avans, Teminat, Kesinti ve Vergi Kalemlerini Parametrik Tasarlayın
Brüt hakediş ile ödenecek net tutar aynı değildir. Avans mahsup, teminat kesintisi, ceza, önceki ödeme, vergi veya sözleşmeye özgü başka kesintiler olabilir. Bu kalemleri kod içine sabit yüzde olarak gömmek farklı projelerde sorun yaratır.
Kesinti türü, hesaplama tabanı, oran/tutar ve açıklama ayrı tutulursa finans ekibi hesabın nasıl oluştuğunu geriye dönük doğrulayabilir. Yasal vergi hesapları için güncel mevzuat ve mali müşavir süreçleri ayrıca dikkate alınmalıdır.
Revizyon Sürecini “Yeni Excel Gönder” Mantığından Çıkarın
Kontrol ekibi bir kaleme itiraz ettiğinde tüm hakedişi e-postayla geri göndermek yerine ilgili satıra revision request açılabilir. Gerekçe, eski değer, önerilen değer ve ek dosya aynı kayıt altında tutulur.
Revizyon sonrası hangi alanların değiştiği karşılaştırmalı görünürse onay veren kişinin tekrar tüm dosyayı baştan incelemesi gerekmez. Bu aynı zamanda audit ve uyuşmazlık yönetimini güçlendirir.
Rol ve Yetkiler Finansal Etkiye Göre Ayrılmalı
Hakedişi hazırlayan kişinin aynı kaydı tek başına onaylayabilmesi her işletme için uygun değildir. Hazırlayan, kontrol eden, proje yöneticisi ve finans onayı gibi roller tanımlanabilir. Tutar eşiğine göre ek onay gerekebilir.
Yetki yalnız menü görünürlüğü değil işlem seviyesinde uygulanmalıdır. Kullanıcı URL/API üzerinden erişse bile yetkisiz sözleşme veya hakedişi değiştirememelidir.
Belge ve Ekleri Hakediş Kaydıyla İlişkilendirin
Metraj cetveli, saha fotoğrafı, tutanak, fatura, sözleşme eki ve imzalı PDF gibi belgeler ilgili dönemle ilişkilendirilebilir. Dosya isimlerini ortak klasörde tutmak yerine belge türü, yükleyen kullanıcı ve tarih metadata’sı eklemek aramayı kolaylaştırır.
Dosya erişimi de rol bazlı olmalı; tahmin edilebilir public URL ile hassas finansal belgeler açılmamalıdır. Upload tarafında dosya türü, boyut ve malware kontrolleri planlanabilir.
Kümülatif ve Dönemsel Raporları Birlikte Sunun
Proje yöneticisi bu ay ne kadar ilerleme olduğunu, finans ise sözleşme başlangıcından bugüne toplam tahakkuk ve ödemeyi görmek ister. Sistem dönemsel ve kümülatif değerleri aynı modelden üretebilmelidir.
Sözleşme bedeli, onaylı hakediş, ödenen, bekleyen, kalan iş ve kesinti toplamı gibi göstergeler proje bazında raporlanabilir. Raporun Excel export’u gerekiyorsa ekrandaki hesapla aynı source-of-truth kullanmalıdır.
Ödeme ile Onaylanmış Hakedişi Ayrı Statülerde İzleyin
Hakediş onaylandı diye banka ödemesi gerçekleşmiş sayılmaz. Onay tarihi, fatura durumu, ödeme planı ve gerçek ödeme tarihi ayrı tutulmalıdır. Kısmi ödeme varsa kalan bakiye sistem tarafından hesaplanabilir.
Muhasebe/ERP entegrasyonu kullanılıyorsa hakediş onayı sonrası fiş/fatura akışı API ile başlatılabilir; entegrasyon hatasında kayıt tekrar gönderilirken duplicate belge üretmemek için idempotency gerekir.
Bildirim ve SLA Kuralları Süreci Hızlandırabilir
Kontrolde üç gündür bekleyen hakediş, revizyon isteğine cevap gelmeyen kayıt veya vadesi yaklaşan ödeme için bildirim üretilebilir. Her küçük değişiklikte herkese e-posta göndermek yerine olay ve rol bazlı bildirim tasarlanmalıdır.
Dashboard’da “onay bekleyen”, “revizyonda”, “vadesi geçen ödeme” gibi çalışma kuyrukları kullanıcıya aksiyon listesi verir. Bu, rapor ekranından daha operasyonel bir faydadır.
Audit Log ve Değişiklik Geçmişi Zorunlu Gibi Düşünülmeli
Finansal değeri etkileyen birim fiyat, miktar, kesinti veya onay değişikliklerinde kim-ne-zaman bilgisinin tutulması gerekir. Yalnız updated_at alanı hangi değerin değiştiğini açıklamaz.
Append-only audit eventleri veya önce/sonra değerlerini kaydeden history tablosu kullanılabilir. Kritik kayıtların hard delete edilmesi yerine iptal/reversal mantığı birçok projede daha güvenli olabilir.
Mobil Saha Girişi Gerekiyorsa Offline Senaryoyu Planlayın
Şantiyede veya saha operasyonunda bağlantı zayıf olabilir. Gerçekleşen miktar ve fotoğraf mobil cihazdan girilecekse offline queue, sonradan senkronizasyon ve conflict çözümü düşünülmelidir.
Aynı satırı iki kullanıcının offline güncellemesi halinde son yazan kazanır yaklaşımı finansal veri için risklidir. Çakışma uyarısı veya versiyon kontrolü kullanılabilir.
Yazılım Seçerken “Her Şeyi Özelleştirelim” Yaklaşımından Kaçının
Her proje için farklı ekran ve tablo açmak bakım maliyetini yükseltir. Sözleşme türleri ve hesap kuralları parametrik tasarlanabiliyorsa yeni projeler konfigürasyonla açılabilir. Gerçekten benzersiz süreçler için modüler genişleme yapılabilir.
Hazır ürün ihtiyacı karşılıyorsa özel yazılım şart değildir. Çok özel onay, entegrasyon, çok şirketli yapı veya saha akışı varsa özel yazılım geliştirme daha anlamlı hale gelebilir.
Hakediş yönetimini dijitalleştirmenin değeri yalnız Excel’i web ekranına taşımak değildir. Sözleşme, dönemsel gerçekleşme, kesintiler, revizyon, onay, belge, ödeme ve audit geçmişi tek veri modelinde birleştiğinde süreç hem daha izlenebilir hem daha denetlenebilir hale gelir.
Hakediş ve proje süreçlerine özel yazılım geliştirme hizmetleri için CoreSoftDigital.com üzerinden bilgi alabilirsiniz.
Çok Şirketli ve Çok Projeli Yapıda Veri İzolasyonunu Planlayın
Aynı yazılım birden fazla şirket, şantiye veya taşeron grubu tarafından kullanılacaksa her kaydın hangi organizasyona ve projeye ait olduğu veri modelinde açık olmalıdır. Kullanıcı yalnız yetkili olduğu projelerin sözleşme ve hakedişlerini görebilmeli; rapor sorgularında da tenant/project filtresi backend seviyesinde uygulanmalıdır.
Merkez yönetim konsolide toplamı görebilirken proje yöneticisi yalnız kendi projesini görebilir. Bu ayrım sonradan ekran filtresi eklemekten daha temel bir authorization problemidir.
Onay İmzası ile Sistem Login’ini Aynı Şey Saymayın
Bir kullanıcının sisteme giriş yapıp “Onayla” butonuna basması ile hukuken belirli nitelikte elektronik imza gerektiren süreç aynı kavram değildir. İşletmenin sözleşme ve mevzuat gereksinimine göre e-imza, KEP veya başka doğrulama ihtiyacı ayrıca değerlendirilmelidir.
Yazılım yine onay eventinin kullanıcı, zaman, IP/device metadata’sı ve belge versiyonuyla ilişkisini saklayabilir. Ancak ürün tanıtımında “bu buton hukuki imzadır” gibi doğrulanmamış iddialardan kaçınılmalıdır.
Eski Excel Verisini İçe Aktarırken Veri Temizliği Yapın
Dijital sisteme geçişte yıllardır kullanılan dosyalarda aynı sözleşme kalemi farklı isimlerle, sayısal alanlar metin formatında veya eksik proje kodlarıyla bulunabilir. Import öncesi kolon mapping, zorunlu alan ve duplicate kuralları belirlenmelidir. Hatalı satırlar sessizce atlanmak yerine ayrı hata raporuna düşmelidir.
Geçmiş hakedişleri yalnız toplam bakiye olarak mı, dönem detaylarıyla mı taşıyacağınız rapor ihtiyacına göre seçilir. Her eski dosyayı birebir kopyalamak yeni sistemin veri modelini bozabilir.
Acceptance Testini Gerçek Hakediş Örnekleriyle Yapın
Demo veride 1–2 satırla doğru çalışan hesap, gerçek projedeki yüzlerce kalem, kısmi gerçekleşme, revizyon ve kesinti kombinasyonunda hata verebilir. Canlıya çıkmadan birkaç gerçek geçmiş hakediş anonimleştirilerek sisteme girilip Excel/muhasebe sonucu ile karşılaştırılabilir.
Özellikle yuvarlama, KDV/vergi kuralı, negatif düzeltme ve önceki dönem devri için expected result set hazırlanması finansal hesaplamanın güvenilirliğini artırır. UAT onayı yalnız ekranın güzel görünmesine değil hesap sonucuna dayanmalıdır.
