Fixed-Fee Software Project Revenue Recognition: A Practical Reference

Key Takeaways

• Under ASC 606, fixed-fee software project revenue is recognized as performance obligations are satisfied — not when invoices are issued or cash is received.
• Percentage-of-completion is the standard method when a project is delivered over time and progress can be measured reliably.
• Three common progress measures are: hours tracked as a percentage of budgeted hours, hours as a percentage of estimated hours at completion (EAC), and milestone-based completion.
• Upfront billing creates deferred revenue (a liability); work delivered but not yet billed creates accrued revenue (an asset). Both appear on the balance sheet until resolved.
• Recognizing revenue based on invoices — the "billing-based trap" — is incorrect under ASC 606 and IFRS 15, and will cause margins to swing and auditors to ask hard questions.

Fixed-fee revenue recognition on a software project means recording revenue in proportion to the work delivered during each accounting period, not in proportion to the invoices sent. Under ASC 606, you recognize revenue when — or as — you satisfy a performance obligation. For most custom software development engagements, that obligation is satisfied over time, which makes percentage-of-completion the operative method.

The practical consequence: if a client pays 50% upfront on a $100,000 project and your team hasn't started yet, that $50,000 sits on your balance sheet as deferred revenue — a liability — until the work is done. Recognizing it as income on the day the wire clears is wrong, and it makes your financials unreliable for any decision that depends on margin or project profitability.

Why Billing-Based Recognition Fails Under ASC 606

The billing-based approach feels intuitive. A milestone is hit, an invoice goes out, finance books the revenue. The problem is that invoicing schedules are negotiated for cash-flow reasons, not because they track the delivery of value. As Birdview PSA notes, this is "the billing-based trap" — and it is explicitly wrong under both ASC 606 and IFRS 15.

Both standards share the same five-step framework:

1. Identify the contract
2. Identify the performance obligations
3. Determine the transaction price
4. Allocate the transaction price to each obligation
5. Recognize revenue as each obligation is satisfied

For a fixed-fee software project, step five is where the work happens. If the project is delivered over time — which custom development almost always is — revenue is recognized over time, in proportion to progress. The billing schedule is irrelevant to that calculation.

A peer-reviewed study on ASC 606 adoption found that the standard has generally increased the value relevance and informativeness of reported revenues. In plain terms: the numbers became more useful for decision-making. That is the point.

When Is Percentage-of-Completion Appropriate for a Fixed-Fee Software Project?

Percentage-of-completion is appropriate when three conditions hold: the project is delivered over time (not at a single point), progress toward completion can be measured reliably, and the total contract price and expected costs can be estimated with reasonable confidence.

Custom software development almost always meets these conditions. The studio is building something incrementally — sprints, modules, phases — and the client receives and controls the work product as it is produced. That is the definition of a performance obligation satisfied over time under ASC 606.

Contrast this with a perpetual software license, where the customer receives the full license at a point in time and revenue is recognized at that moment. For a fixed-fee development engagement, the work unfolds over weeks or months, so over-time recognition applies.

The alternative — recognizing the full contract value at project completion — is only appropriate when the project is genuinely delivered as a single unit at a single point in time, and the customer has no benefit from or control over work in progress. That is rare in custom software development.

How to Measure Progress Toward Completion

Progress measurement is where most studios run into practical difficulty. ASC 606 requires a method that faithfully depicts the transfer of control to the customer. Three methods are commonly used for fixed-fee software projects:

Method 1: Percentage of Budgeted Hours

This is the most common starting point. Revenue recognized in a period equals the contract value multiplied by the ratio of hours logged (and approved) to total budgeted hours.

Hypothetical illustration: Consider a fixed-fee project worth $120,000 with a 600-hour budget. In month one, the team logs 200 hours, but only 180 are approved. Progress is 180 ÷ 600 = 30%, so recognized revenue is $36,000. If the client was billed $60,000 upfront, the $24,000 difference between what was billed and what was earned becomes a contract liability — deferred revenue — on the balance sheet. As more approved hours accumulate, recognized revenue rises and the deferred revenue balance declines. (Source: Birdview PSA)

The key detail: only approved hours count. Logged hours that haven't been reviewed and accepted don't yet represent delivered value.

Method 2: Percentage of EAC Hours

The EAC (Estimate at Completion) method adjusts the denominator as the project evolves. Instead of dividing by the original budget, you divide by your current best estimate of total hours required to finish.

Hypothetical illustration: A project has an 80-hour budget and 76 hours allocated across resources. If 8 hours have been tracked, the budgeted-hours method gives 8 ÷ 80 = 10% complete. The EAC method, using 76 allocated hours as the denominator, gives 8 ÷ 76 = 10.5% complete — a small difference early in the project, but one that compounds as scope shifts. (Source: Rocketlane)

The EAC method is more accurate when scope changes are common, because it incorporates your current view of total effort rather than locking in an initial estimate that may no longer be valid.

Method 3: Milestone-Based Recognition

Milestone-based recognition ties revenue to the completion of defined deliverables — a discovery phase, a working prototype, a module handoff, a final deployment. Each milestone represents a discrete performance obligation or a measurable portion of a single obligation.

Hypothetical illustration: A $100,000 project is structured around four modules: Inventory, Orders, Purchasing, and Shipping, delivered over six months. The client pays 30% at the start, 30% when Orders is complete in month three, and 40% at the end. Each module is assigned a revenue value based on its relative effort. Revenue is recognized as each module is completed and accepted — not when the invoice is issued. By month two, the studio may have completed $75,200 worth of work but billed only $60,000, leaving $15,200 of accrued revenue on the balance sheet: money earned but not yet invoiced. (Source: ITM Platform)

Milestone-based recognition works well when deliverables are clearly defined and client acceptance is documented. It breaks down when milestones are vague or when the client's sign-off process is slow — because you cannot recognize revenue for a milestone the client hasn't accepted.

Deferred Revenue and Accrued Revenue: What Appears on the Balance Sheet

Fixed-fee projects almost always create timing mismatches between billing and earning. Understanding what those mismatches look like on the balance sheet is essential for a clean monthly close.

Deferred revenue (a liability) arises when you bill more than you've earned. The client has paid; you haven't yet delivered the corresponding value. The deferred revenue balance declines as work is completed and revenue is recognized.

Accrued revenue (an asset, sometimes called unbilled receivables) arises when you've delivered more than you've billed. You've earned the revenue; the invoice hasn't gone out yet. This is common in the middle of a project when billing milestones lag behind actual progress.

Both balances need to be calculated and recorded at every monthly close. If your close process doesn't include a project-by-project revenue recognition schedule, these balances will be wrong — and your P&L will be wrong with them.

For a deeper look at how unbilled revenue is recorded and managed, see Consulting WIP Accounting: How to Record and Manage Unbilled Revenue.

The Revenue Recognition Cap and Project Completion

One practical rule that applies regardless of method: recognized revenue cannot exceed the fixed fee. If a project runs over budget — more hours than planned — you do not recognize more than the contract value. The excess cost is a margin problem, not a revenue opportunity.

As Rocketlane's documentation states: "The revenue that can be recognized is limited to the fixed fee, with a maximum cap of 100%." When a project is marked complete, if recognized revenue is still below 100% of the contract value, the remaining amount is recognized on the completion date.

This matters for studios that run over on hours. The over-run shows up as a cost, compressing margin — but it does not inflate revenue. Keeping those two things separate is what makes project-level profitability visible.

What a Clean Monthly Close Looks Like for Fixed-Fee Projects

A reliable monthly close for a software studio with fixed-fee projects requires a revenue recognition schedule that is updated every period. At a minimum, that schedule should capture:

• Contract value for each active project
• Progress percentage as of the close date (using whichever method applies)
• Revenue recognized in the current period
• Cumulative revenue recognized to date
• Deferred revenue balance (if billed ahead of earned)
• Accrued revenue balance (if earned ahead of billed)

Without this schedule, your P&L reflects billing activity, not delivery activity. The two can diverge significantly on a project-by-project basis, and the aggregate distortion makes it impossible to know whether the business is actually profitable in a given month.

For a template that structures this process, see the Month-End Close Calendar Template. For a broader look at what outsourced accounting for software studios covers, including project accounting, see Outsourced Accounting for Software & Web Studios.

Frequently Asked Questions

How is revenue recognized on a fixed-fee software project?

Revenue on a fixed-fee software project is recognized as work is delivered, not when invoices are issued. Under ASC 606, you calculate the percentage of the project completed each period and recognize that proportion of the total contract value. Billing timing is irrelevant to the recognition calculation.

When is percentage-of-completion appropriate for a software project?

Percentage-of-completion applies when the project is delivered over time, progress can be measured reliably, and total costs and contract value can be estimated with reasonable confidence. Custom software development almost always meets these criteria, making over-time recognition the standard approach under ASC 606.

What is the difference between deferred revenue and accrued revenue on a software project?

Deferred revenue is a liability that arises when you bill more than you've earned — the client has paid, but the work isn't done yet. Accrued revenue is an asset that arises when you've delivered more than you've billed. Both appear on the balance sheet and must be reconciled at every monthly close.

Can recognized revenue exceed the fixed-fee contract value?

No. Recognized revenue is capped at 100% of the fixed fee regardless of how many hours the project actually takes. Cost overruns compress margin but do not increase revenue. Any hours worked beyond the budget are a profitability problem, not an additional revenue event.

Laya provides this content for informational purposes only. This material does not constitute tax, legal, or accounting advice. Please consult your own tax, legal, and accounting advisors before engaging in any transaction.

If your studio's monthly close doesn't include a project-by-project revenue recognition schedule, your P&L is likely misstating margin. Book an intro with Laya to see what a clean close looks like for fixed-fee software projects.