WooCommerce refund did not restock inventory: what I check

Customer gets their money back. The order shows Refunded. Stock on that SKU, though, still looks sold out. Packing desks keep marking items unavailable, and the next buyer hits "out of stock" on something you know is on the shelf again.

I treat a missing restock as a settings and line-item problem first, not a theme bug. Below is the order I work through before I start rebuilding inventory by hand on a live catalogue.

Confirm the refund actually tickled Restock

Open the order. In the refund panel Woo shows a Restock refunded items checkbox (wording varies slightly by version). If that was left unticked, money moved and stock stayed as sold. Partial refunds are the usual miss: someone refunds a line for goodwill and forgets restock, or refunds shipping only and assumes the product came back.

I check the order notes timeline too. A clean restock usually leaves a note about quantity returning. No note often means the checkbox never ran, or a plugin short-circuited the stock hook.

Managed stock and the parent product

Under the product (or variation), confirm Manage stock? is on and that you are looking at the same SKU the order used. For simple products that is one stock field. For variable products the parent can look fine while the variation the customer bought still sits at zero.

I also check whether stock was reduced by a warehouse sync or CSV import after the refund. Restock can succeed, then an overnight feed overwrites quantity from an external system that never saw the return.

Partial refunds and mixed carts

Refunding one of three lines should only restock that line. If the wrong line was selected, stock moves on the wrong SKU and the returned item stays depleted. Bundles, composite products, and "sold individually" flags complicate this further.

I compare the refunded line item IDs against the product editor stock fields. If they do not match what the warehouse returned, fix the correct SKU first, then decide whether a manual stock adjust is safer than another refund attempt.

Order status vs inventory hooks

Some stores restock only when status hits Refunded or Cancelled. A custom status, a fulfilment plugin that parks orders on "Returned", or a gateway that marks refunded in Stripe while Woo stays Processing, can skip the stock restore hook entirely.

I confirm the Woo order status, the payment gateway refund state, and whether Action Scheduler shows failed or pending stock-related actions under WooCommerce → Status → Scheduled Actions.

Plugins that rewrite inventory

Multi-location inventory, warehouse apps, barcode scanners, and ERP syncs often own stock after the first sale. Core Woo restock updates the local quantity, then the connector pushes the old figure back from the warehouse that still shows the item as shipped.

On staging I temporarily disable inventory sync plugins, issue a test refund with Restock ticked, and watch the quantity. If core Woo restocks cleanly and production does not, the connector or location mapping is the fix, not another manual edit on the parent product.

Cache, lookups, and front-end "still out of stock"

Admin stock can look correct while the product page still says out of stock because of full-page cache, a CDN edge, or stale product lookup tables. After a confirmed restock I purge the product URL, run Regenerate the product lookup tables under WooCommerce → Status → Tools if the catalogue still lies, and re-check in a private window.

When to stop guessing

If Restock was ticked, managed stock is on the right variation, scheduled actions are clean, sync plugins are ruled out, and the storefront still disagrees with admin, stop shotgun-editing live quantities. At that point you want a staging clone, the refund payload, and someone who has traced inventory hooks and warehouse connectors before.

Most "refund did not restock" tickets come down to an unticked Restock box, the wrong variation, a partial refund on the wrong line, a custom status skipping hooks, or a warehouse plugin overwriting the return. Check the order notes and managed stock first, then sync and cache. Cheers, and get that inventory back on the shelf.