What is Revenue Recognition
Revenue recognition is an accrual accounting principle that revenue be recognized as it is earned. Meaning even if payment is made later, the revenue should be recognized when the goods or services are delivered to customers.
For businesses where revenue is earned over time across a project or service the most common approach is the percentage-of-completion method. The idea is straightforward:
You recognize revenue in proportion to how far along you are on a project. If you’ve incurred 40% of the estimated costs on a $500,000 project, you recognize $200,000 in revenue.
The formula:
Revenue Recognized to date = (Actual costs to date ÷ Total estimated project costs) × Total estimated revenue
Clean in theory. Harder to execute.
But it’s important. Proper revenue recognition is an essential part of accurate financial reporting.
Public companies in the U.S. are required to follow GAAP. Private companies aren’t, but if you’re looking to raise capital, bring on investors, or get acquired, expect to be held to the same standard. Lenders and buyers want GAAP-compliant financials. It’s not a legal requirement until it is.
Accrual vs. cash accounting
Two ways to keep the books. Only one tells you what’s actually happening in your business.
Cash basis is simple: money in, record it. Money out, record it. If a client pays you in December for work you did in October, December gets the revenue. Easy to track. Easy to understand. And for most businesses past a certain size, a distorted picture of financial reality.
Accrual basis matches revenue to the period it was earned and expenses to the period they were incurred, regardless of when cash moves. You deliver a project in October, you book the revenue in October, even if the invoice isn’t paid until December. Same logic on the cost side. This is how GAAP works, and it’s what lenders, investors, and acquirers expect to see.
Cash vs. Accrual Accounting: Which is best for a growing company?
The practical difference: cash basis can make a slow month look great if a few invoices cleared. Accrual shows you what you actually earned. If you’re making operating decisions based on cash basis financials, you’re working with a lag in the data you might not even realize is there.
Most growing businesses hit a point where cash basis stops being useful and starts being misleading. That’s usually around the time they bring on an outsourced controller.
How to set up revenue recognition: step by step
Revenue recognition set up starts with the accounting standard: ASC 606, the five-step model that governs how and when revenue gets recognized. Next, comes the actual math.
Step 1: Confirm the contract.
Before anything hits your books, the contract needs to be solid. Both parties have to be committed, the rights and payment terms have to be clear, and there has to be a reasonable expectation of getting paid. Evaluate the customer’s credit risk before you start booking revenue.
Step 2: Identify deliverables.
A single contract might include design, engineering, construction management, and ongoing support. Each distinct deliverable is a separate performance obligation and each may need to be recognized differently.
Pro tip: A deliverable is distinct if the customer can use it on its own and it’s separately identifiable from everything else in the contract. Break them out before you build your recognition schedule.
Step 3: Set the price.
For fixed-fee contracts this is simple. For anything with variable consideration (performance bonuses, volume discounts, contract modifications, retainers) it gets more complex. Estimate your revenue, factor in uncertainty, and document assumptions.
Step 4: Allocate the price across your performance obligations.
If the contract has multiple deliverables, the transaction price gets split across them based on standalone selling prices. For example, a contract that bundles design and construction services at a package rate needs to be unbundled for recognition purposes. How you allocate affects when and how much revenue you recognize on each component.
Annoying? Yes. But that’s why you pay us the big bucks, right?!
Step 5: Recognize revenue as you satisfy each obligation.
Revenue is recognized when, or as, control of the good or service transfers to the customer. Two scenarios:
For obligations satisfied at a point in time, you recognize when the customer has legal title, physical possession, accepted the asset, and has the risks and rewards of ownership.
An ecommerce sale where the return window has closed is a clean example.
For obligations satisfied over time (like most project-based work) you recognize revenue as you perform. This is where the percentage-of-completion method lives.
Step 6: Build a project master table.
For every active project, you need four numbers:
- estimated total cost
- estimated total revenue
- actual cost to date
- actual billings to date.
If you’re in QuickBooks or NetSuite, some of this can be pulled from your project or job cost module. But in most cases, the estimated cost and revenue figures come from your project managers, not your accounting system. This matters more than you might realize (more to come on this).
Step 7: Calculate your completion percentage.
Divide actual cost to date by estimated total cost. Cap it at 100%.
If a project has incurred $60,000 against an estimate of $50,000, something has gone wrong on the estimate side. You’re over budget. Capping at 100% prevents you from recognizing more than 100% of the estimated revenue.
Step 8: Calculate revenue earned to date.
Multiply your completion percentage by estimated total revenue. This is how much revenue you should have recognized on this project since inception.
Step 9: Calculate what you’ve already recognized.
Pull your prior period entry. Subtract what you’ve already booked from what you should have booked. The difference is your current period revenue recognition.
Step 10: Calculate deferred or accrued revenue.
Compare revenue earned to date against actual billings to date. If you’ve earned more than you’ve billed, you have an asset (unbilled receivable). If you’ve billed more than you’ve earned, you have a liability (deferred revenue).
Both hit the balance sheet. Both need to be reconciled every period.
2 Revenue Recognition Mistakes to Watch For
A quick client case study:
A professional services firm with 40+ active projects runs this model every month:
Project managers submit estimates at kickoff > The accounting team builds the revenue recognition schedule> Month-end close and then the reports go out.
Six months in, the numbers start looking strange. You consistently see thin or negative margins. Deferred revenue balances are hard to explain. Our controller suspects something is wrong but can’t pinpoint it.
After digging into the financials we uncover the problem: actual project costs have been running higher than the original estimates on a significant number of projects. Some by 10%. Some by 30%. But nobody had updated the estimates in the tracking table.
So the model is still running against the original numbers. It thinks a project is 70% complete based on a $100,000 estimate. The project is running $130,000 in costs. It’s over budget, likely over timeline, and the revenue being recognized does not reflect reality.
Two specific failure points to watch:
1. Actuals exceeding estimates without a formula adjustment. When actual costs go above estimated costs, your standard PoC formula will cap completion at 100%. But it will still use the estimated revenue figure as the ceiling. If the project has over-run and the client is going to be billed more, you need the formula to pull actual billings instead of estimated revenue once the over-run is confirmed. That requires an additional conditional in your model.
2. Estimates never getting updated. Project scope changes, budgets shift, other subcontractors come in over bid. No updates = stale data. Your revenue recognition is no longer accurate or reliable.
How to build data quality checks for revenue recognition
In revenue recognition you need to be able to spot anomalies fast. Three things that help:
1). Margin by project, every month.
Build a column that shows estimated margin versus actual recognized margin for each project. They should be close. If a project that was supposed to run at 35% margin is showing 8% or negative, that is a red flag: either the estimate was wrong, the costs are out of control or the billing hasn’t caught up.
2). Conditional formatting on outliers.
Set a threshold: if actual margin deviates from estimated margin by more than 10 percentage points, the cell turns red. This takes ten minutes to set up and will save hours of after-the-fact reconciliation. This means you end up looking for the projects that stand out, not reviewing 40 lines manually every month.
3). A closed-project true-up process.
When a project closes, compare estimated revenue and cost to actual revenue and cost. That variance is your estimate quality score. If you’re consistently off by 20% or more on your estimates, the problem is upstream: in how your project managers are building their budgets.
The accounting model cannot compensate for bad estimates. It can only surface them.
What is required to execute this kind of model
The revenue recognition model is only as accurate as the data your project managers provide.
If estimates don’t get updated when scope changes, your books are wrong. If project managers close out a project in the field without telling accounting, your deferred revenue balance is wrong. If nobody flags when a project goes over budget, you may be recognizing revenue on a loss-leader.
The fix requires a monthly handoff between project management and finance.
