ERP untuk Developer Properti: Inventori Unit, Skema Pembayaran Pembeli, dan Biaya Proyek dalam Satu Sistem

Bisnis pengembangan properti punya ritme yang berbeda dari bisnis dagang atau manufaktur. Satu proyek bisa berjalan bertahun-tahun, nilai transaksinya besar, pembeli membayar dalam berbagai skema, dan setiap unit punya status hukum serta fisik yang berubah dari hari ke hari. Banyak developer menjalankan semua itu dengan lembar kerja yang tersebar: satu file untuk stok unit, satu untuk jadwal cicilan, satu untuk progres pembangunan, dan satu lagi untuk komisi pemasaran. Selama proyeknya satu dan kecil, cara ini masih bertahan. Begitu proyek bertambah, kesalahan mulai muncul: unit terjual ganda, cicilan terlewat ditagih, atau biaya pembangunan tidak jelas menempel ke proyek yang mana.

Artikel ini membahas bagaimana ERP dapat disesuaikan untuk developer properti dan pengelola proyek perumahan atau ruko: dari inventori unit, skema pembayaran pembeli, pencatatan biaya pembangunan per proyek dan per tahap, hingga serah terima dan layanan purna jual. Tujuannya membantu pemilik dan manajer menilai sistem apa yang sebenarnya dibutuhkan, bukan sekadar membeli aplikasi yang tampak lengkap di demonstrasi.

Ringkasan

• Unit properti adalah "barang" unik dengan status yang berubah (tersedia, dipesan, akad, serah terima), sehingga inventorinya harus dikelola per unit, bukan per jumlah
• Skema pembayaran pembeli (uang muka, cicilan bertahap, KPR) perlu jadwal tagih otomatis yang terhubung ke piutang dan arus kas
• Biaya pembangunan harus menempel pada proyek, tahap, dan idealnya per unit, agar margin proyek bisa dilihat sebelum proyek selesai
• Pemasaran, komisi, dan dokumen hukum membutuhkan alur persetujuan serta jejak audit yang rapi
• Mulailah dari satu proyek dan dua alur terpenting, yaitu penjualan unit dan biaya proyek, lalu perluas bertahap

Mengapa bisnis properti tidak cocok dengan ERP generik apa adanya

ERP standar dirancang dengan asumsi barang yang dapat dipertukarkan: seratus kardus dengan kode sama dihitung sebagai seratus. Unit rumah tidak begitu. Unit nomor 12 di blok B berbeda dari unit nomor 13: luas tanah berbeda, posisi hadap berbeda, harga berbeda, bahkan status sertifikat bisa berbeda. Selain itu ada beberapa karakteristik yang membuat bisnis ini unik.

• Siklus panjang: dari pembebasan lahan, perizinan, pembangunan, hingga serah terima, satu proyek bisa memakan tahunan, sehingga pencatatan biaya dan pendapatan harus tahan terhadap pergantian tim
• Nilai per transaksi besar: kesalahan satu unit berarti selisih yang material, jadi kontrol dan persetujuan lebih ketat
• Pembayaran bertahap dan bervariasi: tiap pembeli bisa memakai skema berbeda, dan skema itu terikat pada kontrak yang harus dipatuhi
• Banyak pihak: pembeli, bank pemberi KPR, notaris, kontraktor, pemasok material, agen pemasaran, dan instansi perizinan
• Pengakuan pendapatan yang tidak sederhana: kapan penjualan diakui bergantung pada kebijakan akuntansi dan standar yang berlaku, sehingga perlu dikonsultasikan dengan akuntan

Karena itu, implementasi biasanya berupa ERP inti (keuangan, pembelian, inventori material) yang diberi modul atau penyesuaian khusus properti. Memahami hal ini sejak awal mencegah ekspektasi keliru bahwa satu paket standar akan langsung pas.

Inventori unit dan siteplan sebagai sumber kebenaran

Fondasi sistem properti adalah daftar unit yang akurat. Setiap unit sebaiknya punya satu catatan dengan atribut penting:

• Identitas: proyek, klaster atau blok, nomor unit, tipe
• Spesifikasi: luas tanah, luas bangunan, jumlah kamar, posisi hadap, kelebihan tanah
• Harga: harga dasar, tambahan posisi atau kelebihan tanah, serta riwayat perubahan harga
• Status: tersedia, dipesan, uang muka dibayar, akad, serah terima, atau batal
• Dokumen: bukti pemesanan, perjanjian, status sertifikat, dan izin yang terkait

Status unit tidak boleh diubah oleh sembarang orang. Alur yang sehat membuat setiap perubahan status memiliki syarat: unit baru bisa berstatus "dipesan" setelah tanda jadi tercatat, dan baru "akad" setelah dokumen yang disyaratkan lengkap. Sistem juga perlu mengunci unit yang sedang dipesan agar dua tenaga pemasaran tidak menjual unit yang sama pada saat bersamaan. Masalah unit terjual ganda hampir selalu berasal dari status yang dicatat di banyak lembar kerja tanpa kunci.

Banyak developer juga memakai siteplan interaktif: denah proyek dengan warna per status unit. Tampilan ini membantu tim pemasaran dan calon pembeli, tetapi nilainya hanya sebesar akurasi data di belakangnya. Pastikan siteplan membaca langsung dari catatan unit, bukan gambar yang diperbarui manual.

Skema pembayaran pembeli dan jadwal tagihan

Pembeli properti jarang membayar sekaligus. Skema yang umum meliputi tanda jadi, uang muka yang dicicil, pelunasan lewat KPR, atau cicilan langsung ke developer. Setiap skema menghasilkan jadwal tagihan dengan tanggal dan nominal tertentu.

Praktik yang membantu:

• Template skema: simpan beberapa template (misalnya uang muka dicicil enam kali lalu pelunasan KPR) yang bisa dipilih saat pemesanan, lalu sesuaikan bila ada kesepakatan khusus
• Jadwal otomatis: begitu skema dipilih, sistem membuat jadwal tagihan lengkap dengan tanggal jatuh tempo, tanpa mengetik ulang satu per satu
• Pengingat dan penagihan: pengiriman pengingat sebelum jatuh tempo dan eskalasi bila terlambat, dengan catatan komunikasi yang tersimpan
• Pencocokan pembayaran: setiap transfer dikaitkan ke tagihan yang tepat, terutama karena pembeli sering membayar dengan nominal tidak persis; lihat [rekonsiliasi bank otomatis dengan ERP](/blog/rekonsiliasi-bank-otomatis-dengan-erp) untuk pendekatannya
• Penanganan perubahan: perpanjangan tenggat, perubahan skema, atau pembatalan harus tercatat dengan persetujuan, bukan hanya ditimpa di lembar kerja

Aturan pembatalan dan pengembalian dana biasanya diatur dalam perjanjian dan ketentuan hukum yang berlaku. Sistem bisa membantu menghitung berdasarkan aturan yang sudah ditetapkan, tetapi isi aturannya harus ditentukan bersama penasihat hukum Anda.

Proses KPR dan koordinasi dengan pihak ketiga

Banyak pembelian melibatkan KPR. Di sini developer tidak mengendalikan semua langkah: pembeli mengajukan ke bank, bank menilai, lalu muncul persetujuan, akad kredit, dan pencairan. Namun developer tetap perlu memantau karena keterlambatan di satu langkah menunda serah terima dan penerimaan kas.

Pelacakan sederhana namun efektif adalah checklist per pembeli: kelengkapan berkas, tanggal pengajuan, status di bank, jadwal akad, dan tanggal pencairan. Dengan pelacakan ini, tim dapat melihat berapa pembeli yang macet di tahap tertentu dan memprioritaskan tindak lanjut. Data juga berguna untuk proyeksi arus kas: pencairan KPR adalah penerimaan besar yang waktunya sulit diprediksi, dan semakin baik pelacakannya, semakin realistis proyeksi Anda.

Biaya pembangunan per proyek, tahap, dan unit

Pada sisi biaya, tantangan terbesar adalah menempelkan setiap pengeluaran ke tempat yang benar. Biaya lahan, perizinan, infrastruktur kawasan, material, upah borongan, dan biaya pemasaran harus bisa dilihat per proyek, dan idealnya dialokasikan ke unit atau tipe agar margin tiap unit terlihat.

Struktur yang umum dipakai:

• Proyek dan tahap: proyek dipecah menjadi tahap (pematangan lahan, infrastruktur, pembangunan unit, fasilitas umum) dengan anggaran masing-masing
• Anggaran dan realisasi: bandingkan anggaran dengan realisasi per tahap secara berkala, bukan hanya di akhir proyek
• Pembelian terkontrol: permintaan pembelian material dan kontrak borongan melewati persetujuan bertingkat, serupa dengan [alur approval pembelian](/blog/alur-approval-pembelian)
• Alokasi biaya bersama: biaya infrastruktur kawasan dialokasikan ke unit dengan aturan yang konsisten, misalnya berdasarkan luas tanah
• Termin kontraktor: pembayaran berdasarkan progres fisik yang diverifikasi, bukan hanya permintaan kontraktor

Mekanisme progres dan termin mirip dengan yang dibahas di ERP untuk kontraktor dan perusahaan konstruksi. Bedanya, developer berada di sisi pemberi kerja sekaligus penjual, sehingga perlu menghubungkan biaya pembangunan dengan harga pokok unit yang dijual.

Pemasaran, komisi, dan prospek

Penjualan properti banyak ditopang agen dan tenaga pemasaran dengan komisi. Tanpa sistem, komisi sering menjadi sumber sengketa: siapa yang membawa pembeli, kapan komisi dibayar, dan berapa potongan pajaknya. Beberapa praktik pencegah masalah:

• Catat sumber prospek sejak kontak pertama, termasuk agen yang membawa
• Tetapkan aturan komisi tertulis: persentase, kapan terhutang (misalnya setelah akad atau setelah uang muka lunas), dan kondisi pembatalan
• Hitung komisi otomatis dari data transaksi, lalu minta persetujuan sebelum dibayar
• Hubungkan dengan sistem tindak lanjut prospek, seperti yang dibahas di [sistem follow-up prospek](/blog/sistem-follow-up-prospek), sehingga tidak ada calon pembeli yang terlupa

Data pemasaran juga memberi wawasan: tipe unit mana yang banyak dilihat tetapi jarang dibeli, kanal mana yang menghasilkan pembeli sungguhan, dan berapa lama rata-rata dari kunjungan pertama ke pemesanan.

Dokumen, perizinan, dan jejak audit

Bisnis properti sarat dokumen: izin lokasi, persetujuan bangunan, perjanjian pengikatan jual beli, akta, sertifikat, dan berita acara serah terima. Menyimpannya di folder pribadi karyawan berisiko tinggi, terutama bila orangnya berhenti. Tautkan dokumen langsung ke catatan unit atau proyek, tetapkan siapa yang boleh melihat dan mengubah, dan simpan riwayat versi. Pembahasan lebih umum ada di manajemen dokumen dan arsip digital dengan ERP.

Karena nilai transaksi besar, jejak audit tidak boleh opsional. Siapa mengubah harga, siapa membatalkan pemesanan, dan siapa menyetujui diskon harus tercatat dan tidak dapat dihapus diam-diam. Prinsipnya sama dengan jejak audit dan pengendalian internal di sistem ERP.

Serah terima, garansi, dan purna jual

Pekerjaan tidak selesai saat kunci diserahkan. Pembeli akan melaporkan retakan, kebocoran, atau instalasi yang bermasalah selama masa pemeliharaan. Tanpa sistem, laporan itu tersebar di pesan singkat dan mudah terlewat. Pendekatan yang rapi adalah mencatat berita acara serah terima per unit, menyimpan daftar cacat yang disepakati, lalu mengelola setiap keluhan sebagai tiket dengan penanggung jawab dan tenggat. Pola ini mirip dengan garansi, retur barang, dan layanan purna jual dengan ERP, hanya objeknya berupa unit bangunan.

Portal pembeli juga bernilai: pembeli dapat melihat status cicilan, progres pembangunan dengan foto berkala, dan dokumen mereka sendiri. Ini mengurangi pertanyaan berulang ke tim pemasaran dan meningkatkan kepercayaan. Gagasan serupa dibahas di portal pelanggan dan pemasok B2B.

Laporan yang dibutuhkan manajemen

Setelah data rapi, laporan menjadi mudah. Beberapa laporan yang paling dicari pemilik developer:

• Status stok unit per proyek dan per tipe, termasuk unit yang lama tidak terjual
• Umur piutang pembeli dan daftar cicilan yang terlambat
• Anggaran versus realisasi biaya per proyek dan tahap
• Proyeksi arus kas gabungan: cicilan masuk, pencairan KPR, dan pembayaran kontraktor
• Margin proyek yang diperbarui berkala, bukan baru diketahui setelah proyek selesai
• Kinerja pemasaran: prospek, kunjungan, pemesanan, dan akad per kanal atau agen

Untuk tampilan yang mudah dibaca setiap hari, lihat dashboard bisnis untuk keputusan harian.

Langkah penerapan bertahap

Kesalahan umum adalah mencoba membangun semuanya sekaligus. Urutan yang lebih aman:

• Tahap 1: pilih satu proyek berjalan. Masukkan data unit, status, dan harga. Tutup kebiasaan mengubah status di luar sistem
• Tahap 2: catat pemesanan dan skema pembayaran pembeli, hubungkan ke penagihan dan pencocokan pembayaran
• Tahap 3: aktifkan anggaran dan realisasi biaya per tahap, termasuk persetujuan pembelian dan termin kontraktor
• Tahap 4: tambahkan komisi, dokumen, dan serah terima
• Tahap 5: perluas ke proyek lain dan tambahkan portal pembeli serta laporan lanjutan

Sebelum tahap 1, rapikan data awal. Banyak data unit lama memiliki penulisan yang tidak konsisten. Panduan di persiapan migrasi data sistem baru membantu mencegah masalah yang muncul belakangan. Libatkan juga tim pemasaran, keuangan, dan teknik sejak awal agar alur yang dibangun sesuai dengan cara kerja nyata.

Kesalahan yang sering terjadi

• Menyamakan unit dengan barang biasa sehingga status dan harga per unit tidak terkelola
• Membiarkan banyak versi daftar harga beredar di tangan agen yang berbeda
• Mencatat biaya pembangunan hanya di tingkat perusahaan, bukan per proyek, sehingga margin baru ketahuan di akhir
• Tidak mengunci unit yang sedang dipesan, sehingga terjadi penjualan ganda
• Mengabaikan jadwal pencairan KPR dalam proyeksi arus kas
• Menyimpan dokumen hukum di tempat yang tidak terkontrol
• Memasang sistem tanpa melibatkan akuntan untuk kebijakan pengakuan pendapatan

Pertanyaan yang sering diajukan

Apakah ERP standar bisa dipakai untuk developer properti?

Bagian keuangan, pembelian, dan inventori material bisa dipakai, tetapi pengelolaan unit, skema pembayaran pembeli, dan progres proyek biasanya membutuhkan modul tambahan atau pengembangan khusus. Evaluasi apakah kebutuhan itu bisa dipenuhi lewat konfigurasi atau perlu dibangun.

Apakah perlu terintegrasi dengan siteplan dan website pemasaran?

Sangat berguna. Bila status unit di sistem otomatis tampil di siteplan dan website, calon pembeli selalu melihat ketersediaan terbaru dan tim tidak perlu memperbarui gambar secara manual.

Bagaimana dengan proyek kecil dengan sedikit unit?

Proyek kecil tetap mendapat manfaat, terutama dari pelacakan pembayaran dan biaya per proyek. Mulai dengan modul paling sederhana dan jangan memaksakan fitur yang belum diperlukan.

Bagaimana aturan pajak dan akuntansi properti ditangani?

Aturan pajak dan pengakuan pendapatan properti cukup kompleks dan dapat berubah. Konfigurasi sistem harus mengikuti arahan akuntan atau konsultan pajak Anda, bukan asumsi pengembang aplikasi.

Kesimpulan

Bisnis properti menuntut sistem yang memahami bahwa setiap unit itu unik, pembayaran berlangsung bertahap, dan biaya harus ditelusuri sampai ke proyek serta tahap. Dengan inventori unit yang terkunci dan akurat, jadwal tagihan otomatis, anggaran biaya per tahap, dan dokumen yang tertaut rapi, pemilik dapat melihat posisi proyek tanpa menunggu laporan akhir. Mulailah dari satu proyek dan dua alur terpenting, lalu kembangkan bertahap sambil melibatkan tim yang akan memakainya.

Agsora membantu developer dan pengelola proyek merancang serta membangun ERP yang disesuaikan dengan alur kerja properti, dari inventori unit hingga laporan margin proyek. Bila Anda ingin memetakan kebutuhan sistem untuk proyek Anda, kami siap berdiskusi.