Sell the flat. Get paid when the slab is cast.
Enquiry, booking, payment plan, collection, handover — the whole journey for a project you are selling, on the same file the site is being built in. And the part every builder keeps in somebody's head: the day a construction stage finishes, the demand for every flat waiting on that stage is ready to go out.
The whole chain, in six lines.
Sales in Civil Limitless is not a CRM bolted onto a construction app. It is the far end of the same chain — the tower is linked to the building the site is actually putting up, and the money follows the concrete.
See the construction sideEleven screens, and one of them is the reason for the other ten.
Leads, inventory, bookings, payment plans, demands, collection, brokerage, loans and possession. They matter because they end in a demand note that is raised on the day the work was actually done, not the day somebody remembered.
Where a sales office loses money
The demand goes out three weeks late
The slab was cast on the 4th. Nobody told accounts until the month-end review, and the letters went out on the 26th.
The rate changed, so an old booking changed with it
The tower is repriced in the middle of the year and a spreadsheet formula quietly rewrites a deal that was signed at last year's rate.
Nobody can say what a buyer still owes
Demands in one file, receipts in another, TDS somewhere else, and the delay interest worked out on a calculator when the buyer argues.
Every enquiry has an owner, a history and a date.
A lead is entered with its source — walk-in, website, referral, broker, campaign — the sales executive it belongs to, the tower he is interested in, his budget range, and the date you promised to call him back. Only the name is compulsory, so a walk-in can be captured in ten seconds and completed later.
After that, every call, meeting, site visit, email, WhatsApp message and note is logged against him. When you set a next action date on an activity, it moves the lead's own follow-up date with it — so the diary keeps itself.
- Due today is your call list. It shows every open lead whose follow-up date is today or already past — not only today's — so nothing quietly falls off the bottom. Overdue narrows it to the ones you have already missed.
- A month view when you are planning. Switch to Calendar and the follow-ups sit on their dates, overdue ones in red. Three names fit in a day and the rest read "+3 more".
- A lost lead must say why. Marking a lead Lost without a reason is refused — in the browser and again on the server — so the reason can never be lost. Every status change also writes itself into the timeline: from, to, and the reason.
- Bring your old register in. An Excel of enquiries imports up to 2,000 rows; the header row is found on its own and anything unrecognised in Source becomes "Other".
The ladder
New → Contacted → Visit Scheduled → Visited → Negotiation → Won or Lost. It is the normal order, not an enforced sequence — a buyer who walks in and books the same afternoon can be moved straight to the end.
| Logged | What it does |
|---|---|
| Site Visit — "liked the corner 2 BHK on the 4th" | Sits in the timeline with the date |
| Next action: 22 Aug | Moves his follow-up to 22 Aug — he reappears in Due today |
| Status → Negotiation | Writes "new → negotiation" into the same timeline |
| Convert to Booking | Creates a draft booking and marks the lead Won |
Converting is the only way a lead becomes a booking
Marking a lead Won by hand does not create anything. Convert to Booking does — and it offers only the flats that are genuinely available, checks the flat again at that exact moment in case a colleague booked it while you were talking, and carries the lead's executive and broker across to the deal.
Once a lead has been converted the button disappears and a line shows which booking it became, so the same enquiry can never be booked twice.
The whole building on one screen, and the status is the truth.
Tower by floor by unit, each flat carrying its own status — available, reserved, booked, sold or blocked. When a broker rings and asks what is left on the 12th floor, the answer is on the screen and not in somebody's memory.
Tower A
liveShops, offices and parking slots are units too — parking sits in its own row and is printed on the inventory PDF, but it is left out of the flat counts so the "available" number means what a sales head thinks it means.
Booked and Sold are not yours to type
You can set a unit Available, Reserved or Blocked by hand. Booked and Sold are machine-managed — they follow the booking, and the app refuses a status change on a unit that carries one. To free a flat you cancel its booking, which is exactly the discipline that keeps the grid honest.
- A hold that releases itself. Reserve a flat with a Hold until date and it goes back to Available on its own after that date. Nothing stays blocked because someone forgot to un-block it.
- Build a tower in one pass. Bulk Generate takes floors 1 to 12, four units per floor and a pattern — {F}0{N} gives 101, 102 … 1204. The preview names the units before you press it, and numbers that already exist are skipped, so running it twice is safe.
- A price list per tower. Base rate per square foot plus a floor rise per floor. Leave a unit's rate blank and it takes the list — ₹4,000 with a ₹25 rise makes the 10th floor ₹4,250. Reprice re-applies it to what is still in the market and leaves booked and sold flats alone.
- Or import the architect's schedule. An Excel of units loads against towers that already exist by name, and unit numbers already present are skipped rather than duplicated.
Approval freezes the price. That is the whole point of it.
A booking is built in four steps — the unit, the buyer, the pricing, the payment plan — and it stays a draft while you argue about the discount. The moment it is approved, the numbers stop moving.
The price build-up
Pick the flat and the base price fills itself from that unit's rate times its super area. PLC comes across as the unit holds it. A discount is typed as a negative number, and the agreement value updates on the line below while you are still negotiating.
| Tower A — flat 101, 1,000 sqft | Amount (₹) |
|---|---|
| Base price1,000 sqft × ₹4,025 — base rate ₹4,000 + one floor rise | 40,25,000 |
| Preferential location charge | 0 |
| Premium / discount — typed as a negative | − 25,000 |
| Agreement value | 40,00,000 |
| GST @ 5% on the agreement | 2,00,000 |
| Registration charge — from the payment plan | 25,000 |
| Total deal value | 42,25,000 |
Every one of those figures is written onto the booking as its own copy. Reprice the tower next quarter and this deal does not move. Try to edit the base price after approval and nothing happens — the frozen number stays, and the screen says so.
- A discount of more than 10% of the list price cannot simply be approved. It has to go through Submit for Approval, so the concession is a decision somebody made and not a number somebody typed.
- A draft can be deleted. Anything submitted, approved or cancelled cannot — the audit trail survives, which is what your auditor will ask about.
- Approval also books the brokerage on the agreement value, and turns the flat blue on the inventory grid with the buyer's name on the chip.
Buyer KYC, kept properly
Name, phone, email, address, PAN, bank details, co-applicants one per line with their relation and phone, and the scanned documents.
The two things that go wrong after a booking
A resale before registration. Transfer Unit moves an approved booking to a different buyer. The booking keeps its number and its entire money history — only the buyer changes. The outgoing buyer is written into the transfer history with the date, and the transfer fee is recorded as a receipt on the same booking, so it shows in Received.
A buyer walks away. Cancel asks for a reason and the amount you are forfeiting, and shows you exactly what has been credited to him so far — receipts plus any TDS he deposited. The flat and every parking slot it held go straight back to Available, and the refund note prints for received minus the charge.
Write the plan once. Stamp it on every booking.
A template is a list of milestones, and each milestone falls due in one of three ways: on booking, a number of days after booking, or when a construction stage completes. That third one is what makes the rest of this page possible.
A standard construction-linked plan
There is a starter you can load and edit — 10 / 10 / 15 / 30 / 25 / 10 with a registration charge — and the running total beside the heading turns green when it reaches 100.
| Milestone | Falls due | % | On ₹40,00,000 |
|---|---|---|---|
| On booking | Immediately | 10 | 4,00,000 |
| First instalment | 45 days from booking | 10 | 4,00,000 |
| Foundation | Stage — Footing / Foundation | 15 | 6,00,000 |
| Superstructure | Stage — Superstructure | 30 | 12,00,000 |
| Finishing | Stage — Finishing | 25 | 10,00,000 |
| On possession | Stage — Possession | 10 | 4,00,000 |
| Agreement value | 100 | 40,00,000 | |
| Registration chargeA charge row — a fixed rupee amount, added on top | On booking | — | 25,000 |
- It adds up to the paisa. Percentage rows are spread over the agreement value and the last row absorbs the rounding, so the plan totals the agreement exactly — not ₹39,99,999.40.
- A charge row carries no GST. Registration, club membership, a corpus fund — a fixed rupee amount sits on top of the agreement, and GST is charged only on the agreement-value milestones.
- The stage name has to match. A stage row is matched against that tower's own construction stage list, ignoring capitals and stray spaces. If the table shows a row as unlinked, the name is wrong — and that row will never suggest a demand until it is fixed.
- Change a draft and only the unbilled rows move. Raise the discount and every percentage milestone that has not yet been demanded re-spreads. Milestones already carrying a demand note are left exactly as they were billed.
The schedule freezes at approval, along with the price. Fix the milestones while the booking is still a draft.
This is the programme the site is working to.
The stages in your payment plan are not a separate sales list. They are the construction stages of the sub-project the tower is linked to — the same ones the planning engineer schedules and the site engineer reports progress against.
Because it is one file, "Foundation is complete" is not a phone call from the site to the sales office. It is a fact the sales screen can read.
How progress is recorded on siteThe slab is cast on Tuesday.
The demands are ready on Tuesday.
In most builders' offices this is a human being. Somebody at the site tells somebody in accounts that the foundation is done; accounts finds the payment plan; a clerk works out 15% of each agreement, adds the GST, types twelve letters and posts them. It takes a fortnight, and a fortnight of a crore is real money.
Civil Limitless already knows both halves. It knows the stage is complete, because the site reported it in Project Control. It knows which bookings are waiting on that stage, because the payment plan says so. So it puts them in front of you, priced, the same day.
Suggested and one-click — not silent. On purpose.
The app could raise those demand notes by itself. It deliberately does not, and this is worth saying plainly rather than hiding: a demand note is a financial document that goes to a customer. It carries a number, an amount, GST and a due date, and from the moment it exists it starts accruing interest against a person who has paid you lakhs. Nothing like that should leave your office without somebody looking at it.
So the app does the part machines are good at — noticing, calculating, grouping — and leaves the part people are good at exactly where it belongs. You can hold back the buyer who rang and asked for ten days. You can catch a stage that was ticked complete a week early. Then you press the button, and twelve notes take one second instead of one afternoon.
Press it twice by mistake and nothing happens the second time. Each milestone is stamped with the demand that billed it, so it can never be billed again.
Footing / Foundation reaches 100% on the villa the tower is linked to. Flat 101's 15% milestone — ₹6,00,000 — appears as ready with 5% GST added: ₹6,30,000. One click turns it into demand note DN-1-001, due in fifteen days, that booking's grace period. The same click covers every other flat in the tower waiting on that same stage.
Interest is never stored. It is worked out every time you look.
Each booking carries your own rate per year and your own grace days. From there the delay interest is a calculation, not a saved figure:
outstanding × rate ÷ 100 × whole days past the due date ÷ 365
It is recomputed on the demand register, on the receipt screen and on the printed note, so it is never a stale number somebody calculated last week. Part-pay the demand and the interest follows the smaller outstanding by itself.
- Waiving is instant and honest. It does not pause a clock — it sets that note's interest to zero everywhere at once, right back to the original due date. Un-waive and the whole figure returns, counted from that same date.
- Interest already collected stays collected. A waiver cannot reach into a receipt that was saved last month and take ₹4,000 back out of it.
- Or bill it formally. Raise Interest Debit Note freezes the accrued interest into its own numbered document, and stops the source demand accruing so the same money is never charged twice.
The arithmetic, on DN-1-001
The foundation demand of ₹6,30,000 was due on the 20th and the buyer pays on the 19th of the next month, at the 12% a year written on his booking.
Pre-filled on the receipt screen and fully editable — the cashier can take part of it, or zero it, without anybody editing a formula.
One warning the app writes down for you
A demand can read "interest waived" for two different reasons: you waived it, or you billed it as an interest debit note and the app waived the source so it would not be counted twice. Un-waiving the second kind would charge the buyer the same interest again. The guide inside the app says so at the switch, before you touch it.
Every rupee is tagged to the demand it settles.
Receipts are not a running pot of money that the app spreads around by itself. You say which demand this payment is against, and that is where it goes.
Recording a payment
Pick the demand and the box fills with its gross outstanding and the interest accrued to today — both editable, because the buyer rarely pays exactly what the letter said.
| On the receipt | What it does |
|---|---|
| Against demand | Only pending and part-paid notes are offered, plus "On account" |
| Amount | Part payment is normal — the note drops to part paid |
| Delay interest collected | Pre-filled from the live figure, editable to zero |
| TDS u/s 194-IA | Settles the demand and reduces his balance, but is not cash |
| Bank loan disbursement | Ticked, it separates the bank's money from his own |
| Mode and reference | NEFT, cheque, UPI, cash — with the UTR or cheque number |
A refund is a negative amount. On a cancelled booking that is the only thing the screen will accept.
- An on-account receipt is honest about itself. It lowers the buyer's balance but leaves every demand still showing outstanding and still building interest, because you did not say which one it settles. The screen tells you that rather than guessing.
- A whole bank statement at once. Bulk Receipt Entry is a grid — booking, demand, amount, TDS, date, mode, reference. Blank lines are skipped, and the result line says how many were saved and why the rest were not.
- The status is derived, never typed. A demand is paid once receipts plus TDS cover its amount and its GST, part paid when something has come in, pending when nothing has. Nobody can mark a demand paid by hand.
- A wrong entry can be pulled out. Delete the receipt and the outstanding, the balance and the interest all move back in the same breath — interest that the payment had suppressed reappears, counted from the original due date. The deleted row is kept in the Recycle Bin.
What you can hand over or file
Receipt voucher, buyer ledger as a PDF and as an Excel with live totals, the demand register, the collection register of every receipt with its mode and reference, the bookings register with a totals row, the brokerage register, and a RERA quarterly extract — three sheets for the current quarter covering tower-wise inventory, the quarter's bookings and the quarter's realisations.
Every report the app printsBrokerage is booked the moment the deal is approved.
Each partner has a profile — firm, RERA number, PAN, bank account and a default brokerage percentage. When a booking he brought is approved, the brokerage is worked out on the agreement value and becomes a liability that same moment. It is not a note in a diary that gets settled from memory at Diwali.
- The rate is fixed at approval. The booking's own percentage is used, falling back to the partner's default as it stood on that day. Change his default next year and brokerage already accrued does not move.
- A payout is net plus TDS. You enter what you actually paid him and the TDS u/s 194-H you withheld separately; together they consume the due. GST is added only when he has raised a GST invoice.
- Tag it to the deal. The dropdown shows each of his bookings with its own remaining due, so a part payment against one flat is visible on that row. A general payout still reduces his overall balance.
- He cannot be deleted while he has live bookings — the brokerage on them depends on the record. Set him Inactive instead.
Every meeting and call with a partner is logged the same way a lead's is, so the relationship has a written history and not just a WhatsApp thread.
One partner's ledger
2% agreed on Tower A. The buyer's ₹40,00,000 booking is approved, and ₹80,000 becomes due that day.
The brokerage register exports the same lines for every partner — bookings, due, gross paid, TDS, GST and the balance — so it reconciles against what is on the screen, line for line.
09 · The buyer's home loan
His bank, the sanctioned amount and the loan account number sit on the booking, and unlike the prices they stay editable after approval — because a bank revises a sanction and a builder should not have to cancel a deal over it.
From those details the app prints the consent-to-mortgage letter — the NOC the bank asks for before it releases anything.
Ticking the loan box on a receipt moves that money from the buyer's column into the bank's column. It does not change the total received or the balance by a single rupee — it only tells you where the money came from, which is exactly what you need when a disbursement is late.
The possession letter will not print until both gates are clear.
Handing over a flat with money still outstanding, or with the buyer's snag list unfinished, is how a builder ends up chasing a man who already has the keys. So the app refuses to print the letter until the balance is zero and every snag point has been ticked off — and it says which of the two is stopping it.
- The snag list is live. Type a point during the buyer's walk-through and press Add — it is saved at once, no separate step. Tick it when it is fixed and the date it was cleared is stamped on it.
- A new snag re-locks the gate. Add "balcony door alignment" to a fully paid booking and the possession letter is held again until it is fixed. That is the correct behaviour, even when it is the inconvenient one.
- The other letters are not gated. The allotment letter goes out after approval and the bank NOC whenever he applies for his loan.
- Then registration. Mark Registered records the sale deed and turns the flat from Booked to Sold on the inventory grid — where it stays, in the record, for the rest of the project's life.
Handover, checked
He is paying for a flat he cannot see yet. Tell him where it has reached.
Everything above is your side of the desk. This is his — and it is the reason the construction link is worth the trouble. His payment schedule is not a list of dates somebody made up; it is a list of things that will physically happen to his building.
A schedule tied to real work
At booking he takes home a cost sheet, a payment schedule and the agreement for sale. His instalments are named Foundation, Superstructure, Finishing — not "Instalment 3". He knows what has to be built before he is asked for money again.
A demand that explains itself
The note names the milestone, shows the GST, lists anything already received against it, prints the delay interest line in words he can check — "30 days @ 12% p.a." — and closes with his account summary. It arrives the week the work was done, which is the only time it makes sense.
A receipt for every payment
Amount, delay interest collected and TDS shown separately, so nothing is bundled into one number he has to take on trust. And a tax invoice with CGST and SGST when he or his bank asks for the statutory document.
A ledger that balances
Every demand and every receipt with a running balance, as a PDF or an Excel. When he calls at 9 pm asking what he still owes, the answer takes fifteen seconds and it is the same answer tomorrow.
A complaint that does not get lost
Buyer queries are a register, not a WhatsApp message — subject, category, who it is assigned to, and Open, In Progress, Resolved or Closed. Closing one needs a written answer; the box will not accept an empty resolution.
And the keys, properly
His snag list, ticked off point by point with the date each one was fixed. Then the possession letter, then registration. Nothing about the handover depends on what anybody remembers.
The developer's view, on one dashboard
Units available against booked and sold, collection this month against what has been demanded, overdue money with the interest accrued on it, and the demandable figure — how much you could ask for today, because the site has already earned it.
Beside it, the funnel from enquiry to booking, and how each executive and each channel partner is performing.
An illustration of the dashboard's own KPI strip — on your projects it reads your figures.
Bring one tower and one payment plan.
Thirty minutes on a call. We will set the tower up, link it to the construction, complete a stage, and raise the demand notes off it while you watch.