Job Costing Visibility: How Dimensions Replace Spreadsheet Chaos for Electrical Contractors
The CFO wants to know which project type is most profitable before the next business development meeting. The answer should take thirty seconds to pull from the financial system. The controller runs the job cost report, sorts by project type, and stops. The commercial projects are coded three different ways across four different GL accounts. Healthcare has its own structure. The highway jobs use a fifth.
To compare margin across project types, she needs to export everything to Excel, manually map the overlapping codes to a common framework, and reconcile the differences. That is three hours of work before she can answer a thirty-second question. The CFO does not know the work is happening. The controller cannot skip it.
Every cost is recorded correctly. Every transaction is in the system. The problem is not what went in. It is how it is organized on the way out. A chart of accounts that accumulated over years of project managers, acquisitions, and shifting reporting requirements has no common structure. And a financial system with no common structure cannot answer a straightforward question without manual intervention.
How Charts of Accounts Get Out of Control
In a legacy system, every unique combination of reporting needrequires its own GL code. A labor cost on a commercial project in the downtown office is a different code from a labor cost on a residential job in the suburbs, which is different again from labor on a healthcare build. That logic compounds fast.
A small electrical contractor with twenty active projects, six cost types, and three departments can end up with hundreds of GL codes. Most of them overlap in meaning. Few of them compare cleanly across jobs. The chart of accounts was not designed for cross-job analysis—it was designed to record individual transactions, and that is all it does well.
The result is that every reporting question that crosses more than one job or one cost type requires manual work to answer. The data exists. Getting to it requires effort that belongs to the controller but produces no revenue for the company.
What a Dimension Is and Why It Changes the Equation
A dimension is a tag attached to a transaction. It is not a GL code. You do not need a new account for every reporting combination. You need one GL code and several dimensions that describe the transaction from multiple angles at once.
Instead of creating a unique GL code for commercial-labor-downtown-zone-three, you post to GL 5020 (Labor) and tag the transaction: Project \= Downtown Substation, Cost Type \= Labor, Department \= Commercial, Location \= Zone 3. The code stays clean. The reporting becomes fully flexible.
Inside Sage Intacct, every transaction can be tagged to multiple dimensions simultaneously: project, cost code, cost type, department, location, and more. Contractors who have made the switch find they can shrink their chart of accounts by half while gaining more granular reporting capability, not less. The accounts get simpler. The questions they can answer get more specific.
The Questions Dimensions Let You Answer
The real value of a dimension-based structure is not in how transactions are stored. It is in what becomes possible to ask.
Which jobs are running over on labor? Filter by cost type: labor, across all active projects. The answer comes from the data directly, not from a reconciled spreadsheet.
Which project manager is trending over budget? Filter by dimension: project manager. A pattern visible across one PM's jobs but not another's is a management conversation, not a mystery.
Which project type generates the highest margin? Filter by dimension: project type. If commercial healthcare returns better margin than ground-up residential, that is a business development insight with real strategic value.
Where are material overruns concentrated? Filter by cost code and cost type: materials. If copper is running over on the same project type repeatedly, the estimating assumption may be the problem, not the field.
None of these questions require a spreadsheet to answer. They require dimensions on the transactions and a reporting tool that can filter by them. That is the shift dimension-based accounting makes possible.
Dimensions Organize Good Data. They Cannot Fix Bad Data.
This is the part of dimension-based accounting that does not show up in a product demo. Dimensions are a reporting tool. They surface what is in the system. They cannot correct what was coded incorrectly, posted late, or never entered at all.
Change orders are a useful example. A change order with a vague or undocumented scope gets posted to a vague cost code. A dimension tag on that transaction reflects the vague code accurately. The reporting is clean. The data it is reporting on is not. Undocumented change requests produce undocumented cost entries, and no amount of dimension tagging makes an ambiguous posting queryable.
Timing matters in the same way. A change order that sits approved but unposted for three billing cycles eventually lands in the ledger—in the wrong period, tagged to the right dimensions. The cross-job margin report will show the cost in the month it posted, not the month the work happened. CO approval delays do not just slow cash flow; they distort the dimension-based reporting that depends on timely posting.
The same applies to field time entry. If labor hours are batched weekly and entered from a photo of a time card, the dimension tags on those entries reflect last week's job, not today's. Field data that posts daily carries current dimension tags. Batched field data carries dimension tags applied to work that is already history.
For electrical contractors implementing dimensions, the reporting capability is real. But it performs at the level of the data feeding it. Contractors who get the most value from dimension-based reporting are the ones who have also gotten disciplined about what goes into the system—correct cost codes, timely postings, and documented scope on every change. That is what makes the CFO's thirty-second question answerable.
Frequently Asked Questions
What exactly is a dimension in accounting software?
A dimension is a tag attached to a financial transaction that describes it from a specific angle—project, cost type, department, location, and so on. Unlike a GL code, which is a fixed account in the chart of accounts, a dimension can be applied to any transaction in any account. The same labor posting can carry a dimension for the project it belongs to, the cost type it represents, the PM responsible, and the geographic location—all at once. This enables multi-angle reporting from a single, clean set of transaction data.
How does dimension-based accounting reduce chart of accounts bloat?
In traditional systems, every unique reporting combination requires its own GL code. A contractor with ten project types, six cost types, and four departments might end up with hundreds of codes to accommodate every combination. With dimensions, you maintain one GL code per cost category and use dimension tags to carry all the context. The chart of accounts shrinks to a manageable set of true account categories. The reporting detail lives in the dimensions, not in the accounts themselves.
Can dimensions be added to an existing Sage Intacct setup, or does it require starting over?
Dimensions can be added to an existing configuration. New dimension values can be created and applied to transactions going forward without restructuring historical data. The most useful reporting comes from consistent tagging from the start of a project, but there is no technical barrier to introducing or refining dimensions mid-deployment. Contractors who implement dimensions mid-year typically apply them fully to new projects and do a partial cleanup on active jobs where reclassification is worth the effort.
What is the difference between a cost code and a dimension?
A cost code is a specific category within a project budget—typically tied to a scope of work like rough-in wiring, gear installation, or service labor. It is a line in the job cost structure. A dimension is broader and more flexible: it describes a transaction attribute that applies across all projects and cost codes, such as which project manager owns the work, which department it belongs to, or what project type it falls under. Cost codes tell you what the cost is for. Dimensions tell you who, where, and what kind—enabling comparisons that cut across the job cost structure.
How do dimensions help when a contractor is trying to identify which jobs are going underwater?
Without dimensions, spotting a problem job typically requires pulling individual job cost reports and comparing them manually. With dimensions, a controller can run a single report filtered by dimension—cost type, project manager, or project type—and see margin performance across the full portfolio at once. A job that is trending over budget on labor in week four is visible alongside every other job running the same pattern. Early visibility is what creates the opportunity to intervene before the overrun becomes a write-off.
See What Your Job Cost Data Should Look Like
If your team is spending weekends in spreadsheets to answer questions the financial system should be able to answer on its own, the issue is structure, not effort. Alliance Solutions Group works with electrical contractors to implement the dimension-based reporting that turns transaction data into management visibility.
