> ## 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. # How to add a new SKU to an existing listing > Register the stock, then make an already-published listing actually use it — including the value-list trap that hides a brand new SKU from an old rule. catalog/listings A new [SKU](/docs/concepts/inventory/skus) does not attach itself to any listing. Registering its stock is only half the job — the listing's [Fulfilment rules](/docs/guides/catalog/listing-inventory-rules) also have to recognise the new units, and on a rule built from a fixed list of names or codes, they will not until you add them. ## Prerequisites **Required permissions:** `inventory:sku_general:create` and `inventory:stock_item_general:create` to register the new stock, plus listing manage rights to edit the fulfilment rule. All four system roles hold these. **Before you start, know:** * **Which listing (and which variant, if it has any) should sell the new SKU.** * **What the existing rule matches on** — open the listing's Fulfilment tab and read the condition before changing anything. This decides whether the next steps take one click or several. ## The Walkthrough Follow [Register stock items](/docs/guides/inventory/register-stock-items) to create the SKU (if it does not exist yet) and the stock items behind it. Give it whatever attributes your existing rules match on — size, colour, category, or whatever the listing already uses to sort stock. On a plain listing this is the **Base item**. On a listing with variants, check whether the variant the new SKU belongs to has its own **Variant specific rule** — if it does, that is the one to edit, not the base rule underneath it. Read the condition as the sentence it is: **\[field] \[operator] \[value]**. The operator is what decides what happens next. If the condition matches **Attribute is \[value]** and the new stock items carry that attribute, they are already included — the rule discovers matching stock at order time, not at rule-writing time. Skip to the last step and confirm the count moved. A condition can read **is** (one exact value), **is in list**, or **is not in list**. The last two carry an explicit, fixed set of values — TWICE does not add to that list on its own when a new SKU is created, even one that would obviously belong there. Open the condition, find the values list, and add the new SKU's code or name — matching whichever the condition is built on. A condition reading **SKU Code is in list** needs the SKU's `code`; **SKU Names is in list** needs its `name`. Adding the code when the condition lists names does nothing. Each **Variant specific rule** keeps its own separate condition and its own value list — editing the base rule does not reach them. If the new SKU should fulfil more than one variant value, its identifier has to be added to each of those variant rules individually. Back on the condition you edited, the live **n matches in inventory** count should read higher than before by the number of stock items you registered. If it did not move, the value you typed does not equal what the stock items actually carry — check spelling and case, and check you added it to the right field (name vs. code). ## How do I know it worked? * **The condition's match count increased** by exactly the number of new stock items. * On a listing with variants, **Stock Availability on the Variants tab** shows units behind the variant the new SKU belongs to. That number is computed from the fulfilment rules every time the tab loads — it is a read-out, not a field, so there is nothing to type into it directly. If it is still zero after the rule change, the rule is the thing to re-check. * **A test booking of that listing (or that variant) holds one of the new units** — check the item's Events tab afterwards to confirm. ## Troubleshooting / Common Pitfalls **Cause:** the rule that should fulfil it uses **is in list** (or a single **is**) against item/SKU names or codes, and the new SKU's identifier was never added to that list. Nothing about creating a SKU updates a fulfilment rule automatically, no matter how obviously it belongs there. **What to do:** open the condition, confirm which field it lists (names or codes), and add the new SKU's matching value. **Cause:** it looks like a field because it sits in a table cell, but it is derived — the live result of resolving that variant's fulfilment rule against current stock, recalculated on every load. There is no way to set it, and no code path that writes to it. **What to do:** change the thing it is computed from instead — the fulfilment rule's conditions (this guide) or the stock itself (missing attribute, wrong location, inactive status). **Cause:** **Item Names** / **SKU Names** and **Item Code** / **SKU Code** are different fields matching different values on the stock item. Adding a code to a names list, or a name to a codes list, matches nothing. **What to do:** read the condition's field label before typing anything in, not just the operator. **Cause:** the rule is built on a maintained list of specific values rather than on an attribute every current and future SKU shares. **What to do:** if every SKU that should fulfil this listing (or variant) shares something structural — a category, a size, a product line — add that as an attribute and rewrite the condition to match on it instead. See [Listing inventory rules](/docs/guides/catalog/listing-inventory-rules) for matching on an attribute versus a fixed list. A list you maintain by hand is fine for a handful of SKUs that rarely change; it is the wrong tool for a catalog that keeps growing. **Cause:** a **Variant specific rule** overrides the base rule for that variant value. The base rule's list is not consulted for a variant that has its own rule. **What to do:** find and edit that variant's own rule on the Fulfilment tab, not the base rule. ## Related articles Create the SKU and the stock items behind it. The full rule model — matching fields, operators, and checking what a rule finds. Variant-specific rules, and reading Stock Availability per variant. What a SKU is, and how Stock Items inherit from it.