Introduction
Construction revenue recognition is not a standard accounting problem. The realities of the industry make it uniquely difficult to get right: long-term contracts, retainage withholding, mid-project change orders, and AIA billing cycles that rarely reflect actual work progress.
Under ASC 606, contractors must recognize revenue as project control transfers to the customer — not when cash arrives. For most construction firms, that means recording revenue continuously across multiple fiscal periods while managing contracts that change scope mid-execution.
Get the configuration wrong in NetSuite, and the consequences are concrete: misrecognized revenue, non-compliant financial statements, and WIP schedules that don't hold up under audit.
This article explains how revenue recognition works in NetSuite for construction projects. Specifically, it covers:
- Which recognition methods apply to construction contracts
- How NetSuite's Advanced Revenue Management (ARM) module handles the mechanics
- What factors undermine recognition accuracy
- Where construction finance teams most commonly go wrong
Key Takeaways
- ASC 606 governs construction revenue recognition, with percentage-of-completion (PCM) as the standard method for long-term contracts
- NetSuite's ARM module automates recognition through schedules and journal entries tied to project progress
- Change orders and retainage must be configured correctly — they're the most common source of recognition errors
- Classic NetSuite Revenue Recognition is unavailable in new implementations; ARM is the current path
- Data quality and reporting lag cause most month-end recognition inaccuracies, not just configuration gaps
What Is Revenue Recognition in Construction — And Why Standard Methods Fall Short?
Revenue recognition in construction is the process of recording earned revenue in the correct accounting period, proportional to work completed — not based on when cash is received or invoices are sent.
FASB ASU 2014-09 (ASC 606) establishes the five-step model that governs this process:
- Identify the contract
- Identify the performance obligations
- Determine the transaction price
- Allocate the transaction price
- Recognize revenue when (or as) each obligation is satisfied
For most construction contracts, recognition happens over time — not at a single completion point. ASC 606 allows over-time recognition when any one of three criteria is met:
- The customer simultaneously receives and consumes the benefits as work is performed
- The customer controls the asset as it is created (work in process)
- The asset has no alternative use to the contractor, and the contractor has an enforceable right to payment for work completed to date
Why Construction Is Different
Standard revenue recognition assumes a transaction: deliver the product, recognize the revenue. Construction doesn't work that way.
The gaps that create compliance risk:
- Billing vs. progress: AIA progress invoices reflect negotiated billing schedules, not actual project completion — a firm can be 60% complete but only 40% billed
- Retainage: Owners typically withhold a percentage of earned billings until project completion, creating a gap between amounts invoiced and amounts collectible
- Change orders: Contract values shift mid-project, altering both the revenue ceiling and the cost denominator used to calculate percent complete
- Multi-period contracts: Revenue earned in one fiscal year may not be billed until the next, creating overbilling and underbilling positions that must appear on the balance sheet
The completed contract method (CCM) avoids this complexity by deferring all recognition until project completion, but it is not GAAP-compliant for most long-term contracts and creates volatile income swings. Percentage-of-completion under ASC 606 is the required method for most commercial construction firms — and the harder challenge is executing it accurately across dozens of active projects, each with its own billing schedule, change order history, and retainage position. That's precisely where NetSuite's configuration choices determine whether compliance is manageable or chronically manual.
How NetSuite Handles Revenue Recognition for Construction Projects
NetSuite's Advanced Revenue Management (ARM) module is the engine for construction revenue recognition. Oracle's ARM documentation confirms that ARM automates revenue forecasting, recognition, reclassification, deferral, and auditing through a rule-based event-handling framework — generating journal entries from revenue recognition plans tied to contracts, billing events, or project progress.
For construction, ARM operates across two parallel data streams that must stay synchronized:
- Project costing tracks actual costs incurred and project progress (the inputs)
- ARM schedules use those inputs to calculate and post recognized revenue (the outputs)
When these two streams fall out of sync — delayed cost entries, unrecorded change orders, stale cost estimates — ARM produces wrong outputs regardless of how well it was configured.
Getting the process right requires three coordinated steps. Here's how each one works.
Step 1: Configure Revenue Recognition Templates
ARM templates define:
- The recognition method (percent complete, milestone, straight-line)
- The schedule frequency (monthly, quarterly)
- The deferred revenue account holding unrecognized contract value
Each template is linked to the relevant project or contract line item. For construction, the first configuration decision is whether the contract qualifies for over-time recognition under ASC 606 — confirmed by the criteria above.
Step 2: Track Project Progress and Update Completion Inputs
ARM calculates recognizable revenue each period using:
(Costs Incurred to Date ÷ Total Estimated Contract Costs) × Total Contract Price
Oracle's documentation confirms that percent-complete revenue recognition plans update as project completion percentage changes — making it reliable for projects where costs shift weekly.
Two critical discipline requirements:
- Cost-to-complete estimates must be updated regularly after scope changes or overruns — stale denominators distort every recognition calculation downstream
- Change orders must be recorded in NetSuite immediately upon approval; delayed entries shift both the revenue numerator and cost denominator simultaneously
Step 3: Generate Schedules and Post Journal Entries
Once templates are configured, ARM generates recognition schedules showing how much revenue is allocated to each period. At period close, the finance team runs a batch journal entry process that moves revenue from the deferred account to earned revenue.
Oracle's documentation confirms that journal entries can be generated on demand or scheduled automatically. NetSuite does not recognize revenue until the finance team (or an automated job) creates those entries from the plans.
ARM also maintains a complete audit trail of every recognition event — a requirement lenders, bonding agents, and auditors will ask for by name. That audit trail is only as clean as the data feeding into it, which is where most construction firms run into trouble.
Key Revenue Recognition Methods NetSuite Supports for Construction
| Method | Use Case | NetSuite Support |
|---|---|---|
| Percentage-of-Completion (PCM) | Long-term contracts, GAAP-required | ARM templates with percent-complete schedules |
| Completed Contract (CCM) | Short-term or eligible home contracts | ARM or classic schedules deferring revenue until completion |
| Milestone-Based | Defined performance obligations | ARM triggers recognition at milestone completion |
Percentage-of-Completion
PCM is the primary method for most commercial construction. Revenue is recognized proportional to project progress, measured by cost-to-cost ratio, labor hours, or milestone completion — all configurable in ARM.
For tax purposes, IRC Section 460 generally requires PCM for long-term contracts. Two exceptions apply:
- Small contractors: Expected completion within two years and average annual gross receipts below the applicable threshold (verify current amounts in IRS Rev. Proc. 2025-32)
- Home construction contracts: Buildings with four or fewer dwelling units
Milestone-Based Recognition
For contracts structured around distinct performance obligations — foundation, structural, MEP, fit-out — ARM can allocate the transaction price across each obligation and trigger recognition when control transfers. Accurate standalone selling price estimates for each obligation are required at contract setup; without them, the allocation won't hold up under ASC 606 scrutiny.
Retainage and Deferred Revenue
Retainage — the portion of earned billings withheld by the owner until project completion — requires separate handling. CFMA's guidance on Topic 606 classifies retainage as a contract asset or liability depending on conditions and rights.
In NetSuite, this means:
- Setting up retention receivable accounts distinct from standard AR
- Configuring ARM so retained amounts are not posted as earned revenue until release conditions are met
- Tracking retainage schedules separately to monitor cash impact on working capital
Firms that skip this configuration overstate earned revenue on the income statement until retainage is released. That misstatement is one of the more predictable findings auditors flag on construction engagements.
Factors That Impact Revenue Recognition Accuracy in NetSuite
NetSuite ARM can be configured correctly and still produce inaccurate results. The cause is almost always data quality, not system capability.
Cost Estimate Accuracy and Update Frequency
The PCM formula divides costs incurred by total estimated contract costs. If project managers don't update cost-to-complete estimates after scope changes or overruns, that denominator becomes stale. The result: recognized revenue diverges from reality. Stale estimates produce either front-loaded recognition (if estimates were too high) or deferred recognition (if estimates were too low).
ARM calculates with the data it receives. Outdated inputs are a process failure, not a system one.
Change Order Management Discipline
Unrecorded or unapproved change orders are the most common source of recognition errors in NetSuite construction environments. Every change order moves two variables simultaneously: the contract price (revenue numerator) and estimated costs (denominator). Even a well-configured ARM setup produces wrong outputs when change order data lags.
Datateer's Change Order Impact & Aging module pulls change order data directly from NetSuite, tracking pending, approved, and executed changes — including aging by days since submission — so finance teams can see exactly which stalled change orders are distorting margin and recognition positions.
Disconnected Systems
Construction firms often run field operations in Procore and accounting in NetSuite. When these systems aren't tightly integrated, actual cost data in NetSuite is incomplete, and percent-complete calculations are wrong before ARM even runs.
McKinsey's research on digital transformation in construction notes that firms often fail to capture full digital value when technology efforts remain isolated rather than enterprise-wide — a pattern that directly applies to finance and field data integration.
The Reporting Lag Problem
Even firms with accurate ARM configurations often struggle to surface recognition data in a usable format. WIP schedules, over/under-billing positions, and margin trends are typically assembled manually at month-end — by which point the data is already 10–20 days stale.
Datateer connects directly to NetSuite to automate WIP and revenue recognition reporting, replacing the manual close process with dashboards that refresh overnight. For each job, the platform calculates:
- Percentage complete and earned revenue
- Billed revenue and costs in excess of billings
- Projected margin per project
This eliminates the manual VLOOKUP process that typically precedes every board meeting — pulling from NetSuite source data with no spreadsheet intermediary.
Common Misconceptions and Limitations
"Classic Revenue Recognition Is Sufficient for Construction"
It isn't — and it's no longer an option. Oracle's documentation confirms Classic Revenue Recognition is unavailable in new NetSuite implementations. It remains supported only for customers who previously enabled it. Classic lacks the performance obligation framework required by ASC 606 — meaning construction firms still on classic templates face compliance risk and cannot support the five-step model that governs contract accounting.
ARM is the current path. If you're on a new NetSuite implementation, the question isn't whether to use ARM — it's how to configure it correctly for construction.
"Revenue Recognized Equals Revenue Billed"
This is the most expensive misconception in construction accounting. Billing and recognition are separate processes in NetSuite. A project can be:
- 60% complete but only 40% billed → underbilling (costs in excess of billings — a balance sheet asset)
- 70% billed but only 50% complete → overbilling (billings in excess of costs — a balance sheet liability)
ARM doesn't automatically track these positions. They must be calculated and reported as part of the WIP schedule. Assuming billed amounts equal earned amounts causes financial statements to misrepresent the firm's actual position — the kind of error that surfaces during bonding renewals or audit engagements.
When NetSuite ARM Needs Augmentation
Standard ARM configuration handles most construction scenarios but tends to produce unreliable results when:
- Cost codes vary across projects or entities, breaking the mapping between cost data and contract line items
- Completion percentages are updated irregularly, causing recognition schedules to drift from actual progress
- Recognition spans multiple subsidiaries or jurisdictions, requiring consolidation logic beyond standard ARM setup
Datateer's data cleaning and standardization layer resolves the cost code problem by normalizing codes across systems and aligning them to contract line items automatically. For multi-entity firms, the platform's construction-specific data models handle cross-subsidiary consolidation without custom NetSuite development.
Frequently Asked Questions
How does NetSuite recognize revenue?
NetSuite recognizes revenue through the ARM module, which uses templates linked to contracts or transactions to generate recognition schedules. At period close, journal entries move revenue from deferred to earned accounts based on the configured method — straight-line, percent complete, or milestone.
How is revenue recognized in construction?
Construction revenue is most commonly recognized using PCM under ASC 606. Revenue is recorded proportionally as work progresses — measured by cost-to-cost ratio, labor hours, or milestone completion — rather than waiting until the project is finished.
Is NetSuite good for construction companies?
NetSuite's ARM, job costing, project management, and billing modules make it a capable platform for construction accounting. Proper configuration and integration with field systems like Procore are essential — the platform's value depends heavily on the quality of data flowing into it.
What is the difference between PCM and CCM in NetSuite?
PCM recognizes revenue incrementally as work progresses and is required for most long-term GAAP contracts. CCM defers all revenue until completion and is acceptable only for short-term or eligible home construction contracts. NetSuite supports both through ARM templates.
How does NetSuite handle retainage in revenue recognition?
NetSuite supports separate retention receivable accounts to track amounts withheld by project owners. When properly configured, retainage is excluded from recognized revenue until released — preventing income overstatement on the income statement.
What is ARM and do construction firms need it?
ARM is NetSuite's current revenue recognition module that automates deferral, scheduling, and journal entry creation in compliance with ASC 606. For construction firms with long-term contracts, multiple performance obligations, and retainage, ARM is strongly recommended. The legacy Classic feature is no longer available in new NetSuite implementations.
