Sage Intacct to NetSuite Migration: Step-by-Step Guide

Migrating from Sage Intacct to NetSuite is a model redesign, not a data copy. Sage Intacct is a financial management system built around a flat chart of accounts plus flexible dimensions. NetSuite is a unified ERP where accounting lives alongside inventory, CRM, and supply chain, organized around subsidiaries, classifications, and custom segments.

This structural gap dictates the migration strategy. You cannot perform a straight export and import. The work that actually determines success is translating Intacct's dimension-tagged subledger into NetSuite's subsidiary-and-segment model without breaking open AR/AP fidelity or losing reporting granularity.

This guide covers the specific technical decisions you need to make: dimension-to-segment mapping, chart of accounts restructuring, the open-balance-versus-full-history trade-off, multi-entity and intercompany handling, export and import limits on both sides, cutover sequencing, and reconciliation. For the architectural differences between these two platforms, see Sage Intacct vs NetSuite: The Technical Architecture Guide.

How Do Intacct Dimensions Map to NetSuite Segments?

Map by business meaning, not field names. Sage Intacct uses a flexible dimensional model rather than a rigid chart of accounts. You can tag transactions with 8 standard dimensions (department, location, project, customer, vendor, employee, item, class) plus additional user-defined dimensions — and report across any combination. NetSuite handles classification differently: subsidiaries are the primary legal-entity organizer in OneWorld, and classification fields (Department, Class, Location) plus custom segments are applied at the line-item level of a transaction.

The first mistake teams make is mapping by label alone. An Intacct entity is a separate tax ID or a fully balancing set of books — the closest structural match to a NetSuite subsidiary. An Intacct location rolls up to one entity and shares that entity's tax ID, so it should not become a NetSuite subsidiary unless it truly represents a legal or balancing entity. Map by accounting meaning: legal entity, operating site, management cost center, product classification, or reporting-only tag.

Here is the typical mapping pattern:

Intacct Dimension	NetSuite Target	Notes
Entity	Subsidiary (OneWorld)	Drives legal reporting, currency, and tax nexus
Department	Department	Direct 1:1 map in most cases
Location	Location	Direct 1:1 map — only when it represents an operating site, not a legal entity
Class	Class	Direct 1:1 map
Project	Custom Segment or Project record	Depends on whether you use NetSuite's project module
Customer / Vendor	Entity records	Map to Customer/Vendor body fields
Employee	Employee record	Linked via transaction fields
User-Defined Dimensions	Custom Segments	Each creates underlying custom field components

You can create as many custom segments as you need, set possible values for each one, and add them to specific record types. People using NetSuite can then use the segments to classify records as needed. You can configure segments to display on the GL Impact page.

Custom segments must be created in NetSuite first, values loaded, and the segment applied to the target record types before transaction loads. If a dimension needs to appear on the GL Impact page for consolidated P&L slicing, it must be a List/Record type with GL impact enabled.

Two traps to watch for:

• Performance cost. Applying more than five Custom Segments to transaction line items can degrade NetSuite's UI and SuiteTalk API performance. Consolidate low-usage Intacct dimensions before migrating. If a dimension only supports legacy analytics, archive it in your history extract rather than reproducing it in the target.
• Multiple Select limitations. Multiple Select segment types have limitations: the segment can't have GL impact, cannot be applied to transaction columns, does not support multi-selects on multiple Custom Segments, and cannot configure dynamic defaulting.

How to Rebuild the Chart of Accounts

Rebuild the chart of accounts — do not clone every Intacct account and reporting artifact. Sage Intacct is designed with modern Dimensions tagging for accounting. Your business can easily generate reports with dimensions as different filters. Your company can shorten its chart of accounts compared to other ERP systems because Dimensions don't require account coding.

NetSuite uses a combination of account numbers, subsidiaries, departments, classes, locations, and custom segments to drive reporting. The COA typically needs expansion in some areas (intercompany accounts, elimination accounts) and consolidation in others (dimension-specific accounts that become segments).

Practical steps for the COA rebuild:

1. Export the Intacct COA — pull all accounts with their category, type, normal balance, and status via the GLACCOUNT API object or DDS.
2. Identify dimension-encoded accounts — any account that exists solely to separate a dimension value (e.g., "Revenue — East Region") should collapse into a single account plus a Location or custom segment value.
3. Map account types — Intacct account types (Revenue, Expense, Asset, Liability, Equity) map to NetSuite's account type list, but NetSuite has more granular sub-types (Other Current Asset, Fixed Asset, Contra-Asset, etc.). A mismatch here breaks financial statements. For example, Intacct's Accumulated Depreciation must map to a specific Fixed Asset or Contra-Asset account type in NetSuite.
4. Add intercompany and elimination accounts — NetSuite requires dedicated accounts for intercompany receivables and payables. These accounts are used exclusively for transactions between entities. This separation makes elimination straightforward. Elimination accounts are required for consolidated reporting under OneWorld.
5. Standardize account numbers — NetSuite requires unique account numbers across all subsidiaries (unless Multi-Book is enabled with separate numbering). If your Intacct environment uses alphanumeric account IDs, convert them to a numeric format. NetSuite supports account numbers up to 60 characters.
6. Define parent-child hierarchy — NetSuite supports parent-child account hierarchies natively, with summary parents as non-posting rollups. Map Intacct account groups to NetSuite parent accounts to preserve roll-up reporting.

Sage Intacct's alternative reporting accounts feature allows for a shared single chart of accounts across countries, which means simpler consolidations that don't require mappings between accounts. NetSuite does not have this concept. You will need explicit account mappings per subsidiary if local GAAP requirements differ from group reporting.

In OneWorld, the Subsidiary field is required for chart of accounts imports. Build the NetSuite COA around target reporting, target subsidiaries, and target transaction flows, then map Intacct accounts into it with a crosswalk you can version-control.

Open Balances vs Full Transaction History

This is the most consequential scoping decision in any Sage Intacct to NetSuite migration. Historical migration is one of the most important decisions in a Sage Intacct to NetSuite project. Bringing every transaction into NetSuite sounds appealing, but it is not always the best path.

You have four options, each with different cost and risk profiles:

• Open transactions only — Open transactions only, with historical reports retained outside NetSuite. Migrate unpaid invoices, outstanding bills, unapplied payments, and open POs. Historical reporting stays in Intacct or an archive.
• Summary balances by period — Summary balances by period support comparative financial reporting without full transaction detail. Load journal entries per period to establish historical trial balances in NetSuite. This preserves comparative financials (e.g., year-over-year income statements) without transactional noise.
• Limited transaction history — Limited transaction history, such as the current year and the prior year. Provides drill-down capability for recent audit periods.
• Full historical migration — Full historical transaction migration is used only when the business case justifies the effort and complexity. Every invoice, bill, payment, and journal entry is recreated in NetSuite. Expensive and slow.

For most migrations, the right answer is open transactions plus summary GL balances for 2–3 prior years. This gives auditors comparative financials in NetSuite while keeping the scope manageable.

Full transaction history migrations typically triple the timeline and cost. Every document must be loaded in chronological sequence with correct posting dates, and NetSuite's CSV import has hard limits: 25,000 records or 50 MB per job, 10,000 lines per journal entry via CSV, and 5,000 lines per sales invoice or bill. That volume constraint alone makes full history a deliberate exception, not the default.

If auditors or business units require access to historical line-level transactions, keep the data in Intacct (read-only) or store Intacct exports in a BI tool (Snowflake, BigQuery) or cold-storage database rather than forcing it into NetSuite.

Subledger integrity check: The sum of the open AR and AP transactions loaded into NetSuite must tie exactly to the AR and AP control account balances in the cutover-period journal entries. If they do not, you have a reconciliation gap from day one.

How to Handle Multi-Entity and Intercompany Migration

Treat multi-entity and intercompany as a dedicated workstream, not a side effect of the GL load. Multi-entity management is where Intacct shines brightest. Setting up new entities is straightforward, intercompany transactions automate cleanly, and consolidated reports pull together without manual effort. NetSuite achieves this through the OneWorld module, but with a stricter hierarchical subsidiary structure.

Your NetSuite OneWorld hierarchy can include an elimination subsidiary for each level in the hierarchy. Your subsidiary hierarchy must include one or more elimination subsidiaries under the root subsidiary level before you enable the Automated Intercompany Management feature.

Migration steps for multi-entity:

1. Map Intacct entities to NetSuite subsidiaries — each entity becomes a subsidiary record with its own currency, fiscal calendar, and tax nexus configuration.
2. Build the subsidiary hierarchy first — parent-child relationships must be defined before any transaction data is loaded. This hierarchy cannot easily be changed once transactions are posted.
3. Create elimination subsidiaries — you will need to create at least one elimination subsidiary under the root subsidiary level. Create a separate elimination subsidiary for each level in your hierarchy so you can easily track the eliminations at each level. This elimination subsidiary is where all your elimination entries will be recorded.
4. Define intercompany relationships — Properly configured Intercompany Relationships are required for NetSuite's automated elimination process to function correctly. Incomplete or incorrect relationship configuration is the most common cause of elimination failures. Map Intacct's inter-company relationships to NetSuite's "Intercompany Customers" and "Intercompany Vendors" record types.
5. Migrate entity by entity — load master data and transactions per subsidiary, then validate intercompany balances net to zero at consolidation.

Two practical consequences that matter during migration:

• Reconcile intercompany due-to/due-from before cutover. Do not assume NetSuite will sort out intercompany imbalances after loading. Any imbalance at consolidation indicates a mapping error in entity assignment.
• Import intercompany journal entries separately. In OneWorld, intercompany journal entry import is a separate record type, and each imported intercompany JE needs at least four lines. Intacct notes that dimensions other than Location do not flow to inter-entity transactions, so legacy intercompany detail may already be less dimension-rich than ordinary transactions.

Rather than waiting for period-end processing as required with NetSuite, Sage Intacct includes automated inter-entity transaction processing that dramatically simplifies reconciliation between entities. Be aware that NetSuite's elimination process runs as part of period close, not in real-time. This changes how your finance team will work post-migration.

Extracting Data from Sage Intacct: API and DDS Constraints

Sage Intacct gives you two primary extraction paths, each with distinct constraints. The choice depends on your data volume and freeze window.

XML/REST API

Sage Intacct now enforces API transaction limits under a Performance Tier model. The default tier (Tier 1) allows 100,000 transactions per month. A "transaction" counts each query, readByQuery, create, update, or delete call — query results are capped at 2,000 per call, so large datasets require multiple queries, each counting separately.

Sage recommends limiting queries to fewer than 1,000 records and paginating the results. When manipulating records, limit the number of affected records to fewer than 100.

For a company with 50,000 AP bills, extracting just that one object burns 25+ API transactions. Multiply across GL entries, AR invoices, payments, journal entries, customers, vendors, and dimension values — you can consume a meaningful share of your monthly allocation on a single full extract.

A critical caveat on pagination: Intacct's XML query offsets are new queries, not stable continuations. Records can be missed if underlying data changes between calls. This is a strong argument for extracting after a transaction freeze, or using DDS for larger sets.

The newer REST /core/export endpoint documents a size maximum of 4,000 records.

Data Delivery Service (DDS)

Data Delivery Service (DDS) enables you to extract large amounts of company data from Sage Intacct and send it to a cloud location for analysis and usage with your own tools. DDS is the preferred extraction method for migration-scale data. Because Data Delivery runs as a server-side process, no API transaction limits apply to it.

Key DDS constraints:

• Data Delivery Service requires a separate subscription.
• Organizations with the standard Level of Service are limited to serial execution of these jobs. Customers with a premium Level of Service may be allowed two or more parallel job executions.
• DDS is not configured separately for entities and data is always extracted from the top level. This is true even if you slide into the entity of a multi-entity company before invoking the job.
• You are limited to one DDS job per hour for a change extract on a DDS enabled object.
• If private entities exist, use showprivate from the top level or you will miss that data in query-based extracts.

For migration, use DDS for the initial bulk extract (GLDETAIL, ARINVOICE, APBILL, SODOCUMENT, CUSTOMER, VENDOR, GLACCOUNT, etc.) and reserve API calls for delta syncs during the cutover window. Use GLACCOUNTBALANCE with explicit date parameters for opening balance packs — Intacct warns that skipping the date window can generate excessive unneeded data.

For a deeper walkthrough, see How to Export Data from Sage Intacct.

NetSuite Import Limits: CSV, SuiteTalk, and Load Order

Load NetSuite in strict dependency order: structure first, masters second, transactions last. In practice: subsidiaries → departments/classes/locations → custom segments and values → chart of accounts → customers/vendors/items → open transactions and journals.

CSV Import Assistant

The CSV file has a limit of 25,000 records or 50 MB. It's recommended that imports are separated into smaller files for better performance.

Transaction-specific limits are stricter:

• Journal entries: For journal entries, these limits are 1,000 lines for the user interface and for synchronous SOAP web services, and 10,000 lines for CSV import and asynchronous SOAP web services.
• Sales invoices and bills: The maximum number of lines allowed for importing sales invoices or bills via CSV in NetSuite is 5,000 lines per transaction.

For transaction rows, use account names rather than numbers, and use parent : child notation for subaccounts or other hierarchical references. NetSuite's Import Assistant works by record type, recommends External IDs for new data, and requires the Subsidiary field for many OneWorld record types. Import entities and items before transactions.

CSV import is the fastest route for bulk historical loads. By splitting large exports into multiple files and running them across import queues, you bypass the payload and timeout limits of the API. CSV imports also automatically trigger or bypass server-side SuiteScripts based on your configuration, giving you control over data validation during the load.

SuiteTalk (SOAP/REST API)

Concurrency refers to the number of simultaneous API requests that NetSuite will process in parallel for a given account. An account's concurrency cap is shared across all of its integrations (SOAP, REST, RESTlet calls combined).

• REST batch operations are asynchronous and limited to 100 records per request.
• SOAP transactions have a 200-record limit.
• Each SuiteCloud Plus license increases the account base limit for concurrent web services requests by 10. The account base limit depends on your service tier.
• SuiteCloud Plus allows the use of multi-threading for CSV import jobs and increases the number of import jobs that can be run in parallel.

Practical throughput: if your NetSuite account has a 5-slot concurrency limit and each invoice import takes 2 seconds, your theoretical throughput is about 9,000 records per hour. Loading 100,000 historical invoices would take over 11 hours of uninterrupted API throughput. This is why most teams use CSV Import for bulk historical loads and reserve SuiteTalk for delta sync during cutover.

Use CSV for the initial historical load. Use SuiteTalk for ongoing integrations after go-live. If you are loading significant volume, confirm your SuiteCloud Plus entitlement before migration starts.

For NetSuite's full export and portability story, see How to Export Data from NetSuite.

Cutover Sequencing Around Period Close

The optimal cutover window is immediately after a clean Intacct period close. This gives you a clean trial balance to validate against and avoids mid-period transaction splits.

The cutover sequence

1. Pre-migration (weeks 1–4): Extract historical trial balances, vendor masters, customer masters, and the updated chart of accounts from Intacct. Load and validate these in the NetSuite sandbox. Run at least one full mock migration against a closed month. Freeze mapping and master-data design.
2. Friday (Period Close): Accounting team completes the month-end close in Sage Intacct. Complete all postings, run intercompany eliminations, reconcile subledgers to GL, and lock the period to prevent new transactions.
3. Saturday (Extraction & Transformation): Extract the final Trial Balance by entity, Open AR aging, Open AP aging, intercompany positions, and active inventory balances from Intacct. Run DDS for all objects. Run transformation scripts to map Intacct dimensions to NetSuite segments. This closing trial balance is your reconciliation anchor.
4. Sunday (Loading & Validation): Load master data into NetSuite (if not pre-loaded). Load opening balance journal entries per subsidiary. Load open AR invoices, open AP bills, unapplied payments, and open purchase/sales orders — each assigned to the correct subsidiary with mapped segment values. Load historical summary JEs if bringing in comparative period balances. Run reconciliation tie-outs.
5. Monday (Go-Live): The team logs into NetSuite. Open the new period, redirect downstream integrations, and start live operations. Intacct is relegated to read-only access.

If you must keep users active during the transition, narrow the source-to-target delta to a short final window and rerun only the objects that changed. DDS change jobs exist for exactly this kind of repeatable export.

Reconciliation and Audit-Trail Expectations

A migration is only done when the numbers reconcile and the history is explainable. Without it, your first post-migration audit will be painful.

Minimum reconciliation checkpoints:

• Trial balance by subsidiary — NetSuite TB must match Intacct TB at cutover date, account by account, entity by entity. Total debits and credits must match to the penny. If there is a variance, isolate it by account type, then by specific account, then by segment.
• Open AR aging — total open AR in NetSuite must match Intacct's AR aging report. Validate at both summary and invoice level for the top 20 customers by balance. Confirm aging buckets (0–30, 31–60, 61–90) align, ensuring invoice dates were mapped correctly.
• Open AP aging — same validation as AR. Confirm vendor balances match, especially for vendors with unapplied debits or credits. Verify that vendor terms migrated correctly so payment schedules are not disrupted.
• Bank balances — GL cash account balances in NetSuite must match Intacct and reconcile to bank statements.
• Intercompany balances — due-to/due-from balances must net to zero at consolidation. Any imbalance indicates a mapping error in entity assignment.
• Subledger-to-GL reconciliation — AR subledger total must equal the AR control account in GL; same for AP. This catches transactions that posted to the wrong account during import.
• Inventory valuation — if migrating physical goods, the total inventory asset value in NetSuite must match Intacct, and the quantity on hand per item must align.

Audit trail considerations:

NetSuite maintains a system-generated audit trail on all transactions, including the import source and timestamp. The "created by" field will show the migration user, not the original Intacct user. If your auditors require original user attribution, store the Intacct user ID in a custom field on each imported transaction.

Intacct's original transaction IDs should be preserved as External IDs or in a dedicated legacy-key custom field in NetSuite. This creates a cross-reference between systems that auditors can use to trace any transaction back to its source. NetSuite explicitly supports External IDs for imports and API operations.

Be honest about what NetSuite can and cannot preserve. NetSuite produces its own create-and-update audit history for imported records going forward, but that is not the same thing as carrying over Intacct's original user-by-user chronology. Preserve source reports, exported audit logs, mapping files, and reconciliation workpapers as your permanent audit pack.

Export the tie-out reports from both systems, document any accepted variances (e.g., rounding differences caused by multi-currency conversions), and store them in your permanent audit file.

For a structured approach to validation, see Accounting Data Migration Checklist: The 10-Point Plan.

Scoping the Right Migration for Your Organization

Every Sage Intacct to NetSuite migration has the same core tension: completeness versus speed. Moving everything preserves history but costs more, takes longer, and introduces more failure points. Moving only what is needed gets you live faster but requires maintaining Intacct access for historical lookups.

The right answer depends on your audit cycle, reporting requirements, and entity count. Single-entity companies with two years of clean data can often complete migration in 2–4 weeks. Multi-entity organizations with complex intercompany structures and full-history requirements should plan for 8–12 weeks of dedicated migration work.

A clean migration does three things well: it redesigns segments before moving transactions, it chooses a history scope that matches real reporting needs, and it treats reconciliation as part of the build rather than post-go-live cleanup.