Migrate from EQUAL to Epicor Prophet 21

EQUAL Accounts map to Epicor GL Account records, with the EQUAL account name mapped to GLAccount.Description and the account identifier mapped to GLAccount.AccountCode. EQUAL's category tags (expense classification) map to GLAccount.CategoryID and require a pre-migration category mapping table because EQUAL's tag taxonomy rarely aligns 1:1 with Epicor's GL Category structure. We validate the GL Account hierarchy in Epicor's Chart of Accounts before inserting to catch duplicate account code errors.

EQUAL's virtual card and physical expense card records have no direct Epicor ERP equivalent because Epicor does not have a native card issuance object. We map card records to a Vendor setup in Epicor with the card issuer details stored in Vendor.PaymentMethod and a custom UD field for the original EQUAL card ID. If the customer uses Epicor's Advanced Payment module, we link the card to a Payment Method record configured for virtual card settlement. This is a configuration mapping, not a data migration — card transaction history still flows via the Transaction mapping.

EQUAL card transactions map to Epicor AP Invoice records. The EQUAL transaction date, merchant name, amount, and currency code become APInvoice.InvoiceDate, VendorName (from the card-issuer mapping), InvoiceAmt, and CurrencyCode respectively. We resolve the GL Account for each transaction line from EQUAL's category tag using the pre-built GL Category mapping table. Multi-currency card transactions carry the original currency amount and exchange rate applied at transaction time from EQUAL into Epicor's AP Invoice exchange rate fields.

EQUAL ledger entries that are not card transactions (bank transfers, internal allocations, currency revaluations) map to Epicor GL Journal Entry records. Each EQUAL transaction line maps to a GLJEReal and GLJEDetail record with AccountCode, DebitAmount, CreditAmount, and CurrencyCode resolved from the account and currency mapping tables. We preserve the EQUAL transaction reference as a Journal Entry memo field for audit trail continuity.

EQUAL's per-currency balance records map to Epicor Currency records and exchange rate history in the CurrRate table. We extract every currency code present in EQUAL, create the corresponding Epicor Currency record, then populate CurrRate with historical exchange rates from EQUAL's ledger entries. The base currency of the Epicor legal entity must be identified during scoping to determine which currency is the reporting base in Epicor's GL. Exchange rate type (historical, spot, average) is preserved as a CurrRate.RateTypeId assignment.

EQUAL expense category tags map to Epicor GL Category records (for general ledger classification) and optionally to Expense Code records in Epicor's Expense Management module if the customer licenses that module. We build a tag-to-category mapping table during scoping by reviewing every distinct EQUAL tag value and matching it to the closest Epicor GL Category or Expense Code by name, description, or code pattern. Tags that have no Epicor equivalent are flagged for the customer's admin to create before migration.

EQUAL merchant metadata (name, category, address, payment terms) attached to transaction records maps to Epicor Vendor Master records. We deduplicate merchant records by normalized name during the EQUAL extract, then upsert the resulting vendor list into Epicor before the Transaction import phase so that the VendorID reference is satisfied on each AP Invoice line. Vendor payment terms default from Epicor's Vendor group unless EQUAL specifies different terms per merchant.

EQUAL users referenced on Account, Card, or Transaction records map to Epicor User records by email match. We extract every distinct EQUAL user, match by email against Epicor's User table, and place any unmatched users in a reconciliation queue for the customer's Epicor admin to provision before Transaction import begins. Owner assignment on AP Invoices requires a resolved UserID; records with unresolved owners are held in a staging table.

EQUAL custom objects and extended fields that are not part of the standard Account-Card-Transaction model map to Epicor UD (User-Defined) fields on the relevant Epicor business object. We pre-create the UD field schema in Epicor (UD100, UD01 type tables or extended fields on APInvoice, GLAccount, Vendor) before migration, then populate the UD field data alongside the standard field migration. EQUAL UD tables that represent production, inventory, or BOM data cannot map because Epicor's equivalent objects (Part, JobMtl, JobOper) do not exist in EQUAL and require Epicor's native configuration.

Epicor Parts, PartBin inventory tracking, and PartTran material transactions have no equivalent in EQUAL because EQUAL does not manage inventory or production. These Epicor objects are flagged as new configuration scope. We deliver a written note identifying these modules as requiring Epicor's native Part Master and inventory configuration, including a suggested chart of accounts structure for inventory valuation (WIP, Finished Goods, COGS accounts) mapped from the customer's existing EQUAL spend categories.

Epicor JobMtl (job material), JobOper (job operation), and MES (manufacturing execution) records have no equivalent in EQUAL. Organizations migrating from EQUAL to Epicor typically begin job costing and production tracking in Epicor after go-live, not from EQUAL historical data. We note these as Epicor-native setup scope and do not attempt to backfill production history that does not exist in EQUAL.

Epicor Supplier Management and Supply Chain Planning modules (Forecast, Demand Planning, Replenishment) have no EQUAL source data. Supplier records created from EQUAL's merchant metadata populate only the Vendor Master; Epicor's extended supplier management, EDI setup, and supply chain planning are configured natively in Epicor post-migration.