Possession: offer, handover, conveyance and the occupation certificate
Possession of a booked unit is recorded as three dates on the booking (possession offered, handed over, conveyance registered); the occupation certificate on the tower or project is what allows the offer, the handover marks the unit Sold, and the books' revenue policy names which of these dates is the moment sale revenue is recognised.
Possession: offer, handover, conveyance and the occupation certificate
Possession is the end of a sale: the municipality certifies the building fit to occupy, the developer offers the buyer possession, the buyer takes the keys, and the conveyance is registered. NirmaanOne records these as three dates on the booking and one certificate on the tower or project. They are operational facts first; the books read them to decide when sale revenue is recognised.
How it works in NirmaanOne
The occupation certificate
The occupation certificate (OC) is recorded in one of two places, with the Edit permission on Towers, Floors & Units or on Projects:
- On a tower: Structure, the tower panel, fields Occupation certificate no. and OC date ("Possession can be offered on this tower's units from this date.").
- On the whole project: the project's Settings tab, section Possession, the same two fields ("For the whole project. A tower with its own OC (Structure > tower) uses that one.").
For any unit, the OC that covers it is its tower's own when the tower has an OC date, otherwise the project's. A project where towers receive their OCs at different times records each tower's OC on the tower; a single-building project records it once on the project.
The three dates
The Possession card on the Booking overview shows the OC that covers the unit ("<date> · <number> (tower|project)" or "Not recorded") and the three dates, each set through its own dialog with the Edit permission on Bookings:
- Offer possession: the day the office tells the buyer the unit is ready. Workflow rules can send the possession letter on this event.
- Hand over: the day the buyer takes the unit. The unit's status becomes Sold. Clearing the date sets it back to Booked.
- Register conveyance: the day the conveyance is registered.
Each dialog takes a Date (default today). The rules the server applies:
- The booking must be active. The card shows no possession buttons on a cancelled booking, and the app refuses the change with "This booking is cancelled and can no longer be changed."
- No date can be before the booking date: "A possession date cannot be before the booking date".
- Handover needs an offer first ("Offer possession before handing the unit over") and cannot be before it ("The handover cannot be before the offer of possession"). The Hand over button is greyed out with "Offer possession first" until an offer date exists.
- When the revenue policy in force requires an OC (the default), the OC covering the unit must be dated on or before the offer date; otherwise "<tower or project> has no occupation certificate on or before <date>; record the OC on the tower or the project first". Without any OC the card greys out Offer possession with "Record the occupation certificate on the tower or the project first" and warns "No occupation certificate covers this unit yet, so possession cannot be offered." If the promoter has no books yet, the OC is still required.
- Once a posted revenue run has recognised revenue on the booking, the dates are part of the books and cannot change: "Revenue on this booking is already recognised; its possession dates stay as posted". The card shows "Revenue on this booking is recognised; its possession dates stay as posted." and hides its buttons. This covers every date, including one not yet recorded: a conveyance registered after the booking's revenue was posted can no longer be entered, so record all three dates before the revenue run for that period is posted.
Each date that is set raises a workflow event (Possession offered, Possession handed over, Conveyance registered), so the possession letter, reminders and follow-ups are workflow rules rather than fixed behaviour.
What the books do with the dates
The Revenue policy of the promoter's books names the possession trigger, the booking event the accountant treats as the transfer of control under the point-in-time method. The Revenue recognised on row of the Possession card repeats it:
| Trigger (Recognise on) | Control passes on |
|---|---|
| Possession offered | the offer date |
| Possession handed over (default) | the handover date |
| Deemed handed over | the offer date plus the policy's Days after the offer (default 15), or the actual handover if that came earlier |
| Conveyance registered | the conveyance date |
The organization may set a default trigger for every project (the Projects card under Settings > Organization), and a project may override it for its own bookings (its Settings tab, Recognise revenue on under Accounting). Each revenue run checks every active booking: if the control date is missing or after the period end, the line notes "Waiting for: <trigger>" (for example "Waiting for: possession handed over"); if the policy requires an OC and the OC covering the unit is missing or dated after the control date, the line notes "No occupation certificate on or before the trigger date"; otherwise the booking is 100% recognised in that period. Under an over-time method (by construction stages or by cost) revenue follows progress instead, but the OC gate on Offer possession still applies.
The project's Expected possession date is a different thing: a planning date used for charges collected "At the time of possession" and for disclosures, not a recorded event (see Expected possession).
Why the OC gate exists
A building may not be occupied before its occupation certificate is granted, and an accountant cannot treat a sale as complete while the buyer could still refuse an uncertified building. Tying Offer possession to the OC date keeps the operational record and the revenue record on the same footing, and keeping the dates frozen after recognition means a posted revenue run can always be explained from the booking it was computed on.
Example
Sai Darshan, Tower A, unit A-1203 was booked by Anil Deshmukh on 15 March 2025. The books "Shree Siddhi Developers" use the default revenue policy: Ind AS 115, point in time, Recognise on Possession handed over, Occupation certificate required on.
- On 15 August 2026 the sales manager tries Offer possession dated that day. Tower A has no OC yet and neither does the project, so the button is greyed out: "Record the occupation certificate on the tower or the project first".
- On 21 August the project office receives the OC for Tower A (MCGM/OC/2026/1187 dated 20 August 2026) and records it on the tower under Structure. Tower B is still under construction and has none.
- Offer possession dated 1 September 2026 now succeeds (a toast confirms "Possession offered on …" with the date) and a workflow rule on the Possession offered event, if the organization has set one up, sends the possession letter. Had the sales manager typed 15 August, the dialog would have refused: "Tower A has no occupation certificate on or before 2026-08-15; record the OC on the tower or the project first".
- The buyer collects the keys on 12 September; Hand over dated 12 September 2026 sets A-1203 to Sold. A booking on Tower B cannot be offered possession at all until Tower B's OC (or a project-wide one) is recorded.
- The conveyance is registered on 25 September; Register conveyance records it the same day.
The revenue run for the period ending 30 September 2026 finds the control date 12 September (the handover), on or before the period end, and the OC dated 20 August on or before it, so the booking is recognised at 100% in that period. Had the policy said Deemed handed over with 15 days, the deemed date would be 1 September + 15 = 16 September, and the earlier of that and the actual handover, 12 September, would be the control date; a buyer who never collected the keys would be recognised on 16 September. Once the accountant posts that run, the three dates are locked on this booking; had the conveyance still been pending, it could not have been recorded afterwards.
Where you see it
- Booking overview: the Possession card with Offer possession, Hand over, Register conveyance and Revenue recognised on.
- Structure: a tower's Occupation certificate no. and OC date.
- Project settings: the project-wide OC under Possession and the project's override of the revenue method and trigger under Accounting.
- Revenue policy: Recognise on, Days after the offer and Occupation certificate required.
- Revenue run and Revenue runs: the "Waiting for: …" and "No occupation certificate on or before the trigger date" notes.
- Remaining obligation: what is still to be recognised, banded by expected possession.
- Rules and Event types: the possession events.
Related
Related
- Booking overviewScreen
A booking's home page: the applicant and unit, parking, dates, money summary, termsheet status and possession, with the buttons to edit the booking, see its history, jump to the opportunity or cancel it.
- StructureScreen
Build and maintain a project's towers (wings), floors and units, generate them in bulk, and see every unit's status and designation at a glance.
- Revenue policyScreen
The CA's effective-dated choices on how the books recognise sale revenue and the costs that go with it: framework, method, possession trigger, OC rule, cost treatments and judgement areas.
- Revenue runScreen
One period close: what each booking and member offer recognises, the journals and cost moves it posts, the subjects it left out, and the actions to recompute, post, reverse or delete it.
- Revenue runsScreen
The revenue runs (period closes) of the chosen books, the dialog that prepares a new draft run, and the scheduled rules that draft runs automatically.
- Remaining obligationScreen
The Ind AS 115 disclosure of revenue still to come from what is already booked: each live booking and member offer's price less what the posted revenue runs have recognised, per project, banded by the financial year of the project's expected possession.
- Cancel bookingScreen
The four-step wizard that cancels a booking: it shows the demands and receipts that will be reversed, suggests the forfeiture and charges from the rule in force, sets the refund and posts everything in one go, releasing the unit and parking and marking the opportunity lost.
- RulesScreen
Every automation rule in your organization, system and custom, with filters, the switch that turns each rule on or off, and shortcuts to edit, test, clone, see the run history of or delete a rule.
- Event typesScreen
The named events a rule can listen to: the system events NirmaanOne raises itself and the custom events you add to chain rules or to raise from your own integrations.
- Unit status lifecycle: available, reserved, allotted, held, booked, soldConcept
Where a unit stands right now, from Available through the rehab path (Reserved For Tenant, Allotted) or the sales path (Reserved For Buyer, Booked, Sold), who moves it and what each status blocks.
- Expected possession date and charges at possessionConcept
The project's expected possession date is when the charge groups a pricing plan collects "at time of possession" fall due: one undivided row per charge, owed from booking, outside the buyer's payment plan, re-dated on every open booking when the date changes.
- Booking: agreed total, applicants and sharesConcept
A booking is the closed deal on one unit for one opportunity, made from the current Approved estimate: it fixes the agreed total, numbers itself by financial year, books the unit and parking, and names the primary applicant and the co-applicants with their ownership shares.
- Effective-dated rulesConcept
Rules that change over time (the RERA escrow share, TDS on sales, booking cancellation forfeiture, the revenue policy and cost budgets) are kept as dated rows; the row in force on a date is the latest one starting on or before it, so old documents keep the figures they were made with.
- Construction stages and share bucketsConcept
A project's construction stages (plinth, slabs, possession) each carry a share of a 100% bucket, one bucket for the project-wide stages and one per tower; completing a stage dates the installments waiting on it and moves the revenue progress.