A kisti schedule is not a list of dates and amounts. It is a set of rules — a price, a payment plan, a start date, milestone links and adjustment logic — from which dates and amounts are produced. That distinction is the whole difference between a schedule you can maintain for 300 buyers and a spreadsheet that quietly diverges from reality within a quarter.
A worked example
A 1,400 sq ft flat in Uttara at BDT 11,000 per sq ft, total BDT 1,54,00,000, on a 60-month plan:
| Head | Basis | Amount (BDT) |
|---|---|---|
| Booking money | Fixed | 5,00,000 |
| Down payment | 25% of price, less booking money | 33,50,000 |
| Monthly kisti | (Price − 25% − milestones) ÷ 60 | 1,54,000 × 60 |
| Milestone: topping out | 5% of price | 7,70,000 |
| Parking | Fixed, one slot | 8,00,000 |
| Utility and connection charges | At actuals, billed before handover | Estimated 4,50,000 |
Two observations. The monthly figure is derived, not typed — change the price by BDT 200 per sq ft and every one of the 60 rows moves. And parking and utility charges sit on the same ledger, because a buyer asking "what do I owe" means everything, not just the flat.
The four ways the spreadsheet version fails
1. It stops matching the agreement. A discount is agreed, the schedule is edited, and nobody updates the signed plan. At registration, the two documents disagree and the buyer's version is the one in writing.
2. Receipts are entered against the wrong row. A buyer pays two instalments at once, someone marks the wrong month, and the ageing report is wrong from then on — usually in the direction that hides a problem.
3. Restructures overwrite history. The original terms are gone, so a dispute two years later has no record of what was agreed when.
4. Nobody can produce a ledger. The buyer asks for a statement, and someone spends an hour assembling one from three tabs. Whatever they produce is not reproducible, which means it is not evidence.
What the schedule needs to know
- The price and its components, including any discount and who approved it. See price lists and discount control.
- The payment plan as a named, approved template, so a buyer's plan can be identified rather than described.
- The milestone links, if any, so instalments are raised on certified progress rather than dates. See milestone billing.
- The allocation rule for partial payments and the treatment of excess.
- The restructure history, so the current schedule can always be traced back to the signed one.
The three views that come free
Once the schedule is rules rather than rows, three reports fall out of the same data instead of being maintained separately: the buyer ledger, the due list for a given month, and the ageing report. That is the practical test of whether a schedule is properly modelled — if those three can disagree with each other, they are three files, not three views.
Restructuring, done properly
Restructures are normal. A buyer loses a job, an NRB buyer's remittance schedule changes, a delay makes the original plan unreasonable. The controls that keep them safe are simple: a documented reason, an approver above the person negotiating, a new schedule that starts from the outstanding balance rather than from scratch, and the old one retained. Done this way, a restructure protects both sides. Done as a spreadsheet edit, it protects nobody.
What to do next
Take three buyers at random and ask your team for a one-page ledger showing every charge, every receipt and the current outstanding for each. If they cannot produce all three in five minutes, your schedule lives in a spreadsheet even if you believe it does not — see what a rule-based schedule looks like.