Get your SKUs lined up
The order to do things in so your costs land on the right products: tidy Shopify first, take the baseline, then line up any remaining codes, calculate and sync. Why the baseline only happens once.
Updated 27 August 2026
Almost everything that goes wrong with costing in Landara is the same thing wearing a different hat: a cost recorded against a code that does not match what Shopify sells.
This page is the short version of how to avoid it, and what to do when it has already happened.
Why the SKU carries so much weight
Shopify owns your quantities. Landara attaches a cost to the movements Shopify reports, and it matches the two on the SKU. That is the only join between them.
So when the codes do not line up, both halves quietly go wrong at once:
- The cost layer sits under a code nothing sells, so it never depletes. Your stock valuation climbs and never comes down.
- The sale arrives under a code with no layers, so it costs nothing. Your margin looks better than it is.
Nothing errors. No red row, no failed import, no warning on the COGS report. That is why it is worth ten minutes up front.
This is the single most expensive mistake in the product, and it is completely invisible while it is happening. It usually surfaces months later as a COGS figure that will not reconcile and no explanation for why.
The order to do things in
- Settle your product data in Shopify. The SKUs you intend to keep, titles that read the way you want, and a field holding your suppliers' codes. This is the step people skip, and the SKUs are the part that is hard to undo.
- Connect Shopify to Landara, and set your opening stock baseline.
- Line up any remaining codes. Where a supplier's code still differs from yours, tell Landara once. Options below.
- Calculate the shipment. Landed cost per unit is worked out from the document.
- Sync costs to Shopify. This is the step that writes your cost layers.
Step 1 comes first because step 2 happens once. Setting your opening stock baseline gives each product a starting cost layer, and Landara does that once per product: running it again later skips anything that already has one. It is not a way to correct a catalogue you fixed afterwards.
So the SKUs your products carry at that moment are the ones your costs are filed under. Rename one afterwards and its cost stays behind under the old code.
You do not need to set a cost per item in Shopify. Landara uses it when it is there, and asks you for the rest: the guided setup screen lets you fill in missing costs before you take the baseline, and Fill missing costs on the Cost Layers page handles them afterwards. Do not go and price your whole catalogue in Shopify on our account.
That said, if you would rather have those costs in Shopify anyway (they drive Shopify's own margin reporting too), you can set them for the whole catalogue in one file alongside the supplier fields. See Bulk-edit product fields in a spreadsheet.
New products are the exception. If something does not exist in Shopify yet there is nothing to tidy: create it there, or let a supplier invoice bring it in, and it picks up its cost from the invoice rather than from a baseline.
Calculating with the wrong SKU costs you nothing on its own: the landed cost per unit is the same either way. It is syncing that writes the layers, so a code only has to be right by step 5.
Landara tells you before you calculate
Open a shipment that has not been calculated and Landara checks every SKU on the invoice against your Shopify catalogue. You will see one of two things above the products table:
- All 107 SKUs on this invoice match products in your Shopify store. Nothing to do.
- 12 of 107 SKUs will not reach a product in your Shopify store, listing which, with a button through to the fix.
Codes you have already linked count as matching, so once you have told Landara that a supplier's code means your SKU, it stops asking.
The four ways they fail to line up
The supplier uses their own codes
The usual case. Your supplier prints LAB57, you sell it as LAB-ADC-250.
Two ways to handle it, and they are not alternatives so much as different sizes of the same job:
- A few lines: correct the SKU directly in the products table on the shipment.
- A lot of lines: export to a spreadsheet, fix them in bulk, import back. See Fix invoice lines in a spreadsheet.
Either way Landara offers to remember the pairing, so the next invoice from that supplier arrives already resolved. Saved pairings live on Dashboard → COGS → Cost Layers.
Let Shopify hold the supplier's code
If you already record each supplier's code against your products in Shopify, or you are willing to, Landara can read it and build the mapping for you. This is the least work of any of the options, especially on a large catalogue.
Two fields, at two different levels, and the levels matter.
| Field | Where it goes | Why |
|---|---|---|
| Supplier SKU | Variants | Each variant has its own SKU, so it has its own supplier code |
| Supplier Name | Products | A product comes from one supplier, so the name belongs once on the product rather than repeated on every variant |
- In Shopify go to Settings → Custom data, and add a definition of type Single line text in each place: one on Variants for the code, one on Products for the supplier's name.
- Call them whatever suits you. Landara matches on the identifier Shopify generates from the name, so renaming them later changes nothing.
- Fill them in. The product field can be bulk-edited with Shopify's own product CSV export and import. The variant field cannot, so Landara gives you an export and import for that one on the Cost Layers page.
- In Landara, tell it which fields those are. You can do that in either place: Cost Layers → Supplier SKUs → Read from Shopify, or the first time you open Cost Layers → Start Setup, which offers the same choice. Check the summary and approve it.
Landara remembers the fields you picked, so every screen that needs a supplier code will fill it in from then on. Pick them once.
Editing the fields in bulk
Shopify can bulk-edit product fields through its own CSV export and import, but not variant ones. Since the supplier's code is a variant field, Landara gives you an export and import for it on Cost Layers → Supplier SKUs → Edit product fields in a spreadsheet.
That file carries both levels and Shopify's cost per item, so one pass sets who supplies a product, what they call each variant, and what each one cost you. A few things about it:
- Rows are matched on the Variant ID. Sort and filter as much as you like. Do not change or delete that column: a row without one is skipped, and anything you typed on it is not applied. Deleting whole rows you do not need is fine.
- SKU and Product are there so you can read the file. Editing them stops the import and names the rows, because this does not rename products.
- Emptying a cell does not clear the value. Landara only sets fields, never removes them, and tells you which cells it left alone. Clear those in Shopify if you meant to.
- A product with no SKU is not in the file at all, and Landara says which ones. Give them a SKU and export again.
- Write costs as plain numbers with a full stop. A cell with a comma in it stops the import rather than being guessed at, because
249,00reads as either 249 or 24,900 depending on where you are and the wrong answer is permanent.
The full walk-through, including how to create the two fields in Shopify, is Bulk-edit product fields in a spreadsheet.
Writing that file to Shopify does not put anything into Landara. Once it is in, use Read from Shopify on the Supplier SKU links card to bring the codes across. That saves the links and nothing else, so it creates no cost layers and changes no costs.
Shopify's bulk editor for these fields does not work properly in Microsoft Edge, because of a limit on URL length. Use Chrome, Firefox or Safari.
The supplier's name is optional. Without it, a link applies to any supplier, which is right if you buy each product from one place. Add it when two of your suppliers use different codes for the same product.
A product with no SKU cannot be linked to anything. Landara files every cost against the Shopify SKU, so a product without one is left out of the export entirely. It tells you which ones and how many, so give them a SKU in Shopify and export again.
Useful Shopify guides: creating the field and filling it in for many products at once.
Reading the field does not link Landara to it permanently. It proposes the pairs, you approve them, and they are saved as ordinary supplier SKU links. Change the field in Shopify later and nothing moves behind your back: read it again and Landara shows you what is different.
You renamed a SKU in Shopify
Renaming a SKU in your Shopify admin splits the product in two: the layers keep the old code, the sales use the new one.
Landara spots this on its own and lists it on the Cost Layers page under SKUs renamed in Shopify, with the number of layers stranded under the old code and a button to move them. See Stock on hand and availability.
Two products share a SKU
If the same SKU is on more than one product in Shopify, Landara will not guess which one you meant, so it matches neither. Correcting the invoice cannot fix this. Give each product its own SKU in Shopify, then check the shipment again.
The product is not in Shopify yet
Nothing is wrong, it just does not exist there. On a calculated shipment the sync panel offers to create the missing products for you.
If it has already happened
You have not lost anything, and this is worth knowing because it changes how urgent this feels.
Landara does not store a COGS figure. It works COGS out by replaying your movements against your layers, every time. So when you correct the codes and move the layers, sales that already went through uncosted are costed correctly from then on, including the ones in the past.
What does not change on its own is anything already posted to your accounting software. That stays where it is, and the difference shows up as a correction rather than a rewrite.
Moving cost layers between SKUs changes which sales they cost, so figures for periods you have already reported on can change. Landara refuses to move layers that fall in a closed period and tells you which ones, so post a correcting journal for those instead.
Where to look
| Screen | What it tells you |
|---|---|
| A shipment, before calculating | Which SKUs on this invoice will not reach a product |
| Cost Layers, Supplier SKUs | Every pairing you have saved, and SKUs renamed in Shopify |
| Stock on hand | SKUs Shopify holds with no cost, and costed stock Shopify does not report |
| COGS report | Sales that costed nothing, which is the symptom of all of the above |
