Rescuing a 5,000-SKU Sage X3 Product Import at a Food and Seafood Distributor

Client Profile

A food distribution business serving restaurants and independent grocers, with roughly 5,000 active product records across frozen seafood, fresh proteins, dry goods, and packaged items. The catalog carried the UOM complexity this industry is known for. Products purchased in PC but received by weight. Items sold by the piece but stocked by the case. Catch-weight products with their own configuration rules. A unit vocabulary that ran CT, PL, CS, BOX, PK, EA, LB, KG, and more. Conversion coefficients were often missing from structured fields and buried inside product descriptions instead.

What Went Wrong on Import

The first attempts failed on misplaced indicators. The whole file rejected. In X3's import format, the last row of the text file has to be empty, field separators have to match the template exactly, and any column shifted against the X3 import/export layout kills the load.

When the file structure was corrected, the failures changed shape rather than going away. Some products imported. Others bounced out of the error log for a mix of reasons: invalid UOM codes, referenced values that had not been set up in X3 yet, and Excel corrupting the source file on save. Leading zeros were stripped from codes. Item codes like MAY1234 came through as dates.

What the Source Data Actually Looked Like

Once the files were opened and compared against the template, the picture was clearer. Field mapping did not line up with the X3 import/export template. Columns had shifted during earlier rounds of manual copy-paste and VLOOKUP work, and nobody had caught it. The text-file conversion format and the field separators were wrong. Legacy UOM abbreviations — lbs, box, bag — did not match X3's required values, which wanted lb, bx, bg. And stock units in the legacy system were not the smallest unit used per product, which is something X3 requires. That one detail was throwing off conversion coefficients and, downstream, pricing.

Pack weights and conversion ratios existed, but only inside free-text descriptions. Not in structured fields where an import expects to find them.

The Cleanup

Migration tools exist. None of them decide for you that stock unit has to be the smallest unit in the hierarchy, or that PC does not belong on a non-catch-weight product. Those are catalog-specific judgment calls, and they have to be applied consistently across every record.

The work went in this order:

1. Field mapping rebuilt against the X3 import template
2. UOM values cross-referenced to X3's unit list and normalized (lbs → lb, box → bx, bag → bg)
3. X3 rules applied catalog-wide: stock unit as the smallest unit used, pack unit never equal to stock, no PC on non-catch-weight items
4. Pack coefficients and product weights extracted from the free-text descriptions
5. Irregular characters that break text-file exports stripped (commas, asterisks, stray quotes)
6. Records that could not be resolved cleanly flagged for local staff to review before import, rather than guessed

Outcome

Imports started running with only rare errors, and the load process became repeatable. That last part mattered more than the first import itself. Clean product data in X3 put the business on realistic ground to roll the system out to additional locations, which had been the plan all along but had not felt viable while the core catalog was still failing to load.

One Thing Worth Knowing

Tooling handles file movement. It does not decide what "correct" looks like for your catalog. That part is the work.