ERP for Property Developers: Unit Inventory, Buyer Payment Schemes, and Project Costs in One System

Property development runs on a different rhythm from retail or manufacturing. A single project can last years, transaction values are large, buyers pay under many different schemes, and every unit has a legal and physical status that changes from day to day. Many developers run all of this on scattered spreadsheets: one file for unit stock, another for installment schedules, another for construction progress, and yet another for marketing commissions. While there is one small project, this holds together. Once projects multiply, errors start to appear: a unit sold twice, an installment that was never billed, or construction costs that nobody can attach to the right project.

This article explains how an ERP can be adapted for property developers and managers of housing or shop-house projects: from unit inventory and buyer payment schemes to recording construction costs by project and phase, through handover and after-sales service. The aim is to help owners and managers judge what system they actually need, rather than buying an application that merely looks complete in a demo.

Summary

• A property unit is a unique "item" whose status keeps changing (available, reserved, contract signed, handed over), so inventory must be managed unit by unit, not by quantity
• Buyer payment schemes (down payment, staged installments, mortgage) need an automatic billing schedule connected to receivables and cash flow
• Construction costs must attach to the project, the phase, and ideally each unit, so project margin can be seen before the project ends
• Marketing, commissions, and legal documents need approval flows and a tidy audit trail
• Start with one project and the two most important flows, unit sales and project costs, then expand step by step

Why a generic ERP does not fit property out of the box

A standard ERP assumes interchangeable goods: a hundred cartons with the same code count as one hundred. Houses are not like that. Unit 12 in block B differs from unit 13: the land area differs, the facing direction differs, the price differs, and even the certificate status can differ. Several other characteristics make this business unique.

• Long cycles: from land acquisition and permits to construction and handover, a project can take years, so cost and revenue records must survive staff turnover
• Large value per transaction: an error on one unit means a material difference, so controls and approvals must be stricter
• Staged and varied payments: each buyer may use a different scheme, tied to a contract that must be honored
• Many parties: buyers, mortgage banks, notaries, contractors, material suppliers, marketing agents, and permit authorities
• Non-trivial revenue recognition: when a sale is recognized depends on accounting policy and applicable standards, so it should be discussed with your accountant

For this reason an implementation is usually a core ERP (finance, purchasing, material inventory) extended with property-specific modules or customization. Understanding this early prevents the mistaken expectation that one standard package will fit immediately.

Unit inventory and the site plan as the source of truth

The foundation of a property system is an accurate list of units. Each unit should have one record with the key attributes:

• Identity: project, cluster or block, unit number, type
• Specification: land area, building area, number of rooms, facing direction, extra land
• Price: base price, surcharges for position or extra land, and the history of price changes
• Status: available, reserved, down payment received, contract signed, handed over, or cancelled
• Documents: booking proof, agreement, certificate status, and related permits

Unit status must not be changeable by just anyone. A healthy flow attaches conditions to each change: a unit can become "reserved" only after the booking fee is recorded, and "contract signed" only after the required documents are complete. The system should also lock a unit being reserved so two sales agents cannot sell the same unit at the same moment. Double-sold units almost always come from status kept in several spreadsheets with no lock.

Many developers also use an interactive site plan: a project layout with a color per unit status. This view helps the marketing team and prospective buyers, but its value is only as good as the data behind it. Make sure the site plan reads directly from the unit record, not from an image updated by hand.

Buyer payment schemes and billing schedules

Property buyers rarely pay in one go. Common schemes include a booking fee, a down payment paid in installments, final settlement through a mortgage, or direct installments to the developer. Each scheme produces a billing schedule with specific dates and amounts.

Practices that help:

• Scheme templates: keep several templates (for example, a down payment in six installments followed by mortgage settlement) that can be chosen at booking, then adjusted for special agreements
• Automatic schedule: once a scheme is chosen, the system generates the full billing schedule with due dates, without retyping each line
• Reminders and collection: reminders before the due date and escalation when late, with the communication history stored
• Payment matching: every transfer linked to the right invoice, especially because buyers often pay slightly off amounts; see [automated bank reconciliation with ERP](/blog/rekonsiliasi-bank-otomatis-dengan-erp) for the approach
• Change handling: deadline extensions, scheme changes, or cancellations recorded with approval, not just overwritten in a spreadsheet

Cancellation and refund rules are usually governed by the agreement and applicable law. The system can help calculate based on rules already set, but the content of those rules must be decided with your legal advisor.

The mortgage process and coordination with third parties

Many purchases involve a mortgage. Here the developer does not control every step: the buyer applies to the bank, the bank assesses, then come approval, the credit agreement, and disbursement. Yet the developer still needs to monitor, because delay at any step postpones handover and cash receipt.

A simple but effective tracker is a per-buyer checklist: document completeness, application date, status at the bank, signing schedule, and disbursement date. With it, the team can see how many buyers are stuck at a particular stage and prioritize follow-up. The data also feeds cash flow projections: mortgage disbursement is a large inflow whose timing is hard to predict, and the better the tracking, the more realistic your projection.

Construction cost by project, phase, and unit

On the cost side, the biggest challenge is attaching every expense to the right place. Land, permits, estate infrastructure, materials, subcontractor labor, and marketing costs must be visible per project, and ideally allocated to a unit or type so the margin of each unit shows.

A commonly used structure:

• Project and phase: the project is split into phases (land preparation, infrastructure, unit construction, common facilities), each with its own budget
• Budget versus actual: compare budget with actuals per phase regularly, not only at the end of the project
• Controlled purchasing: material purchase requests and subcontracts pass through tiered approval, similar to a [purchase approval flow](/blog/alur-approval-pembelian)
• Shared cost allocation: estate infrastructure costs allocated to units by a consistent rule, for example by land area
• Contractor payment terms: payment based on verified physical progress, not just the contractor's request

The progress and payment-term mechanics resemble those covered in ERP for contractors and construction companies. The difference is that a developer is both the client and the seller, so it must connect construction cost to the cost basis of the units sold.

Marketing, commissions, and leads

Property sales rely heavily on agents and commissioned marketers. Without a system, commissions often become a source of disputes: who brought the buyer, when the commission is paid, and how much tax is withheld. A few practices that prevent problems:

• Record the lead source from first contact, including the agent who referred
• Set written commission rules: percentage, when it becomes payable (for example after the contract or once the down payment is complete), and cancellation conditions
• Calculate commissions automatically from transaction data, then require approval before payout
• Connect to a follow-up system, as discussed in [lead follow-up systems](/blog/sistem-follow-up-prospek), so no prospective buyer is forgotten

Marketing data also provides insight: which unit types are viewed often but rarely bought, which channels bring real buyers, and how long it takes on average from first visit to booking.

Documents, permits, and the audit trail

Property is document-heavy: location permits, building approvals, sale and purchase binding agreements, deeds, certificates, and handover records. Keeping them in employees' personal folders is risky, especially when someone leaves. Link documents directly to the unit or project record, define who may view and edit, and keep version history. A more general discussion is in document management and digital archives with ERP.

Because transaction values are large, the audit trail cannot be optional. Who changed a price, who cancelled a booking, and who approved a discount must be recorded and impossible to erase quietly. The principle is the same as in audit trails and internal control in ERP systems.

Handover, warranty, and after-sales

The work does not end when the keys are handed over. Buyers will report cracks, leaks, or faulty installations during the maintenance period. Without a system, these reports scatter across chat messages and are easily missed. A tidy approach is to record a handover record per unit, store the agreed defect list, then manage each complaint as a ticket with an owner and a deadline. The pattern resembles warranty, returns, and after-sales service with ERP, except the object is a building unit.

A buyer portal is also valuable: buyers can see installment status, construction progress with periodic photos, and their own documents. This reduces repeated questions to the marketing team and increases trust. A similar idea is discussed in customer and supplier portals for B2B.

Reports management needs

Once the data is tidy, reports become easy. A few of the reports property owners ask for most:

• Unit stock status per project and type, including units that have not sold for a long time
• Buyer receivable aging and a list of late installments
• Budget versus actual cost per project and phase
• Combined cash flow projection: incoming installments, mortgage disbursements, and contractor payments
• Project margin updated regularly, not discovered after the project ends
• Marketing performance: leads, visits, bookings, and contracts per channel or agent

For a view that is easy to read every day, see business dashboards for daily decisions.

Rolling out in stages

A common mistake is trying to build everything at once. A safer order:

• Phase 1: pick one running project. Enter unit data, status, and prices. Stop changing status outside the system
• Phase 2: record bookings and buyer payment schemes, connect them to billing and payment matching
• Phase 3: activate budget and actual cost per phase, including purchase approvals and contractor payment terms
• Phase 4: add commissions, documents, and handover
• Phase 5: extend to other projects and add the buyer portal and advanced reports

Before phase 1, tidy the starting data. Much historical unit data is written inconsistently. The guidance in preparing data migration for a new system helps prevent problems that surface later. Also involve the marketing, finance, and engineering teams from the start so the flows you build match how they really work.

Common mistakes

• Treating units as ordinary goods, so status and price per unit go unmanaged
• Letting several versions of the price list circulate among different agents
• Recording construction costs only at company level, not per project, so margin is learned only at the end
• Not locking units being reserved, which leads to double sales
• Ignoring the mortgage disbursement schedule in cash flow projections
• Storing legal documents in uncontrolled places
• Installing a system without involving an accountant on the revenue recognition policy

Frequently asked questions

Can a standard ERP be used for a property developer?

The finance, purchasing, and material inventory parts can be used, but unit management, buyer payment schemes, and project progress usually require additional modules or custom development. Evaluate whether those needs can be met by configuration or must be built.

Does it need to integrate with the site plan and marketing website?

Very useful. When unit status in the system automatically appears on the site plan and website, prospective buyers always see the latest availability and the team does not need to update images manually.

What about small projects with few units?

Small projects still benefit, especially from payment tracking and cost per project. Start with the simplest module and do not force features you do not yet need.

How are property tax and accounting rules handled?

Property tax and revenue recognition rules are fairly complex and can change. System configuration must follow the guidance of your accountant or tax consultant, not assumptions made by the application developer.

Conclusion

A property business needs a system that understands that every unit is unique, payments happen in stages, and costs must be traceable to the project and phase. With accurate, locked unit inventory, automatic billing schedules, phase-level cost budgets, and neatly linked documents, owners can see the position of a project without waiting for the final report. Start with one project and the two most important flows, then grow step by step while involving the people who will use it.

Agsora helps developers and project managers design and build ERP tailored to property workflows, from unit inventory to project margin reports. If you would like to map the system needs for your projects, we are ready to talk.