Cost coding is the most consequential foundational decision in a commercial construction firm's accounting setup, and it's the decision most often made by accident — inherited from the predecessor controller's 2014 setup, copied from the GC down the street, or matched to the estimator's spreadsheet templates from a prior firm. This is a working guide for mid-market commercial subs and GCs on how cost coding should be designed, why cost-code drift across systems is the root cause of pay-app reconciliation pain, and how to think about restructuring without breaking the historical record.
If you're the controller, CFO, or owner of a mid-market commercial construction firm, the cost-code structure is the foundation that everything else (the SOV, the budget, the pay app, the WIP schedule, the job-cost report, the year-end financials) sits on top of. Get it right and the firm's reporting clicks together. Get it wrong — or, more commonly, let it drift across systems — and every monthly close, every pay-app cycle, every closeout gets harder than it has to.
This post is the foundational accounting design conversation that nobody on the construction-software podcast circuit talks about, but that determines whether your firm's accounting actually works.
What "cost code" actually means in commercial construction
A cost code is the identifier you use to classify a construction cost. The classification serves several purposes simultaneously:
- Estimating — the estimator builds a bid by quantifying scope per cost code (so many SF of drywall hung, so many CY of concrete poured, etc.)
- Budgeting — the approved estimate becomes the project budget with the same cost-code structure carried forward
- Job costing — actual costs incurred (labor, materials, equipment, subcontracts) are coded to the same structure for comparison against budget
- SOV and pay app — the schedule of values and the AIA G702/G703 (see our G702/G703 working guide) are typically structured by cost code or by groupings of cost codes
- WIP and financial reporting — the GL chart of accounts (which is a different but related structure) rolls up the job-cost data into financial statements
The same cost code shows up in five or six different systems during a typical project. Whether those systems share a consistent structure determines whether the work of reconciliation is a click or a week.
The four common cost-code structures
1. CSI MasterFormat. The Construction Specifications Institute's MasterFormat is the industry-standard division structure (Division 01 General Requirements through Division 49 Transportation, with newer divisions added periodically). MasterFormat is the language of specifications and is widely used by architects and engineers. Many GCs and subs structure their estimating and project management around it. The downside: it's specification-oriented, not accounting-oriented — some MasterFormat sections don't map cleanly to GL categories.
2. CSI UniFormat. A different CSI taxonomy organized by building system / building element (A: Substructure, B: Shell, C: Interiors, D: Services, etc.) rather than by trade. Less common for accounting; sometimes used for conceptual estimating early in a project's life.
3. Custom GC-defined codes. Many mid-market GCs use their own structure that combines MasterFormat division-level codes with custom sub-codes for sub-trades and crew classifications. This can work well when designed thoughtfully; it becomes a problem when the in-house structure doesn't reconcile to the MasterFormat that the architects and subs are using.
4. Trade-specific custom codes. Subs typically organize around their own trade's structure: concrete subs by mix designs and pour locations; electrical subs by panels and circuits; drywall subs by wall types and finishes. These structures are richest within the trade but often don't map cleanly to the GC's preferred structure on the project.
Most commercial projects have all four operating simultaneously: the architect's specs in MasterFormat, the GC's project management in a custom structure, the GC's accounting in a third structure that ties to their GL, and each sub's internal records in their trade-specific structure. The reconciliation cost is real.
Why cost-code drift across systems is the root cause of pay-app reconciliation pain
Most pay-app cycles that bounce back from the GC's accountant for "doesn't reconcile" reasons trace to cost-code drift. Here's the pattern:
- The estimator builds the bid in a structure organized by takeoff (e.g., "Slab on Grade — First Floor")
- The contract is written with an SOV structure matching how the owner wants to see billing (e.g., "Concrete — Foundations")
- The PM platform opens a budget in a third structure matching the GC's PM organization (e.g., "03 30 53 Cast-in-Place Concrete — Slabs")
- The accounting system has yet a fourth structure matching the GL chart of accounts (e.g., GL code 5210 Materials — Concrete, GL code 5310 Labor — Concrete)
- The pay app, when generated, has to reconcile across all four structures — usually by hand
The 28th-of-the-month reconciliation that mid-market GC and sub accountants do is largely a cost-code translation exercise. Reduce or eliminate the translation and you've cut your monthly close time by half.
How to design a cost-code structure that survives growth
If you're designing or redesigning a cost-code structure for your firm, the principles:
1. Pick a backbone and stick to it. CSI MasterFormat is the safest backbone for commercial work because it's the language of the specs and the subs already speak it. Pick MasterFormat division-level (e.g., Division 03 Concrete) as the top level, then add as many sub-levels as your reporting needs (e.g., 03 30 53 for cast-in-place slabs).
2. Limit the depth. Three or four levels is usually enough. Going deeper (5+ levels) makes the structure too granular for estimators to use consistently and too fine for the GL to roll up cleanly. Most mid-market firms operate with 200-500 active cost codes; fewer than 100 is too coarse, more than 1,000 is too fine.
3. Map cleanly to the GL. Every cost code should have a default GL account for materials, labor, equipment, subcontract, and other expense types. The mapping should be one-to-one or many-to-one, never one-to-many. If a cost code can post to multiple GL accounts depending on transaction type, your accounting will drift.
4. Reserve number ranges for trade expansion. Leave gaps in your numbering so you can add new trades or sub-trades without renumbering. CSI MasterFormat's structure already does this; if you customize, preserve the spacing.
5. Don't rename codes mid-project. Once a project's cost-code structure is set, freeze it. Renaming "03 30 50 Slabs" to "03 30 53 Cast-in-Place Slabs" mid-project breaks every report that references the original code. New codes for new projects; old codes stay frozen.
6. Document the structure. A one-page reference of the active cost-code structure, with the GL mapping for each, in the firm's accounting policy folder. New PMs, new estimators, and new accountants should be able to learn the system in 20 minutes. If your structure requires institutional knowledge to interpret, it will degrade.
The relationship between cost codes, the SOV, and the GL chart of accounts
Three related but distinct structures:
Cost codes classify costs at the most granular level. The transaction-level record. "This $4,500 labor entry is coded to 03 30 53.20 Slabs — Pour Labor."
The SOV aggregates cost codes for billing purposes. Several cost codes might roll up into one SOV line: "03 30 53.10 Forms," "03 30 53.20 Pour Labor," and "03 30 53.30 Finishing" might all roll into SOV line "Slab on Grade." The SOV is the structure the owner sees on the pay app.
The GL chart of accounts aggregates further for financial reporting. The cost-code transaction posts to a GL account; the GL accounts roll up into financial-statement categories (Direct Costs, Indirect Costs, etc.).
These three structures should compose cleanly: cost code → SOV line (for billing) and cost code → GL account (for financial reporting), with no transaction left uncoded. Most mid-market firms have this mostly working, with corner cases that drift.
What goes wrong, specifically
The four most common cost-coding pathologies:
1. Cost codes diverging across the estimating system, the PM system, and the accounting system. The estimator uses one structure (or no formal structure); the PM uses Procore's defaults; the accountant uses Sage's defaults. The "same" project has three different cost-code structures, and reconciliation is by hand. (Covered in more depth in why the mid-market GC stack is broken.)
2. Custom codes that map to multiple GL accounts depending on transaction. Cost code 03 30 53 might post to GL 5210 (Materials) for material purchases, GL 5310 (Labor) for labor, GL 5410 (Equipment) for equipment. This is normal — but if the transaction type isn't reliably captured, the GL posting drifts and you can't tell at year-end how much of cost code 03 30 53 was labor vs. material.
3. Sub costs that don't reconcile with GC cost codes. The sub bills against their internal cost-code structure; the GC's accounting books the AP against the GC's structure. The mapping requires retyping or an integration layer; either way it's a place where drift occurs.
4. Structure inherited from a prior firm or a prior version of the firm. The controller who set up the cost-code structure left three years ago; the current team has been making one-off additions without understanding the original design intent; the structure is now incoherent. Closeout cost analysis on long projects becomes guesswork.
How AOS handles cost coding
In AOS, the cost-code structure is a project-level (and firm-level) object that propagates across every module. Specifically:
- One cost-code structure per firm, with project-level variations only where the contract requires it (e.g., an owner who insists on their own SOV structure)
- The estimator's structure becomes the budget structure becomes the SOV structure — no translation step, because the structures are the same
- Each cost code maps to a default GL account by transaction type (materials, labor, equipment, subcontract, other), with the mapping defined once at the firm level
- Sub-side and GC-side cost-code reconciliation is automatic when both are on AOS — the sub's SOV references the GC's contract cost-code structure cross-tenant, so a sub's billing for cost code 03 30 53 lines up to the GC's tracking of the same code
- Structure documentation is built in — the active cost-code reference is a generated artifact, always current, with the GL mapping visible
- Restructuring tools — if you need to evolve your structure, the platform supports merging codes, splitting codes, and renumbering with full audit trail. Critically, historical records stay coded to the codes that were active when they were created; new projects use the new structure.
- Reporting works across the structures — you can produce a job-cost report against any rollup level (specific code, parent code, division, custom grouping)
The estimating & money page covers the cost-code integration with estimating specifically. The sub accounting and GC accounting role pages walk through the workflow from the accountant's seat. For the related AP workflow, see construction AP automation for mid-market GCs.
The cost-coding readiness checklist
- Does your firm have a documented cost-code structure that a new hire could learn in 20 minutes?
- Is the structure the same in estimating, PM, and accounting, or does each system have its own?
- Does every cost code map cleanly to the GL chart of accounts by transaction type?
- When subs bill you, does their cost-code structure reconcile to yours, or does it require manual translation?
- Can you produce a job-cost report at any rollup level (specific code, division, custom grouping) without manual report-writing?
- If you wanted to evolve your cost-code structure for next year's projects, do you have a clear path that preserves historical records?
If most answers are "kind of, with workarounds," that's the gap a unified platform closes — but the foundational design decision still has to be made well. The software doesn't fix bad design, just bad execution.
If you'd like to talk through it
We're in private-beta design-partner mode for commercial subs and GCs. If you'd like to walk through your firm's cost-code structure with someone who's seen what works at mid-market scale — including how AOS handles the four pathologies above — apply to the beta. The structure conversation often pays back significantly more than the platform decision itself.