Most Sage X3 import failures are not random. They trace back to a small set of predictable mistakes — errors in UOM configuration, wrong import sequence, Excel handling, or assuming the import log is telling you everything. This post covers the five we see most often and what to do about each one.
Mistake 1: UOM direction errors
The UOM conversion coefficient in Sage X3 goes one specific direction — stock unit to sales/purchase unit, or the reverse depending on the field. Getting it backwards produces a coefficient that's the reciprocal of what you need. A product set up as 12 EA per CS becomes 0.0833 CS per EA, which flows through every order calculation.
The fix: confirm the GESTCO conversion table direction before populating ITF coefficients. Validate by running a manual conversion check on 5–10 products before importing the full catalog.
Mistake 2: Importing BPCUSTOMER before BPARTNER
BPCUSTOMER and BPSUPPLIER are child tables. Name, currency, and most header fields live in BPARTNER — the parent. If you import BPCUSTOMER directly without first loading BPARTNER and BPADDRESS, those fields arrive blank and no import error is raised. The silent failure only surfaces when a user opens the customer record and finds the name empty.
The correct sequence is: BPARTNER → BPADDRESS → Contacts → BPCUSTOMER or BPSUPPLIER. This sequence must be documented and followed exactly, in order, every time.
Mistake 3: Excel quietly corrupting your data
Excel reformats data on open without asking. Leading zeros on part numbers become integers. Dates shift format based on regional settings. Long numeric strings get converted to scientific notation. None of this is visible until after you've built your import file.
The fix: work in CSV from the start, not xlsx. If your source data arrives as Excel, convert it immediately — do your transformations in Python or a proper ETL tool, never in Excel directly. Validate the output CSV in a text editor before running any import.
Mistake 4: Trusting the import log to catch everything
Sage X3's import log reports what it checked, not what it missed. If a field isn't in the validation rule set, a bad value imports cleanly and shows no error. Payment terms codes that don't exist in the target environment, country codes in the wrong format, blank required fields in optional modules — all can pass the log.
The fix: validate against the actual target environment data before importing. Export the valid lookup values from Sage X3 and cross-reference your import file against them. Don't rely on the log as your only check.
Mistake 5: Treating the source data as the scope
The source system's field list is not your import scope. Clients often hand over a legacy export and assume every field maps cleanly. In practice, the source has fields Sage X3 doesn't use, uses different code structures, and is missing fields Sage X3 requires. Scope drift happens when new fields are added mid-project after the initial template review.
The fix: lock the scope to the Sage X3 import template, not the source export. Confirm field coverage in writing before any transformation work starts. Changes after that point are a new scope item.
These five mistakes account for the majority of failed or incomplete Sage X3 imports. Most are preventable with upfront validation and a documented sequence. If you're working through a migration and running into issues not covered here, get in touch — we're happy to take a look.
Heading into a Sage X3 migration? We handle the data work — fixed fee, fully remote. See services →