A finance team moving off QuickBooks almost always arrives with a chart of accounts that has been growing for a decade. Somewhere in it sit 5100-01-DEN, 5100-02-DEN and 5100-01-HOU, plus thirty more variations of the same supplies expense. The first thing worth looking at in a migration is not the trial balance. It is that account list, because Sage Intacct dimensions are about to make most of it unnecessary.
None of that sprawl is a bookkeeping failure. It is what happens when the only place to store business context is the account number itself. Every new location, department, program or funding source gets encoded into the string, and the string gets longer every year. Nobody decides to build a 900-line chart of accounts. It accumulates, which is one of the quieter signs a team is outgrowing QuickBooks.
Moving that context out of the account number and onto the transaction is a small technical difference and a large practical one. It is the change that most reshapes how a finance team designs its books during a migration, and it has to be settled early, because redesigning it after go-live means touching history.
Key Takeaways
- A dimension is a tag applied to a transaction, not a segment inside an account code. The account says what happened; the dimensions say where, for whom and on what.
- Because context lives on the transaction, adding a location or department no longer means adding accounts. The chart of accounts stops growing, and usually shrinks during migration.
- The most common mistake is making everything a dimension. The second is leaving dimensions optional, which produces untagged entries and reports that never tie back to the general ledger.
- Dimension design has to happen before data migration, because historical transactions cannot be retroactively tagged with context that was never captured. After go-live, somebody has to own the dimension value list.
Screenshots throughout are Sage Intacct product material. The figures shown in them are Sage’s demonstration data, not Lucentive client results.
What Sage Intacct dimensions actually are
A dimension is a tag you attach to a transaction rather than a segment you build into an account code. Location, department, project, customer, vendor, employee, item and any dimension you define yourself travel with the entry through the general ledger, receivables, payables, time entry and revenue management. One account, many angles.
The mechanical difference is worth being precise about. In a segmented chart of accounts, the combination of segments is the account: post to 5100-01-DEN and you have posted to an account that exists only to hold Denver’s clinical supplies. In a dimensional ledger you post to account 5100, Supplies, and separately tag the entry Location = Denver, Department = Clinical. The account is one field. The dimensions are others, which is the core of how a dimensional general ledger works.
Two things follow. A new value can be added without touching the chart of accounts, so a new clinic is one location value rather than forty account codes. And dimensions are not confined to journal entries: the same tags apply to an AP bill, an AR invoice, a timesheet line and a revenue schedule, so operational and financial activity share one vocabulary.
Why your chart of accounts gets shorter
A segmented chart of accounts multiplies. Track three locations, five departments and five projects and one expense account needs up to 75 code combinations to cover every intersection. Add a sixth department and the multiplication runs again across every affected account. Dimensions replace that multiplication with addition.
| What you need to see | Segmented chart of accounts | Account plus dimensions |
|---|---|---|
| Supplies across 3 locations, 5 departments and 5 projects | Up to 75 code combinations for one expense | 1 account, plus 3, 5 and 5 values that combine freely |
| Adding a sixth department | A new code combination on every account it can touch | One new dimension value; no accounts created |
| Reporting on a slice nobody planned for | A new account structure, or a spreadsheet export | Group or filter by that dimension in the report writer |
This is the point in a migration where finance teams tend to relax. The 900-line chart of accounts turns out to be one or two hundred real accounts wearing a costume made of segments. Pulling the segments out is most of the work of designing the new chart.
Standard dimensions, custom dimensions and the class question
Sage Intacct provides standard dimensions out of the box and lets you create user defined ones on top. The standard set generally covers location, department, class, project, task, customer, vendor, employee and item, though availability depends on the modules and edition you subscribe to. Confirm the list against your own subscription, not a generic feature page.
Standard dimensions are already wired into the modules: customer and vendor populate from the transaction, location and department act as the organizational backbone, project and task carry through to time entry and billing. Reports, dashboards and consolidation logic understand them without configuration.
The Sage Intacct class dimension deserves a note, because QuickBooks users recognize the word and assume it maps one to one. It does not. In QuickBooks, class is often the only tag available, so one class list ends up doing three jobs: department, program and line of business. In Sage Intacct those are separate dimensions, and part of design is untangling which job each class value was doing.
Custom and user defined dimensions
User defined dimensions cover what the standard set does not: funding source, grant, campaign, route, service line, cohort, whatever your business actually manages by. They behave like standard dimensions on transactions and in reporting, and they are where most industry-specific value shows up.
The temptation is to create one for every attribute anybody has ever asked about. Resist it. Every dimension is a field somebody has to populate correctly on every relevant transaction, forever. A useful test: name the report it feeds, and name the person who will notice within a week if it stops being populated. If either answer is vague, it belongs as an attribute.
Dimension groups and dimension relationships
Two features arrive later in most projects than they should. Dimension groups bundle values into a named set, so several locations roll up as one region without inventing a parent dimension. Dimension relationships constrain which values are valid together, so a user cannot tag a bill with a project belonging to a different customer.
Groups are a reporting convenience. Relationships are a data quality control, and they are the more valuable of the two. Most dimensional reporting problems are not reporting problems. They are entry problems that surface three weeks later, when a report shows spend against a project that closed last year. Relationships are also far easier to define while you are still mapping old data than to retrofit afterwards.
What dimensional reporting changes about month-end
Dimensional reporting turns a fixed report into a set of views over the same data. In the report writer you choose which dimensions to filter by, group by and column by, so a standard income statement becomes profitability by project or revenue by region without a new report, a new export or a new account structure.
What that removes is more specific than faster reporting. It removes the rebuild. In a segmented ledger, seeing the numbers a different way means a spreadsheet with a manual mapping table, or a chart of accounts change that only applies going forward and makes prior periods incomparable. In a dimensional ledger the transactions were already tagged, so the new view runs across everything posted. That is the foundation the dashboards sit on, and it is worth knowing what finance teams actually build first before you start designing screens.
Multi-entity work benefits for the same reason. Because entity, location and department are dimensions rather than separate ledgers, consolidated and entity-level reporting come from one dataset, so consolidating finances across multiple entities stops being a monthly assembly job. That is why the old datasheets on this topic always paired reporting with consolidations. They are one mechanism seen from two distances.
The honest limit: dimensional reporting is only as good as the tagging discipline underneath it. A dashboard showing department-level margin is showing you the entries that were tagged. If half your card spend arrives as one untagged import, the dashboard is confidently incomplete. That is a process problem, and it gets solved during implementation or not at all.
Designing your dimension structure before you migrate
Dimension design belongs at the front of an implementation, ahead of data migration and configuration. The reason is blunt: you cannot retroactively tag history with context that was never recorded. Whatever your old system did not capture, your opening balances will not have either.
- Start from the questions, not the fields. Collect the reports people actually run and the questions leadership asks that currently need a spreadsheet. Those are your dimension list.
- Sort every existing account segment into a real account, a dimension, or something never worth tracking that got encoded anyway.
- Decide required versus optional per transaction type. A dimension required on AP bills but optional on journal entries produces reports that do not tie.
- Map the QuickBooks class values. Assume each is doing more than one job and split accordingly.
- Decide how much history comes across, and at what grain. Most migrations bring summarized opening balances plus a window of transactional detail, keeping the old file read-only as the archive.
- Name an owner for dimension values. If everyone can create them, you will have three spellings of the same location by the second quarter.
[DATA: How long Lucentive’s dimension design workshop typically runs and how many client reports it usually starts from — Rich to confirm]
What changes for your team after go-live
The visible change on day one is at data entry. Coding an AP bill now means choosing a department and, depending on your design, a project or funding source. Those few extra seconds per bill are where adoption is won or lost, so defaults, relationships and a short list of valid values matter more than any dashboard.
The change that shows up in month two is quieter. Requests that used to route through finance stop doing so. A project manager who can see their own project costs does not email for a report. Finance stops being the reporting bottleneck and starts getting asked harder questions.
One new responsibility appears. Nobody maintains the chart of accounts in the old sense, but somebody owns dimension master data: approving new values, retiring old ones, keeping naming consistent. Teams that assign that explicitly at implementation still have clean dimensional reporting a year later.
Summary
Dimensions are the reason a Sage Intacct chart of accounts can be shorter than the QuickBooks one it replaces while answering more questions. Context moves from the account code onto the transaction, so adding a location or a service line is one new value instead of a wave of new accounts, and any report can be re-cut by any dimension that was captured.
The work is front-loaded. Which dimensions you need, which are required where, how classes map and who owns the value list are decisions made before migration, and they determine whether your reporting is trustworthy a year from now. That is also why the old version of this page ended in a gated datasheet form and this one does not. A datasheet describes a feature. What you need is a decision about your own chart of accounts.
A G2 review badge sat just above that form, and it is worth being plain about what a badge like it settles and what it leaves open.
If you are sizing up a move from QuickBooks or an older Sage product, bring your actual account list and the reports you cannot currently produce. Talk to Lucentive. Our consultants have 25+ years each in mid-market finance systems, and the first thing they will do is start crossing lines off that list.
Frequently asked questions
What are the standard dimensions in Sage Intacct?
The standard set generally includes location, department, class, project, task, customer, vendor, employee and item, with availability depending on which modules and edition you subscribe to. Standard dimensions are already understood by reports, dashboards and consolidation logic, so they need no configuration to work. Confirm the exact list against your own subscription before designing around it, because module scope changes what is available to you.
How is the Sage Intacct class dimension different from QuickBooks classes?
In QuickBooks, class is often the only available tag, so one class list ends up standing in for department, program and line of business at the same time. In Sage Intacct those are separate dimensions. Part of migration design is splitting each existing class value into whichever dimension it was actually representing, which is usually why the class list shrinks and the reporting gets sharper.
How does dimensional accounting differ from Sage 50 or QuickBooks?
Both handle departmental tracking, but mainly through segments inside the account code or a single class field. Context therefore multiplies the account list and is capped by the number of tags the system allows. A dimensional ledger stores context as separate fields on the transaction, so the account list stays flat and several kinds of context coexist on one entry. The difference shows up most when you need a view nobody planned for.
Can we add dimensions after go-live?
Yes, and that flexibility is a real advantage of a dimensional ledger. The limitation is historical: a dimension added in month nine has no values on the first eight months of transactions unless somebody goes back and tags them. Capture anything you already know you will report on from day one.