Dimensional COA: Depth Matters More Than You Think

You picked Sage Intacct for the dimensional COA (chart of accounts). Maybe a consultant talked you out of building 400 GL accounts and into 50 GL accounts plus eight dimensions. Maybe you joined a company that had already done it. Either way, you've been running clean dimensional reporting for a year, and you want to keep it.

Then you start evaluating FP&A platforms and you notice a pattern: every vendor says "we integrate with Sage Intacct." Fewer of them tell you what happens to your dimensions after the integration runs.

‍

What a dimensional COA actually is

A dimensional COA is the structural decision to keep your GL accounts small and pure, and push everything else into orthogonal tags that you can slice and combine freely.

Instead of: 5000 - Salaries - Engineering - San Francisco - Project Apollo

You have: 5000 - Salaries tagged with Department=Engineering, Location=San Francisco, Project=Apollo, Customer=null.

The benefit: you can ask "what did we spend on salaries by project?" and "what did we spend across all expense accounts in San Francisco?" and "what did Project Apollo cost in total?" — all from the same data, without rebuilding the COA every time.

‍

The cost: any system downstream of Sage Intacct that doesn't speak dimensions is going to flatten this back into a clumsy account-string approach.

Why FP&A tools tend to flatten it

FP&A platforms designed before dimensional accounting was common — and many still are — model their data around a hierarchical GL. Department is a level, Location is a level, Account is a level. You can have three or four hierarchies, but they nest. Cross-cutting analysis (Department × Location × Project simultaneously) requires either pivoting or duplicating the model.

When you connect Sage Intacct to a hierarchical-GL FP&A platform, the integration has to decide where to put each dimension. The usual answer is: pick the two most important dimensions, build them as hierarchies, and stash the rest in an "attribute" field that doesn't roll up. The other six dimensions are gone for budgeting purposes.

This is the moment when the cost of switching ERPs to fit the FP&A platform almost starts to make sense. Don't do that. Pick a different FP&A platform.

‍

The reporting use cases you lose when dimensions collapse

• Project profitability across departments. Project Apollo runs across engineering, design, and customer success. With dimensions, you sum across departments by project. Flattened, you're back to a pivot table.
• Customer profitability with cost allocations. Direct revenue per customer is easy. Allocated cost per customer requires dimensions to cross-cut.
• What-if by funder. Nonprofits need to slice every expense by funder to forecast what happens if a grant doesn't renew. With one funder dimension, you toggle. Flattened, you build a separate model.
• Location-level workforce planning. New office in Austin? You want to budget headcount, rent, utilities, and equipment by location independent of department. With a Location dimension, that's a clean slice. Flattened, you're filtering by account-string substrings.

‍

How to test for it during a demo: 3 questions

1. "Take your Sage Intacct demo data and show me Revenue by Customer × Location × Product simultaneously, as one report." If the demo person flips through multiple report tabs to assemble this, the platform has flattened. If it's three drop-downs and one report, you're fine.

2. "What happens if Sage Intacct adds a new dimension after Centage / Limelight / Planful is live?" Native dimensional handling: the new dimension appears in the model automatically on next sync. Flattened: the customer success team logs a remap ticket.

3. "Show me how you budget at the dimension intersection." A dimensional FP&A platform lets you budget at, say, Department × Location simultaneously without exploding the row count. A flattened one either requires you to budget at the lowest level and roll up, or it duplicates the row per intersection. The first approach loses the top-down workflow. The second creates a model so large it stops being maintainable.

‍

Centage's dimensional handling

Centage's data model treats dimensions as first-class objects. Every Sage Intacct dimension — standard or custom — comes through on the native API integration and is available in budgets, forecasts, and reports without any mapping step. You can budget at any combination of dimensions. New dimensions added in Sage Intacct after Centage is live appear in the model on the next sync.

You can also add operational dimensions that don't exist in Sage Intacct — for example, scenario tags or planning categories that only live in the FP&A layer. These don't pollute the ERP and are scoped to Centage's own reporting.

‍

Frequently Asked Questions

Does Centage preserve all Sage Intacct dimensions?

Yes. Every dimension in Sage Intacct — including custom dimensions you've added — is preserved in Centage's model and available across budgets, forecasts, and reports. There is no remapping or flattening step in the integration.

Can I add operational dimensions Centage doesn't see in Sage Intacct?

Yes. Centage supports planning-layer dimensions that exist only within Centage. Useful for scenario tagging, model versioning, or planning categories that don't belong in the ERP.

How are dimensions used in reports vs in budgets?

Identically. Anything you can slice in a report you can budget at. There's no asymmetry where reports support six dimensions but budgets only support two.

What happens if Sage Intacct dimensions change after Centage is live?

The native API integration picks up new dimensions and dimension values on the next sync, automatically. There's no support ticket required.