RERA and Dubai Escrow Compliance: Classify the Money at Receipt

A developer receives a payment from a buyer on a Tuesday. Somewhere in the next few seconds, a decision is made about what that money is. Most systems make it much later, at month end, when someone runs a report and allocates.

That gap is where escrow compliance goes wrong, and it goes wrong in a way that looks fine until an auditor puts the ledger next to the bank statement.

RERA escrow compliance software has one job that matters more than the rest: it has to know, at the moment of receipt, which portion of that payment the developer may spend and which portion it may not. Everything else in this article follows from getting that one thing in the right place.

The two regimes, side by side, in engineering terms

Both markets protect buyer money in off plan sales. They do it differently enough that the same code cannot serve both without a jurisdiction flag doing real work.

India, under RERA. Section 4(2)(l)(D) requires that 70 per cent of the amounts realised from allottees for a project goes into a separate account with a scheduled bank, to cover construction and land cost. The remaining 30 per cent is the developer's working money. The split is proportional and it applies to what is realised, which means it applies at receipt, per project.

Dubai, under Law No. 8 of 2007. Article 6 requires a dedicated escrow account per off plan project, held with a trustee bank approved by the Real Estate Regulatory Agency and monitored by the Dubai Land Department. Buyer payments go into that account. Funds cannot be mixed between projects. Drawdown is tied to construction progress rather than to a fixed percentage at receipt, and the escrow agent retains five per cent of the total escrow value once the completion certificate is obtained, releasing it one year after the units are registered in the purchasers' names.

Read those two paragraphs as a data model and the differences become concrete.

India needs a proportional split computed at receipt, per project, with the 70 per cent restricted to two named purposes. Dubai needs strict per project isolation, a drawdown gated on certified progress, and a retention schedule with a release date driven by an event outside the developer's control.

One is a splitting problem. The other is a scheduling problem. A system built for either one alone will need surgery to take the second.

Classify at receipt or fail at audit

Here is the design point the whole article rests on.

Almost every finance system a developer already owns treats an incoming payment as a single amount against an invoice. The escrow treatment happens afterwards, in a spreadsheet, at reporting time. Somebody works out what the split should have been and reports it.

That produces a report that reconciles to itself and does not reconcile to the bank. The report says 70 per cent went to the designated account. The bank says a payment landed in the operating account on the 14th and a transfer went out on the 29th. For fifteen days the developer was holding restricted money in an unrestricted account, and no report will show that because the report is monthly.

The fix is unglamorous and it is the whole build. At receipt, the payment is split into two or more ledger postings with different spend permissions attached, before any allocation logic runs. A receipt of 1,000,000 rupees against a project under RERA becomes 700,000 restricted and 300,000 free at the instant it is recorded, and the restricted posting carries a flag that no payment run can override without an explicit certified drawdown.

Do that and three things become easy that are otherwise hard. The bank reconciles daily rather than monthly. Any report can be regenerated from postings rather than reconstructed. And a developer physically cannot spend restricted money by accident, because the system will not let a payment run touch a restricted posting.

The real estate industry page puts this in a single line: escrow aware receipting that separates drawable from non drawable money at the moment of receipt rather than at reporting time. That line is a 90 to 190 hour module, and it is the one to fund first.

Milestones are certificates, not dates

The second common failure is a payment plan engine keyed to calendar dates.

Off plan payment plans look like they are date driven. Ten per cent on booking, ten per cent in March, fifteen per cent on completion of the third floor slab. The middle one is a trap, because in both regimes what actually authorises a demand and a drawdown is certified construction progress, not the arrival of a month.

So the engine has to be keyed to a certificate. An engineer certifies a milestone, that certification is the event, and the buyer demand plus the escrow drawdown are both consequences of it. If the slab is late, the demand does not go out. If a system sends demands on dates, it will eventually demand money for work that has not been certified, which is a regulatory problem in Dubai and a disputable demand in India.

This inverts how most billing systems are built. Instead of a schedule that generates invoices, you have an event that generates invoices. The schedule becomes a forecast rather than an instruction.

There is a useful side effect. Once certification is the trigger, cash forecasting improves rather than degrades, because the forecast now carries an explicit assumption about certification dates that somebody owns. Finance teams tend to like this within about two weeks and dislike it for the first one.

Retention, and the release date nobody controls

The Dubai five per cent deserves its own section because it behaves unlike anything else in the ledger.

The escrow agent retains five per cent of the total value of the escrow account once the developer obtains the completion certificate. That amount releases one year from the registration of units in the purchasers' names.

Three engineering consequences follow.

The release date is not knowable at project start. It depends on when buyers register, which depends on buyers. So the retention balance has to sit in the ledger as a receivable with an estimated date and an explicit confidence, and it must be re estimated as registrations happen rather than set once.

Registration is per unit, so the trigger is a distribution, not a date. A 200 unit tower does not register on one day. Modelling it as a single date will misstate the release by months. Track registration per unit and derive the release schedule from the distribution.

Cash forecasts have to show it separately. Five per cent of a project's escrow value held for over a year is material, and a finance director who finds out about it late will not be pleased. It should appear as its own line in every forecast from day one, not as an adjustment at handover.

None of that is difficult. All of it is invisible if the system was built for India first and extended to Dubai afterwards, which is the usual order and the reason retention is the most common gap we find.

One system, two jurisdictions

A group operating in both markets wants one finance function, and that is achievable if the jurisdiction is modelled as a property of the project rather than as a separate installation.

The shared parts are larger than they look. Buyer and unit registry, receipting, demand generation, reconciliation, audit trail and reporting are all common. What differs is a rules layer: the split percentage and its permitted uses, whether drawdown is proportional or progress gated, the retention rule, and the report formats each regulator expects.

The trap is currency and unit measurement leaking into the shared layer. Carpet area in India is the contractual figure and the sale agreement is written on it, while Dubai deals in a different measurement convention entirely. Store the contractual figure with its unit and its basis explicitly, and never convert for display without carrying the original. A group that normalises area into one internal unit will eventually print a number that does not match a signed agreement, and that is a document problem rather than a software one.

The same caution applies to rounding. A 70 per cent split on an odd amount produces a remainder, and the remainder has to land somewhere deterministic and documented. Pick a rule, write it down, and make it the same rule in the report and the posting.

What this costs, with the hours shown

The rate is $40 to $100 per hour by role. Portals and reporting sit near the floor, the money ledger and jurisdiction rules near the ceiling, and mixed teams blend to around $65.

Module	Hours	What it covers
Project and unit registry with jurisdiction rules	40 to 90	Project, tower, unit, buyer, contractual area with basis, jurisdiction flag
Escrow aware receipting	90 to 190	Split at receipt, spend permissions on postings, rounding rule, reversal handling
Milestone certification and drawdown	80 to 170	Certificate as the event, demand generation, progress gated drawdown
Retention and release scheduling	50 to 110	Five per cent hold, per unit registration tracking, forecast line
Regulator reporting and audit pack	60 to 130	The returns each authority expects, regenerable from postings
Trustee bank reconciliation	60 to 120	Daily statement matching, exception queue, break investigation

Worked example. Registry 65 plus receipting 140 plus milestones 120 plus retention 80 plus reporting 95 plus reconciliation 90 equals 590 hours. That is $23,600 at $40, $59,000 at $100, and about $38,350 at a $65 blend.

The full span across the six modules runs 380 hours at every minimum to 810 at every maximum.

Deliberately excluded: bank charges, escrow agent fees, the statutory audit itself, and any ERP licence. The first two belong to the bank, the third to an accredited auditor, and the fourth is yours to buy. Any supplier quoting one number that includes them is making comparison harder rather than easier.

Cancellations, and the money that has to go backwards

Every escrow design gets tested by its first cancellation, and most fail it.

A buyer withdraws at 40 per cent paid. In India the refund position depends on the agreement and on what RERA permits to be forfeited, and the money being refunded has already been split, with the restricted portion possibly already drawn against certified construction. In Dubai a cancellation follows a regulated process through the Land Department and the escrow account is where the refund comes from, not the operating account.

Three things the system has to handle and usually cannot.

A reversal is not a negative receipt. If the original receipt created a restricted and an unrestricted posting, the reversal has to unwind both in the correct proportion, and it has to record that the restricted portion may already have been spent legitimately. A single negative line against the invoice loses that information permanently.

Forfeiture creates income out of restricted money. Whatever is retained under the agreement changes character. It stops being buyer money held in trust and becomes the developer's, and it has to move accounts and postings together rather than by journal at month end.

The unit goes back into inventory with history attached. Resold later, it carries a payment history from a different buyer, and the escrow trace for that unit now spans two contracts. Auditors will ask for the whole chain. Systems that key escrow postings to the buyer rather than to the unit cannot produce it.

None of this is exotic. Cancellation rates on off plan projects are high enough that a hundred unit tower will see several, and the first one arrives long before the compliance reporting is finished. Design the reversal path at the same time as the receipting path, in the same two week block, rather than treating it as an edge case for later.

What auditors actually ask for

Worth knowing before you design the reporting, because it shapes the schema.

Trace one payment end to end. A specific receipt, its split, the postings it created, the bank line it matched, and every drawdown it later funded. If that trace takes an analyst two days, the system has the wrong shape.

Show that restricted money was never spent unrestricted. Not a report saying it was not. Evidence that the system could not have. Spend permissions on postings give you that; a monthly reconciliation does not.

Reproduce a historical return. Regenerate last quarter's submission from the underlying data and get the same numbers. Systems that overwrite state instead of appending postings fail here, and it is usually discovered during the audit rather than before it.

Explain every break. Reconciliation differences are normal. Unexplained ones are not. An exception queue with a reason code on each resolved break is the artifact that turns a difficult audit into a short one.

Design for those four and the audit becomes an afternoon. Design for the report format alone and it becomes a fortnight, every time.

There is a fifth request that comes up less often and hurts more. An auditor asks to see the system prevent something, live. Attempt a payment run against a restricted posting and show what happens. A screen refusing the action ends that line of questioning in thirty seconds. A policy document describing why nobody would do it does not, because the auditor's job is to test the control rather than to read about it.

A sequence that reaches a compliant first project

Weeks 1 to 2. Registry and jurisdiction rules. Small, and everything after it depends on the model being right.

Weeks 2 to 6. Escrow aware receipting, with spend permissions enforced in the posting layer. Do not defer this behind a payment plan engine. Receipting correct with a manual payment plan is a compliant position. A beautiful payment plan on top of unclassified money is not.

Weeks 6 to 9. Reconciliation against the trustee bank, daily, with an exception queue. This is where you find out whether the receipting design actually works, and finding out at week nine is much better than at audit.

Weeks 9 to 13. Milestone certification and drawdown.

Weeks 13 to 16. Retention scheduling and the regulator returns.

Sixteen weeks, roughly 590 hours, and a defensible bank position from week six rather than week sixteen.

One closing note. Both regimes were written to protect buyers from developers spending money that was not yet theirs to spend. A system that makes that impossible by construction is easier to build than one that detects it afterwards, and it is the only version that survives contact with a busy finance team on a Friday.