The $40,000 implementation that booked $55,200 of revenue: revenue recognition for project managers
Revenue follows what the customer gets, not what they pay or what sales booked. Why a discounted implementation carries more revenue than its price, why a services PM's progress reports move the income statement, and why every change order is a revenue event.
Revenue is the most important number in most companies' financial statements, and the one most often misstated. Investors value software companies largely on revenue growth. Managers are paid on it. Salespeople are motivated by the bookings that eventually become it.
Most project managers assume revenue is someone else's problem. It isn't. In services, product launches and pricing changes, project decisions change revenue directly: an acceptance clause, a free month, a change order, a revised estimate of hours. This is one of the places where the MBA core and day-to-day project management meet, and it's taught in week 11 of the program.
The rule in one sentence
Since 2018, US public companies have recognized revenue under ASC 606 (IFRS 15 internationally), a single model that replaced more than a hundred pieces of industry guidance. Its core principle: recognize revenue to depict the transfer of promised goods or services to customers, in the amount the company expects to be entitled to in exchange.
The five steps
- Identify the contract. Approved, with each party's rights and payment terms, commercial substance, and probable collection. Contracts negotiated together may need combining; changes to scope or price are modifications.
- Identify the performance obligations. Each distinct promise: the customer can benefit from it on its own, and it isn't significantly integrated with other promises. SaaS is a series of daily service periods treated as one obligation. Implementation any qualified partner could perform is usually distinct.
- Determine the transaction price. Including variable consideration (discounts, rebates, SLA service credits, usage fees), constrained to what's highly probable not to reverse.
- Allocate the price to obligations in proportion to their standalone selling prices: what each would sell for on its own.
- Recognize revenue when or as each obligation is satisfied: over time (the customer consumes the benefit as you perform, or you're enhancing an asset the customer controls, or you're building something with no alternative use and have a right to payment) or at a point in time.
Worked example: a bundle at Larkspur
Larkspur Freight Software is the book's fictional $140M-ARR case company. On 1 March it signs a customer for a two-year subscription covering 600 vehicles, plus implementation and on-site training. The subscription is invoiced annually in advance; implementation and training are invoiced on completion.
| Obligation | Contract price | Standalone selling price | % of SSP | Allocated revenue |
|---|---|---|---|---|
| SaaS subscription, 24 months | 480.0 | 504.0 | 87.5% | 463.8 |
| Implementation | 40.0 | 60.0 | 10.4% | 55.2 |
| Training | 10.0 | 12.0 | 2.1% | 11.0 |
| Total | 530.0 | 576.0 | 100% | 530.0 |
The $46k discount from standalone prices is allocated proportionally across the bundle. Subscription: recognized ratably, $19.3k a month. Implementation: over time, measured by hours (60% complete at 31 March → $33.1k in March, the rest in April). Training: at a point in time when delivered in April.
Here's the counterintuitive result. The implementation was priced at $40k, but it carries $55.2k of revenue, because the discount belongs to the whole bundle, not to the line the salesperson happened to discount. Since implementation and training are delivered early, the allocation also pulls revenue forward:
| Year 1 | Year 2 | Total | |
|---|---|---|---|
| Billed | $290.0k | $240.0k | $530.0k |
| Revenue recognized | $298.1k | $231.9k | $530.0k |
Same contract, same total, different timing. The differences between billing and revenue sit on the balance sheet.
Contract balances: where the timing differences live
| Balance | When it arises |
|---|---|
| Contract liability (deferred revenue) | The customer has paid, or been billed with an unconditional right to payment, before the company performs |
| Contract asset | The company has performed but its right to payment is conditional on something other than time, such as a later milestone |
| Receivable | An unconditional right to payment |
| Remaining performance obligations (RPO) | Contracted revenue not yet recognized, billed or not; the current portion (cRPO) is closely watched for subscription companies |
Services: where the project manager's numbers become revenue
Harbor, the book's fixed-price migration for Meridian Bank, was billed on four milestones, each requiring the customer's formal acceptance within five business days (with passive acceptance if they didn't respond):
| Milestone | Value | Share | Acceptance evidence |
|---|---|---|---|
| M1 Design and wave plan | $84,000 | 20% | Signed acceptance notice |
| M2 Pilot complete | $105,000 | 25% | Signed acceptance; pilot report |
| M3 Production waves complete | $147,000 | 35% | Signed wave reports 1–3 |
| M4 Training and handover | $84,000 | 20% | Signed acceptance notice |
For billing, acceptance is everything: no signed acceptance, no invoice. But for revenue, the question isn't when invoices go out. Migration work on Meridian's own GitLab environment enhances an asset Meridian controls, so revenue is recognized over time, typically measured by hours incurred against total estimated hours. Three consequences follow, and all of them run through the PM's reports:
- When progress runs ahead of milestones, revenue exceeds billing and the difference is a contract asset (unbilled revenue).
- When a milestone is billed before the matching work is done, the difference is deferred revenue.
- When estimated total hours rise, the measure of progress falls and revenue already recognized is adjusted with a cumulative catch-up. On a fixed fee, overruns reduce margin directly; if total expected costs exceed the fee, the whole expected loss is recognized immediately.
That's why the book's rule for services PMs is simple: report progress accurately and early. A revised estimate to complete isn't just a project fact. It changes revenue the company has already reported.
Every change order is a revenue event
When Meridian bought a subsidiary and asked GitLab to migrate 2,000 more repositories, the change order (CO-1, $96,000) raised an accounting question before it raised a delivery one. Was it a separate contract, or a modification of the existing one?
Because it added distinct services (migrating different repositories) at prices consistent with standalone selling prices, it was accounted for as a separate contract with its own progress measurement. Had the repositories been added at a deep discount, or had the change altered the original scope in ways that weren't distinct, the answer would have been a termination-and-new-contract or a cumulative catch-up on the combined contract. This is why services change orders are reviewed by revenue accountants.
The questions a project manager should raise
| Situation | Question to raise | Why |
|---|---|---|
| New SKU or add-on | Is it a separate performance obligation? What's its standalone selling price? | Allocation and timing of revenue |
| Bundled discount | How is the discount allocated? | Revenue per element differs from price per element |
| Usage- or outcome-based pricing | How is variable consideration estimated and constrained? | Revenue may lag billing |
| Customer acceptance clauses | Do they delay transfer of control? | Revenue may wait for acceptance |
| Services with customization | Distinct from the software or not? | Combined obligations change timing |
| Change order | Separate contract or modification? | Catch-up adjustments; margin |
| Fixed-fee overrun | Measure of progress? Loss contract? | Revenue adjustments; expected loss recognized immediately |
| Partner or marketplace sale | Principal or agent? | Gross versus net revenue |
| Free months, credits, SLA credits | Variable consideration or consideration payable to the customer? | Reduces the transaction price |
The most dangerous of these is the third. A friendly “sure, we'll include the extra training” in an email to a customer can create a new performance obligation, change the allocation of the whole contract, and become a restatement. Never promise customers anything outside the contract.
How students practice this
Week 11 pairs leadership and conflict with the financial accounting core: double entry, the three financial statements and revenue recognition. Students post Larkspur's bundle through all five steps in a spreadsheet they build themselves, then reconcile Harbor's milestone billing against progress-based revenue and explain the contract balances to a “CFO” in a two-minute Loom.
Adapted from Projects, For Real, chapters 69 and 97. The projects, people, vendors and numbers are the book's fictional case studies, set against GitLab's publicly documented practices. Gantt Guild is not affiliated with GitLab Inc.
