Connecting a shop POS to ecommerce requires agreement about who owns product data, how stock changes reach the other channel and what happens while updates are delayed. Compare integrated-suite and connector approaches before choosing a system. A shared product name does not prove a shared stock position, and a payment integration does not automatically provide complete catalogue or order synchronisation.
WooCommerce Square documents a connector between two platforms. ERPNext documents an inventory ledger within a business system, which provides a useful contrast for assessing the stock record. These examples support an architecture comparison, not a claim that Square merchant services are available to a Zambia-based shop. Verify payment eligibility separately. WooCommerce Square sync settings, ERPNext Stock Ledger.
Should you connect existing tools or choose a common system?
A connector may suit a business that already depends on its till or online store. A common business system may reduce the number of separate product records, but the actual ecommerce and POS features still need to be established. Neither architecture eliminates configuration, permissions or reconciliation work.
Compare the change surface. With a connector, product fields, stock movements and order fulfilment cross an integration boundary. With a common system, staff may share underlying records but still use different workflows and permissions. Ask the demonstrator to show the records behind each interface instead of assuming that matching dashboards mean identical data.
Document what you are keeping: product identifiers, existing orders, customer records and the source of opening stock. A proposed migration that starts with empty demonstration data has not yet shown how the current business will operate after the switch.
What does the connector documentation actually promise?
WooCommerce Square asks the operator to choose a source of truth for product data. It also states that the site must support background processing. Stock checks from in-person sales occur on a schedule rather than instantly, and apply to products opted into sync.
Those details matter more than a general “real-time integration” claim. The existence of a scheduled interval creates a period during which another channel may still display an older value. The documentation does not measure that period for your shop or promise that simultaneous selling cannot oversell.
It also warns that later Square checks can replace manually entered WooCommerce quantities. A local stock edit is therefore not necessarily durable. Staff need an agreed editing location and a recovery procedure for mistakes. Official sync behaviour.
How should the architecture options be compared?
| Architecture | Primary evidence example | Useful reason to consider it | Question that remains |
|---|---|---|---|
| POS-to-store connector | WooCommerce Square source-of-truth and sync controls | Preserve an existing platform while linking records | What crosses the boundary, and when? |
| Shared inventory system | ERPNext ledger and source vouchers | Trace several stock operations through one ledger | Which POS/ecommerce modules meet the required workflow? |
| Deliberately separate stock allocation | An editorial operating alternative | Keep channels apart where reliable sync is unavailable | Who moves stock between allocations and checks exceptions? |
The final row is a proposed business approach, not a feature attributed to either product. It needs a written allocation procedure. A separate online allocation can still be wrong if staff sell from it without recording the movement.
Which catalogue details cause avoidable conflicts?
Begin with stable product and variant identifiers. WooCommerce Square requires unique SKUs for imported Square products. That is different from a display title: two variants can share a similar name while requiring separate stock records.
List ownership for title, description, images, category, availability and stock. Do not assign one owner for “the catalogue” if different fields are intentionally maintained in different systems. Check how the chosen connector handles each field and whether later sync replaces a local edit.
The Square documentation describes missing-product hiding only after a complete catalogue read; if that read fails partway, no products are hidden under that feature. This is a product-specific behaviour worth testing, not a universal deletion rule. Keep “temporarily unavailable”, “removed from catalogue” and “sync failed” as distinct investigation outcomes.
An original concurrent-sale test
Use a test product that cannot trigger real fulfilment. Establish its starting stock and the owning system. Then stage a POS sale and an online checkout against the same last available unit, using the authorised testing setup.
Record the order of events rather than asserting they happened simultaneously. Capture when each channel displayed availability, when each sale was accepted, when the stock update was observed and what the customer was told. Do not invent a universal acceptable delay; agree the business’s decision rule before judging the result.
Next, interrupt the integration’s normal update route in a controlled test environment and repeat an ordinary sale. Restore the route and inspect whether the change is applied once, lost or duplicated. This is a proposed acceptance exercise, not a report of measured product behaviour.
Finally, return the item and inspect both systems. A return should not be assumed to restore saleable stock automatically. Record the physical disposition and the resulting inventory event separately from any financial refund.
What should the conflict register retain?
Use these fields for each discrepancy: product/variant identifier, source system, event reference, expected quantity, observed quantity, last successful update evidence, customer impact and resolution owner. Add the action taken and the evidence that the next sync did not overwrite it.
Where invoices can update stock, inspect whether the same goods already have a receipt. ERPNext explicitly warns against combining a stock-updating invoice with a receipt for those goods because that records stock twice. A connector moving documents between systems must respect the same physical event boundary. ERPNext buying guide.
Do not enable every synchronisation option at once simply because it is available. Product data, stock and fulfilment need separate acceptance results. WooCommerce Square’s bidirectional fulfilment option is distinct from its inventory controls; prove the required behaviour for each.
Bring the conflict register to a discussion of Spout’s web development service, or start an enquiry with the platforms you currently use.
Include a variant whose display name closely resembles another item. Confirm that the connector matches the stable identifier rather than choosing by title. Retain the mapping result so a later catalogue rename cannot silently redirect stock or order lines to the wrong variant.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.