Migrate from Sales ERP to Acumatica

Sales ERP customer master maps directly to Acumatica's Customer screen (AR303000). Customer class determines the default terms, GL account defaults, and tax zone assignment. Multiple Sales ERP addresses per customer map to Acumatica's location hierarchy with one primary address flag set on import.

Sales ERP vendor master maps to Acumatica's Vendor screen (AP303000). 1099 vendor flags, payment methods, and terms map to the corresponding Acumatica vendor attributes. Tax ID (EIN) on the vendor record maps to Acumatica's Tax Record ID field for 1099 reporting.

Sales ERP GL account codes map to Acumatica's GL Account screen (GL202500). Account type, active/inactive status, and posting class carry over. Header accounts and detail accounts must be distinguished — Acumatica enforces the header/detail hierarchy at the account level, not at the segment level.

Sales ERP inventory items are split into Acumatica Stock Items (tracked by quantity) and Non-Stock Items (tracked by value only). Item class drives the default posting accounts for COGS, Inventory, and Revenue. The UOM on the Sales ERP item record becomes the base UOM in Acumatica's UOM group.

Sales ERP open sales orders migrate as Acumatica sales orders with status Preshipment or On Hold. Line items map to SO Lines with inventory ID, UOM, quantity, and unit price. The Sales ERP order date maps to Acumatica's Order Date; the expected ship date maps to the Requested On date.

Open Purchase Orders migrate to Acumatica's Purchase Orders screen (PO301000) with status Pending or On Hold. Vendor and vendor location are resolved via the vendor master migration. Line items carry the inventory ID, UOM, quantity, and unit cost from the source purchase order.

Open AR invoices migrate to Acumatica's AR Invoice screen (AR301000). The Sales ERP invoice number becomes the Reference Nbr. Payment terms, due date, and branch ID are carried forward. If the invoice is partially paid, the balance and applied amount are preserved as an open AR document.

Open AP bills migrate to Acumatica's AP Bill screen (AP301000). The vendor invoice number maps to Reference Nbr. Branch ID is assigned per the vendor's default branch or the mapping rule defined in the migration plan. Tax zone and terms are inherited from the vendor record.

Sales ERP tasks, notes, and activity records map to Acumatica's Activities screen (CR306000). Activity type (email, phone call, task) maps to the Activity Type picklist. The related entity (Contact, Customer, Vendor) is resolved via the source's entity reference ID stored in a custom Source_Ref__c field for cross-reference.

Sales ERP custom objects and entities that have no direct Acumatica equivalent are created as user-defined fields on the closest standard screen, or as custom tables via Acumatica's schema extension tools. We map the custom object fields to new UDFs before data loads so referential integrity is maintained.

Sales ERP file attachments on records migrate to Acumatica's Files screen and attach via NoteID to the corresponding entity record (Customer, Vendor, SO, etc.). Files are re-uploaded to Acumatica's document management system. File size limits and MIME type handling are enforced per Acumatica's attachment specifications.

Sales ERP users are matched to Acumatica users by email address. Active users who have an Acumatica license receive the OwnerId assignment on migrated records. Inactive or unmatched Sales ERP users are assigned to a migration service account; the original owner ID is stored in Source_Owner_ID__c for audit traceability.

If Sales ERP stores project or job records, these map to Acumatica's Projects screen (PM301000). Budget, commitment, and revenue recognition settings are configured based on the source project status and accounting method. Projects with no equivalent in Acumatica are preserved as custom fields for reference.

Sales ERP business unit or division records that have no 1:1 mapping to a single Acumatica branch require a branch-mapping plan. Multiple source business units may consolidate into one Acumatica branch, or one source unit may split into multiple Acumatica branches — the decision is made before migration based on your chart-of-accounts design.