Migrate from Oracle PeopleSoft to Acumatica

PeopleSoft VENDOR records map directly to Acumatica Vendors. The VENDOR_ID becomes VendorID, VENDOR_NAME becomes VendorName, and payment terms map through a value lookup. Acumatica requires an active AP account for each vendor — we create the AP account link during the vendor load phase. SETID-scoped vendor groups become Acumatica vendor classes.

PeopleSoft CUSTOMER records map to Acumatica Customers with the CUST_ID becoming CustomerID and NAME becoming CustomerName. PeopleSoft's AR business unit mapping translates to Acumatica's AR subperper in the branch context. Customer credit limits map to the CreditLimit field; overdue balances become open AR transactions in Acumatica.

PeopleSoft PO_HDR and PO_LINE records combine into Acumatica Purchase Orders. PO status (Open, Closed, Cancelled) maps to Acumatica status codes. POLINE inventory items link to Acumatica InventoryIDs where the item exists. Partially-received POs are supported — Acumatica's receipt application captures remaining quantities at migration close.

PeopleSoft EMPLOYEES table maps to Acumatica Employees. EmployeeID becomes EmployeeID, NAME becomes EmployeeName, and department links map to the DepartmentID. HCM data (job title, employment type, manager) migrates as standard fields. Benefits enrollment and dependent data require separate import scenarios in Acumatica HR.

PeopleSoft's separate Account, Department, Product, and Project tables combine into a single Acumatica GL Account record using the subaccount mask. The mask splits a concatenated PeopleSoft segment string into account and subaccount segments. For example, Account=61000 + Dept=100 becomes Account=61000 with Subaccount=DEPT-100 based on the configured mask.

PeopleSoft Department is a separate record but in Acumatica it becomes a subaccount segment rather than a top-level object. We extract DEPARTMENT records, apply the configured subaccount mask, and load each department as a subaccount under the DEPT subaccount segment in Acumatica's chart of accounts.

PeopleSoft PROJECT and PROJECT_TASK records map to Acumatica Projects. PROJECT_ID becomes ContractNbr, PROJECT_NAME becomes Description, and status values map directly. Tasks map as project tasks with budget amounts transferred to the project's budget fields. Project-type dimensions become subaccount segments when Acumatica's project accounting is configured.

PeopleSoft AP voucher records (VOUCHER, VOUCHER_LINE) map to Acumatica AP Transactions. Invoice number, vendor reference, gross amount, and discount terms carry across. Unpaid open items are loaded as AP documents with status Open. Prepaid vouchers and adjustments require separate transaction type mapping.

PeopleSoft AR invoice records map to Acumatica AR Invoices. Customer reference number, invoice amount, due date, and terms map directly. Open AR items are loaded as undeposited invoices in Acumatica. Credit memos and adjustments from PeopleSoft load as separate AR document types with corresponding reference links.

PeopleSoft journal records (JRNL_HEADER, JRNL_LINES) map to Acumatica GL Transactions. Period, fiscal year, journal number, and line amounts carry across. Multi-company journal entries from PeopleSoft become separate journal batches per entity in Acumatica. Adjusting entries and reversing journals are flagged for period-assignment review in Acumatica.

PeopleSoft POSITION_DATA maps to Acumatica Positions. Position number becomes PositionID, job code maps to the position title, and head-count slots transfer as active position records. Vacant positions remain as open head-count slots in Acumatica's position budget view.

PeopleSoft custom records created in PeopleTools map to Acumatica custom fields. Since Acumatica custom fields require definition in the Customization Project editor before data loads, we first export the PeopleSoft record structure, create matching Acumatica custom fields, then load the data as custom field values in the Acumatica import scenario.

PeopleSoft intercompany journal entries span multiple business units in one transaction. Acumatica does not have a native intercompany journal construct — each company in Acumatica is a separate legal entity. We split PeopleSoft intercompany journals into separate journal batches per company, flagged with the original intercompany reference for reconciliation.