"Real estate on Acumatica" splits into two genuinely different problems depending on which side of real estate a company is on, and conflating them is where a lot of scoping conversations go sideways. A real estate developer building and selling properties is fundamentally a project-costing problem — extremely close to how Acumatica's Construction Edition already thinks. A real estate investor/landlord holding and leasing properties is the property-management problem covered in the companion post, with the lease-administration gap and all.
Development: genuinely close to a native fit
For a developer, each property or phase of a development is a Project with a real budget — land acquisition, site work, construction draws, soft costs (permits, architecture, financing fees) — and this is exactly the job/project costing that Acumatica's Construction Edition and the core Projects module are built around. Committed cost tracking (purchase orders and subcontracts committing future spend before it's actually incurred) matters more here than in most professional-services verticals, because a developer needs to know total committed cost against budget, not just cost incurred to date, to avoid a nasty surprise near completion.
Task: Site Work (Phase 2)
Original Budget: $420,000
Committed (open POs/subcontracts): $385,000
Actual to date: $210,000
Remaining exposure: Budget - Committed = $35,000 uncommitted headroom
(the number a developer actually needs, and the
one a plain "budget minus actual" report hides)
Revenue recognition on units sold
Selling completed units or lots needs percentage-of-completion or completed-contract revenue recognition tied to the project budget — Acumatica's Projects module supports revenue recognition rules that post based on percent-complete, which is the mechanism to use rather than manual journal entries at each milestone. Getting the recognition method right (and consistent with the firm's actual accounting policy, which is a conversation with the client's auditor, not just a system default) is worth confirming explicitly before go-live rather than defaulting to whatever the demo used.
Investment/holding side: same gap as property management
Once a development is complete and the developer holds units for lease rather than selling them, the problem becomes the property-management one — lease administration, CAM, escalations — none of which is native, all of which is customization on top of the AR/GL core, exactly as described in the property-management post. A developer that also holds a portfolio needs both patterns in the same instance, cleanly separated by Project type so a leasing property doesn't accidentally inherit construction-budget reporting fields it doesn't need.
I have seen proposals imply a single native real-estate capability handles development and leasing uniformly. It doesn't — development leans on genuinely strong native Projects/Construction functionality; leasing leans on customization. Scope and quote them separately even within one client relationship.
Wrapping up
If the client is developing and selling, Acumatica's Projects/Construction capability is a strong, largely native fit — budget the effort into getting committed-cost tracking and revenue recognition configured correctly. If the client is holding and leasing, treat it as the property-management customization problem, and don't let a client-facing pitch blur the two.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.