The BlueCollar Project Budget is the central cost-management tool within BlueCollar Projects. It is a functional report and planning interface where users can see and drill into open commitments and actual costs to date, make cost projections, and compare Original, Current, and Projected Estimates against one another.
In construction, the budget is the financial backbone of every project. It connects field activities (represented by Cost Codes) with the general ledger (represented by Cost Types, which are GL Accounts), producing a real-time view of project profitability. This is valuable because, unlike legacy construction systems that rely on subledger mappings, BlueCollar uses NetSuite's native GL directly — every transaction coded to a project posts to the GL in real time, keeping project cost detail permanently in sync with the financials.
The Budget UI is available in English and French. It displays in French automatically when the NetSuite user's language preference is set to French, and in English otherwise — no extra setup is needed.
Budgets depend on a few foundational elements being configured first. These are covered on their own setup pages:
A project must exist before its budget can be created, and the budget must exist before job costs can be applied to it.
The BlueCollar budget grid exposes a specific set of financial columns, each with a precise definition.
| Field | Description |
| Project | The Project is always the base level that Budgets can be rolled up to. When a Project has child Projects associated the budget of the parent as well as all the children will show here. This is useful for users who want to track unique pieces of work such as floors in a building or lots in a neighborhood individually while maintaining visibility into the building or development overall. |
| Division | Groups Cost Codes together on Budget UI and sums those groupings. |
| Cost Code | Cost Code (Custom Segment) |
| Cost Type | Cost Types typically drive GL impact in construction accounting. Because NetSuite does not have subledgers but rather posts to the GL in real time, GL Accounts are designated as Cost Types in BlueCollar Projects, which allows them to be budgeted and costed against. |
| Original Estimate | The Original Budget before Change Orders including Budget Adjustments. |
| Current Estimate | Initially, the Current Estimate is updated in unison with the Original Estimate upon Budget Submission (Submit or Submit Later). The Current Estimate is then meant to only be updated through the Change Order process. |
| Projected Estimate | Users are able to create cost projections to predict the project’s costs at completion. The projections exists beginning as of the ‘Through Date’ that is used when the projections are saved. For example, if the ‘Through Date’ is set to 06/30/2026 when a projection is saved then that projection will exist beginning on that date when the next projection is made. If no new projection is made that would be the final projection going forward. Projections can be created while in Draft or Submitted Mode and users can elect to Submit or Submit Later to save their Projections. |
| Total Cost | Sum of Committed Costs and Actual Costs |
| Committed Costs | Includes unbilled portion of Approved Purchase Orders tagged to the BlueCollar Project. Committed Cost will also be reduced by receipts against Items that are marked as Available for Receipt AND Accruable – meaning that cost is incurred when received. It is recommended to use Items when creating PO’s for a Project. Note: The Item’s Expense account is what will drive the cost impact to the project as well as the data validation against the Budget. Inventory items coded to a Project on a PO are not validated on a Project because receiving inventory items from a PO does not have a cost impact – only an asset impact. |
| Actual Costs | Includes Approved posting transactions coded to the Project. |
| Costs to Complete | [Current Estimate – Total Cost] Note: This calculation is useful for measuring actuals vs. estimates as well as overall project management to a budget. |
| Proj Cost Complete | [Projected Estimate – Total Cost] Note: This calculation is useful for measuring how well the project steward like a Project Manager knows their project cost and can accurately predict variances from the budget over time. In many cases, predicting the outcome of a project early is more important than merely focusing on a budget because it forces users to understand their past costs and think through their future costs whereas focusing on budget alone can sometimes cause managers to withhold project resources that may have otherwise resulted in lower cost over overall. |
| (Over) / Under | [Projected Estimate – Current Estimate] Note: This calculation is useful because this value is the amount of profit over or under what was budgeted based on the most recent projection. This keeps users focused on profit impact as a function of cost. |
The grid tracks Hours and Units in parallel with the dollar columns, so you can plan and measure non-dollar metrics — like labor hours or installed quantities — the same way you track cost. Each set follows the same Original → Current → Projected → Actual progression:
| Metric | Original | Current | Projected | Actual |
|---|---|---|---|---|
| Hours | Original Hours | Current Hours | Projected Hours | Actual Hours |
| Units | Original Units | Current Units | Projected Units | Actual Units |
Original Hours and Original Units are entered on the budget line, Current values follow the budget and Change Order lifecycle, Projected values come from your saved projections, and Actual Hours and Actual Units roll up from posted activity. This lets you measure a project against an hours- or units-based plan right alongside its dollar budget.
When a project has child projects, the Budget UI displays the parent project's own budget plus aggregated data from all children. This allows users to track unique pieces of work individually — floors in a building, lots in a neighborhood — while maintaining a single roll-up view of the overall building or development.
Every project's budget moves through three states:
| Status | Description | Editable? |
|---|---|---|
| Not Initiated | Default status when a project is created. No budget lines exist yet. | N/A |
| Draft | Budget lines have been added and saved via Submit Later. Users can continue editing, adding, and deleting budget lines. | Yes |
| Submitted | Budget is locked via Submit. No further edits are permitted unless the status is changed back to Draft. | No |
Status transitions:
Once a budget is submitted, the standard way to modify the Current Estimate is through the Change Order process rather than by unlocking the budget — this keeps the Original Estimate and Current Estimate cleanly separated so you always retain the original baseline.
Committed Costs represent the unbilled portion of Approved Purchase Orders (and Transfer Orders) tagged to a project. They answer the question: how much cost are we contractually obligated to pay that hasn't yet been billed or received?
Committed Costs are reduced by:
A committed cost line can never go below zero.
Project POs must use Items, not expense lines. BlueCollar's cost engine only reads the Items tab on a Purchase Order — the Item's Expense account drives both the cost impact to the project and the budget data validation. Lines added to the Expense tab on a project PO are invisible to the committed-cost calculation, the budget validation, and (for subcontracts) the Subcontract Billing Tool. This rule applies to every project PO, whether it's a subcontract or a regular vendor PO.
Inventory items are handled differently. Inventory items coded to a project on a PO are not validated against the budget and do not appear as committed costs. Receiving inventory creates an asset entry, not a cost entry, so it falls outside the committed-cost model.
The Budget UI lets users drill into any committed or actual cost figure to inspect the individual transactions behind it for a given Cost Code / Cost Type combination. The drilldown shows the account, transaction number (as a clickable link to the source transaction), transaction type, date, period, vendor, amount, billed amount, and committed remaining. The columns shown in the committed-costs drilldown are configurable per account, so an account can surface the extra detail your team needs.
Actual Hours and Actual Units are drillable too. At every roll-up level — the individual Cost Code / Cost Type line, the Division summary, and the Project total — the Actual Hours and Actual Units values each link to a source search showing the records behind the number, just like the cost figures do.
This allows users to move from a summary number straight to the source documents without leaving the budget — useful when reconciling a cost code or investigating an unexpected variance.
You can export the budget grid whenever you need to share it or work with it offline:
Budget actions are controlled through BlueCollar Global Permissions. A few behaviors worth knowing: administrators must be granted permissions explicitly (they do not inherit automatically), and the system applies the highest permission level across all of a user's assigned roles.
| Feature | Application | Action | Permission |
|---|---|---|---|
| View the Budget UI from the project's tab | BUDGET | BUDGET_VIEW_BUDGET | VIEW |
| View the Budget UI and create new budget items | BUDGET | BUDGET_CREATE_ITEMS | FULL |
| Edit projected estimate or original estimate | BUDGET | BUDGET_PROJECTIONS | FULL |
| Change budget status from Submitted back to Draft | BUDGET | BUDGET_STATUS | FULL |
| Delete budget lines (when no Change Orders or costs exist against the line) | BUDGET | BUDGET_DELETE_ITEMS | FULL |
Unlock Budget. This feature allows transactions to be coded against a Project / Cost Code / Cost Type combination that does not yet have a budget item — the budget item is created automatically during transaction entry. For it to work, both the BlueCollar Project and BlueCollar Cost Code custom segments must be configured with Filtered By: Subsidiary (see Setup and Initial Configuration).
Labor hours by account are not tracked. If you need to distinguish labor hour types, create separate Cost Codes for each type rather than trying to split hours by Account. Accounts are not available on NetSuite Time Records, so splitting hours by Account would require non-native customization and cause reporting inconsistencies.
One GL account per item. NetSuite items are designed to have a single GL account each, and BlueCollar follows that native behavior. Customers who need flexible GL at the item level should be guided toward native NetSuite functionality.
Cost Code Detail. A Cost Code Detail option lets you associate cost codes with the matching contract (SOV) lines, keeping the cost codes you budget against aligned with the lines you bill on the contract.