Migrate from Sage Intacct to Dolibarr ERP

Sage Intacct GL accounts map to Dolibarr's accounting plan (plan comptable). Account numbers, names, and active status transfer directly. Sage Intacct's account type hierarchy (Asset, Liability, Equity, Revenue, Expense) maps to Dolibarr's account type classification. We flag any sub-account segment that exceeds Dolibarr's default hierarchy depth so the customer's admin can decide whether to flatten or restructure before import.

Sage Intacct journal entries map to Dolibarr journal types based on entry type. Each line's account reference and debit/credit amounts transfer directly. Sage Intacct's dimension tags (department, class, location) are written to a Dolibarr 'extrafields' JSON column or a linked category record so that the dimensional context is preserved alongside the journal line. The customer receives a written dimension-to-category mapping table for verification.

Sage Intacct Dimensions (department, class, location, customer, project) are not native Dolibarr objects. We map each dimension to a Dolibarr Category of the appropriate type (Product Category, Contact Category, or ThirdParty Category). Dimension values become category labels with a reference back to the Sage Intacct dimension name. A written dimension inventory document is delivered so the customer's admin can reassign or merge categories post-import.

Open AP bills from Sage Intacct export via REST API including vendor association, invoice number, due date, and line items. We map Sage Intacct vendor records to Dolibarr ThirdParty (type Supplier) before invoice import so that the supplier_id foreign key resolves at import time. Any bills in 'pending approval' or 'draft' state are flagged in a reconciliation report because Dolibarr requires invoices to be validated before they appear in accounting entries.

Open AR invoices from Sage Intacct map to Dolibarr Customer Invoice records with customer association, invoice number, due date, and line items. We map Sage Intacct customer records to Dolibarr ThirdParty (type Customer) before invoice import. Invoice payment status is preserved as Dolibarr payment condition and statut fields. Balance-forward vs open-item AR settings are noted during discovery and mapped to Dolibarr's invoice discounting and payment term configurations.

Sage Intacct customer master records map to Dolibarr ThirdParty with type 'Customer'. Address fields, payment terms, and default GL accounts transfer directly. Custom fields on the customer object use the '!' prefix in Sage Intacct's REST API; we discover all custom fields during schema mapping, strip the '!' prefix in the Dolibarr extrafields JSON structure, and verify values land in the correct Dolibarr field after import.

Sage Intacct vendor master records map to Dolibarr ThirdParty with type 'Supplier'. We handle the same custom field discovery and prefix resolution as with customer records. Vendor payment terms and default expense accounts transfer to Dolibarr's supplier form fields.

Sage Intacct item records (products and SKUs) map to Dolibarr Product. Description, unit price, cost, and GL association export via REST API. Bundle and matrix items with parent-child relationships require a separate product-bom resolution step because Dolibarr handles bill-of-materials structures differently. We preserve the parent-child relationship and flag any matrix items for manual BOM configuration review.

Sage Intacct project headers and task hierarchies map to Dolibarr Project records. Project status, billing type, and customer association transfer directly. Billable vs non-billable flags are preserved as Dolibarr Project usage types. We map the project-level customer association to Dolibarr's Project/ThirdParty link. Tasks become Dolibarr ProjectTask records under the parent project.

Sage Intacct fixed asset records (acquisition cost, date, asset class) migrate to Dolibarr Asset module if the customer has the Asset Management module enabled. Depreciation schedules require recalculation in Dolibarr because jurisdiction-specific conventions may differ. We transfer acquisition details and flag depreciation for manual verification against the customer's accounting policy.

Sage Intacct custom objects use the 'nsp::' namespace prefix in REST API endpoints (e.g., nsp::unbilled). We discover all custom objects during schema mapping, query them via POST /objects/platform-apps/nsp::{name}, and map each to a Dolibarr extrafields structure on the nearest standard object or to a separate Dolibarr module if the object represents a standalone entity. We flag any custom objects with cross-object lookups for manual review because Dolibarr's relationship model differs from Sage Intacct's.

Sage Intacct custom fields prepend '!' in the REST API (e.g., !region). We discover all custom fields on every object during schema mapping, strip the '!' prefix, and map values to Dolibarr extrafields JSON on the corresponding object. Not all Dolibarr objects support unlimited extrafields; we verify the target object's extrafield capacity during discovery and flag any overflow to the customer's admin for manual assignment.

Sage Intacct's multi-entity structure (subsidiaries, cost centres, franchises) has no native Dolibarr equivalent at the standard tier. Dolibarr handles multi-company scenarios through separate instances or a third-party multi-company module. We export the entity hierarchy and intercompany transaction rules from Sage Intacct, map each entity to a separate Dolibarr instance or a ThirdParty with a company_type of 'Company', and deliver a written routing table for intercompany journal recreation in the target configuration.

Sage Intacct budget data can be exported and re-imported into Dolibarr's Budget module if enabled. Budget periods and scenario values map to Dolibarr budget lines tied to the accounting plan. We flag budget scenarios that use Sage Intacct's multi-dimensional allocation model because Dolibarr's budget module uses a flat line-item structure.

Sage Intacct employee records export via REST API and map to Dolibarr User records if the HRM module is enabled, or to ThirdParty records with a 'HR' tag if the module is not in scope. Compensation history and PTO balances migrate as extrafields on the User or ThirdParty record. Actual payroll runs do not migrate because payroll processing is module-gated and jurisdiction-specific.