> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Get your stock into TWICE
> Register the stock you own, whichever system it comes from — the route to use, what the import creates alongside it, and how to reconcile the result.
Part of step 4 of the [launch path](/docs/guides/launch/overview), [Bring in your data](/docs/guides/launch/bring-in-inventory-and-catalog). This is the first thing you do that touches real data, and everything after it — listings, availability, pricing, your first order — reads what you put in here.
Three sources, one page. Read the section for where your stock is now; the checks at the end apply to all three.
**Finish [Set up your business](/docs/guides/launch/set-up-the-foundation) first.** Stock items attach to locations and carry attribute values, and the import creates a location or an attribute it does not recognise rather than refusing the row. Importing against a half-built foundation means importing again.
Attributes matter most. Existing attributes are offered as import columns automatically and are matched by their key; anything else you map becomes a **new attribute on your account**, not just on the rows you imported. Design them before the import, not after it.
## What you are creating
Two records, and knowing which is which decides how you shape your file.
| | What it is | One per |
| -------------- | -------------------------------------------------------------- | -------------------------------------- |
| **Stock item** | A physical thing you own, with its own code, history and costs | Unit, or pool of interchangeable units |
| **SKU** | The definition those units share | Model, size, variant |
A stock item can exist without a SKU. A SKU groups stock items so a listing can ask for "any one of these" rather than a named unit.
Read more: [Stock item vs SKU](/docs/inventory/stock-item-vs-sku).
## Pick your route
| Where your stock is now | Use | The thing that goes wrong |
| ------------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------- |
| TWICE 1.0 | Reconcile what was migrated, or export and reshape | The 1.0 model does not map one-to-one onto stock items and SKUs |
| A spreadsheet or another system | **Inventory > Stock items > Register Items > Import CSV** | One bad column mapping, repeated 4,000 times |
| Nothing yet | **Register Items**, or **Upload Images** for stock you cannot describe | Registering faster than you decide how units are tracked |
### From TWICE 1.0
If your move is a migration with a scope agreed with TWICE, your SKUs and stock items come across for you and your job is to check them, not to import them. Follow [Migrating from TWICE 1.0](/docs/guides/migration/overview) instead of this page — it is written for an account with a live 1.0 system on the other side of the switch, and it carries constraints a launch does not.
If you are exporting from 1.0 yourself, the export is the easy half. The mapping is the work, and there is one decision the export cannot make for you: **for each group of stock, does every unit become its own stock item, or do they become one pooled record with a quantity?** Serialized units — anything with a serial number, a service history, or a per-unit cost you care about — need their own row. Interchangeable units do not.
Make that call per group before you write the file. It sets what your file looks like, and it is expensive to change once orders have attached to the records.
For 1.0 itself — where its exports live and what they contain — see [support.twicecommerce.com](https://support.twicecommerce.com).
### From a spreadsheet or another system
**Import ten rows before you import four thousand.** The importer sends rows in batches of 1,000, so a failure part-way through leaves the earlier batches already created. There is no undo: a stock item that has never been booked can be deleted, and everything else is archived, not removed.
A ten-row test costs a minute and shows you the mapping, the tracking behaviour and the records the import created alongside your items — all the things a full run makes expensive to discover.
Only two columns are required: **Item Name** and **Location**. Everything else is optional, and any column in your file can be mapped to a different TWICE column by hand.
The one that catches people is **Quantity**, because the CSV import behaves the opposite way to the registration dialog:
| Quantity in the row | Result |
| ------------------- | ---------------------------------------------------------------- |
| 1 or blank | One stock item, tracked individually |
| 2 or more | **One pooled record** holding that quantity, under a single code |
If you need each unit tracked separately, give each unit its own row with a quantity of 1. The dialog defaults the other way, so a file written from what you saw in the dialog will pool stock you meant to serialize.
The full column list, the wizard's five steps and the failure modes are in [Import inventory from a CSV](/docs/guides/inventory/import-inventory-csv).
### Starting fresh
Register as you go, from **Inventory > Stock items > Register Items**. It is the right route when you are adding stock in ones and tens, and the dialog makes the tracking decision explicit rather than inferring it from a column.
Use **Upload Images** instead when you cannot describe the stock from memory — second-hand intake, a mixed pallet, anything where the category has to be looked up. You give it photos and it suggests the name, category and attributes for you to correct. It is a suggestion, not an import: check it before you register. See [Register from photos](/docs/guides/inventory/register-from-photos).
## Check what the import created alongside your stock
An import that ran without errors still changes three other things on your account. Check all three, on every run, including the ten-row test.
| Check | Where | Why |
| ---------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| SKUs | **Inventory > SKUs** | Any SKU name or code in your file that did not exist is now a SKU |
| Locations | **Settings > Locations** | Any location name that did not match is now a location, with no address and no opening hours — and locations can affect what your plan bills |
| Attributes | **Settings > Attributes & Tags** | Every column you mapped as a new attribute now exists account-wide |
"Helsinki Store" and "Helsinki store " are two different locations to the importer. A trailing space in one row is how an account ends up with two of everything.
## Reconcile by value, not by row count
The row count tells you the import ran. It does not tell you it was right: a price column mapped to the wrong field, or a decimal place lost in the export, leaves the count identical and the numbers wrong.
**Purchase Price is not an import column.** It is set on the SKU, where every stock item under it inherits the value, or on the stock item itself to override its SKU. Set it after the import — on the SKU for a group of identical units, or by selecting rows in **Inventory > Stock items** and [bulk-editing them](/docs/guides/inventory/bulk-edit-stock-items).
Then check the total. Export the Stock items table to CSV and sum the Purchase Price column against the same total in the system you came from. The export writes TWICE's own field names as its first row, so an exported file maps back onto the import columns without renaming anything — which also makes it the fastest way to correct a batch: export, fix, re-import.
Where the totals differ, find the specific item rather than accepting the gap. An error found now is a correction. Found after go-live, when a customer has already been charged from it, it is a refund.
## If the import went wrong
Archive, do not try to delete. Only a stock item that has never been booked can be hard-deleted; everything else moves to the archive, which keeps its history and can be undone with unarchive. Select the rows in **Inventory > Stock items** and use **Archive**.
Archiving is refused when it would affect live data — an upcoming booking, a listing left with no stock — and tells you what it would have hit. During a launch that check should come back clean, and it is worth reading rather than forcing when it does not.
Read more: [Archive stock items](/docs/guides/inventory/archive-stock-items).
## Done when
* Every group of stock has a deliberate tracking decision behind it: serialized units have their own records, pooled units have one.
* Stock item counts match what you exported, per location.
* Total purchase value in TWICE matches the same total in the system you came from.
* **Inventory > SKUs**, **Settings > Locations** and **Settings > Attributes & Tags** contain only what you meant to create.
* Anything that did not reconcile is written down and has an owner.
## Related articles
The launch step this guide belongs to.
Every column, the five wizard steps, and the failure modes in full.
The dialog route, one item or a handful at a time.
Letting TWICE read the unit off its images.
What TWICE counts as a unit, and what groups those units.
Serialized versus pooled tracking, and when each is right.
The path to follow instead if you have a live 1.0 system.