A WooCommerce refund is rarely just a financial reversal. It simultaneously triggers a money movement and a stock movement, and the stock event almost never lands where the physical unit actually sits. When a customer returns an item, the unit's new home depends entirely on how it comes back: over the counter at the store that received it, in a parcel sent to the fulfilment warehouse that originally shipped it, or nowhere at all because the item is damaged or unsellable. Restocks recorded in Square carry a location, and the destination is easy to get wrong when the return is handled by someone who does not know where the unit now sits.

This tutorial breaks down how to align WooCommerce refund restocks with the correct Square location. You will learn why the default restock lands in the wrong place, how to route restocks by return method, and how to make the location adjustment explicit in both systems. We will also walk through a worked example showing how a national pool hides a shortage, review reconciliation checks after restocking, and close with takeaways for the next return season.

A Refund Is Two Events: Money Moves, Stock Does Not Follow

WooCommerce treats a refund as an order adjustment. The line item is marked refunded and the payment is reversed. That sequence is entirely about money, and it completes without anyone deciding where the physical unit went.

Stock handling is a separate switch. WooCommerce can restore the refunded quantity to product stock when the refund is recorded, but that stock field belongs to the product or variation, not to a shelf in a named store. Multi-location inventory in WooCommerce comes from plugins rather than core.

Square tracks inventory per location, so a quantity carries a location identity. A WooCommerce stock number has one only if your integration maps it to a single Square location or maintains a defined breakdown per location.

Both records can be right and still disagree

WooCommerce is correct that the customer was refunded, Square is correct about its own per-location arithmetic, and neither states where the unit is sitting now. Disagreement starts here because orders and shipments deduct from a known location, while returns credit with no obvious destination. The money side needs the same single-reversal discipline as loyalty points on refunds, and the stock side still needs a destination.

Why the Default Restock Usually Lands in the Wrong Place

Once the money side completes, the stock side falls back to whatever the system or the operator assumes. That assumption holds for a posted return to the shipping location and fails when a customer hands the item to a different store.

When availability is read from a combined figure, a credit applied anywhere raises the headline count, so the total looks healthy while the shelf that lost the unit remains short.

A credit posted to the wrong location may trigger no alert and fail no transaction; the totals just stop matching what staff can count. See how live per-location availability keeps pickup promises honest.

At volume this compounds. NRF expected nearly $850 billion in 2025 returns, so one misplaced unit is repeated many times, not corrected once.

An unassigned return stays wrong until someone reconciles it. It carries forward through month-end and the next allocation cycle, then appears as an oversell or stock count variance later. That is why the restock destination must be decided by route, not by default.

Decide the Restock Destination by Return Route

Once the refund is in front of you, stop treating restock as a default. The return route, not the customer's preference or the integration default, decides the destination: returned in store, posted back to a fulfilment store, or written off as unsellable. Ask one question at processing: is the unit physically in a named store, in transit to a fulfilment location, or gone from sellable inventory?

Record that answer on the refund record itself. Reconstructing route later from carrier tracking or staff memory is guesswork, and it fails at the volume where accuracy matters. Route assignment belongs to whoever physically touches the unit: counter staff or the receiving team sets the destination, while the ecommerce operator applies it. If connector behaviour is changing at the same time, use a clean connector cutover sequence.

Record that route on the refund record; the three routes below show what each destination requires.

In-Store Return: The Location Holding the Unit Owns the Restock

For the in-store route, an aggregate national pool is the wrong destination. The receiving store, the one the customer walked into, owns the restock, even when a different store or warehouse fulfilled the original order. Those locations are frequently different, and defaulting to the original allocation pushes the unit to a shelf that never received it.

Leave the original order's allocation record untouched. The return should create a new positive adjustment at the receiving location so the audit trail shows both what shipped and what came back.

Inspect before you restock: damaged, incomplete or out-of-season units take the write-off route, not the shelf. If the receiving store does not normally carry the SKU, restock it there anyway so the shelf count is honest, then handle any transfer as a separate movement. Safety stock rules per location become easier to set once this count is accurate.

Capture the adjustment at the point of receipt. A later batch leaves shelf figures wrong for the whole window between return and batch, which is exactly when the next online order gets misallocated.

Posted Back: The Fulfilment Store That Shipped It Owns the Restock

Posted returns invert the in-store rule: the unit is not on a shelf yet, so the destination is the fulfilment location that allocated the original line item. Read that allocation from the original order record, not a default warehouse, especially when peak orders split across locations. Restock only after the parcel is received and inspected. A scanned return label or carrier delivery scan does not make a unit sellable, and an in-transit quantity must not inflate availability.

If the customer posts the item to a store that did not ship it, treat it as an in-store return at that location. The same per-unit discipline then carries into split shipments and kit lines. For split shipments, default to the location recorded on the specific line item. If that record is missing, choose a splitting rule and document it, because you will apply it repeatedly. For kit or bundle lines, confirm component stock mappings before restocking. Batch receiving by delivery is practical, but adjust each unit at inspection and batch only the paperwork, timestamping the adjustment to the intake so any later variance traces to a specific point.

Written Off: Neither Location Gets the Unit

The remaining route is the write-off, and it reverses the logic of the previous two: if the unit is not returning to sellable condition, no location receives a positive adjustment. The refund still completes on the money side, while the stock side records a loss rather than a return. Keep those records separate. A refund that also restocks a damaged item buries the loss inside a healthy inventory figure, so margin reporting never shows it. Under IAS 2, inventory write-downs to net realisable value are recognised as an expense, which supports treating the unit as a cost rather than a return (IAS 2 inventories).

Location handling depends on whether the unit was ever deducted. If it was never removed from a location, there is nothing to remove. If it was deducted, apply the removal to the location that last held it, so the shelf count matches reality. Set the threshold before you need it: define the conditions that trigger a write-off, the value requiring sign-off, and who can authorise it at store level. Finally, keep write-offs on their own exception list. Mixing them with normal restocks inflates return rates at innocent locations and corrupts the routing data used for planning.

Make the Location Adjustment Explicit in Both Systems

Write-offs close the loop for units that never return to sellable stock. For units that do, the adjustment has to land in the right system, at the right location, and be recorded so you can reconcile it later. On the WooCommerce side, treat stock as independent of the refund event. If product-level restock on refund is enabled alongside a location-specific adjustment, the same unit can be credited in two places. Pick one path and disable the other.

On the Square side, apply the adjustment to the specific location and attach a reason. That reason field turns an anonymous quantity change into a record you can reconcile against refunds by date. Then follow a fixed order: receive the unit, inspect it, apply the adjustment at the destination location, and confirm that online availability recalculates from the breakdown rather than the aggregate pool.

Document the mapping in one place: which WooCommerce product corresponds to which Square item, and which Square location or locations back each availability figure. Unwritten mappings get re-guessed by every new staff member.

The routing rule stays your decision. SquareSync for Woo syncs products, inventory, orders, customers and loyalty between Square and WooCommerce in real time, which shortens the window in which a refund sits unresolved, but the destination logic is still something you define.

A Worked Example: How a National Pool Hides a Shortage

With location-specific adjustments in place, the failure mode is easier to see. Consider an illustrative, unnamed merchant: Store A, a high-street shop, and Store B, a fulfilment warehouse. WooCommerce reports 12 units of one SKU, split 4 at A and 8 at B. An online order for 1 unit ships from B, so B drops to 7 and the combined figure reads 11. Every record matches the shelves.

The customer returns that unit in person at Store A. The refund is processed and stock restores to the aggregate pool, so WooCommerce reads 12 again. Store A’s shelf count never gains the unit, and the credit lands wherever the integration defaults. The result is two wrong numbers wearing a right total: A understates by 1 because an unrecorded unit sits on its shelf, and B overstates by 1 because it is still allocated orders for a unit it never received.

The failure compounds. When Store A sells that unit in person, its record goes negative or blocks the sale, and the combined pool has promised the same unit twice. A misplaced return has become a shortage the national total concealed. Routed correctly, the same scenario produces one positive adjustment at Store A, a combined figure of 12, and two locations that match their shelves. See our guide to WooCommerce inventory management for the wider control problem.

Reconciliation Checks After the Restock

The worked example corrects a single return; in practice, returns arrive in batches, and each refund can look correct in isolation while two locations remain wrong. Verify per destination, not in total.

Count at the destination. Spot-check the locations that received the most returns in the period. Concentrate the sample there, since those are the locations where a misrouted credit would show up.

Compare residuals, not totals. Line each Square location quantity up against the WooCommerce breakdown mapping for that location. Record the per-location variance and leave the aggregate out of it.

Run the exception report. Filter refunds by date and pull any with no matching location adjustment. This needs no new tooling, and it surfaces the units sitting unassigned in the pool.

Tighten over a season. Route recorded at refund, destination adjustment timestamped, write-offs on their own list. After a full season, the exception rate shows whether the routing rule is followed or merely documented.

Set tolerances in advance. Decide how far a location count can drift before it triggers an investigation, so the check stays routine rather than a fresh judgement call each cycle.

Takeaways for the Next Return Season

Reconciliation shows you what drifted; prevention sits upstream. Lock five habits into the refund workflow before the next peak.

Route before you restock. At refund time, record whether the unit sits in a named store, is in transit to a fulfilment location, or is unsellable.

Credit the holding location. In-store returns restock the receiving store, posted returns restock the shipping location, and write-offs restock nothing.

Disable product-level restock on refund if you maintain a per-location breakdown, or the same unit gets counted twice.

Adjust against a specific Square location ID with a reason attached, timestamped at inspection. If a line item shipped from multiple sites, follow the location on that line item; see how order splitting works.

Run the exception report monthly. Refunds without a matching location adjustment are your misrouted units; fixing them early keeps the aggregate pool from hiding a shelf shortage.

Conclusion

A WooCommerce refund moves money; it does not move stock.

Your next step is simple: run that exception report on this month's refunds and see how many units lack a recorded destination.