Jewelry Inventory Management: A Practical Guide

Jewelry inventory management is the discipline of tracking stock for a category where the underlying assumption behind most inventory software — that a SKU restocks as the same SKU — breaks down constantly. A $6,000 pendant with a specific stone is not interchangeable with the next pendant that looks like it in a photo. A size 6 and a size 9 of the same ring style are not the same unit with a different label; sometimes they are, and sometimes the size 6 is a one-of-a-kind piece that happens to fit that finger. A piece sitting in the display case might not belong to the store at all. None of that is exotic. It is what a jewelry catalogue looks like once it has more than a hundred pieces in it, and it is why brands doing $3M–$30M in jewelry revenue keep hitting inventory problems that a general ecommerce playbook does not anticipate.

Why Does Standard Jewelry Inventory Management Fail on a Jewelry Catalogue?

Standard inventory software — Shopify’s native model included — is built around one number per SKU: Available. It assumes every unit of a SKU is fungible, restockable, and owned by the seller the moment it enters the catalogue. Jewelry violates all three assumptions at once, on the same product page, for different reasons.

A serialised piece violates fungibility: two rings with the same style number can differ in exact stone weight, clarity grade, or an engraved hallmark, so selling “one of SKU-4471” is not the same claim as selling one of a hundred identical t-shirts. A ring-size run violates it differently — sizes 5 through 10 of the same design genuinely are the same object at different scales, which is the one case where Shopify’s variant model fits cleanly. Made-to-order pieces violate restockability, because there is no stock to restock; the order triggers production. And memo or consignment stock violates ownership, because it is physically present and sellable but not owned until it sells or the memo period lapses.

A single Available number cannot hold all four states without losing information. The result, in practice, is a store that shows a piece as in stock when it is a customer’s ring in for repair, or shows zero available on a made-to-order style because nobody separated “no stock” from “no stock yet, by design.”

What Is the Mechanism That Actually Fixes This?

The mechanism is running owned inventory and memo/consignment inventory as two separate ledgers, not one blended count — and treating serialised pieces, ring-size runs, made-to-order pieces and repair intake as four distinct tracking models layered on top of those two ledgers, rather than four exceptions bolted onto one.

An owned-stock ledger answers one question: what does the business hold and control the sale of, right now. It includes finished pieces sitting in inventory and, for a brand that manufactures in-house, the raw materials — gold by weight, stones by carat and certificate — consumed to make them. A memo ledger answers a different question: what is physically present and sellable, but reversible, because a supplier can recall it or the memo period can end without a sale. Both ledgers can point at the same physical shelf. They cannot point at the same count, because a reconciliation, a margin report, or an insurance schedule built on the wrong ledger gives a wrong answer that looks correct until someone checks it by hand.

In a Shopify-based build, this typically means a second location record scoped to memo stock, with its Available count wired the same way owned stock is — so it still decrements on a sale and still blocks an overcommit — but excluded from the owned-inventory value reported to accounting. Repair intake gets its own non-sellable status for the same reason a customer’s ring cannot be allowed to sit in a pickable location: the cost of getting this wrong once, by selling a piece that belongs to a customer, is disproportionate to the cost of building the separation up front. This is the same pattern Pointerflow builds for ops automation generally — a workflow doesn’t fail because a rule was missing, it fails because two states that behave differently were forced to share one field.

Why Does the Obvious Approach — One Inventory List, More Tags — Fail?

The obvious fix, when a jewelry brand first notices the problem, is to keep one product list and add tags: memo, repair, made-to-order. Tags describe a piece; they do not change what the Available number means, and every report, reorder trigger and low-stock alert built on Available keeps reading memo stock as owned stock and repair intake as sellable stock. Tags are a labelling layer over a counting problem, not a fix for it.

The failure shows up first in reordering. A reorder point set against Available will fire — or fail to fire — based on a count that includes pieces the business doesn’t own and excludes pieces waiting on a customer’s decision. It shows up second in margin reporting: cost of goods sold calculated against a blended inventory value overstates owned stock by whatever memo inventory happens to be on the floor that month, and the error moves every time a supplier’s memo shipment changes. It shows up third, and most expensively, in insurance and shrinkage investigations, where the first question — was this piece ever actually ours — has no fast answer if ownership was never tracked as a field, only implied by a tag someone might have forgotten to apply.

What Does This Cost to Run, Compared to Leaving It as One List?

Splitting owned and memo stock into two ledgers costs setup time once — a second location or a custom field, a workflow that writes to the right ledger depending on how a piece entered the catalogue, and a report that sums both correctly for the storefront while keeping them separate for accounting. It does not cost more per transaction to run once it is built; a sale still decrements one count, the way it always did, the count is just now attached to the right ledger automatically instead of by memory.

The ongoing cost that does not go away is physical reconciliation — someone still has to count the safe, verify serial numbers against the system, and confirm a memo shipment matches what the supplier’s paperwork says came in. Software narrows the gap between the recorded count and the physical count; it does not remove the need to check. A cycle count cadence weighted by unit value — checking the highest-value categories on a short, fixed schedule rather than waiting for an annual count — is the operational habit that makes the two-ledger system worth having built.

What Does This Look Like for a Ring-Size Run Specifically?

A ring style that genuinely restocks across sizes behaves like Shopify’s variant model expects: one parent product, one variant per size, one Available count per variant, decremented on sale like any sized apparel item. The mistake is applying that model to every ring in the catalogue, including the one-of-a-kind pieces that happen to be a specific size. A serialised ring is not a variant of a style with a quantity of one in one size slot — it is its own product, sized once, sold once, and its “restock” is sourcing a different piece that is not the same object.

A product-catalogue structure that confuses the two is the single most common cause of a jewelry brand’s ring-size stockouts looking inconsistent: some styles restock cleanly because they were modelled as true variants, and others show phantom availability because a one-of-a-kind piece was forced into a variant slot that implied it could be replenished.

Who This Approach Is Not For

A jewelry brand under the $3M floor, selling primarily made-to-order or bespoke pieces with no meaningful memo relationships and a catalogue small enough for one person to know by memory, does not need two ledgers — a well-kept spreadsheet and Shopify’s default Available count will outrun the actual complexity for a while. The two-ledger approach earns its cost once memo relationships, serialised stock and staff who were not there when a piece came in all exist at the same time, which is typically the same point a brand crosses $3M and Shopify Plus stops being optional.

Jewelry inventory management is, at its core, an ops automation problem: the software has to encode which state a piece is in — owned, memo, made-to-order, in repair — and route every count, report and reorder trigger through that state instead of one blended number. Pointerflow’s ops automation work is built around exactly this kind of workflow separation for scaling ecommerce brands, where the fix is rarely a bigger inventory app and almost always a system that stops forcing two different things to share one field. Brands weighing a broader platform move to support this kind of setup can also read how Shopify inventory tracking and general ecommerce inventory software handle the same location and variant mechanics this piece builds on.