Define the inventory quantity before choosing a connector

Distinguish physical stock, committed stock, unavailable stock and sellable stock. Shopify explains these concepts in its inventory states documentation. An expected delivery is not available inventory.

Then write down your own definition of the availability sent to the store: which reservations are deducted, which units are blocked, and which warehouses supply each location? Similar labels in the ERP may represent different calculations. Matching two fields called “stock” does not prove that the systems agree.

An SKU helps with matching, but check its uniqueness and keep a stable mapping between the variant, ERP item and location. Batches and bundles need additional rules; do not silently include them in an initial scope.

An ownership matrix to complete with your team

This matrix is a starting point for a business whose ERP manages its warehouse. Adapt it if Shopify, a fulfillment provider or another system handles that function.

Flow Suggested owner Rule to define Required evidence
Receipts and physical adjustments ERP → Shopify Publish sellable quantities by variant and location, accounting for the relevant reservations An adjustment explained in both systems
New online order Shopify → ERP Choose the trigger and distinguish creation, payment and reservation One ERP order linked to the Shopify order ID
Reservation awaiting transfer Integration between the systems Preserve the reservation until the ERP confirms it has been recorded No stock released for sale while waiting
Picking and shipment ERP or fulfillment provider → Shopify Identify shipped lines and quantities, including partial shipments Only the lines actually shipped change status
Cancellation before shipment Authorized system → other system Check picking status and release the reservation once Quantities and statuses reconciled after cancellation
Return and refund Support, warehouse and payment system, each within its role Separate the financial decision, physical receipt and release for resale A refund alone does not increase sellable stock

For each row, add a person responsible and an acceptable maximum delay. A newly created order may be unpaid; a paid order may need review. Define what authorizes picking and what reserves inventory, without assuming these happen at the same time.

Fictional scenario: stock rises during a sale

This is an imagined testing scenario, unrelated to any client or Codezilla project. A single location holds ten units: two blocked for inspection and three already reserved. Initial availability is therefore five units. Shopify and the ERP agree.

Shopify then records a sale of two units. Its availability falls to three, but the order is still waiting to reach the ERP. If a sync writes the ERP's previous availability of five in the meantime, two units already sold may be offered for sale again.

The test is to deliberately pause order transfer in a test environment, then trigger an inventory update. Expected availability is three. Once the ERP confirms the reservation, it must remain three: the same two units must not be deducted a second time.

Ask how the connector handles reservations not yet recorded in the ERP and outdated inventory snapshots. One approach can reconcile pending orders against a dated or versioned ERP snapshot; it must fit the systems' actual capabilities. Increasing sync frequency alone does not demonstrate control over concurrent writes. With multiple sales channels, a safety buffer may reduce exposure without guaranteeing that overselling cannot occur.

Handle returns without confusing money and goods

Shopify lets you refund an order with a restocking choice. The integration must distinguish this operation from actually receiving and inspecting the product.

Plan three separate cases: a refund without a return, a returned item that cannot be resold, and an inspected return ready for resale. Decide which system approves restocking and how the other receives that decision. If both sides add the same unit, the flow remains wrong even when every execution succeeds.

Choose a connector using acceptance evidence

Start by examining your ERP's existing connector. It is sufficient if its rules cover your variants, locations, reservations and returns, with accessible error records and controlled recovery. A focused integration becomes relevant when a necessary rule is missing and the interfaces allow it to be implemented. Adding n8n does not create data or operations absent from the ERP.

Request a demonstration of these cases, including identifiers, before-and-after states and timestamps:

  • an order transferred and then received again, without a duplicate or a second reservation;
  • a sale followed by an outdated inventory snapshot, as in the scenario above;
  • a partial shipment followed by cancellation of the remaining items;
  • a refund without a return, followed by an unsellable return;
  • an outage followed by recovery limited to missing orders.

Shopify webhooks do not guarantee delivery order or receipt of every event. Supplement notifications with periodic reconciliation of orders and quantities. Define who investigates a discrepancy and who may authorize a correction.

The useful deliverable is a flow map, a definition of availability and accepted tests, together with a recovery procedure. A pilot can start within a limited scope once those rules are approved. Price synchronization or invoicing can be scoped separately.

For general recovery controls, read how to sync two tools with n8n without duplicates. To define the exchanges your store needs, explore our automation and software integration support or tell us about your project.