Dynamics GP Inventory Migration: Costing, Serial Numbers & Lot Tracking

Migrating the Inventory module out of Dynamics GP is the hardest data workstream in most ERP transitions — harder than GL, harder than AP/AR. GP's inventory tables encode not just what you have on hand, but how it got there — every receipt layer, every serial assignment, every lot allocation, every cost layer built up over years of transactions. Copy the item master and the quantity, and you might look fine on day one. But the first time someone sells a serialized unit, processes a return against a specific lot, or runs Adjust Cost – Item Entries in Business Central, the cracks show.

GP's inventory architecture was designed decades ago on a highly normalized set of Dexterity-era SQL tables that separate item definitions, site-specific configurations, pricing, and historical transactions. You are not lifting and shifting a flat file. You are translating a complex, interdependent data model into a structurally different one.

This guide covers the structural problems that break Dynamics GP inventory migrations: costing method translation, unit of measure schedule mapping, serial and lot tracking history, multi-location quantity integrity, pricing architecture, and BOM/kit conversion. If you are moving to Business Central, NetSuite, Acumatica, or any modern ERP, these are the failure points your implementation partner may gloss over.

For the broader context of GP's end-of-life timeline, see Dynamics GP End of Life: 2025–2031 Timeline & Migration Plan.

How GP Stores Inventory Data: The Tables That Matter

Before discussing migration, you need to understand what you are extracting. GP's inventory module spans dozens of SQL tables. The ones that cause migration failures are:

The critical relationship: the IV10200 (Purchase Receipts) table creates a record with a unique receipt sequence number every time a positive-quantity transaction is posted. If the item has lot or serial tracking, corresponding lines are added to IV00200 or IV00300 with the same receipt sequence number and quantity. The IV10200, IV00300, and IV00200 tables keep track of how many items have been used for each receipt line. The remaining quantity for each line must match between IV10200 and IV00300/IV00200.

If those quantities diverge — which happens more often than you would expect in a 15-year-old GP instance — your migration will carry the discrepancy into the new system.

Three structural characteristics make GP inventory particularly hard to extract cleanly:

1. Quantity is calculated, not stored as a flat value. GP does not keep a single static "Quantity on Hand" that you can query and trust unconditionally. The value in IV00102 is dynamically reconciled across receipt and sales histories. Unposted batches will immediately cause migration discrepancies.
2. Costing is layer-based. GP stores individual cost layers for FIFO and LIFO valuation in IV10200. Compressing these layers during migration destroys your historical valuation.
3. Tracking tables are bloated. The IV00200 (Serial) and IV00300 (Lot) tables contain not just current on-hand data, but the complete receipt and allocation history for every item ever tracked. For a company that has run GP for 15 years, these tables can contain millions of rows of historical data with no operational value in the new system.

Costing Method Conversion: FIFO, LIFO, Average, and Standard Cost

The core problem: GP and your target ERP may both support the same costing method names, but the internal algorithms produce different results.

The native GP-to-Business Central migration tool imports inventory with the cost valuation method that is set in GP at the time the migration is run. Location information and the quantity on hand for each item is migrated. This means the tool locks you into your current GP costing method. If you want to switch from Average Cost to FIFO during the migration — which many distribution companies do — the native tool will not help.

One nuance worth noting: GP supports FIFO perpetual, LIFO perpetual, moving average perpetual, FIFO periodic, and LIFO periodic as inventory valuation methods. Business Central supports FIFO, LIFO, Average, Standard, and Specific. The systems overlap, but they are not symmetrical — Specific is a Business Central costing option that does not exist as a named valuation method in GP Inventory Control. (learn.microsoft.com)

Here is where the costing methods diverge between GP and Business Central:

Even if a Business Central item is set to FIFO, the Unit Cost field still displays an average cost. Depending on your Inventory Setup, this average cost might not be as it seems either. This confuses finance teams who expect the item card to show the oldest receipt cost. The actual FIFO application happens at the value entry level when transactions post — not on the card.

GP periodic users need a separate review. Microsoft's stock-status guidance says FIFO and LIFO periodic inventory is valued at standard cost. If you are leaving GP periodic and moving to a true perpetual method in BC, do not assume an opening-value tie-out means future inventory behavior will match. (learn.microsoft.com)

When You Need to Change Costing Methods During Migration

Switching costing methods is not uncommon. A company using Average Cost in GP may want FIFO in Business Central for better lot traceability. Or a manufacturer on FIFO may want Standard Cost for variance analysis. In Business Central, you cannot change an item's costing method after the item has ledger entries — Microsoft's documented workaround is to create a new item and transfer inventory. (learn.microsoft.com) This means the conversion must happen during migration, not after.

A costing method conversion requires:

1. Collapsing existing cost layers — All open receipt layers in IV10200 must be consolidated into a defensible opening balance
2. Recalculating the opening cost — For FIFO-to-Standard, you set the standard cost and treat any difference as a day-one variance. For Average-to-FIFO, you create synthetic receipt layers from the opening inventory
3. Documenting the bridge — Your auditors need a reconciliation showing that total inventory value in GP at cutover equals total inventory value in the new system, even though the per-unit costing logic changed

A concrete example: GP shows 100 units on hand built from two open layers — 40 units at $10 and 60 units at $12. If the target ERP will run FIFO and you load a single opening balance of 100 units at a blended $11.20, your next sale will not cost correctly because you destroyed the receipt-layer structure. If the target will use Standard costing, the rule changes again: BC values standard-cost inventory increases at the current standard cost, not the actual receipt cost.

The native migration tool cannot do any of this. It is a costing-method-preserving migration, not a costing-method-converting one. For common patterns in how these transformations fail, see Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Mapping GP Unit of Measure Schedules to Modern ERPs

UoM Schedules are a GP-specific construct that does not exist in most modern ERPs. In Business Central, there isn't a direct equivalent to the Unit of Measure Schedules table (IV40201) found in Dynamics GP. Schedules aren't actually units of measure — they're an ID in Dynamics GP that holds a group of units of measure. Business Central doesn't have UoM Schedules. It only stores units of measure that would be in the GP table IV40202.

In GP, a UoM Schedule is assigned to each item in IV00101 via the UOMSCHDL field. The UoM Schedule is assigned to each item (stored in the IV00101 table) and determines what units of measure are available for each item. The setup of the UoM Schedule is stored in tables IV40201 and IV40202. Multiple items can share a single schedule — for example, a schedule named "BOX-12" might define that 1 Box = 12 Eaches, and that schedule can be assigned to hundreds of items.

Business Central does allow you to set up and manage multiple units of measure for items. You can define a base unit of measure for each item and then create alternate units of measure for purchasing, production, or sales. These alternate units of measure specify how many units of the base unit of measure are handled in different processes.

Here is the mapping pattern:

The migration work: extract every item's schedule assignment from IV00101, join it to IV40202 to get the base UoM and conversion factors, then create item-level UoM records in the target ERP. The trap is that GP allows multiple items to share one schedule, but target ERPs define UoM conversions per-item. If two items share a schedule in GP but need different conversion factors in the target system, you have to split them.

Here is a SQL extraction approach to flatten GP UoM data for a modern ERP payload:

SELECT 
    i.ITEMNMBR AS ItemNumber,
    i.UOMSCHDL AS UomSchedule,
    u.BASEUOFM AS BaseUoM,
    d.UOFM AS AlternateUoM,
    d.QTYBSUOM AS ConversionFactor
FROM 
    IV00101 i -- Item Master
JOIN 
    IV40201 u ON i.UOMSCHDL = u.UOMSCHDL -- UoM Schedule Header
JOIN 
    IV40202 d ON u.UOMSCHDL = d.UOMSCHDL -- UoM Schedule Detail
WHERE 
    i.ITEMTYPE = 1 -- Active Inventory Items

Validate the output to ensure no items have missing base UoMs — these cause hard rejections in the target ERP.

Run a pre-migration query against IV40201/IV40202 joined to IV00101 to identify how many unique schedules are in use, which items share schedules, and whether any schedule has conversion factors that are inconsistent with the target ERP's decimal precision. Fixing UoM issues after migration means re-doing every open PO and SO.

Migrating Serial and Lot Tracking History (IV00200 & IV00300)

This is where most GP inventory migrations get expensive — not because the current on-hand data is hard to move, but because the history is massive and teams cannot agree on how much to bring over.

GP's serial and lot tables store the full lifecycle of every tracked unit:

• IV00200 (Serial Number Master): Every serial number ever received, with flags for whether it has been sold, its receipt sequence number, location, unit cost, and date received
• IV00300 (Lot Number Master): Every lot number with quantity received, quantity sold, quantity allocated, unit cost, receipt sequence number, and vendor number
• IV30400: Historical serial and lot number records from closed transactions

When GP's reconcile runs, it checks each receipt sequence number line and verifies that there are available serial or lot numbers in IV00200 or IV00300 to cover the remaining quantity in IV10200. If there are not enough serial or lot numbers to cover the remaining quantities, reconcile will add records using "RECONCILEXX" as the placeholder serial or lot number.

This means GP itself can create synthetic records during reconciliation. If you see RECONCILE01, RECONCILE02, etc. in your serial or lot tables, those are GP's patches for data integrity issues. You must resolve these before migration or you will carry phantom serial numbers into the new system.

-- Find placeholder serial numbers created by GP Reconcile
SELECT ITEMNMBR, SERLNMBR, LOCNCODE, QTYTYPE
FROM IV00200
WHERE SERLNMBR LIKE 'RECONCILE%'
 
-- Find placeholder lot numbers
SELECT ITEMNMBR, LOTNUMBR, LOCNCODE, QTYRECVD, QTYSOLD
FROM IV00300
WHERE LOTNUMBR LIKE 'RECONCILE%'

The History Decision: Migrate or Archive?

You have two real options for historical serial/lot data:

Option 1: Migrate only active on-hand serial/lot records. Move only records in IV00200 where the serial number is not yet sold (SERLNSLD = 0) and records in IV00300 where the lot has remaining quantity (QTYRECVD - QTYSOLD > 0). This keeps the new system clean. The downside: warranty lookups, recall traceability, and regulatory audits that require full serial history will need to query an external archive.

Option 2: Archive the full GP database separately. You can create a copy of the Dynamics GP database in Azure Data Lake so that you have it for future reference after the migration to Business Central online. A customer isn't required to copy their database to Azure Data Lake, but there are several benefits to doing so, including having access to the historical data that isn't migrated by the migration tool.

For most distribution and manufacturing companies, the practical approach combines both: migrate active on-hand tracking data into the new ERP, and archive the full GP database (including IV00200, IV00300, and IV30400 history) to Azure Data Lake. A BI tool or a reporting connector like eOne's Popdock can surface historical data inside the new ERP interface without physically loading it into your production database. (eonesolutions.com)

Physically migrating decades of serial/lot history into the new ERP bloats the database, degrades transaction performance, and provides no operational benefit for day-to-day transactions. For a deeper discussion of what data should and should not move, see What Data Should You Actually Migrate to Your New ERP?.

Multi-Location Inventory: Site, Bin, and the IV00102 Quantity Problem

The Item Quantity Master (IV00102) stores the quantities of items. It consists of an 'overall' record that holds the totals for all sites as well as a record for each site that the item is assigned to. The two types are differentiated by the Location Code and Record Type.

This is where multi-location migrations break. You cannot migrate a single quantity-on-hand number per item. You must migrate per-site, per-bin quantities — and each of those quantities must tie back to the receipt layers in IV10200 and the serial/lot records in IV00200/IV00300 for that location.

A normal inventory transaction posting affects IV00102 to adjust quantity, inserts records into IV30300 for history, and affects IV10200 and IV10201. All these tables must have the same quantity in normal cases, but in some cases you might have differences. The reconciliation utility reconciles IV00102 based on the difference between Quantity Received and Quantity Sold of IV10200.

GP's warehouse model can include sites, item-site assignments, multiple bins, and transaction-type default bins at both site and item-site level. When multiple bins are enabled, GP can populate AUTOCREATE bins during reconcile. Business Central also has locations and bins, but there can be only one default bin per item per location, and bin behavior changes at more advanced warehouse levels. Treat site and bin mapping as a first-class workstream, not a cleanup task after the load. (learn.microsoft.com)

Your validation grain should be at least:

item_number
location_or_site
bin_code
lot_number
serial_number
base_uom
qty_on_hand
inventory_value

Pricing Architecture: Standard Price Lists vs. Extended Pricing

GP has two completely separate pricing engines, and the migration approach differs for each.

Standard Pricing stores data in IV00107 (Item Price List Options) and IV00108 (Item Price List). The IV00108 table is simply listing the price for each item/currency/UoM combination. So for example, if you have an item that can be sold as both an EACH and a CASE, you could enter a price for EACH and a price for CASE in the item pricing. Those would be stored as different lines in the IV00108 table.

Extended Pricing uses an entirely different set of tables — SOP10109 (Price Books), SOP10110 (Price Sheets), IV10401 (Price Group Detail), and IV10402 (Pricing Details). Extended Pricing supports price books assigned to customer groups, price sheets with date-effective pricing and quantity breaks, promotional pricing with start/end dates, and customer-specific price overrides. GP does not allow you to use both pricing engines simultaneously. (learn.microsoft.com)

Most target ERPs do not have a 1:1 equivalent of GP's Extended Pricing. Business Central uses Sales Prices and Sales Line Discounts (or the newer Price Lists feature). NetSuite uses Price Levels and Quantity Pricing Schedules. The structural translation requires flattening GP's multi-layer pricing hierarchy into the target system's format — and deciding which historical pricing rules are still active versus expired.

BOMs, Kits, and Assembly Structures

GP stores bill of materials data in IV00104 (Item Kit Master) for kits, and in the Manufacturing series tables (BM00101, BM00111) for production BOMs.

The migration challenge is both structural and behavioral. A GP Kit is assembled on the fly during sales order entry — kit quantities are not tracked in inventory; only component quantities are. (learn.microsoft.com) A GP Assembly is built and stocked in advance as a finished good. If you map a GP Kit to an Assembly item in the new ERP, you will artificially inflate your component inventory and break your sales fulfillment workflows.

Business Central supports both Assembly BOMs (similar to GP kits) and Production BOMs (similar to GP manufacturing BOMs). BOM and routing data require careful validation. Manufacturing configurations that operate in GP may need to be restructured to align with Business Central or Supply Chain Management processes for production orders, work centers, and routings. Manufacturing item BOMs and routings need redesign for BC — they are simpler in BC, which is generally good. But "simpler" means some GP routing complexity — like subcontract operations or concurrent operations — may not have a direct equivalent.

If the target will calculate standard costs from assembly or production BOMs in BC, Microsoft requires the parent and component items to use the Standard costing method. Settle that before BOM cost rollups and opening valuation sign-off. (learn.microsoft.com)

Pre-Migration Data Cleansing and Reconciliation

Before extracting any inventory data, you must clean the source. GP MVP Victoria Yudin and other system experts consistently point out that unposted batches and orphaned records will cause the calculated quantity to differ from physical reality. (victoriayudin.com)

Run these checks in GP before your final extraction:

1. Post all unposted inventory batches. Check IV10000 (Unposted Transactions header) and IV10001 (line detail). Any unposted batch means items are in a work state — quantities in IV00102 will not match the receipt layers in IV10200. Ensure no unposted transactions exist in Sales Order Processing (SOP), Purchase Order Processing (POP), or Inventory Control.
2. Run Inventory Reconcile for all items (Tools > Utilities > Inventory > Reconcile). This forces GP to recalculate the quantities in IV00102 based on the actual receipt and sales transaction details in IV10200.
3. Run the Historical Inventory Trial Balance (HITB) report and compare it to the General Ledger inventory account balances. If these do not match, you have a posting-level discrepancy that must be resolved before migration.
4. Query for RECONCILEXX records in IV00200 and IV00300. These indicate prior data integrity issues that GP patched with placeholder serial/lot numbers.
5. Clear orphaned allocations. Resolve any cases where an item is marked as allocated to a sales order that no longer exists.

Post-Migration Validation Framework

After loading inventory into the target ERP, run these validation checks before go-live. Inventory QA fails when teams compare the wrong totals. The right framework checks quantity, value, and traceability at the same operational grain the business uses.

Tier 1: Quantity Integrity (Day 1)

Tier 2: Costing Integrity (First Week)

• GL reconciliation: Compare total inventory valuation in the target ERP to the GL inventory account balance. These must match. Use like-for-like reports — Microsoft's GP guidance notes that the Stock Status report includes only On Hand quantities, while the Purchase Receipts report includes all quantity types. Comparing unlike reports creates fake variances. (learn.microsoft.com)
• Spot-check 20 recently received items: Verify that the cost on the most recent receipt layer in the target ERP matches the PO cost from GP.
• Process a test sale of a serialized item: Confirm the correct serial number is consumed and the COGS entry reflects the expected cost (not the item card's displayed average).

Tier 3: Operational Validation (First Two Weeks)

• Price a sales order using a customer who had Extended Pricing in GP. Verify the correct price is returned.
• Process a lot-tracked item return. Verify the lot number is correctly credited back to on-hand.
• Run the Adjust Cost – Item Entries job (in BC) and confirm no unexpected value entries are generated. BC's cost adjustment can revalue item costs after posting, especially for actual-cost items and average cost periods. (learn.microsoft.com)
• Compare BOM explosion for 5 representative manufactured items between GP and the target system.
• Pick a known lot or serial and prove you can trace it through the target ERP — receive it, transfer it between locations or bins, and sell it without breaking availability. Business Central's Item Tracing and Find Entries pages are a good test model. (learn.microsoft.com)

For a complete migration validation approach including financial data, see The Ultimate ERP Data Migration Checklist (10-Point Plan). For an in-depth look at moving historical financial data alongside inventory, see Dynamics GP to Business Central: Migrating 20 Years of History.

How ClonePartner Handles GP Inventory Migrations

Inventory migrations are where generic migration tools hit their limits. The native GP-to-BC migration wizard handles the straightforward case: same costing method, active items only, standard pricing. For everything else — costing method conversions, selective serial/lot history migration, Extended Pricing translation, multi-location BOM restructuring — you need custom transformation logic.

ClonePartner's approach to GP inventory migrations:

• Pre-migration data audit scripts that scan IV00102, IV10200, IV00200, and IV00300 for quantity discrepancies, RECONCILEXX placeholders, orphaned receipt layers, and unposted batches — before a single record is extracted.
• Costing method conversion scripts that collapse GP cost layers and rebuild them in the target ERP's format, with full audit trail documentation for your finance team.
• Selective serial/lot migration that moves active on-hand tracking data into the target ERP while archiving historical records to Azure Data Lake or your preferred storage layer.
• UoM schedule decomposition that translates GP's IV40201/IV40202 structure into per-item base and alternate UoM records in the target system, including validation of conversion factor precision.
• Automated reconciliation that programmatically compares GP's dynamically calculated quantities against the new ERP's subledger by item, location, lot, serial, and value — proving to your auditors that every unit and every dollar made the transition.

With 1,500+ completed migrations, we have seen every variant of GP inventory data — from 200-item distributors to 50,000-SKU manufacturers with 20 years of lot history. The work is not glamorous, but getting it wrong means your warehouse team cannot ship on day one.