The contract was clear enough when it was signed: 20% on mobilization, 25% on design approval, 35% on user acceptance, 20% on go-live. Eight months later, the software house's finance manager is scrolling through email threads trying to establish whether the design was ever formally approved, the project lead insists UAT finished "weeks ago", the client's accounts department says it never received an invoice for either, and the company has quietly financed over NPR 14 lakh of delivered work with its own overdraft. The payment schedule existed. What never existed was a system connecting work completed to invoices raised.
Milestone billing Nepal service companies rely on - in IT, consulting, engineering, and design - is the standard structure for project contracts, and for good reason: clients pay for demonstrated progress, and providers get cash through the life of the project instead of one terrifying invoice at the end. But the model only works when three links hold: milestones defined precisely enough to be verifiable, completion tracked and approved somewhere authoritative, and invoicing triggered the moment approval lands. Break any link and the payment schedule becomes decoration on a contract nobody re-reads.
This article works through the full chain - choosing between milestone and time-and-material billing, defining milestones that trigger cleanly, generating invoices from approvals, and handling the two accounting questions milestone contracts always raise: retainers and revenue recognition. The worked example is a Nepali IT project, because delivery-tied payment terms are now the norm in contracts with banks, corporates, and government agencies alike.
Milestone Billing or Time-and-Materials - Choosing the Right Meter
The two billing models meter different things. Time-and-materials bills effort: hours worked at agreed rates, invoiced on a calendar cycle, with the client carrying the risk of how long the work takes. Milestone billing bills outcomes: fixed amounts released when defined deliverables are accepted, with the provider carrying the delivery risk. Neither is universally better - the choice follows the shape of the work and the trust between the parties.
Milestone billing fits when scope can be defined up front and the client needs budget certainty: a system implementation, a building design, a compliance audit with a known report at the end. It is also, practically speaking, what many Nepali clients will insist on - procurement committees and boards approve fixed amounts against named deliverables far more readily than open-ended rate cards. Time-and-materials fits when scope is genuinely unknowable - exploratory development, ongoing support retainers, staff augmentation - and demands the timesheet discipline to back every invoice with an hour-level schedule.
The hybrid is common and legitimate: a fixed milestone schedule for the core delivery, plus a time-and-materials rate card for change requests beyond the agreed scope. That structure protects the provider from the classic milestone trap - unlimited revision cycles inside a fixed price - while giving the client a predictable core cost. Whatever the mix, it must be written into the contract before work starts; a billing model renegotiated mid-project is a dispute with paperwork.
Milestone billing meters outcomes and suits defined scope with budget-conscious clients; time-and-materials meters effort and suits open-ended work backed by timesheets. The strongest Nepali contracts combine both - fixed milestones for the core, a rate card for changes.
Defining Milestones That Actually Trigger - A Worked Schedule
A milestone earns its place in a contract only if a reasonable person can say, without argument, whether it has happened. Each one needs four elements: a named deliverable, written acceptance criteria, an identified approver on the client side, and its payment value. Here is the schedule for our worked example - a Kathmandu software house building an inventory system for a trading company at NPR 24 lakh: Milestone 1, contract signing and mobilization, 20% - NPR 4.8 lakh, due on signature. Milestone 2, approved system design document, 25% - NPR 6 lakh, accepted by the client's IT head within ten working days of submission. Milestone 3, user acceptance testing complete, 35% - NPR 8.4 lakh, triggered when the agreed UAT script passes and the sign-off sheet is countersigned. Milestone 4, go-live and handover, 20% - NPR 4.8 lakh, on production deployment plus delivery of documentation and training.
Notice where the precision concentrates: the UAT milestone - the largest payment - is defined by a countersigned script, not by the feeling that testing went well. That is deliberate. Vague milestones fail exactly in proportion to their value, because the more money a trigger releases, the more incentive exists to debate whether it fired. The ten-day acceptance window on the design milestone matters too: without a deemed-acceptance clause, a silent client can park a milestone - and its payment - indefinitely.
Milestone structures dominate both ends of Nepal's project economy. Government contracts - IT systems, consulting assignments, engineering supervision - pay against deliverable-linked schedules, with the added reality that releases follow budget cycles and often cluster late in the fiscal year, so a provider's invoice may be approved long before it is paid. Corporate contracts with banks and trading houses increasingly copy the same delivery-tied structure, sometimes holding 10-20% as a retention released after a support period. Both patterns reward the same discipline: contemporaneous acceptance records and invoices raised the day the trigger fires, because in a payment queue, the invoice that arrived first and is documented best moves fastest.
Load the schedule into the project system on day one - milestones with values, criteria, approvers, and expected dates - so the payment plan lives where the work is tracked, not in a PDF nobody opens. That single act converts the schedule from a legal artifact into an operational one: every project review now shows delivery status and billing status side by side.
Every milestone needs a named deliverable, written acceptance criteria, a client-side approver, and a value - with the most precision spent on the largest payments. Add acceptance windows so silence cannot park your cash, and load the schedule into the system where work is actually tracked.
From Completion to Invoice - Closing the Gap Where Cash Leaks
The expensive gap in milestone billing is rarely the work and rarely the client - it is the dead time between a milestone being achieved and an invoice existing. In manually run firms, that gap is measured in weeks: the project team moves on to the next phase, nobody tells finance, and the invoice is eventually raised from memory during a cash squeeze. Every week inside that gap is interest-free credit extended to the client, financed by the provider's overdraft at commercial rates.
The systematic version closes the gap to a day. The project lead marks the milestone complete in the system and attaches the evidence - the countersigned UAT sheet, the acceptance email, the deployment note. An approval step confirms it: the project manager or a director reviews the evidence and approves the milestone, creating an auditable record that this trigger fired, on this date, on this proof. And that approval generates the invoice - pre-filled with the contract's milestone value, the client's details, and VAT at 13% - ready to issue the same day. In our example, the UAT approval on 12 Mangsir produces the NPR 8.4 lakh invoice (NPR 9,49,200 with VAT) on 12 Mangsir, not in Poush when someone remembers.
Attach the acceptance evidence to the invoice itself, not just the internal record. A milestone invoice that arrives with the countersigned UAT sheet, the acceptance email, and the delivery note answers the client's internal question - "did we actually approve this?" - before it is asked, and moves through their approval chain with nothing to query. In our experience, most late payments on milestone contracts in Nepal are not refusals; they are invoices waiting for someone on the client side to reconstruct the justification the provider could have supplied on page two.
The same record kills the other classic dispute: the client who, months later, questions whether a milestone was really done. A dated approval trail with attached sign-offs is not an argument - it is the end of one. Firms that run this chain consistently find their receivables aging improves for a reason that has nothing to do with collections effort: their invoices are simply harder to ignore and impossible to dispute.
The weeks between milestone completion and invoice issue are free credit you extend by accident. Close them to a day: completion marked with evidence, approved through a workflow, invoice generated from the approval - and send the acceptance proof with the invoice so the client has nothing to query.
Retainers and Revenue Recognition - The Accounting Behind the Schedule
Milestone contracts create money that has been received but not yet earned, and money that has been earned but not yet billed - and both need honest homes in the books. The retainer is the first case: a client pays an advance - our example's 20% mobilization payment functions as one - and that receipt is a liability, not revenue. The work has not happened; the money is, economically, still the client's. As milestones complete, the earned amounts either offset against the advance or bill on top of it, per the contract's structure, and the liability converts to revenue step by step. Firms that book advances as income on receipt overstate their profits in the quarter they sign deals and understate them in the quarters they do the work - a distortion that misleads exactly the decisions, like hiring and pricing, that depend on knowing when money is truly earned.
Revenue recognition is the same principle applied at reporting dates. Under the accrual principles Nepal Accounting Standards follow, revenue belongs to the period in which the work is performed and accepted - not the period the cash arrives. A well-run milestone schedule makes this almost mechanical: approved milestones are earned revenue; unapproved work in progress is not yet revenue; unearned advances are liabilities. Where a milestone spans a year-end, or a contract's substance is continuous service dressed in milestone clothing, the treatment needs judgment - discuss long-duration contracts with your auditor rather than defaulting to whichever treatment flatters the year.
At fiscal year close, three balances on milestone contracts attract auditor and IRD attention: advances received but unearned (liabilities, not income), milestones completed but uninvoiced (earned revenue with VAT and tax consequences), and work in progress on unfinished milestones. Booking these by cash movement instead of substance misstates both profit and tax. List every open project before Ashadh 31, classify each contract's position, and confirm the treatment with your auditor - reconstructing it in Kartik during the audit is always worse.
VAT deserves a final timing note: issuing a milestone invoice creates output VAT payable in that month's return, whether or not the client has paid. That is one more reason invoice timing should be a deliberate act driven by milestone approval - not an accident of when finance hears the news - and one more reason the approval record matters, since it documents why the invoice was raised when it was.
Advances are liabilities until milestones earn them, revenue belongs to the period the work is accepted, and every invoice creates VAT payable regardless of collection. A clean milestone record makes all three positions mechanical at year-end - and defensible in front of the auditor and the IRD.
Frequently Asked Questions
Use milestones when the scope is definable up front and the client values budget certainty - implementations, designs, audits, anything with a nameable end state. Use time-and-materials when scope is genuinely open - exploratory work, ongoing support, staff augmentation - and back it with disciplined timesheets, because every T&M invoice is only as defensible as the hour records behind it. In Nepal, milestone structures also match how clients approve spending: boards and procurement committees release fixed amounts against named deliverables far more readily than open rate cards. The practical best answer for many contracts is the hybrid - fixed milestones for the defined core, a rate card for change requests - which protects you from unlimited revisions inside a fixed price while keeping the client's core cost predictable.
Four elements, all in writing: a named deliverable, acceptance criteria a reasonable person can verify, an identified approver on the client side, and the payment value. Test each milestone with one question - could the client and I disagree about whether this has happened? "Development substantially complete" fails the test; "the attached UAT script executed with all critical cases passing, countersigned by the client's IT head" passes it. Two protective clauses are worth adding in Nepal's market: an acceptance window with deemed acceptance - if the client neither accepts nor rejects within the stated days, the milestone stands - and a clear statement of how rejection works, with specific defects listed and a re-submission cycle, so a milestone cannot be parked indefinitely by silence or by vague dissatisfaction.
As liabilities from the day they arrive. An advance is money received for work not yet performed - it sits in a client advances account, and converts to revenue only as milestones are completed and accepted, either by offsetting against milestone invoices or per whatever structure the contract specifies. Booking advances as income on receipt inflates the signing quarter and starves the delivery quarters, distorting every margin decision built on the numbers. Note the tax dimensions too: issuing a tax invoice creates output VAT payable in that month's return regardless of the accounting treatment of the underlying advance, and year-end positions on unearned advances and unbilled completed work affect taxable income - so classify every open contract before Ashadh 31 and confirm the treatment of long-running engagements with your auditor.
From Milestone Approval to Posted Invoice in One Motion
MISAC's accounting-first architecture is what closes the completion-to-cash gap this article describes. The unified approval chain covers project work items and vouchers alike: a milestone approved with its evidence attached flows straight into a sales invoice, and the moment that invoice saves, the complete double-entry posts itself - receivable, revenue, and the 13% VAT captured in the IRD-format register for that month's return. Advance receipts post as client liabilities, offset milestone by milestone, so the earned-versus-unearned position is simply what the ledger already says, at Ashadh 31 or any other date.
Custom fields shape the project structure to your contracts without a developer: milestone value, acceptance criteria, client approver, and due date as fields on the project record; document attachments holding the countersigned UAT sheets and acceptance emails against the exact transaction they justify; validation rules that stop an invoice being raised without an approved milestone behind it. Template-based printing then produces the invoice your client's procurement expects - configurable columns, signature lines, and a QR-signed original they can verify was never altered.
MISAC Intelligence Pvt. Ltd. has built billing and project systems for Nepali IT firms, consultancies, and contractors for over a decade. If your payment schedules live in contract PDFs while your overdraft finances delivered work, we would be glad to show you the connected version.
Ready to See MISAC in Action?
If completed milestones are waiting weeks for invoices at your firm, talk to us about billing that fires the day the work is approved.