How to import your cost and pricing history into a new tool

Exporting your cost history is the half everyone talks about. Getting it in somewhere, correctly, is the half that decides whether your margins are real. A cost import that lands wrong does not throw an error. It just quietly tells you a candle costs $2.40 when it costs $4.80, and you find out at the end of a market season.

This guide covers the file shapes an importer expects, the columns that actually matter, the five breakages that cause nearly every wrong number, and the checks that prove the result before you trust it. It applies to any move, though the case in front of most makers right now is Stocky, which Shopify retires on August 31, 2026.

Coming from Stocky? Shopify retires Stocky on August 31, 2026, and there is a version of this page written around exactly that move: the Stocky migration checklist. Start there if Stocky is the tool you are leaving.

Two file shapes, and what each one can rebuild

Cost data comes out of old tools in one of two shapes, and they are not equally useful.

1. A purchase history: one row per purchase line. Date, vendor, item, quantity, unit cost, line total. This is the good one. From it, a costing tool can rebuild not just what a material costs now, but how it got there, which is what makes a margin defensible.
2. An item snapshot: one row per item, with a current cost. Fine for getting started, but it carries no trail. You will know a jar costs $1.35 and have no record that it was $0.90 in the spring, so you cannot explain last season's margins with it.

Take both if your old tool offers both. If it offers only the snapshot, take it and keep the invoices. And if you are still on the export step, the export walkthrough covers which reports to pull first, while the migration checklist puts the whole move in order.

(Stocky facts here come from the Shopify Help Center article "Transitioning from Stocky", verified July 2026. Export formats change; check your own file rather than trusting any published column list, including this page's.)

The columns that matter

Open your file and look for these. Not every export has every one, and the names vary by tool. What matters is that you can point at the concept:

• A stable item identifier. A SKU or code that does not change. Names get edited; identifiers are what let you match a row today to the same material next year.
• The item name, so a human can tell what the row is.
• Variant or option, if your old tool split one material across sizes or colors.
• Unit of measure. The single most load-bearing column on the list, and the one most often missing.
• Quantity purchased on that line.
• Unit cost, or line total, or both. Two of the three are enough; one is not.
• Currency, if you have ever bought from abroad.
• Purchase date, which is what orders the history.
• Vendor, which is what makes a price comparison possible later.

If a concept is missing entirely, decide now whether you can supply it from somewhere else, from the invoice or from your own knowledge of pack sizes, before you import rather than after.

Before you import: five minutes on the file itself

• Save a working copy and leave the original untouched.
• Confirm there is exactly one header row, and that it sits on the first line.
• Delete any totals or subtotal rows at the bottom. They import as materials with strange costs.
• Unmerge merged cells and remove blank spacer rows.
• Save as CSV, UTF-8. If your old tool handed you a spreadsheet file, this is the conversion step, and it is where accented supplier names get mangled if you skip the encoding.
• Note the row count. You will check it again after the import.

The five things that break a cost import

1. Currency and number formatting

Cost columns arrive with currency symbols, thousands separators, and sometimes a comma as the decimal mark. An importer that reads "1,250" as one thousand two hundred and fifty when it meant one and a quarter is off by a factor of a thousand. Strip symbols, settle on a period decimal, and if you have bought in more than one currency, convert first and note the rate you used. Negative numbers in parentheses, an accounting habit, also need rewriting as a minus sign.

2. Units: the pack-size trap

This is the one that gets almost everybody. You buy jars by the case. The export says quantity 1, unit cost $14.40, and you make 12 candles from it. Import that as-is and every candle carries a $14.40 jar. Or the reverse: a case cost imported as an each-cost divides your material cost by twelve and makes everything look wonderfully profitable.

Decide, per material, what one unit means, and convert everything to it before importing. Weight is the same story: grams, ounces and pounds mixed in one column will produce cost errors of sixteen or twenty-eight times. Pick one unit per material and never mix.

3. Variant mapping and identifier mangling

The same wax may appear as three rows under three slightly different names, which splits one material's history into three partial ones. Meanwhile a spreadsheet program will happily strip the leading zero from an item code, or turn a long numeric SKU into scientific notation, so two rows that should match no longer do.

Sort by name before importing, merge the duplicates deliberately, and format identifier columns as text. If your old tool had parent items and child variants, decide which level is the material, and drop the other, or you will double-count.

4. Historical cost layers

Tools store cost differently: the latest price paid, a moving average, or dated layers in the order they were bought. If you import only "current cost" you are importing an answer without its working, and the new tool has nothing to recompute from. If you import the purchase rows instead, the new tool can build its own cost the way it intends to.

Know which one you are handing over, and know what the receiving tool does with it. A moving average and a first-in-first-out layer will give you different numbers on the same purchases, which is fine, as long as you know which method your reports are using and can say so to an accountant.

5. Dates and rounding

Date columns arrive as day/month, month/day, or a spreadsheet serial number, and a misread date column shuffles your history into the wrong order. Set one date format across the file before importing.

Rounding is the quiet one. A wick that truly costs $0.0375 stored as $0.04 is off by seven percent, and that error rides every unit you make. Where an export gives you quantity and line total, import those and let the tool do the division at full precision, rather than importing a pre-rounded unit cost.

Import in slices, not in one leap

If the tool lets you, bring in twenty rows first and look at the result. A mapping mistake found on twenty rows takes two minutes to fix. The same mistake found on two thousand rows, after a week of work built on top of it, is an evening. Then import the rest, in files small enough that you can still tell what went where.

The checks that prove it worked

Run all of these. They take about twenty minutes and they catch different failures.

1. Row counts. Distinct items in your file against materials created. A gap means rows were skipped or silently merged.
2. Reconcile one invoice. Pick a real purchase order, add up its line totals, and find the same total in the new tool. This single check catches currency, decimal, and quantity errors at once.
3. Spot-check three materials against their invoices. Unit cost should match to the cent, or you should know exactly why it does not.
4. Recompute one finished product by hand. Add its parts up on paper, compare with the tool. A mismatch here is a unit problem nine times out of ten.
5. Sort by unit cost and read both ends. The cheapest and dearest materials are where pack-size and decimal errors show themselves.
6. Search for zero or blank costs. Each one makes some product look more profitable than it is.
7. Check the date span. Earliest and latest purchase dates should match your file. A short span means part of the history did not arrive.
8. Export from the new tool and open the result. If the data cannot come back out on day one, the import solved less than it looks.

When all eight pass, stop tuning and go use the thing. Perfect historical data is not the goal; numbers you can defend are.

What this looks like in Batchnook

Plainly, and with nothing oversold (the Stocky comparison page shows the same move side by side):

• A generic column mapper. Paste your CSV or upload the file, then match your columns to item, unit, quantity, and cost. There is no dedicated Stocky preset, so expect a few minutes of honest mapping per file rather than one button. Importing a spreadsheet walks the mapping step by step.
• A dry run before anything is written. It tells you how many materials and products will land and flags conflicts, and nothing is saved until you approve it.
• Moving-average cost from then on. Every new purchase re-averages the material, so a product's cost reflects what you have been paying lately. The method is disclosed on every report. Snap a supplier receipt and the scan reads the lines, and you approve them before anything counts.
• A 24-hour undo, so a bad mapping is a reversible afternoon.
• Recipes are built here, once. Retail stock tools do not carry a maker's build, so you enter each product's parts a single time and the cost maintains itself after that.

And whatever you decide: you can export everything, materials, products, batches, orders and cost history, as JSON or CSV, free, on every tier, forever. You are doing this migration because a tool closed. It should never be this hard to leave the next one.

FAQ

If you have not pulled your files yet, start with how to export your data from any inventory tool, then work through what to look for in a maker costing tool once your exports are safe.