Inventory and SKUs

Inventory is the list of things you own. One record per physical item, regardless of how many marketplaces it is listed on.

Inventory (open).

One item, many listings

This is the model everything else depends on. An item is the physical thing — its photos, description, condition, cost, SKU. A listing is that item offered for sale on one marketplace.

One item, four listings, one sale. That relationship is what makes auto-delist possible: when a sale lands on one listing, Reskale knows which other listings are the same item and can pull them down.

Break the relationship — two records for one physical thing — and auto-delist cannot help you, because as far as the data is concerned you own two.

Adding items

• Import from a connected marketplace — import your listings.
• Create directly — creating a listing. You can save as a draft without listing anywhere.
• CSV — Inventory → Import accepts an eBay-style export. Creates records only; it does not list anything.

SKUs

A SKU is your own identifier for an item — a shelf location, a bin number, a sourcing batch.

It matters when an item sells and you need to find it in a garage. Marketplace listing IDs are for computers; the SKU is for you.

Reskale can generate SKUs, or you can use your own scheme. If you already have one from another system, keep it — consistency across your history is worth more than any particular format.

Watch for collisions on re-import. If two items end up with the same SKU during an import, one can be dropped. If an import reports fewer items than you expected, duplicate SKUs are the first thing to check.

Duplicates

Inventory → Duplicates finds records that look like the same physical item and offers to merge them.

The common cause is importing the same item from two marketplaces: no shared identifier exists between them, so each import creates its own record.

Merging combines the records into one item with both listings attached. Worth running after any large import — and worth doing before you rely on auto-delist, which needs the merge to work at all.

Statuses

• Draft — created, not listed anywhere.
• Listed — live on at least one marketplace.
• Sold — sold somewhere.
• Not listed — was listed, no longer is.

If an item shows as listed but is not actually live on the marketplace, correct it with Mark as not listed. Stale "listed" rows are misleading in two directions: they inflate what you think is for sale, and they make auto-delist chase listings that are already gone.

Cost basis

Record what you paid. It feeds profit calculations in Sales and Bookkeeping.

Entering it at intake — while you still remember what the box cost — takes seconds. Reconstructing it in April from a shoebox of receipts does not.

Filtering

Filter by marketplace, status, category, brand or SKU. The most useful in practice is not listed on X — that is the working list for a crossposting session, since it is exactly the set of items missing from a marketplace.

Specialist categories

Two verticals have their own intake flows, because generic item fields do not capture what buyers of these actually search for:

• Music — release matching and grading for vinyl. See Discogs.
• Automotive — identify a vehicle from a photo or its VIN, check recalls and safety ratings, and save it to inventory with what you paid and what you expect to sell it for.

Both write into the same inventory.

Deleting

Deleting an item removes it from Reskale. It does not delist it from any marketplace — delist first, then delete, or you will have live listings that Reskale no longer knows about and therefore can never take down.

Deleting an item does not remove its past sales from Sales or Bookkeeping. Revenue history is a record of what happened, and it survives the item being removed.