Why your store's prices and stock are wrong by Friday (and how to keep them in sync)

If you run a store that sells someone else's products, there is a number you have never measured and are paying every month anyway: the gap between what your supplier is charging right now and what your store still believes.

It is not a dramatic gap. It is a dollar here on a product whose cost went up, a variant that sold out on Tuesday and stayed "in stock" on your site until Friday, a markup that was right in March and quietly stopped being right in June. None of it shows up as a line on a report. All of it shows up as refunds, apology emails and margin you did not know you lost.

This piece is about where that drift comes from, what it actually costs, and the only approach that fixes it for good.

Where the drift comes from

Every product in your store is a snapshot. The day you added it, the supplier's price was X, the stock was Y, and the variants were whatever they were that morning. From that moment, three things start moving.

The supplier's price moves. Suppliers reprice constantly: currency swings, their own costs, promotions that end. A product you imported at $8.40 is $9.10 a month later. If your store still says $19.99 because you set it from an $8.40 cost, your margin just shrank and nobody told you.

Stock moves faster than price. A supplier variant sells out, comes back, sells out again. Each time it is out, your store is still taking orders for it. That is the oversell: a customer pays, you go to place the supplier order, and it is not there. Now you are choosing between a refund and a substitute the customer did not ask for.

The catalog itself changes. Variants get renamed, retired, or split. A colour that existed as one option becomes three. A product disappears entirely. Your store keeps the old shape until someone notices.

The common thread is that none of this is your mistake. The data was correct when you entered it. It stopped being correct because the world moved and your store did not.

What it costs

People usually think about this in terms of the oversell, because that is the painful one: a paid order you cannot fulfil. But the oversell is the rare, visible case. The common, invisible case is margin.

Take a store with 400 products, each marked up from supplier cost. If supplier prices drift upward by even 3% over a quarter, and nobody re-prices, that is 3% of cost quietly transferred from your margin to your supplier's, on every sale, without a single thing looking wrong. On a store doing $20,000 a month that is hundreds of dollars a month you would have kept by changing numbers you never saw change.

Then there is the time. The manual fix is to check. Open the supplier, open your store, compare, update. For ten products that is an evening. For four hundred it is a job, and nobody does it, which is why the drift compounds.

The approaches that do not work

Checking by hand works for a week. It stops the first time something more urgent comes up, and the drift resumes.

Spreadsheets are a way of writing down what you checked. They do not check anything. The spreadsheet is stale the moment you close it.

Pricing higher to leave room is what most stores quietly do. You take a bigger markup than you need so that a cost increase does not wipe you out. That protects margin on the products whose cost goes up and overprices the ones whose cost does not. You lose sales to be safe.

Buying a tool that alerts you moves the work from "checking" to "reading alerts and then checking". It is better, but it is still you doing the update, which means it still stops when you are busy.

The approach that works

The only thing that keeps a store current is a loop that runs whether or not you remember to run it: re-read the supplier, apply your pricing rules, update the store, repeat on a schedule.

Each part matters.

Re-read, do not remember. The source of truth for a supplier's price and stock is the supplier, today. Anything stored on your side is a guess about what the supplier said last time. A loop that re-reads the actual product each time cannot drift, because there is nothing to drift from.

Rules, not numbers. If your price is a number you typed, every cost change needs a new number. If your price is a rule — "cost plus 40%, round to .99, never below $12" — a cost change produces the right price on its own. You set the rule once; the loop applies it every time. The same rule handles the product whose cost rose and the one whose cost fell, correctly, with no attention from you.

Update in place. The loop must recognise that the product it just read is the same product already in your store, and update that listing. A loop that creates a new listing every time gives you duplicates, which is a different mess. Matching on a stable identity from the supplier (their SKU, their product id) is what makes a re-read an update rather than an addition.

Decide what "gone" means. When a supplier product disappears, you want a choice: hide it in the store, mark it out of stock, or leave it alone and tell you. "Delete it" is almost never the right default, because orders already placed still point at it.

Run it on a clock. Daily is enough for most stores. Every few hours if your suppliers reprice often or your stock turns fast. The point is not the interval; the point is that it runs without you.

What this looks like in practice

Here is the shape of a store that has stopped drifting:

1. Every product in the store came in from a supplier link, so the connection between the listing and its source is known.
2. A pricing rule exists once, not per product: markup, rounding, a floor, maybe a compare-at price.
3. A schedule re-reads every supplier product on an interval and applies the rule.
4. The store receives price and stock updates on the listings it already has. New variants appear; retired ones are hidden, not deleted.
5. After each run, a short report says what changed: which prices moved, which products went out of stock, which came back.

That last item is the one people underrate. Once the loop is running, you stop checking for drift and start reading a change log. "Twelve prices rose this week, three products went out of stock" is a sentence you can act on in thirty seconds. "Is my store correct?" is a question that used to take an evening to answer and now does not need asking.

Doing this with ScrapeOra

This is the loop ScrapeOra runs. You paste a supplier product or catalog link; the products land in your library with their variants, price and stock. You set a pricing rule once in Pricing. You attach a schedule, and on every run ScrapeOra re-reads the supplier, applies the rule, and updates the listings in your Shopify, WooCommerce or BigCommerce store, matching each product by its stable supplier identity so nothing duplicates. Products that disappear are hidden rather than deleted. The Changes page shows exactly what moved after each run.

For suppliers with an official API, such as CJdropshipping, Printful and Printify, it reads through the API. For a supplier's own store, it reads the product pages you gave it. Either way the data is the supplier's current data, not a snapshot you typed in once.

The free plan runs this daily for a small library, which is enough to see it work before you decide anything.

The short version

Your store is a snapshot of your suppliers taken on the day you added each product, and it has been going stale ever since. Checking by hand stops the first busy week. The fix is a loop: re-read the supplier, apply a rule instead of a number, update the listing you already have, on a schedule that does not depend on you. Once it runs, drift stops being something you hunt for and becomes something you read about.