Why Developers’ Sales, CRM and Finance Systems Never Agree on Unit Availability

Every developer with active sales has lived some version of this Monday morning. A broker calls to say his client has paid a reservation deposit on a two-bedroom on the 14th floor. The sales manager says the unit was held for another buyer on Friday. Finance says neither deposit has been matched to a receipt, and the ERP still shows the unit as available. Three teams, three systems, one apartment, and two buyers who both believe it is theirs.

It is tempting to treat this as a discipline problem, as if someone forgot to update a sheet. It rarely is. Double-booked units happen when availability is stored in several places, updated by different people, at different speeds, for different reasons. Nobody is being careless. The setup simply cannot agree with itself.

This article looks at the systems most developers run, where they drift apart, what that costs in time, money and reputation, and how to fix it without throwing away software you have already paid for. It also covers why the fix is as much a revenue operations (RevOps) question as a technical one.

Four places where "available" lives

Most developers, whether they sell in one market or across several, run some combination of the following. Each is sensible on its own.

• The CRM (Salesforce or Microsoft Dynamics 365). Sales owns it. It holds leads, opportunities, offers and unit holds. A unit's status changes when a salesperson moves a stage or remembers to tick a field. In the CRM, "available" usually means no active opportunity has locked the unit.
• The ERP. Finance owns it. It holds contracts, instalment schedules, receipts, tax treatment and revenue recognition. A unit is truly "sold" here only once the sale is booked and money is posted. In the ERP, "available" means no contract exists yet.
• Broker and listing portals. These may be a bespoke portal, a CRM community module, a third-party inventory feed or a public listing portal. External brokers and buyers rely on them to see what is on offer. Too often they show a snapshot that refreshes on a schedule or after someone uploads a file.
• Excel. The master availability sheet, the release schedule, the price list with last-minute adjustments. It is often the document the sales director trusts most, because it is the only one they can edit themselves in thirty seconds.

Each system is correct by its own definition. The trouble is that "held," "reserved," "booked" and "sold" mean different things in each one, and no rule says which system wins when they disagree. So the people in the middle, usually sales administrators and finance coordinators, become the integration layer. They copy, reconcile and chase by hand.

For a group with projects in several locations, this multiplies. Each site or country tends to grow its own sheets and its own habits, and head office sees inventory only after someone has stitched the pieces together.

How one unit gets sold twice

Consider a developer with two towers in active sales and a launch weekend coming up. This is a hypothetical, but most sales leaders will recognise it.

On Thursday at 6pm, a salesperson is talking on a messaging app with a buyer who is travelling in a different time zone. The buyer agrees to reserve a unit and promises to transfer the deposit the next morning. The salesperson places a hold in the CRM at 6:10pm. That hold does not reach the broker portal until the next scheduled refresh, which is after midnight. The Excel sheet the sales director circulates was last updated on Wednesday, so it still shows the unit as open.

At 9pm, a broker from another firm opens the portal, sees the unit available and messages his own client, a multilingual buyer working through the evening and switching between two languages. That client transfers a deposit on Friday morning. Over the weekend, a third person on the sales team, looking at the Excel sheet, offers the same unit to a walk-in at the sales gallery.

By Monday, finance has a bank transfer it cannot match to anything, a CRM hold in someone else's name, and a gallery visitor expecting a booking form. Somebody now has to tell a buyer no, ideally in the buyer's own language, with a refund, an apology and a broker who wants to know why the commission is at risk. The unit itself is the smallest part of the damage.

What finance sees that sales does not

The double-booking is the visible failure. The quieter failures happen in the gap between CRM and ERP, and they tend to surface at the worst moment, such as invoicing, audit or handover.

Price and payment plan drift. A discount is approved on a messaging app by a sales director, entered in the CRM offer at one figure, written into the contract at a slightly different one, and never updated in the Excel price list. Finance books what the contract says. Sales reports what the CRM says. The month-end reconciliation becomes a forensic exercise.

Buyer data that does not match. The CRM holds a buyer's name as typed by a salesperson. The passport or national ID says something different, and the spelling differs again once the name is transliterated between scripts. Under regional e-invoicing mandates, such as Peppol-based schemes, invoice data is expected to be consistent and valid. A mismatch between the buyer record in the CRM and the one in the ERP means a rejected or corrected document and a customer who wonders why paperwork keeps coming back. Buyer records scattered across systems and personal spreadsheets are also harder to govern under data protection laws such as GDPR, because nobody can say with confidence where a person's data actually lives. Indirect tax adds another layer. Where VAT or a similar tax applies, treatment often depends on the unit type, with residential and commercial supplies handled differently. If the unit's classification is wrong or stale in one system, finance finds out when it prepares the return, not when the deal is made.

Deposits with no home. A deposit lands in the bank before a hold exists, or a hold exists with no deposit behind it. Neither the CRM nor the ERP can tell the full story alone, so someone builds a spreadsheet to track "pending" items. That spreadsheet then becomes yet another place where availability lives.

Cancellations that do not travel. A buyer cancels, finance processes the refund, and the unit goes back into stock in the ERP. The CRM still shows it as sold, the broker portal still hides it, and the unit sits idle until someone notices. In a slow quarter, an invisible unit is lost revenue.

The cost of every system being slightly right

None of this requires dramatic failure to be expensive. The damage accumulates through small, repeated friction.

• Delays. Every sale waits for someone to confirm status by phone or message. Reservation confirmations, booking forms and payment receipts move at the speed of the slowest hand-off.
• Exhausted teams. Sales administrators spend launch weeks cross-checking sheets instead of supporting buyers. Finance staff spend month-end matching transfers to deals by hand. During peak seasons, or when working hours shift and event calendars fill up, the same manual effort lands on fewer people for fewer hours.
• Mistakes. Wrong prices, wrong buyer details, wrong unit status. Each one is minor, and each one needs a correction that takes longer than the original entry.
• Frustrated customers. Buyers and brokers experience the developer as a single organisation. They do not care that the CRM and ERP are separate. They see inconsistent answers, repeated document requests and, in the worst case, a unit they thought they had bought being sold to someone else.
• Leaked money. Units sit unsold because status is stale. Discounts are granted outside approved limits because nobody sees the offer and the contract side by side. Brokers dispute commissions. Refund and reconciliation work consumes hours that cost real salary.
• Blind leadership. Executives who want one answer to "what is available, held and sold across all our projects today?" wait for a manually assembled report that is already out of date when it arrives.

None of these show up as a line item called "fragmentation." They show up as overtime, write-offs, strained broker relationships and a sales team that stops trusting the data.

Why the usual fixes do not hold

Most developers have already tried something. A connector between the CRM and the ERP. A nightly export to the broker portal. A rule that Excel must be updated before 5pm. These help, and then they decay, for three reasons.

Nobody has defined what "available" means. If the CRM, ERP and portal use different status lists, no connector can translate between them cleanly. The first job is a single unit lifecycle, such as available, held, reserved, booked, contracted and cancelled. It must state who can change each state, on what evidence, and for how long a hold lasts. This is classic RevOps work: sales, finance and marketing agreeing on shared definitions and handoffs, so that everyone is counting the same thing.

Integrations are built point to point and run one way. A nightly push from CRM to portal does not help if the portal's booking request has to travel back. Each new connection adds another thing to break, and the first time Salesforce or Dynamics is updated, or the ERP is upgraded, something quietly stops syncing.

Nobody owns the link after go-live. The consultant who built the connector has moved on. The IT team supports the systems but not the logic between them. When a sync fails at 11pm before a launch, there is no one whose job it is to notice.

What works is closer to an operating backbone than a set of connectors. It means one agreed status model, a clear system of record for each fact, changes that flow in both directions, brokers seeing the same inventory the sales team sees, and Excel demoted from source of truth to a report that reads from the real data. On top of that sits a central command center or operating center view, where leadership can see inventory, holds, deposits and exceptions across every project and location in one place. And someone is accountable for keeping it all running.

How The Ninjaz Group approaches it

The Ninjaz Group is a managed-services partner. We design the change, wire a client's existing systems into one operating backbone, and stay on to run it. For a developer with this problem, that usually unfolds in three phases. You can stop after any one of them.

Blueprint. We map the operation end to end, from enquiry to hold to reservation to contract to payment to handover, across every project and location in scope. The point is to find every gap where work is done twice, data goes stale or money leaks. That includes the places no one has documented, like the messaging-app approvals and the private spreadsheets. You keep the map either way, whether or not you go further with us.

Build & Link. We build what is missing and wire the systems you already have, whether that is Salesforce or Dynamics, your ERP, the broker portal and the supporting spreadsheets, into one backbone. There is no rip-and-replace. Software you have already paid for stays. This is the work of our Managed Link layer, the operating layer between systems, built, owned and maintained by us so that CRM, finance, website and messaging behave like one system. Where the Blueprint shows that something is genuinely missing, such as a proper hold-and-expiry process or a command-center view for leadership, Managed Transformation Services covers the strategy, design and development of that change.

Operate. After go-live, we provide support, monitoring and continuous improvement, through Managed Business Operations. Think of it as your operations and IT team without the headcount. When a sync fails or a new project launches with new inventory rules, someone is already responsible.

On delivery, strategy and account leadership stay close to your operation, whether you run a single market or a multi-country group. We adapt the design to local requirements such as tax rules, e-invoicing schemes and data protection obligations, so that one backbone can serve every site without forcing each one into the same mould.

If your sales, CRM and finance teams keep arriving at different answers about the same unit, the fix does not have to start with new software. It can start with a shared definition and a map of where the answers diverge. To talk through what that would look like for your projects, book a consultation.