QuickBooks to Sage Intacct Migration: Multi-Entity & Dimension Mapping

Moving from QuickBooks to Sage Intacct is not a lift-and-shift. It is a structural data transformation — from a flat Chart of Accounts with classes and locations bolted on as tags, to a dimensional general ledger where every transaction can be sliced by location, department, project, customer, and custom dimensions independently. If you treat this as a simple export-and-import, your GL will not balance, your reports will break, and your finance team will spend weeks reconciling in the same spreadsheets you were trying to escape.

This guide covers the specific technical mapping between QuickBooks and Sage Intacct's architecture, multi-entity consolidation design, historical data import strategy, API and CSV import constraints, and a direct comparison of migration methods — so your team can plan the move with real constraints, not vendor promises.

For the broader context of why ERP data migrations fail, see Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Why Growing Multi-Entity Companies Outgrow QuickBooks

QuickBooks works well for single-entity companies with straightforward reporting needs. A company with one entity, one revenue stream, and a small finance team can run comfortably in QuickBooks — the data stays manageable, and reporting is straightforward because the business itself is straightforward. The problems start when the org chart outgrows the software's architecture.

The Multi-Entity Wall

QuickBooks Online does not have native multi-entity functionality — unlike NetSuite or Microsoft Dynamics, QBO treats each company file as a completely separate database. If you manage five entities, you are logging into five separate company files, exporting five separate trial balances, and manually eliminating intercompany transactions in a master spreadsheet. In Sage's Anchor Loans case study, the finance team described exporting financials from QuickBooks to Excel across 43 entities and working through a 25-tab spreadsheet. (sage.com)

Consolidations of multi-entities simply can't be done in QuickBooks. If your accounting staff is still using QuickBooks, they need to consolidate the data as best they can using spreadsheets — a process that's cumbersome and time-consuming to the point that the data is already out of date by the time the consolidation is accomplished.

If entities are more like segments than separate legal companies, QuickBooks classes and locations can serve as the answer — you run one company file and use classes to distinguish between entities, tagging each transaction with a class. This works well when you don't need separate balance sheets or when the entities are closely related. But once you need separate balance sheets, separate tax IDs, or intercompany elimination entries, classes and locations stop scaling.

QuickBooks also bends under multi-entity reporting because its tracking fields do not behave the same way. Intuit documents that classes are linked to transaction details, while locations are linked to both headers and details — that is why a balance sheet by class is not reliable in the same way as a balance sheet by location. Intuit lets you nest classes up to five levels, which sounds flexible but often means one field has been carrying department, region, product line, and program semantics all at once. (quickbooks.intuit.com)

Chart of Accounts Bloat

In QuickBooks, tracking revenue or expenses by department, location, and entity requires creating a new GL account for every possible combination. If you have 10 expense accounts, 5 departments, and 4 locations, you do not have 10 accounts — you have 200.

A shared chart of accounts across multiple entities is not a feature available in QuickBooks. Staff must spend many hours adding every common new vendor, customer, expense, income, or change in inventory to each individual appropriate entity. The potential for errors and missed entries become enormous the more you grow your organization.

Sage Intacct was built for exactly this inflection point. It manages all entities within a single environment. Intercompany eliminations are automated, and consolidated reporting happens in real time. Automated consolidations reduce your monthly close time by up to 79%. It automates multi-entity consolidations — whether you have two entities or hundreds.

But to achieve this, your data must be restructured during the migration — not just moved.

The Core Challenge: Mapping QuickBooks Classes to Sage Intacct Dimensions

This is where most migrations either succeed or go sideways. The architectural difference between the two systems is fundamental, not cosmetic.

In QuickBooks, your Chart of Accounts is a single flat list of numbered accounts. Classes and Locations are optional tags applied to transactions for basic segmented reporting. If you want to track 3 locations across 5 departments and 5 projects, you either create one massive flat account list or rely on class/location tagging that only goes one level deep.

Most financial solutions use a hard-coded structure for your chart of accounts. To track 3 locations, 5 departments, and 5 projects, you'd need 75 account code combinations — and adding a new location or department could force you to add hundreds of additional accounts. Sage Intacct dimensions accounting software lets you keep it simple — you only need to set up your primary account codes. As your business changes, there's no need to add hard-coded segment combinations.

Sage Intacct comes with eight built-in dimensions: location, department, vendor, customer, employee, project, item and class. You can also create user-defined dimensions (UDDs) when none of the eight built-in dimensions apply.

The Mapping Table

There is no safe one-to-one field map from QuickBooks to Intacct. The right target depends on business meaning, not on matching the label "Class" to the label "Class."

QuickBooks COAs rarely map directly into Intacct. Migration is the best time to redesign around dimensions for scalability.

COA Compression in Practice

Suppose your QuickBooks COA contains:

5100-NYC-Rent
5100-LA-Rent
5100-CHI-Rent
5200-NYC-Utilities
5200-LA-Utilities
5200-CHI-Utilities

In Sage Intacct, this becomes:

Account: 5100 (Rent)
Account: 5200 (Utilities)
Location dimension values: NYC, LA, CHI

Six accounts become two accounts plus three dimension values. At scale — 50 expense accounts across 10 locations — that is the difference between 500 accounts and 60 setup records. Dimensions are smart tags you apply to transactions. Instead of multiplying accounts for every reporting combination, you keep a lean chart of accounts and assign context such as location, department, project, or customer.

The mapping often looks more like decomposition than conversion. Here is how a single QuickBooks transaction line typically decomposes:

quickbooks_source:
  account: '6100-Marketing-West'
  class: 'Events:Field'
  location: 'US-West LLC'
intacct_target:
  gl_account: '6100 Marketing'
  entity: 'US-West LLC'
  department: 'Marketing'
  class: 'Events'
  custom_dimension_channel: 'Field'

If that feels like more transformation than you expected, that is the point. QuickBooks to Sage Intacct migration is less about moving rows and more about separating legal structure, managerial reporting, and transactional coding before history gets loaded.

Document your mappings (COA→COA, classes/locations→Dimensions) — good documentation means smoother audits.

Multi-Entity Setup: From Separate QB Files to One Intacct Environment

If you are running three QuickBooks files for three entities today, you are moving into a single Sage Intacct company with multiple entities under one umbrella.

In a multi-entity shared company, entities represent a separate tax identification or a separately secured, fully balancing set of books. Entities typically represent divisions, franchises, affiliates, associations, locations, chapters, self-balancing funds or subsidiaries, with a shared chart of accounts. The company has a set of data lists that's shared among all entities — including users, chart of accounts, customers, suppliers, and employees. Administrators define the shared data lists once at the top level.

This is a significant architectural shift. In QuickBooks, each file has its own COA, its own vendor list, and its own customer list. In Intacct, these are shared. That means:

• COA standardization is required before migration. If Entity A uses account 6000 for "Marketing" and Entity B uses 6000 for "Travel," you need to resolve that before importing anything.
• Vendor/customer deduplication is mandatory. The same vendor might exist in all three QB files with slightly different names, terms, or addresses. Intacct's shared lists mean one record per vendor, period.
• Inter-entity transactions get automated. Sage Intacct records inter-entity transactions separately from other types of receivable and payable transactions. For each entity in your company, you can specify the payable and receivable accounts you want to use for inter-entity transactions. No more manual Due-To/Due-From entries in Excel.

If you have the Multiple Entity Package (MEP) in your contract and will have less than 1,000 entities in the system, there is no additional cost to add a new entity.

Intacct also requires inter-entity receivable and payable configuration in multi-entity shared companies, and if you have partial ownership, it supports formal ownership structures for consolidation. That is a very different target architecture from a single QuickBooks company with tracking fields layered on top. (developer.intacct.com)

Historical Data Import: What to Move and What to Leave Behind

This decision shapes your entire migration timeline. Most teams default to "bring everything" — and that is almost always a mistake.

It is rarely necessary — or cost-effective — to bring every past transaction. Most companies use a balanced approach: detailed history for recent years, with older transactions summarized or kept in QuickBooks read-only.

Migrating full transactional history clutters the new system, inflates API usage, and forces you to map thousands of obsolete vendors and deprecated accounts into your clean Intacct environment.

For a deeper exploration of what to migrate and what to archive, see What Data Should You Actually Migrate to Your New ERP?.

The Hybrid Approach (Recommended)

Most companies migrate 2–3 years of transaction history as summary journal entries (monthly GL balances by account) and keep the QuickBooks file as a read-only archive for detail lookups.

Here is what that looks like in practice:

The single highest-risk moment in any QuickBooks migration is the opening balance load. Every balance sheet account in the new ERP must match the closing balance in QuickBooks to the penny on the cutover date.

Whatever scope you choose, build the reconciliation pack before final load: closing trial balance, AR/AP aging, bank reconciliation checkpoints, and the management reports executives actually read. If the mapped Intacct output does not tie back to those control reports, you are not ready.

For the full pre-migration validation process, see our Accounting Data Migration Checklist: The 10-Point Plan.

Sage Intacct's Import Dependencies and API Limits

Sage Intacct's import system is powerful but unforgiving. Two constraints catch teams off guard every time: dependency sequencing and API transaction limits.

Dependency Sequencing: Order Matters

CSV imports must be performed in a specific order because of dependencies within the data. For example, if you have transactions that require locations, but you have not entered or imported the locations, the transaction import fails.

The best practice is to import foundational information — for example accounts, departments, or locations — before you can successfully import transaction data. If the supporting information does not exist, the transaction import will fail.

The correct import order for a QuickBooks-to-Intacct migration:

1. Dimensions first: Locations, departments, classes, projects, custom UDDs
2. Chart of Accounts and terms: Base GL accounts, AR terms, AP terms, tax codes
3. Master data: Vendors, customers, employees, items
4. Open items: AR invoices, AP bills (which reference vendors, customers, accounts, terms, and dimensions)
5. Balances and history: GL journal entries, opening balances

If you try to import an AR Invoice for "Acme Corp" with "Net 30" terms before the "Acme Corp" customer record and the "Net 30" term record exist, the API will reject the transaction entirely. Required fields must contain the ID of the related record, such as the account number for a General Ledger account. The data entered must match what's in Intacct exactly.

API Performance Tier Limits

If you are using the Sage Intacct API (REST or XML) for migration instead of manual CSV uploads, you need to understand performance tiers.

Performance Tier 1 is the standard tier and is included at no cost to each Sage Intacct customer. Tier 1 allows for a generous amount of monthly API transactions but limits offline concurrency processing to a single job. Tier 1 is designed for customers who do not plan to exceed 100,000 monthly API transactions. This performance tier will meet the needs of over 95% of all Sage Intacct customers.

100,000 transactions sounds like a lot — until you are importing years of GL history, thousands of vendor records, tens of thousands of AR invoices, and AP bills across three entities. Each API call counts.

If you go over the allotted number of transactions in a month, you will receive a bill for the overage. Intacct charges the overages in "packs" of ten transactions. The overage fee for Performance Tier 1 subscribers is $0.15 per pack.

The math: If a migration pushes 223,000 API transactions in a single month, the overage is (223,000 − 100,000) / 10 × $0.15 = $1,845 in unexpected fees.

API transactions from authorized Marketplace Partners, ISV solutions, and Sage Intacct's own applications do not count against the Performance Tier transaction entitlement purchased by a customer. If your migration partner's tools are Marketplace-authorized, their API calls may not count against your tier.

Concurrency and Extraction Limits

The real killer is the offline process queue. At the standard Performance Tier 1, Sage Intacct limits each company to one concurrent offline process. Large CSV imports processed offline queue behind each other — and behind other companies — adding hours to your migration window.

Sage's Performance Tier white paper lists Tier 1 with an API throttle of 6 concurrent requests per app and 8 per company. Do not assume you can brute-force a migration with massive parallelism. (developer.sage.com)

On the extraction side, QuickBooks Online query responses return at most 1,000 entities per response, while Sage Intacct query pages top out at 2,000 and rely on offsets for the rest. Sage warns that offset calls are separate queries, so if the underlying data changes between pages you can miss records. Freeze source posting before the final pull, or you invite reconciliation drift that is hard to explain later. (developer.intuit.com)

To avoid overage costs, your migration scripts must batch transactions around document headers. Instead of sending 50 individual API calls for a 50-line AP Bill, the payload should be structured to send the header and all 50 line items in a single, well-formed API request. One AP Bill header counts as one API transaction even if it contains many line items.

Migration Methods: DIY CSVs, VARs, or Dedicated Services

Three main approaches exist. Each has real trade-offs.

Option 1: DIY CSV Imports

Your team exports data from QuickBooks, manually reshapes it in Excel to match Sage Intacct's CSV templates, and uploads file by file through Company > Setup > Import Data.

Where it works: Small, single-entity migrations with minimal history and a clean COA.

Where it breaks: Multi-entity migrations with COA standardization and vendor deduplication across files. Large transaction volumes that exceed what manual Excel manipulation can handle without errors. Intacct recommends removing all commas from your CSV file. If there are commas in the data of your file, your data will be shifted 1 column over — which will either cause errors in the information, or cause the whole import to fail. Formatting thousands of multi-dimensional journal entries in Excel almost guarantees reconciliation errors.

Option 2: Implementation Partners (VARs)

Your VAR handles system configuration, COA design, workflow setup, and user training — and includes data migration as a line item in the statement of work.

Where it works: VARs understand Sage Intacct configuration deeply. A VAR with experience in your field understands your unique needs — chart of accounts redesign, and transitioning to Sage Intacct's dimensional COA requires a thoughtful redesign.

Where it breaks: Data migration is typically not a VAR's core competency. The standard pattern: VAR provides blank CSV templates, tells your finance team to fill them out, reviews the result, and uploads. The actual extraction, transformation, and deduplication work falls back on your team. For a deeper look at this dynamic, see Why Data Migration Isn't Implementation.

Option 3: Dedicated Migration Service

A specialist team handles the complete ETL pipeline — extraction from QuickBooks (Desktop SDK, QBO API, or file exports), transformation to Intacct's dimensional structure, dependency-sequenced loading, and reconciliation against source data.

Where it works: Multi-entity migrations, migrations with 50,000+ transactions, and any migration where the finance team cannot afford to spend weeks filling out templates.

Where it breaks: Adds a third party to the project (alongside VAR + Intacct). Requires coordination between implementation and migration timelines.

Common Failure Modes

1. Importing a bloated COA without dimensional redesign. If you bring 500 segment-encoded accounts into Intacct instead of compressing them into 80 base accounts + dimensions, every report will require manual filtering and your team will be back in Excel within a month.

2. Loading transactions before master data. Transaction data should not be imported before information about the transactions has been imported. In practice, teams forget that a dimension value, a payment term, or an exchange rate type needs to exist before any transaction referencing it can load.

3. Migrating all transactional history. Transferring all historical data is often a bad choice. This can add 3 to 5 weeks and usually provides little value after the first few years. Limit the migration to 2 to 3 years of details and opening balances unless there's a clear need for full history.

4. Ignoring API overage costs. If you are migrating via API and you push 250,000 transactions in a month on Tier 1, that is a $2,250 surprise invoice from Sage. Budget for it or batch across months.

5. Not running a sandbox test. Dry runs are essential. Load a test set (masters + trial balance + a slice of open AR/AP) into a sandbox and reconcile: trial balance in Sage Intacct = closing TB in QuickBooks at the cutover date. Aged AR/AP detail ties out. Key reports (e.g., P&L by department/project) render correctly with Dimensions.

6. Expecting data cleanup to happen during migration. Data cleanup is a prerequisite, not a parallel task. Migrating messy data into a new system doesn't clean it — it just relocates the mess somewhere more expensive. Vendor records, customer master data, and historical balances should be reconciled before migration.

7. Skipping vendor/customer deduplication across entities. When merging separate QuickBooks files into one Intacct environment, the same vendor often exists in all three with slightly different names, terms, or addresses. If you do not deduplicate before import, Intacct's shared lists will contain conflicting records that create downstream integrity issues.

How ClonePartner Handles QuickBooks-to-Intacct Migrations

We sit in the dedicated migration service category — focused on the technical gap that VARs leave behind: the actual extraction, transformation, and loading of complex financial data. We do not hand you blank templates. We engineer the pipeline.

Programmatic dimensional mapping. Our migration scripts take your flat QuickBooks COA, identify the segments encoded in account numbers or names, and programmatically map them to the correct Intacct dimensions. The output is a documented crosswalk that your team reviews and approves before anything loads.

Dependency-aware sequencing. Our import pipeline automatically creates parent records (dimensions, terms, vendors, customers) before the transactions that reference them. No manual ordering, no failed imports because a term code does not exist yet.

API limit management. We optimize transaction batching — grouping line items under AP bill headers, consolidating GL journal entries by period — to stay well within Tier 1 limits. For high-volume migrations, we pre-calculate the total API transaction count and flag overage risk before the first record loads.

Multi-entity deduplication. When merging separate QuickBooks files into one Intacct environment, we run automated matching against vendor names, addresses, and tax IDs to surface duplicates before they create data integrity issues in Intacct's shared lists.

Trial balance reconciliation. Every migration includes automated TB comparison between QuickBooks source data and Intacct loaded data. Discrepancies are flagged down to the penny before cutover.

Three Questions Before Your First Import

The safest way to approach a QuickBooks to Sage Intacct migration is to answer three questions before the first import file exists:

1. Which QuickBooks locations are legal entities? If they need separate balance sheets and tax IDs, they become Intacct entities, not location dimensions.
2. Which class values really represent separate dimensions? If one class tree is doing triple duty as department, region, and program, it needs to be decomposed — not imported as-is.
3. How much history needs to live inside Intacct on day one? If the answer is "everything," push back. Two to three years of monthly summaries plus open items is the right scope for almost every company.

Answer those early and the rest becomes a controlled engineering project. Answer them late and you spend the first close undoing your own migration.