Migrate from NetSuite to Odoo ERP

NetSuite account type codes (0=Bank, 1=AR, 2=Inventory, 5=Fixed Assets, 10=AP, 21=Income, 23=COGS, 24=Expense) map to Odoo Account types. We preserve acctNumber as the account code, account name as the account label, and NetSuite's isInactive flag as a archived state in Odoo. Eliminations accounts in NetSuite's subsidiary model become Odoo inter-company accounts under multi-company configuration.

NetSuite Customers map to Odoo Contacts with the Customer flag enabled. We preserve address fields (billingAddress, shippingAddress), tax registration fields, credit limit, payment terms, and currency settings. NetSuite's custentity_* custom fields on Customer records migrate as Odoo custom fields on res.partner via Studio or Python field definition.

NetSuite Vendors map to Odoo Contacts with the Vendor flag enabled, enabling the purchase module to function. We preserve tax ID, bank account details, payment terms, and the vendor-specific address subrecords. Custom fields on Vendor (custentity_*) migrate alongside standard fields as Odoo res.partner custom fields.

NetSuite inventory items, assemblies, non-inventory items, and service items map to Odoo Product Templates. We preserve the item's SKU (stored in itemId or itemNumber), unit of measure, cost, sales price, product type mapping (inventory item = storable product, assembly = consignment or kit depending on Odoo configuration), BOM relationships on assemblies, and landed cost fields. Lot and serial number settings map to Odoo's lot/serial tracking on stock.move.

NetSuite Sales Orders map to Odoo Sale Orders. We preserve order date, customer reference (poNumber), line items with quantities and prices, tax amounts, shipping address, incoterms mapping where present, and order status (Pending Fulfillment maps to Sale Order state 'sale', Shipped to 'done'). Open versus closed status is determined by shipping status in NetSuite at the time of extraction.

NetSuite AR invoices map to Odoo Account Moves of type 'out_invoice'. We preserve invoice number, invoice date, due date, line-level amounts with taxes, exchange rates on foreign-currency invoices, and payment terms. NetSuite's custbody_* custom fields on transaction headers migrate as Odoo account.move custom fields. Historical paid invoices are migrated as posted moves; open AR invoices are migrated with state='draft' pending payment reconciliation.

NetSuite Vendor Bills map to Odoo Account Moves of type 'in_invoice'. We preserve vendor reference, bill date, due date, line-level amounts, taxes, and currency exchange rates. Open AP bills migrate with state='draft' pending payment reconciliation against Odoo's bank statement reconciliation feature. Historical paid bills migrate as posted moves.

NetSuite journal entries require an explicit carry-forward policy agreed upon before migration. Option A (historical replay): we preserve original posting dates, line descriptions, amounts, and exchange rates by replaying each journal entry as an Odoo move with the original date and account assignments. Option B (opening balances): we extract period-end GL balances from NetSuite and create fresh Odoo opening-balance entries as of the cutover date, carrying forward net balances rather than historical detail. We present both options to the customer's finance team and capture the choice in the migration contract before sequencing data.

NetSuite open receivables are extracted by aging bucket (0-30, 31-60, 61-90, 90+) with invoice numbers, amounts, due dates, and customer references. We create a reconciliation view in Odoo showing open AR as aged move lines linked to the migrated contacts. Payments received after cutover are reconciled manually in Odoo's bank statement reconciliation view.

NetSuite open payables are extracted similarly to AR aging, with vendor, bill number, amount, due date, and aging bucket. We create a reconciliation view in Odoo showing open AP as aged move lines linked to migrated vendor contacts. NetSuite payments made before cutover are reconciled against the migrated bills.

NetSuite's subsidiary model allows one database to represent multiple legal entities with intercompany eliminations at the subsidiary level. Odoo handles multi-entity differently: each legal entity is a separate company database pod under a single Odoo instance with multi-company rules for shared contacts and products. Each NetSuite subsidiary must map to a distinct Odoo company with its own Chart of Accounts, fiscal year, and posting journal. Intercompany transactions in NetSuite become cross-company journal entries in Odoo under the multi-company configuration. We build the subsidiary-to-company map during discovery and validate journal configuration before any data lands.

NetSuite Custom Records are user-defined record types accessed via custrecord_* script IDs. Every NetSuite environment has a unique set of custom record types not discoverable via public documentation. We run a metadata discovery pass against the account's SuiteQL endpoint to enumerate all active custom objects and fields before building the migration map. Custom fields on transactions (custcol_*) and entities (custentity_*) require special handling in the NetSuite REST/SOAP payload. Destination Odoo custom models are created via Studio or Python model definition matching the source schema, including field types, required flags, and relational fields. Custom Record migration runs last because these records often reference Customers, Vendors, and Items that must be present first.