Migrate your Sage Intacct data

GL accounts map 1:1 via the REST API or Data Delivery Service. Account numbers, names, active status, and type are stable fields. We preserve the full account hierarchy during migration.

Historical journal entries are migratable, but dimensional tags must be applied as a separate step after import. Non-dimensionalized GL transactions migrate faster but lose filterable metadata in Sage Intacct.

Open AP bills, payments, and vendor associations export cleanly via the REST API. We flag any bills in a 'pending approval' state because Sage Intacct requires workflow routing before they can be posted.

Open AR invoices, payments, and customer records are fully migratable. We map customer balance-forward vs open-item AR settings from the source to preserve collection history.

Customer and vendor master records, including addresses, payment terms, and default GL accounts, migrate via the REST API. Custom fields on these objects (up to 100 each) require explicit field-level mapping due to the '!' prefix convention in the REST API.

Item records including description, unit price, cost, and GL association export via REST API. Bundle and matrix items require parent-child relationship mapping that we handle explicitly.

Project headers and task hierarchies migrate cleanly. We preserve project status, billing type, and customer association. Billable vs non-billable flags require verification against the source system.

Fixed asset records migrate but depreciation schedules require recalculation in Sage Intacct because each jurisdiction uses different conventions. We transfer acquisition cost, date, and asset class; depreciation logic is re-established post-migration.

Budget line data can be exported and re-imported, but Sage Intacct's native Planning module uses its own scenario structure. We map budget periods and amounts to the correct scenario and fiscal year.

Dimensions (department, class, location, customer, project) are a core concept unique to Sage Intacct. Source system categories must be mapped to Sage Intacct dimension values explicitly—every transaction must carry at least one dimension to be meaningful in reporting.

Custom objects behave like database tables and can be exported via REST API. Their fields use the '!' prefix in the API and may have relationship definitions that require careful key mapping during migration.

Custom fields on any object are migratable but require schema discovery first. The REST API prepends '!' to custom field names, and not all objects allow unlimited custom fields (Customer, Vendor, Item, Project, Contract are capped at 100). We discover and map each custom field before import.

Entity definitions, inter-company transaction rules, and consolidation mappings are fully exportable. We preserve the entity hierarchy so that cross-entity GL entries route correctly post-migration.

Document attachments stored within Sage Intacct are not accessible via the REST API for bulk export. We recommend a parallel document migration strategy (e.g., SFTP file transfer) alongside the record migration.

Employee records and payroll history are migratable via REST API, but payroll processing is often module-gated. We map employee fields, compensation history, and PTO balances; actual payroll runs are re-established in Sage Intacct's Payroll module.