Migrate from Digit to Acumatica

CustomerClassID and VendorClassID must exist in Acumatica before customer and vendor records can be saved

Acumatica enforces referential integrity on CustomerClassID and VendorClassID — you cannot save a Customer or Vendor record without a valid class that is already registered in Acumatica's configuration screens. This is a pre-import schema step, not something resolved during data loading. We deliver a class-mapping plan based on Digit's class values so Acumatica classes can be created before any customer or vendor records are imported. If a Digit class has no equivalent, we recommend a default fallback class and flag the mismatch for your Acumatica admin.

Digit N:N item-to-vendor relationships require vendor-price records in Acumatica — no native N:N exists

Digit supports many-to-many relationships between items and vendors, where a single item can have multiple vendors and a single vendor can supply multiple items with different pricing. Acumatica does not have a native N:N item-vendor table; instead, Acumatica stores vendor-specific pricing on Vendor Prices (linked to InventoryItem and Vendor). We resolve this by creating one Vendor Price record per unique item-vendor pair found in Digit, populating VendorID, InventoryID, and the source unit cost. This requires a post-mapping pass after both Items and Vendors are committed so the foreign keys resolve correctly.

Digit item splits into Stock vs. Non-Stock require ItemType to be set at insert time in Acumatica

Acumatica InventoryItem records are split by ItemType ('Stock Item' vs. 'Non-Stock Item'), and the type cannot be changed after the record is created. Digit's single item entity does not natively distinguish these types. We infer the split from Digit's item flags (e.g., a flag for 'track inventory' or 'stocked item') or from item category fields. If Digit has no explicit flag, we apply a configurable rule — items with stock-on-hand quantities above zero default to 'Stock Item'. This rule must be agreed upon and documented before the import runs.

Digit note attachments must be re-hosted in Acumatica's Files storage — base64 inline storage is not supported

Digit may store file attachments inline (e.g., base64-encoded files attached to customer or item records). Acumatica requires files to be uploaded to its Files repository and linked via a NoteID foreign key — it does not accept inline base64 file data in the standard import. We extract Digit's attachment content, upload each file to Acumatica Files using the API, and create a Note record with the file reference. Files exceeding Acumatica's 25MB per-file limit are flagged for manual handling. This step adds processing time proportional to the number and size of attachments.

Acumatica GL accounts require Active flag and a valid AccountCD — inactive or missing accounts block transaction import

Sales order lines in Acumatica carry LineType ('Invenotry' or 'Service'), and service lines require a valid AccountID for COGS posting. If the referenced account is inactive or missing in Acumatica, the import validation fails and the record is rejected. We audit Digit's expense and revenue account references against Acumatica's GL Account list before migration, creating missing accounts and activating inactive ones in the schema-setup phase. This ensures all transaction lines have a valid posting account before any sales orders are loaded.