Sage Intacct Dimensions
Where every Sage Intacct dimension lands in QuickBooks
Sage Intacct gives you fourteen standard dimensions and as many user-defined ones as you care to pay for. QuickBooks Online Advanced gives you two axes that a P&L can actually pivot on. This is how you decide which of your dimensions survive as data, which become reports, and which get retired on purpose.
15,000+ migrations completed · Intuit QuickBooks Solutions Partner (QSP) · IES Migration Partner
Why translating dimensions beats flattening them
There are only two honest ways to move a dimensional chart of accounts into QuickBooks. Most migrations pick the wrong one by default, because flattening is what a CSV export makes easy.
Flattening means folding dimension values into the GL account number itself, so 5010 becomes 5010-100-200 for account, department and location. It imports cleanly on the first attempt, which is exactly why it is tempting. The cost arrives later. Your account list grows as the product of every dimension combination rather than the sum, and you permanently lose the ability to pivot. A flattened chart can be filtered by string position; it cannot be re-cut by a dimension you did not think of when you designed the numbering.
Translating means measuring which dimensions are genuinely populated on posted transactions, mapping the two that carry real reporting weight onto the axes QuickBooks can pivot, routing project-shaped dimensions to Projects or Customer:Job, and rebuilding the rest as report definitions instead of stored data. It takes an assessment and a sign-off. It leaves you with a chart of accounts a controller can still read in three years.
When flattening is the only option
Three situations where we flatten deliberately rather than as a shortcut:
- The destination is QuickBooks Online Plus, where classes and locations share a single hard cap of 40 combined entries. Plus cannot absorb a real dimensional structure and no amount of design work changes that.
- More than two dimensions carry genuine P&L reporting weight and Intuit Enterprise Suite is off the table for budget or timing reasons. Something has to give, and a flattened segment is more honest than a custom field that silently cannot report.
- The dimension is a true accounting segment rather than an analysis tag, for example a fund in a nonprofit that must appear on every line of a statutory statement. A segment that is legally required on the face of a statement belongs in the account structure.
If your board pack still runs on maintained dimensions and the model is trusted, optimization may beat migration. We will say that on discovery rather than force a map.
The decision is not stylistic. It is a measurement. Before anyone designs a mapping, we count how many of your dimensions are actually populated on posted transactions over the last two fiscal years. In most Sage Intacct environments the answer is four to eight, not fourteen, and roughly half of those turn out to be populated on under five percent of lines.
The mapping table
Where each Intacct dimension type lands
Sage Intacct ships fourteen standard dimensions. This is the destination we recommend for each one in QuickBooks Online Advanced, QuickBooks Enterprise and Intuit Enterprise Suite. Anything marked as a report is rebuilt as a report definition rather than carried as a field.
| Intacct dimension | QuickBooks Online Advanced | QuickBooks Enterprise | Intuit Enterprise Suite |
|---|---|---|---|
| Location | Location | Class, or a second class segment | Dimension |
| Department | Class | Class | Dimension |
| Class | Custom field, or merged into Class naming | Class segment | Dimension |
| Project | Project | Customer:Job | Project dimension |
| Task | Sub-project, or retired | Job sub-level | Project dimension |
| Customer | Customer | Customer | Customer |
| Vendor | Vendor | Vendor | Vendor |
| Employee | Vendor or Employee record | Employee | Employee |
| Item | Product or service | Item | Item |
| Warehouse | Location, if not already used | Site, with Advanced Inventory | Location dimension |
| Contract | Custom field on the transaction | Custom field on names | Dimension |
| Cost type | Sub-account, or report | Item type or sub-account | Dimension |
| Asset | Fixed asset register, outside the GL | Fixed asset item | Fixed asset |
| Affiliate entity | Separate company file | Separate company file | Entity in the hierarchy |
| User-defined dimensions | Custom field, reporting caveat below | Custom field on names or items | Dimension |
The caveat that decides most of these rows. A QuickBooks Online custom field cannot produce a profit and loss report. Intuit states plainly that the capability does not exist. Custom fields surface in transaction-level reports such as Transaction Detail by Account, Sales by Customer and Customer Balance Detail, and nowhere else. So a dimension you move into a custom field is searchable and auditable, but it is no longer a reporting axis. If a dimension needs to slice your P&L, it has to become a class, a location, a project, or an IES dimension. There is no fourth option.
Do not build a mapping on Tags. Intuit has retired QuickBooks Online tags: they were withdrawn for new users on 19 May 2025 and existing users can rely on them only until 19 May 2028. A dimension parked in Tags is a dimension with an expiry date.
How much dimensional capacity each destination really has
The mapping above is only feasible inside these limits. They are the reason the destination decision has to come before the mapping decision, not after.
| Capability | QBO Plus | QBO Advanced | QuickBooks Enterprise |
|---|---|---|---|
| Classes and locations | 40 combined, hard cap | Unlimited | 100,000 classes |
| Chart of accounts | 250 | Unlimited | 100,000 |
| Custom fields | 4 per transaction | 12 per transaction | 30 on names, 15 on items |
| Values per custom field | 100 | 100, so 1,200 in total | Free text or list |
| Custom field on a P&L | No | No | No |
| Billable users | 5 | 25 | Up to 40 |
Two pivotable axes in QuickBooks Online Advanced, against four to eight populated dimensions in a typical Sage Intacct tenant. That gap is the entire migration design problem, and it is arithmetic rather than opinion.
Where Intuit Enterprise Suite changes the arithmetic
IES is the only destination in the family with genuine multi-dimensional reporting rather than two axes plus custom fields. As of the Summer 2026 release, dimensions are applied at the transaction header level rather than line by line, they can be reclassified as your reporting structure changes, they carry across billable expenses, time and recurring payments, and reports support multi-level pivots so several cuts stay in view at once.
Two limits worth knowing before you assume IES solves everything. Balance Sheet by Dimension is still in beta and covers a single entity, with consolidated multi-entity views expanding later this year. And dimensional richness does not remove the need for a mapping: it raises the ceiling on how many dimensions can survive the move, which changes the answer to the translate-or-flatten question rather than removing the question.
What breaks when you migrate from a raw CSV dump
A general ledger export gives you debits, credits, dates and account codes. It does not give you the structure that made those numbers mean something. Four things are missing every time, and all four are discovered after cutover rather than before, unless someone looks for them.
1. Allocation definitions come out as results, not as rules
Sage Intacct allocations can be driven by a statistical account, by relative financial account balances, or by any standard or user-defined dimension, and recurring allocations true up automatically by reversing the prior run. Calculation parameters are attached to each journal entry, so the export shows you the allocated amounts. It does not show you the basis. Rebuild the definitions from the allocation setup before the instance closes, or your first post-migration month end produces numbers nobody can explain or reproduce.
2. Statistical accounts are not in your GL range
Statistical accounts hold non-financial quantities such as headcount, member counts or square footage, and Sage’s own guidance is to put them in a separate account range precisely so they are not grouped with GL accounts. A general ledger export scoped to your GL range therefore excludes them by definition. Every allocation and every per-unit metric that depends on them breaks silently, because the amounts still import and only the drivers vanish.
3. Multi-entity dimension values collide
Dimension values are frequently reused with different meanings across entities, so Department 200 is Operations in one entity and Clinical in another. A flat export concatenates them into one list. Consolidated reporting then aggregates two unrelated things under one label, and the total still foots, which is what makes this failure so hard to catch.
4. Report trees carry no data at all
Account groups and reporting trees are the structures that turn a dimensional ledger into a board pack. They are definitions, not transactions, and nothing about them appears in a GL export. Inventory every saved report and every account group before the contract ends, because API access ends when the contract ends.
The mapping workbook, and the sign-off before cutover
The mapping is a deliverable your controller approves in writing, not a decision buried in a migration script. Five steps, and nobody touches the destination until step four is signed. The mapping track itself typically runs about two weeks, ahead of and separate from the migration timeline.
- 01
Inventory every dimension in use
Pull the full dimension list, standard and user-defined, with the member count for each. This is the list on paper, and it is almost always longer than the list in practice.
- 02
Measure what is actually populated
For each dimension, count the share of posted transaction lines carrying a value over the last two fiscal years. Dimensions populated on under five percent of lines are candidates for deliberate retirement, not migration.
- 03
Rank by reporting dependency
Walk the saved reports and the board pack, and record which dimension each one groups or filters on. A dimension that drives a report an executive reads every month outranks one with more members and no consumers.
- 04
Draft the workbook and get it signed
One row per dimension, with the destination field, the transformation rule, the retirement decision where it applies, and the named report that justifies it. Your controller signs this before any data moves. This is the step that gets skipped and the step that prevents the argument in month two.
- 05
Reconcile dimensionally, not just in total
Trial balance agreement alone will not catch a mapping error, because a misrouted dimension still foots. We compare the dimensional reports side by side, source against destination, for every report named in step three, and the controller signs again before the source goes read only.
Questions we get on dimension mapping
How many Sage Intacct dimensions can QuickBooks actually report on?
Two, in QuickBooks Online Advanced: class and location, both of which are unlimited on that tier and both of which a profit and loss report can group by. Projects adds a third axis for project-shaped work. QuickBooks Enterprise gives you class plus Customer:Job. Intuit Enterprise Suite is the only destination with genuine multi-dimensional reporting and multi-level pivots. Custom fields are not a reporting axis on any tier, because QuickBooks Online custom fields cannot produce a P&L at all.
Can we keep all fourteen standard dimensions?
Not as reporting axes, and in practice you do not want to. Sage Intacct ships fourteen standard dimensions and allows user-defined ones on top with no published cap, but the number in use is what matters. Most tenants we assess post against four to eight, and several of those are populated on a small minority of lines. The mapping workbook decides which become fields, which become reports, and which are retired on purpose with the reason recorded.
What happens to a dimension we move into a custom field?
It stays searchable and auditable and it appears in transaction-level reports such as Transaction Detail by Account, Sales by Customer and Customer Balance Detail. It will not slice your profit and loss, now or later, because Intuit states that capability does not exist for custom fields. Treat a custom field as a place to preserve a value for audit, never as a substitute for a reporting dimension.
Should we use Tags instead?
No. Intuit retired QuickBooks Online tags for new users on 19 May 2025, and existing users can rely on them only until 19 May 2028. Any mapping built on tags has a known end date, and rebuilding a dimensional structure twice costs more than designing it correctly once.
Do our allocations survive the migration?
The allocated amounts import. The allocation logic does not, because a general ledger export contains results rather than rules. Sage Intacct allocations can be driven by statistical accounts, by relative account balances, or by dimensions, so the basis has to be documented from the allocation setup and then rebuilt in the destination or moved into a recurring schedule. Capture the definitions while the instance is still live: API access ends with the contract.
What about statistical accounts like headcount or square footage?
They will not be in a GL export. Sage’s own guidance is to keep statistical accounts in a separate account range so they are not grouped with general ledger accounts, which means a GL-scoped export excludes them. They have to be pulled deliberately and then rebuilt, usually as a small reference table feeding a report rather than as accounts in the destination.
We use dimensions as funds and grants. Does that change the mapping?
Yes, and it usually pushes the answer towards the account structure. A fund that has to appear on the face of a statutory statement is an accounting segment, not an analysis tag, so it belongs in the chart of accounts or in a class hierarchy rather than a custom field. Intuit Enterprise Suite handles fund and grant tracking through its dimensional structure, which is why nonprofit exits from Sage Intacct more often land on IES than on QuickBooks Online.
Can we run the two systems in parallel while we validate the mapping?
Yes, and for a dimensional migration you should. The migration runs alongside the live instance so your team keeps posting and closing, and we compare the dimensional reports side by side before anything is cut over. Trial balance agreement is necessary but not sufficient here, because a misrouted dimension still foots to the correct total.
Where to go next
Sage Intacct Migrations
The service page: scope, method, and how a dimensional exit is sequenced so your close is not the test.
Export These Seven Things Before the Instance Goes Dark
Dimensions, allocation logic, statistical accounts and attached documents do not come out in a CSV, and the API dies with the contract.
Get your dimension mapping assessed before you commit to a destination
Bring your dimension list, your saved report inventory and your board pack. You leave knowing how many of your dimensions are genuinely in use, which destination can carry them, and what the mapping workbook will look like.
Also useful: Intuit Enterprise Suite vs Sage Intacct and the full playbook library
Next step
Book a dimension mapping review.
Thirty minutes, with your dimension list open.