How to update product prices, inventory, and discontinued items

1. Introduction

Throughout this guide we follow a fictional supplier, Summit Grove Home, running a routine maintenance cycle: an inventory file adjusts quantities and restock information, a price file updates cost, MSRP, and MAP, and a discontinued file retires one SKU. All product names, SKUs, prices, quantities, and dates shown are fictional demo data.

These workflows sit alongside — not inside — the general catalog import covered in mapping CSV columns to catalog fields. The platform features behind them are Inventory & Price Sync and Version History.

2. The three types of catalog updates

Each update type is a purpose-built module keyed by SKU. It touches only the fields it carries — nothing else about the product changes.

This separation is the point: a price file can't accidentally zero your stock, and an inventory file can't disturb your pricing. For a full product-content refresh — new descriptions, images, or categories — use the general catalog-import workflow instead (see How It Works).

3. Before preparing an update file

Three questions to settle first: which products are changing (only include those — these are targeted updates, not full re-imports), which fields are changing (pick the matching module), and whether your SKUs in the file match the SKUs in your catalog exactly. Files are standard CSV or Excel — the same formats as the rest of the platform (see CSV & Excel).

4. Identify products consistently by SKU

The SKU is the join key: every row in an update file finds its product by SKU. Rows whose SKU doesn't match an existing product can't apply — so consistency between your source systems and your catalog matters more than anything else in this workflow. Watch for the classic mismatches: stray whitespace, leading zeros dropped by a spreadsheet, and variant suffixes present in one system but not the other. Clean SKU discipline is part of broader product data management.

5. Prepare an inventory update

An inventory file carries SKU and quantity, plus restock information where supported — a restock date or ETA, a restock quantity, and unit-of-measure or notes columns where supported.

Note the out-of-stock row: a zero quantity with a restock date tells resellers when to expect product back — far more useful than a bare zero.

6. Prepare a price update

A price file carries SKU plus one column per price role you're changing — cost, price, MSRP, MAP, or verified custom roles. Partial updates are the normal case where supported: include only the SKUs and only the roles that changed, and everything you leave out stays untouched.

All figures fictional. MAP values here are delivered to resellers as price data alongside the numbers your Catalog Rules calculate — keeping the MAP role current is what keeps the floor you communicate meaningful.

7. Prepare a discontinued-item update

A discontinued file carries SKU, discontinued status, a discontinued date, and notes where supported — the date is what lets resellers plan a sell-down instead of discovering a hole in the catalog.

8. Include the brand when required

The same SKU may exist under different brands, so include the brand whenever more than one brand could match. If your account carries multiple brands and a SKU could match products in more than one, the update file must include a brand column so each row resolves to exactly one product. When the brand is ambiguous and missing, the row is flagged in validation rather than guessed at.

9. Understand the single-brand fallback

If your account has exactly one brand, the brand column is unnecessary — every SKU can only match within that brand, so the file may omit the column entirely and rows resolve by SKU alone. The moment a second brand exists, treat the brand column as required and add it to your file templates before you need it.

10. Upload and parse the update file

Upload the file to the matching module — inventory, prices, or discontinued. The platform parses it and shows what it found before anything applies: nothing in your catalog changes at upload time. Parsing is where structural problems surface — a missing SKU column, an unreadable sheet, a header the module doesn't recognize.

11. Review validation results and errors

Validation is the checkpoint between your file and your catalog. Review it row by row before applying:

Unmatched rows don't apply — fix the file and re-upload, or proceed knowing those rows are skipped. A high unmatched count usually means a SKU-discipline problem (section 4), not a file problem.

12. Apply the update

Applying commits the validated rows as a batch: the products' targeted fields change, and the batch is recorded in that module's history with what changed and when. Applying is deliberate — a parsed file sitting in review touches nothing until you apply it.

13. Rebuild affected catalogs

Shared catalogs are generated artifacts: after a price or discontinued update, rebuild the affected catalogs so the change flows through to what resellers actually receive — with overrides and Catalog Rules re-applied on top of the new data.

14. Verify the updated product data

Spot-check like a reseller would: open a handful of updated products and confirm the new quantity, the new role values, or the discontinued flag and date. If the catalog is shared, check the reseller-facing result too — the habit that catches a wrong base role or a missed rebuild before a partner does. The full sharing-side verification routine is in the catalog-sharing guide.

15. Review update history

Every applied batch lands in its module's history — your audit trail of what changed, when, and from which file.

16. Roll back a price update

Applied the wrong price file? Roll back the batch from price history. A rollback is a forward operation: it creates a new history entry that restores the price roles the batch had changed — the original batch stays in history, nothing is deleted, and the audit trail shows both the mistake and the correction. Rebuild affected catalogs afterward so resellers see the corrected numbers.

17. Roll back an inventory update

Inventory history supports the same batch-level rollback: select the batch, roll it back, and a new history entry restores the quantities that batch had set. Before relying on it, read the caveat in section 19 — inventory's update behavior makes rollback scope narrower than it might first appear.

18. Roll back a discontinued-item update

Discontinued batches roll back the same way — the flags and dates the batch set are reversed by a new history entry. Individual products can also be cleared one at a time from the discontinued view, which is often simpler when only one SKU was flagged in error. Rebuild affected catalogs after a discontinued rollback so hidden products reappear where rules allow.

19. Understand the inventory rollback caveat

20. Configured FTP update workflows

Where configured, update files can arrive by FTP instead of manual upload: a scheduled ingestion process must be configured for the account, and files may be routed to the right update module by the configured update-file naming convention. The same validation and history apply to ingested files. FTP is a configured workflow, not a default behavior — accounts don't watch an FTP folder continuously out of the box. For choosing between manual, FTP, and other delivery paths, see CSV vs JSON vs API vs FTP.

21. Common update-file mistakes

22. Product-update checklist

Common questions