Migrate from iXERP Standard to Acumatica

iXERP customers map directly to Acumatica Business Accounts with the Customer class. The CustomerCD becomes the BAccount ID; CustomerName maps to Acumatica's Name. Primary contact details, addresses, and status (active/inactive) carry over as-is. iXERP customer codes that exceed Acumatica's 10-character ID limit require truncation or a prefix-stripping rule applied during migration.

Each iXERP contact record attached to a customer becomes an Acumatica Contact linked to the same BAccount. Email, phone, job title, and address fields map 1:1. Multiple contacts per customer are preserved via the Contact lookup on the BAccount. iXERP's primary-contact flag maps to the IsPrimaryContact flag in Acumatica.

iXERP vendors map to Acumatica Vendors (BAccount with Vendor class). VendorCode becomes the Acumatica BAccount ID; VendorName becomes the display Name. Payment terms, currency, and tax ID map to the corresponding Vendor fields. Vendors without an Acumatica-matching tax registration ID are flagged and held in a staging table for manual resolution before the full run.

iXERP items with inventory tracking become Acumatica StockItems; service items and non-inventory parts become Non-StockItems. The ItemCode becomes InventoryCD; Description maps to Description. Valuation Method in Acumatica (Average, FIFO, Specific, Standard) is set based on iXERP's cost-layer configuration — if iXERP uses Average cost, the StockItem.ValuationMethod is set to Average. ItemClasses in iXERP maps to the PostingClass in Acumatica, which controls the accounts used for COGS and Inventory GL postings.

iXERP warehouse locations map to Acumatica Sites (INSite). Each item-warehouse combination in iXERP creates a corresponding row in Acumatica's InventoryItemWarehouse table. DefaultBin is set from iXERP's bin location field if present. Quantity on Hand, ReorderPoint, and SafetyStock carry over as opening balances before the first post-migration transaction.

Open and completed iXERP sales orders map to Acumatica Sales Orders. OrderNumber becomes the Acumatica OrderNbr; Customer maps via BAccount lookup; OrderDate becomes OrderDate. Line items map by InventoryCD lookup and quantity/price fields carry over. Completed iXERP orders are migrated as fully shipped/invoiced orders using the Completed status flag. iXERP order statuses (Pending, Confirmed, Shipped) map to Acumatica's Open, Pending, Completed status values per the sales order type.

iXERP purchase orders map to Acumatica Purchase Orders. The PO number becomes OrderNbr; VendorID resolves via email or code match; line items map by InventoryCD or Non-Stock Item ID. iXERP's receipt-linked POs create a corresponding AP Bill in Acumatica once the PO receipt is recorded.

iXERP sales invoices map to Acumatica AR Invoices. RefNbr becomes the Acumatica reference number; CustomerID links to the BAccount; TranTotal and TaxTotal carry over. The DocType is set to Invoice for billed records and CreditMemo for iXERP credit notes. If iXERP tracks payments separately, each payment creates an Acumatica Payment with the corresponding application to the invoice.

iXERP AP invoices map to Acumatica AP Invoices. VendorID resolves via code or name match; the invoice number becomes RefNbr; line items carry descriptions and amounts. Prepayments tracked in iXERP create Prepayment documents in Acumatica with the same allocation logic.

iXERP chart of accounts maps to Acumatica Accounts. AccountCode becomes AccountCD; Description maps to Description; account type (Asset, Liability, Equity, Revenue, Expense) maps to the Active flag and account group. iXERP's account active/inactive flag sets the Account.IsActive value in Acumatica. If iXERP uses account segments (e.g., Cost Centre as a second segment), FlitStack maps the second segment to the Subaccount field using Acumatica's Subaccount mask configuration.

iXERP cost centres become Acumatica Subaccounts linked to the relevant accounts. The Subaccount mask in Acumatica is configured to match the iXERP segment structure. For businesses with separate legal entities per cost centre, iXERP cost centres map to Acumatica Branch entities, each with its own Company tree entry. This requires the Consolidated Ledger module in Acumatica.

iXERP journal entries map to Acumatica GL Batches with individual debit/credit lines as GLTrans. Each line carries AccountCD, SubaccountID, DebitAmt, and CreditAmt. BatchNbr becomes the Acumatica batch reference. iXERP's entry date and description map to the Batch.Date and Batch.Description fields. Entries marked as Posted in iXERP are migrated as Released batches in Acumatica; draft entries become Unreleased.

iXERP fixed assets map to Acumatica Fixed Assets with AssetCD, Description, ClassID, AcquisitionDate, and AcquisitionCost. Depreciation method (Straight-Line, Declining Balance) maps to the DepreciationMethod field on the FixedAsset. Book values and accumulated depreciation are carried into Acumatica's Asset Book records. Useful life and salvage value map to the corresponding Asset Book fields.

iXERP project records map to Acumatica Projects using the Project Management module. ProjectCode becomes ContractID; ProjectName becomes Description. Project status (Active, Completed, On Hold) maps directly. If iXERP stores budget lines, these migrate as Budget lines in Acumatica's Project budget view. Time and expense entries linked to iXERP projects map to Project Transactions in Acumatica.

iXERP employee records map to Acumatica Employees. EmployeeCode becomes Acumatica's EmployeeID; Name maps to LastName and FirstName; Department maps to the Department field. Employee status (Active, Inactive) carries over. For companies not using Acumatica's payroll module, employee records serve as reference data for project allocation and expense tracking only.

iXERP custom properties on any entity (Customer, Item, SalesOrder, etc.) migrate as custom fields on the corresponding Acumatica DAC. The Acumatica developer (or FlitStack's schema team) creates the Usr-prefixed field on the target DAC and publishes the customization project. Each custom property value is then written to the new column during migration. Field type mapping: text properties become PXDBString, numeric properties become PXDBDecimal or PXDBInt, date properties become PXDBDate.