8. Invoicing, revenue, close-out and lessons

Back to the case study · Previous: 7. Changes, risks and keeping the client informed

8.1 Milestone invoices (Billing tab)

Each instalment is invoiced when its sign-off happens. On the Billing tab, for the line:

1. Tax %: 0 (export under LUT).
2. Mark it Ready once the client has signed. OSERP will not invoice a milestone whose step is not complete or marked Ready.
3. Raise invoice: a sales document for Klipvallei, tagged to the project and the sign-off step.
4. In the Unified Sales Workspace, advance it to Invoice. Set its Due date to 21 days after the invoice date, because that is what the terms say.
5. When the client's SWIFT transfer arrives, advance it to Payment with the bank reference.

Invoice	For	Date	INR	Paid
INV-2026-00001	Advance on signing (20%)	29 Apr	3,40,000	8 May
INV-2026-00002	Blueprint signed off (15%)	5 Jun	2,55,000	25 Jun
INV-2026-00003	Build complete (20%)	24 Jul	3,40,000	14 Aug
INV-2026-00004	UAT signed off, apps live (20%)	21 Aug	3,40,000	10 Sep
INV-2026-00005	Go-live (15%)	1 Sep	2,55,000	22 Sep
INV-2026-00006	Change order CO-001	25 Sep	1,50,000	open
INV-2026-00007	Project closure after hypercare (10%)	30 Sep	1,70,000	open
Total			18,50,000	15,30,000 paid

The Billing tab will not let the total go past the contract value. Advances are included in that limit, so the only way to invoice more is an approved change order.

The client sees the same invoices, with their balances, on the Account tab of the portal:

Set the due date on every invoice

INV-2026-00006 shows as Overdue to the client because its billing line's due date was the invoice date itself. The other invoices show no due date at all. Enter the due date from the agreed terms (21 days) when you advance each invoice. The client then sees the right status, and Accounting > Customer Dues chases the right invoices on the right day.

8.2 Revenue by progress (Progress & revenue tab)

An invoice is a request for payment. Revenue is earned by doing the work. On a fixed-price project the two rarely move together: the advance is billed before any work, and the closing 10% after it. OSERP measures revenue by progress (IFRS 15 / Ind AS 115).

At each month end:

1. Record progress: Method Cost to cost, Forecast cost at completion (what the whole job will cost, as you see it today), and the Reading date. OSERP divides the cost so far by the forecast. That gives the percentage complete.
2. Recognise this period: OSERP compares earned to date (percentage x contract value) with what is already in revenue from the invoices, and posts only the difference. Revenue is never counted twice.

Month end	Cost so far	Forecast cost	Complete	Earned to date	Billed to date	Recognised this period
31 May	1,88,350	12,10,000	15.57%	2,64,690	3,40,000	-75,310
30 June	4,40,275	12,10,000	36.39%	6,18,630	5,95,000	+98,940
31 July	8,87,400	12,97,000	68.42%	12,65,770	9,35,000	+3,07,140
31 August	12,20,500	13,02,000	93.74%	17,34,190	12,75,000	+1,28,420
30 September	12,96,700	12,96,700	100%	18,50,000	18,50,000	-4,59,190

Earned to date is the percentage complete times the contract value at that date (17,00,000 until CO-001, then 18,50,000). In May the advance ran ahead of the work, so 75,310 of the advance was held back from revenue as billed in advance. From June to August the work ran ahead of the invoices, so revenue was recognised before it was invoiced. In July the forecast went up by 87,000: CO-001 (53,000) and the courier rework.

In September the go-live, change order and closure invoices (5,75,000 in one month) ran ahead of the work done that month, so the recognition run took the excess back out of revenue. This is the method working: the September invoices did not inflate September's profit. The posted runs show September twice: the first reading used a forecast of 12,97,100 (99.97%, -4,59,745), and a final reading at the actual cost of 12,96,700 took the job to exactly 100% and recognised the last 555.

Raise the forecast when you know

Cost to cost is only as good as the forecast. When the courier rework and CO-001 appeared in July, Meera raised the forecast at once. Leaving it at 12,10,000 would have shown the job further along than it was, and taken revenue for work not yet done.

8.3 Earned value (Performance tab)

Measure	Value	Meaning
Budget at completion (BAC)	12,63,000	The budget, including CO-001
Earned value (EV)	12,63,000	Budget x % complete
Actual cost (AC)	12,96,700
Cost performance (CPI)	0.97	97 paise of planned work for every rupee spent. Green: within 5% of plan.
Schedule performance (SPI)	1.00	On time. Go-live on 1 September, as baselined.
Cost variance	-33,700	The extra hours less the travel saving (chapter 5)

During the project, a CPI that drops below 0.95 is the early warning. It turns amber, and then red below 0.85.

8.4 Close-out

1. Overview > Move to Technically complete after hypercare. The project still accepts cost, because a late supplier bill belongs to the job, but no new commitments.
2. When the last two invoices are paid: Move to Closed. A closed project accepts nothing, which stops next year's work landing on a finished job.
3. Settlement (optional for this type): moves the project's collected cost to cost of sales on the Settlement tab, if your accounts keep project costs there.
4. Projects > Reports: the Portfolio shows every project's contract, budget, cost, revenue, margin and what each client still owes. Billing, Change orders and Revenue recognition give the detail behind them.

8.5 The profit bridge

	INR	Where it came from
Planned profit at signing	4,90,000	17,00,000 less the 12,10,000 budget (28.8%)
The Courier Guy's API change	-22,800	24 hours, not billable (chapter 7)
UK importer feed, second round	-11,400	12 hours
First iOS submission rejected	-7,500	10 hours
Travel under budget	+8,000	1,52,000 against 1,60,000
Margin on change order CO-001	+97,000	1,50,000 price less 53,000 cost, approved before work
Actual profit	5,53,300	29.9% of 18,50,000

The three overruns came from the riskiest parts of the scope, the integrations and the App Store. That is why chapter 1 priced customization and integrations well above the standard work.

8.6 What made the difference

#	Control in OSERP	Chapter	What it protected or added
1	Price built from the work plan, with customization and integrations priced on their own	1, 4	A price that carries its own risk; nothing to renegotiate when a connector misbehaves
2	Exclusions and an optional item in the agreement	4	No argument about third-party fees or support after hypercare
3	20% advance, then payments tied to sign-offs	4, 8	The client's money ahead of the partner's costs throughout
4	Hours costed monthly to the step they were spent on	5	Each overrun visible on its own step in the month it happened
5	Purchases tagged to the project and the step, with GSTINs right	5	Subcontract and travel cost on the right budget line; 23,760 of input credit claimable
6	Change orders priced and approved before work	7	97,000 of margin; the overrun absorbed more than twice over
7	RAID with owners and dates	3, 7	Load-shedding, App Store and excise risks handled before they cost money
8	Revenue by progress with an honest forecast	8	The true margin every month, not only at the end
9	The client portal	2, 7	Updates, documents and invoices in one place for the client, without weekly status calls

8.7 Checklist for your own implementation project

Before you price

• Break the work into steps; ask each consultant for their own hours.
• Cost the team at real cost rates. List every purchase with the step it serves.
• Price standard work, customization and integrations separately, and price the last two for their risk.

In OSERP, before the work starts

• Company: export print line, GST state, Projects and Budget switched on.
• Client (with country and currency) and suppliers (with GSTIN and state).
• Every consultant an employee, so their hours can be costed.
• Project: type IT / software implementation, customer, manager, dates.
• Structure: one step per priced item; sign-offs for each payment; owners on phases.
• Schedule: dates, links, Set baseline.
• Team: cost and bill rates for everyone.
• Agreement: scope in parts, exclusions, options, payment schedule tied to sign-offs, terms. Issue, accept, Apply to the billing plan.
• Move to Released; budget on every step; raise the advance.

Every month

• Timesheets sent and approved; Post labour cost up to the month end.
• Purchases through purchase order, bill and payment, tagged to the project and step.
• Read the Budget tab; raise the forecast; Record progress and Recognise this period.
• Update the RAID log; publish a client update.
• Price every new request as a change order before doing it.

At the end

• Invoice each sign-off with its due date.
• Technically complete after hypercare; Closed once paid.
• Offer the support contract (the optional line in the agreement).

8.8 Exercises

1. A courier bill. Nimbus receives a bill from a courier for sending signed documents to Stellenbosch: INR 2,400 + 18% GST. Where does it go, and what does the project show?
2. A rate rise. Sanjay's cost rate goes from 950 to 1,050 on 1 August. What do you change, and what happens to the hours he booked in July?
3. An extra request. In August the client asks for a second card machine at the tasting room, to be set up and tested. It needs about 6 hours from Rahul. What do you do?
4. A slipping forecast. At the end of June the integrations look like taking 60 more hours than planned. What do you change on the Progress & revenue tab, and what does it do to June's revenue?

Answers

1. Purchasing > Unified Purchase Workspace: a purchase (request, order, bill, payment), vendor the courier, 2,400 at 18%, Project KLV-ERP-2026 and WBS element 1.9.1 Project management and governance. The project's cost rises by 2,400. The 432 GST goes to input credit, not to the project.
2. Team & time: end Sanjay's line on 31 July and Add to team a new line for him from 1 August at 1,050. His July hours keep the 950 rate, because a rate change applies from its date and past time is never revalued.
3. Changes: a change order (for example 6 h x 1,800 bill rate = 10,800, cost 6 x 800 = 4,800), Submit, approve once the client agrees, add a billing line, then do the work. Doing it first and asking later is how the 97,000 in this case study would have been 0.
4. Record progress with the forecast cost at completion raised by 60 x 950 = 57,000. The same cost is now a smaller share of a bigger total, so the percentage complete falls, and the recognition run takes correspondingly less revenue in June. Profit is no longer overstated.