An item import can finish successfully while leaving the warehouse with unusable records. A case may be treated as an individual unit. A lot-controlled product may arrive without a traceable opening balance. A purchasing team may discover that an item is unavailable to the subsidiary placing the order.
A reliable NetSuite item master migration therefore starts with business rules and ends with transaction testing. Import success is only one checkpoint. The inventory owner must also prove that users can buy, receive, move, sell and count the migrated products under the intended configuration.
This guide gives inventory owners and migration leads a practical way to structure that proof. The examples are hypothetical, and the appropriate design depends on enabled features, item types, accounting policies and the migration method selected for your account.
The item master describes what an item is and how the business handles it. Opening inventory describes what the business owns at cutover, where it sits and how it is valued. Mixing those decisions into one uncontrolled spreadsheet makes errors difficult to isolate.
Prepare distinct datasets for item definitions, supporting reference data and opening inventory. Reference data might include units of measure, locations, subsidiaries and accounting assignments. Opening inventory may require quantities, values, bins, inventory status, lot identifiers or serial numbers, depending on the configured features and chosen loading process.
Assign ownership before mapping fields. Operations owns physical handling and traceability requirements. Finance owns valuation and account decisions. The migration lead owns identifiers, transformation logic and load dependencies. Each owner should approve the part they understand rather than signing an entire technical workbook without a clear review boundary.
Do not infer an item type solely from a legacy label such as product, service or miscellaneous. Ask how the item behaves.
Does it represent stock whose quantity and value must be tracked? Is it purchased for immediate consumption? Is it assembled from components? Must each physical unit be identifiable? Is a group of units managed under one production lot? Will the same commercial description cover materially different handling requirements?
Document the answer with a sample transaction chain. A replacement component might need purchasing, receipt, storage, issue and return. A consulting service might need purchasing and billing without physical inventory. These differences should drive the target design.
Some item and costing decisions are difficult or restricted to change after creation. Validate the exact restrictions for the selected record type before creating production records. A temporary mapping chosen to meet a load deadline can become an expensive operational constraint.
A unit description is not a conversion rule. “Box” could mean six units for one item and twenty units for another. It may even vary by supplier.
For each item, record the base unit, purchasing unit, selling unit and conversion factors supported by the intended units structure. Then test the calculations with realistic quantities. If one carton contains twelve each, receiving five cartons should produce sixty each under that design. A sale of eighteen each should leave forty-two each, before any other movement.
Check whether prices and costs are expressed per carton or per each. A quantity conversion that works perfectly can still produce a twelvefold valuation error when the cost denominator is wrong. Preserve the source unit alongside the transformed value so reviewers can reconstruct the calculation.
A sample template should include more than clean records. The following hypothetical candidates illustrate useful rejection tests:
These are design rejection cases, not promises about which error message a particular import will display. Some invalid business combinations can pass a technical import and only surface later.
For a hypothetical product, the approved source position is eighty each at a total inventory value of 1,600 currency units. The quantity check proves eighty units. The value check proves 1,600. A correct quantity with a value of 19,200 is still a failed migration.
Perform reconciliation by meaningful dimensions: item, location, subsidiary and relevant inventory detail. Review negative quantities, zero-value stock, obsolete items and unusually high unit values separately. A company-wide total can conceal one location being overstated while another is understated.
Do not assume the source average cost can simply be pasted into every target costing design. The opening-value method must support the selected item and accounting configuration. Finance should approve how any source valuation differences are treated and how the opening inventory ties to the ledger.
Start with a small representative population containing ordinary inventory, special units, returns, traceable stock and boundary cases. Load dependencies first, then item definitions, then the approved opening position through the selected method.
Run a purchase and receipt, a sale and fulfillment, a transfer where relevant, and a return. Check quantities, inventory detail and accounting consequences at each step. Ask warehouse users to perform these tests with their intended roles, because administrator access can hide permission gaps.
For every test, retain the input row, resulting record identifier, expected outcome, actual result and reviewer. Correct the transformation at its source and rerun the affected population. Repeatedly editing individual target records weakens repeatability and leaves the final production load exposed to the original defect.
You can assess the entire population, but migration scope should distinguish active items, dormant items needed for open transactions and historical-only records. Agree how excluded history remains accessible before removing anything from scope.
Description cleanup is useful, but classification, units and traceability carry greater operational risk. Set those rules first so a neatly named record does not conceal the wrong behavior.
No. It proves the selected rows were accepted through that route. Approval also needs quantity and value reconciliation, reference-data checks and successful representative transactions.
The accountable finance owner should approve the policy and opening-value treatment, with operational input where physical handling matters. A technical importer should implement those decisions rather than invent them.
Bring your highest-risk items, unit conversions and opening-stock exceptions to CuriousRubik for a scoped migration review. The useful starting point is a representative test pack that exposes dependencies before the full item population reaches production.