The Complete UAE Property Developer Accounting Guide: IFRS 15 Revenue Recognition for Ready and Off-Plan Projects

Accounting for property development in the UAE is considerably more complex than accounting for most other industries, for one structural reason: the sale of the asset and the production of the asset happen at the same time, often years apart from when cash actually changes hands.

In a typical retail business, a product is manufactured, then sold, then delivered, and revenue is recognized at delivery. In UAE real estate, particularly off-plan development, the sequence is reversed and overlapping. A developer may sell a unit on day one of a 100-unit tower while the building itself is still a hole in the ground. The buyer pays in installments tied to a payment plan, not to construction milestones. The cash collected does not go directly to the developer — it is held in a RERA-regulated escrow account and released only against verified construction progress. And of the 100 units in the building, perhaps only 20 to 25 are sold at any given point, each potentially sitting at a different payment milestone.

This guide exists to walk through that complexity carefully, with reference to the actual accounting standards that govern it, and with enough worked examples that an accountant, auditor, or ERP consultant can use it as a working reference rather than a conceptual overview.

There is a widespread belief — repeated even by some ERP consultants and finance teams — that IFRS 15 simply says: "recognize revenue based on the percentage of project completion." That statement is not accurate, and treating it as a blanket rule is one of the most common sources of error in this area.

IFRS 15 does not say that revenue should automatically follow overall project completion. It requires revenue to be recognized based on progress toward satisfying a specific, identified performance obligation — and only after that performance obligation has first been determined to be satisfied over time rather than at a single point in time.

This means the cost-to-cost percentage-of-completion method discussed throughout this guide is the appropriate measure of progress only once a developer has established, based on the specific contract wording and the enforceability of payment rights under the governing law, that the over-time criteria are genuinely met. The assessment is contract-specific, not industry-wide.

UAE real estate developers generally sell under two structures, and the accounting complexity differs substantially between them.

Ready property accounting is comparatively simple because the timing of revenue recognition, the transfer of cash, and the transfer of the asset tend to converge around a single handover event. Off-plan accounting is harder because three separate timelines — the buyer's payment plan, the construction progress, and the escrow release schedule — run independently of one another and must all be reconciled in the books simultaneously, for every unit, every month.

A further complication specific to off-plan development: in a single 100-unit building, perhaps only 20 to 25 units have been sold at any given time. The remaining 75 to 80 units are unsold inventory. Construction costs for the entire building are being incurred regardless of how many units are sold, but only the costs attributable to sold units can be matched against revenue. Costs attributable to unsold units remain capitalized as inventory (work in progress) until those units are eventually sold.

Many UAE accountants are already comfortable with the mechanics of leasing income, which provides a useful — though imperfect — mental anchor before diving into sales accounting.

In a typical UAE tenancy, the tenant pays one year's rent upfront, often as a small number of post-dated cheques (commonly structured as 1, 2, or 4 cheques). The full amount received is recorded as a liability — advance rental income — because the landlord has not yet earned it. As each month of occupancy passes, one-twelfth of the annual amount is reclassified from the liability account into rental revenue. If a tenant occupies the unit for one month, exactly one month's worth of rent moves from "advance" to "earned." The trigger for recognition is the simple, linear passage of time — measured by occupancy.

Off-plan sales accounting follows the exact same underlying logic — an amount is received before it is earned, so it sits in a liability account until it is earned — but the trigger for recognition is fundamentally different. It is not the passage of calendar time. It is construction progress, measured against the specific performance obligation in the sale contract.

This single difference — time-based recognition versus performance-based recognition — is why leasing accounting can be handled with simple straight-line schedules, while off-plan sales accounting requires the full apparatus of IFRS 15: performance obligations, transaction price allocation, a measure of progress, and contract assets or liabilities that move every single reporting period as estimates are refined.

IFRS 15 Revenue from Contracts with Customers is the single global standard governing how and when an entity recognizes revenue. It replaced IAS 11 Construction Contracts and IAS 18 Revenue, along with several related interpretations including IFRIC 15 Agreements for the Construction of Real Estate, for annual periods beginning on or after 1 January 2018.

IFRS 15 organizes revenue recognition into a five-step model. For a property developer, each step has a specific, non-obvious answer.

The Sale and Purchase Agreement (SPA) is the contract. The performance obligation is typically the promise to deliver a specific, identified real estate unit — for example, "Apartment 1204, Tower B." Where the unit is described with enough specificity that the developer cannot substitute a different unit without breaching the contract, the unit is treated as having no alternative use to the developer, which matters for the over-time assessment discussed below.

For a single-unit sale, the transaction price is simply the agreed sale price in the SPA, adjusted for any variable consideration such as early-payment discounts or penalty clauses. Allocation across multiple performance obligations (for example, where parking, storage, or furniture packages are sold as separately identifiable promises) follows the relative standalone selling price of each.

This is where property developer accounting diverges from almost every other industry, and where the determination must be made with real care rather than assumed.

The remainder of this guide focuses on the scenario most readers are seeking — over-time recognition using the cost-to-cost method — on the explicit basis that the developer has first established that its specific contracts meet the IFRS 15.35 criteria. Where that determination instead concludes point-in-time recognition is appropriate, the accounting is considerably simpler: cash received remains a contract liability throughout construction, with no revenue or cost of sales recognized until legal title and possession transfer at handover.

Once a developer establishes that revenue is recognized over time, two new balance sheet items become central to the accounting: the contract liability and the contract asset. Both exist because cash collection and revenue recognition almost never move in perfect lockstep.

A contract asset differs from an ordinary trade receivable in one important respect: a receivable represents an unconditional right to payment (only the passage of time stands between the entity and collection), while a contract asset's right to payment is still conditional on something else — typically further performance, or reaching a contractual billing milestone. This distinction also matters for impairment: contract assets are subject to the expected credit loss requirements of IFRS 9, the same as receivables.

The relationship between these two accounts over the life of a single unit sale typically follows a predictable arc: contract liability rises early (cash collected outpaces performance), narrows as construction catches up to cash collected, may flip into a contract asset later in the project if performance outpaces the buyer's payment schedule, and resolves to zero — with the corresponding amount moving to revenue and, eventually, a receivable or cash — at handover.

Everything described so far applies to real estate developers under IFRS 15 globally. The escrow mechanism is what makes UAE — and specifically Dubai — property developer accounting distinctly local, and it must be layered carefully on top of the revenue recognition mechanics above without being confused with them.

Under Law No. (8) of 2007 Concerning Escrow Accounts for Real Estate Development in the Emirate of Dubai, a developer selling units off-plan cannot deposit buyer payments into its own operating account. Instead, a dedicated escrow account must be opened for each project with a RERA-accredited escrow agent (typically a bank). All buyer payments — and financier funding for the project — must be deposited directly into that project-specific escrow account. The funds are legally ring-fenced: creditors of the developer cannot attach the escrow balance, and the money may only be used for the construction of that specific project.

From an accounting perspective, this means a UAE developer's chart of accounts needs to separately distinguish restricted cash (escrow) from unrestricted cash (operating), and movements between them are pure cash reclassifications — they do not touch revenue, cost of sales, or the contract asset/liability balance at all. Only the underlying construction performance (cost incurred relative to total estimated cost) drives revenue recognition; the escrow release is simply how that performance gets paid for.

Once a developer has confirmed that a performance obligation is satisfied over time, IFRS 15.41 requires it to select a single method to measure progress toward completion and to apply that method consistently to similar performance obligations. The two broad categories are output methods (e.g. units delivered, milestones reached, surveys of work performed) and input methods (e.g. costs incurred, labor hours expended, machine hours used).

For property developers, the cost-to-cost input method is the most commonly applied in practice, because reliable cost data is usually more readily available and more objectively verifiable than subjective output assessments on a large, multi-trade construction project.

Borrowing costs incurred to finance construction are a separate matter, governed by IAS 23 Borrowing Costs, not IFRS 15. Where a development qualifies as a "qualifying asset" under IAS 23.5 (typically because it takes a substantial period — commonly judged as more than approximately six months to a year — to get ready for sale), directly attributable borrowing costs are capitalized into the cost of the work in progress rather than expensed as incurred, which in turn affects the total estimated project cost used in the POC denominator.

Using the worked scenario above (Unit A: AED 1,000,000 sale price, 20% advance, project 20% complete at Month 6), here is the complete flow of journal entries from contract signing through to revenue recognition.

The buyer pays the 20% advance. This must be deposited into the project's RERA escrow account. Because the developer has not yet performed, the amount is a liability, not revenue.

As the developer pays contractors across the whole project, the cost is capitalized as Work in Progress (an inventory-type asset), not expensed immediately — because the related revenue has not yet been recognized.

RERA's appointed engineer verifies 20% completion and authorizes the escrow agent to release AED 150,000 to the developer's operating account, to be used for paying contractors. This is a pure cash reclassification — restricted to unrestricted — and does not touch revenue.

Because Unit A's specific contract is 20% complete, 20% of its AED 1,000,000 contract value moves from contract liability into revenue. The matching proportion of Unit A's estimated cost (assume AED 500,000 total estimated cost for Unit A specifically) moves from Work in Progress into Cost of Sales.

Imagine that by Month 8, the project is 40% complete. Under IFRS 15, the developer should now recognize 40% of Unit A's revenue, or AED 400,000 cumulative. However, the buyer has only paid the initial 20% (AED 200,000) and is not contractually due to pay again until handover. The contract liability has already been fully depleted by the Month 6 entry. The entry now must recognize the excess as a contract asset (an unbilled receivable) rather than a contract liability reversal.

Real portfolios rarely look like the single clean example above. The scenarios below cover the situations that actually arise across a typical off-plan sales book — different payment-versus-progress combinations, defaults, handovers, unsold inventory, project losses, cost revisions, contract modifications, and construction delays. Each assumes the developer has already established over-time recognition applies, per the IFRS 15.35 assessment discussed earlier.

The accounting described in this guide is conceptually clear but operationally complex at scale. A developer with 500 sold units across five projects — each at a different stage of payment and construction — cannot realistically manage POC calculations, cumulative catch-up adjustments, contract asset/liability movements, and escrow tracking manually every month. An ERP system designed for this business model must automate the entire recognition cycle.

The following describes the minimum table structure, the monthly automation logic, and the key system design decisions relevant to any ERP platform — whether SAP, Microsoft Dynamics 365, Oracle NetSuite, Odoo, or a custom-built solution.

The key design insight is that the Unit is the primary accounting object. Every revenue, cost, contract asset, contract liability, and cash transaction must ultimately be traceable back to a specific unit ID — because it is at the unit level, not the project level, that the individual IFRS 15 performance obligation exists and the revenue recognition calcuation is performed.

A well-implemented ERP for this model will also handle: escrow sub-ledger with restricted vs. unrestricted split, automated milestone billing linked to payment schedules, unit-level cost allocation from the project cost pool, RERA milestone tracking with linkage to escrow release approvals, contract modification workflows, and monthly reporting packages showing revenue recognized, cost of sales, gross profit, contract asset, contract liability, and WIP for each project and each unit.

These are the errors most frequently encountered in practice — in audit findings, ERP implementations, and finance team reviews. Each can lead to material misstatement.

The following standards, interpretations, and official sources are cited or drawn upon throughout this guide.