Get your stock into TWICE

Register the stock you own before anything is built on it. This is the first thing you do that touches real data, and listings, availability, pricing and your first order all read 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 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. Design your attributes before the import rather than after it. Existing attributes are offered as import columns automatically and are matched by their key, and anything else you map becomes a new attribute on your account rather than on the imported rows alone.

​

What you are creating

Two records, and knowing which is which decides how you shape your file. 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.

​

Pick your route

​

From TWICE 1.0

Follow Migrating from TWICE 1.0 instead of this page 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 rather than import them. That path 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. Decide one thing the export cannot decide 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? Give serialized units their own row. That means anything with a serial number, a service history, or a per-unit cost you care about. Interchangeable units do not need one. Exporting from 1.0 is the easy half; the mapping is the work. 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. See support.twicecommerce.com for 1.0 itself: where its exports live and what they contain.

​

From a spreadsheet or another system

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: 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.

​

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, such as second-hand intake, a mixed pallet, or anything where the category has to be looked up. It takes photos and suggests the name, category and attributes for you to correct. Check the suggestion before you register: it is a suggestion rather than an import. See 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. “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. Set Purchase Price after the import, because it is not an import column. Set it on the SKU, where every stock item under it inherits the value, or on the stock item itself to override its SKU. Use the SKU for a group of identical units, or select rows in Inventory → Stock items and bulk-edit them. 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. That 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, such as an upcoming booking or a listing left with no stock, and it tells you what it would have hit. Expect that check to come back clean during a launch, and read it rather than forcing past it when it does not. Read more: 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