Quick answer
Growth above £20m usually fails in the back office, not the storefront. For fashion brands scaling to £200m the right stack separates experience from finance: Shopify owns the customer-facing transaction, the ERP owns the financial record and SKU master, and the WMS owns physical stock. An orchestration layer enforces ownership, prioritises high-velocity SKUs for rapid stock updates, and routes fulfilment events so finance never loses the audit trail. Get that boundary right and you cut reconciliation debt, reduce oversells during drops, and avoid long-term agency captivity.
Introduction
Operational pressure usually becomes visible when finance and operations start spending more time fixing data than launching product. For fashion brands this happens early. High SKU counts, seasonal drops, and return rates north of 25% create repeated mismatch between Shopify, your warehouse, and the ledger. The cost of getting it wrong is real: missed revenue during launches, extra headcount for manual reconciliation, and lost customer trust from oversells or late refunds.
This playbook is written for Ecommerce Directors, Ops leads, CFOs and CTOs who are outgrowing an app-heavy Shopify stack and need a practical, operator-focused blueprint to move from 'connected' to 'governed'. It focuses on the infrastucture and operational plays that stop architecture pressure from becoming business-critical failure.
Executive summary
- Scope: Fashion brands scaling from £20m to £200m, high SKU churn and high return rates.
- Architectural hinge: Make the ERP + WMS the financial and inventory owners; let Shopify be the experience layer that subscribes to authoritative data.
- Source-of-truth verdict: SKU/Item master and sales facts belong in the ERP; physical inventory belongs in the WMS; Shopify subscribes to both.
- Biggest operational risk: Sync illusion and ownership leakage where apps or ad-hoc scripts silently take control of inventory or returns rules.
- Single project decision that determines success: Define and enforce ownership boundaries before any integration work starts.
Operating principles
Each principle below explains why it matters and the anti-pattern to avoid.
| Principle | Why it matters | Anti-pattern to avoid |
|---|---|---|
| Explicit Source of Truth | Prevents operational drift where product or price edits create divergent records across Shopify, ERP and PIM. | Allowing bi-directional edits on SKU fields in Shopify, ERP and PIM simultaneously. |
| Asynchronous Order Flow | Protects warehouse capacity and finance from premature consumption of inventory for unverified orders. | Posting every basket to the ERP immediately on checkout without fraud or payment validation. |
| Inventory Latency Prioritisation | Reduces oversells during drops by prioritising high-velocity SKUs for near-term updates while allowing lower-velocity SKUs to update less often. | Assuming a single uniform sync frequency is sufficient for all SKUs during peak trading. |
| Logistics Abstraction | Supports carrier changes, multi-node fulfilment and 3PL swaps without front-end rework. | Connecting each 3PL directly to Shopify so fulfilment status is fragmented across systems. |
| Governed Exception Handling | Automates common exceptions such as part-refunds, exchanges and returns grading so finance can reconcile faster. | Relying on manual processes and spreadsheets to fix exceptions that occur during peak. |
Stack composition
The table below describes each layer, its role, candidate systems and when to pick them for fashion operations.
| Layer | Role | Candidate systems | When to pick what |
|---|---|---|---|
| Commerce & Experience | Front-end transactions, customer accounts, promotions and checkout customisation. | Shopify Plus | Choose Shopify Plus when conversion, rapid launches and checkout flexibility are priorities. |
| Business Logic (ERP) | Financial ledger, item master, procurement, multi-entity reporting. | NetSuite, Brightpearl, Microsoft Business Central | Choose an ERP when manual finance work or multi-entity VAT prevents timely close. |
| Fulfilment (WMS) | Physical stock movement, returns grading, pick/pack and putaway logic. | Peoplevox, SnapFulfil, 3PL proprietary systems | Choose a specialist WMS when returns exceed about 25% or when pick speed matters for margin. |
| Orchestration | Transforming, queuing and routing events between Shopify, ERP and WMS; observability and retry policies. | Integration layer / iPaaS or managed orchestration | Pick orchestration once you have more than two systems that must exchange transactional data reliably. |
| PIM / Catalogue | Product content enrichment and channel-specific presentation. | Akeneo, Pimcore or ERP-tied PIM | Use PIM when product variations, imagery and channel-specific content exceed what Shopify can comfortably manage. |
Source-of-truth ownership map
The owner system must be documented and enforced. Below are the recommended ownership assignments for fashion stacks.
| Data object | Owner system | Downstream consumers | Notes |
|---|---|---|---|
| SKU / Item master | ERP (or PIM coordinated with ERP) | Shopify, WMS, Marketplaces, BI | SKU code and cost must be authored in ERP. PIM can hold descriptions and imagery but not the financial SKU key. |
| Inventory availability (physical) | WMS | Shopify (subscriber), ERP | Shopify should never be the authoritative system for stock counts; it subscribes to WMS updates via middleware. |
| Sales order record (financial) | ERP | Finance reports, BI, Customer service | ERP holds the sales fact once an order is accepted and the sale is recognised for VAT and audit purposes. |
| Customer profile and lifetime value | CRM or ERP depending on use case | Shopify, Marketing platforms, BI | Shopify holds session-level data but CRM/ERP should hold canonical customer IDs and LTV metrics for finance and loyalty reconciliation. |
| Returns and credit notes | ERP | WMS, Shopify, Finance | Ensure returns grading events at the WMS generate Credit Memo creation in the ERP; refunds in Shopify must not create permanent ledger divergence. |
| Payouts, gateway fees, merchant fees | ERP | Finance, Bank reconciliation | Map Shopify payouts and PSP fees to ERP ledger entries; reconcile to bank statements with automated matching where possible. |
Data flows and integration responsibilities
Each flow below must have an interface owner and a clear contract. The table lists common flows for fashion operations.
| Flow | From → To | Trigger | Cadence | Failure mode |
|---|---|---|---|---|
| Sales Order creation | Shopify → ERP | Payment captured and fraud cleared | Webhook or near real-time queue | Webhook failure or rate limit causing orders to queue and delay fulfilment. |
| Inventory availability update | WMS/ERP → Shopify | Pick/pack, goods-in, cycle count | Priority SKUs: high-frequency (minutes); others: scheduled batch | Overselling when priority updates are delayed due to API limits or queue back-pressure. |
| Fulfilment status & tracking | WMS/3PL → Shopify | Parcel created / tracking assigned | Event-driven | Missing tracking updates result in customer chargebacks or CS escalation. |
| Returns grading & credit note | WMS → ERP → Shopify | Item received and graded | Event-driven | Refund issued in Shopify but the ERP ledger never receives a credit memo. |
| Payout reconciliation | Payment provider / Shopify → ERP | Payout file available | Daily or monthly depending on volume | Settlement drift where payouts, fees and refunds do not align with ERP postings. |
Interface ownership
| Interface | Owned by | Contract notes |
|---|---|---|
| Shopify Order → ERP Sales Order | Integration / Orchestration layer | Must validate payment and fraud state, map taxes and multi-entity fields, and provide retry with idempotency. |
| WMS Fulfilment → Shopify Fulfilment Event | WMS owner / 3PL tech lead | Interface ends when tracking is posted to Shopify; return status events must link to a receipts ID for ERP credit memos. |
| ERP Inventory → Shopify availability | ERP owner with orchestration layer | ERP publishes logical availability; orchestration enforces frequency prioritisation and buffer policies for Shopify. |
Reference architectures
Choose the pattern that matches your operational constraints. Each is explicit about what it fits and where it fails.
| Name | Components | Fits | Breaks |
|---|---|---|---|
| Governed Hub-and-Spoke | Shopify Plus, ERP (hub), WMS, Orchestration | High-volume DTC fashion needing finance-grade reporting and multi-node fulfilment. | Breaks when ultra-dynamic pricing or PIM-first enrichment is required without a tight PIM-ERP contract. |
| PIM-First Content Stack | PIM, Shopify, ERP, WMS | Brands with heavy product enrichment needs and many marketplaces. | Breaks if PIM ownership is not coordinated with ERP SKU keys, creating catalogue fan-out issues. |
| ERP-Native WMS Stack | Shopify, ERP with native WMS module, limited third-party WMS | Lower complexity warehouses with simple returns processes and single-node fulfilment. | Breaks at scale when returns grading or pick optimisation becomes a warehouse competitive edge. |
The operational playbook
Concrete plays your teams should run. Each play is sequenced and has clear owners and success signals.
| Play | When to run | Steps | Owner | Success signal |
|---|---|---|---|---|
| Peak inventory sync stress test | 4 weeks before a major drop or Black Friday |
|
Ecommerce Manager & Warehouse Lead | Zero oversells and queue backlog cleared within SLA window during the test. |
| Returns reconciliation audit | Monthly during ramp, then quarterly |
|
Finance Director & Ops Lead | All sampled returns match Shopify value to ERP credit memo amounts. |
| Monthly reconciliation drill | Every month-end |
|
Finance | Reconciliation exceptions resolved within 3 business days. |
Decision frameworks
Use the matrices below to choose between common architectural options.
How to connect Shopify to ERP
| Option | When it fits | When it fails |
|---|---|---|
| Direct API integration | Low volume, single warehouse, minimal transformations. | High volume, multi-entity VAT, complex tax mapping or many transforms. |
| iPaaS / Orchestration | High volume, multi-region, many endpoints and need for visibility and retries. | Small stores where licence cost outweighs benefit. |
| Native app connector | Fast to implement, works for simple two-system setups. | Breaks when exceptions and custom mapping are required at scale. |
WMS vs ERP-native fulfilment
| Option | Why choose | Trade-offs |
|---|---|---|
| Best-of-breed WMS | Superior returns handling, pick optimisation and speed. | Integration complexity and risk of inventory drift unless orchestration enforces contracts. |
| ERP-native WMS | Tighter financial integration and fewer moving parts. | Often lacks advanced returns grading and pick optimisation used by fashion brands. |
Scorecards
Use these readiness checks before committing to an architecture change.
| Dimension | Ready looks like | Not ready looks like |
|---|---|---|
| Source of truth clarity | Documented owners for SKU, inventory, orders and returns; enforced at integration layer. | Staff edit inventory in Shopify and ERP with no clear audit trail. |
| Integration observability | All interfaces expose queues, retry metrics and failure alerts. | Errors are only visible when customers complain or finance raises an exception. |
| Returns handling | Returns grading in WMS triggers ERP credit memos automatically. | Refunds created manually in Shopify and adjusted later in the ledger. |
What good looks like
- Finance can reconcile a week of trading in under an hour with automated matching for payouts and fees.
- Inventory on Shopify reflects warehouse availability for priority SKUs within minutes during peak drops.
- Product launches do not require manual uploads across systems; the SKU is mastered once and fans out.
- Adding a new fulfilment node or a marketplace does not require a wholesale rework of catalogue or order flows.
What breaks at scale
| Symptom | Cause | Impact | Prevention |
|---|---|---|---|
| Oversells during a drop | Inventory updates delayed by API rate limits or queue back-pressure | Customer cancellations, brand damage, lost revenue | Prioritise high-velocity SKUs in orchestration and implement buffer policies in Shopify. |
| Reconciliation debt at month-end | Returns and refunds not mapped to ERP credit memos | Finance spends days reconciling payouts; delayed close | Map return receipt events to automatic credit memo creation and reconcile payouts to ledger daily. |
| Operational latency | Direct app integrations without retries or dashboards | Orders stall, fulfilment is delayed and CS load increases | Introduce an orchestration layer with visibility and retry policies. |
Commercial trade-offs
| Decision | Cheap path | Premium path | Cogent2 view |
|---|---|---|---|
| Integration architecture | Direct app-based connectors from Shopify App Store | Managed iPaaS or orchestration with monitoring and retries | App connectors are quick but brittle; invest in orchestration when volume or complexity increases. |
| WMS selection | ERP-native WMS module | Best-of-breed WMS integrated via orchestrator | Choose best-of-breed when returns and pick speed materially impact margin. |
Ecosystem recommendations
| System | Role | When to use | When not to |
|---|---|---|---|
| Shopify Plus | Commerce and experience | High-growth DTC fashion where speed to market matters | Not ideal for complex B2B pricing matrices. |
| NetSuite / Brightpearl / Microsoft Business Central | ERP - financials and SKU master | When finance needs audit-ready ledgers and multi-entity VAT | Smaller teams with limited ERP capability may prefer simpler systems. |
| Specialist WMS | Fulfilment and returns grading | When returns exceed 25% or in-house fulfilment is strategic | If warehousing is entirely outsourced to a 3PL that provides full tech integration. |
Scaling warnings
- £20m: Manual reconciliation for returns becomes a full-time burden. Consider automating returns-to-ledger flows.
- £50m: Multi-node fulfilment requires routing logic that usually needs orchestration beyond Shopify Scripts.
- Peak trading: 10x order spikes expose API rate limits and queue back-pressure. Run a peak stress test before each major event.
Common failure patterns
| Pattern | Why | Cogent2 view |
|---|---|---|
| Reconciliation debt | Returns and gateway fees are not mapped to ERP credit memos and ledger entries | Finance becomes reactive and loses trust in ecomm numbers; invest in return event mapping and payout matching. |
| Source-of-truth ambiguity | Multiple systems accept edits to the same fields | Define ownership boundaries and enforce them in the orchestration layer to avoid phantom inventory. |
| Sync illusion | Dashboards show success but queues are delayed under load | Expose queue depth and retry rates; prioritise at-risk SKUs for near real-time updates. |
Cogent2 view: Integration is a governance problem, not only a technical one. If finance cannot reconcile payouts without spreadsheets, the architecture has failed.
Cogent2 view: App-accrual is the silent tax on growth. Shopify apps can own pricing, returns rules or stock buffers without anyone noticing; that ownership leakage becomes expensive quickly.
Cogent2 view: You should design for exception handling first. Happy-path order flows are easy; what breaks during returns, exchanges and partial refunds determines whether the stack will scale.
The Cogent2 verdict
For fashion brands scaling to £200m the pragmatic path is clear. Let Shopify lead the experience and the ERP lead finance and SKU mastery. Use a WMS to manage the physical reality of stock and an orchestration layer to enforce contracts, queueing and prioritisation. This architecture reduces reconciliation debt, limits agency captivity and keeps the brand in control of its catalogue and margins.
Needs business confirmation
The following items require confirmation from the business or platform owners before they can be published as facts. Needs business input before publishing.
- Confirm common VAT treatments for UK fashion brands selling into the EU via Shopify Markets.
- Confirm Shopify Plus GraphQL and REST rate limits for high-concurrency inventory updates in your specific Shopify plan and region.
Frequently asked questions
How quickly should orders post from Shopify to the ERP?
Orders should post after payment capture and fraud validation. Exact timing depends on the operating model; many teams use webhook-driven posting with an orchestration queue to ensure idempotency and retries.
Can Shopify be the source of truth for inventory?
No. Shopify should be a subscriber to warehouse availability. Physical counts must come from the WMS and logical availability managed in the ERP.
Do I need a PIM?
If product attributes, imagery and channel-specific content are complex and used across marketplaces, a PIM reduces catalogue inconsistencies. Ensure SKU keys remain mastered in the ERP.
When should we introduce an orchestration layer?
Introduce orchestration when you have more than two transactional systems or when you need visibility, retries and priority routing for inventory updates.
How do we prevent oversells during a product drop?
Prioritise high-velocity SKUs for rapid inventory sync, implement Shopify buffers for low counts, and run stress tests in the orchestration layer ahead of the drop.
What is reconciliation debt and why does it matter?
Reconciliation debt is the backlog of unexplained variance between Shopify figures and ERP ledger entries. It creates headcount cost and delays month-end close.
Should I connect my 3PL directly to Shopify?
Avoid direct-to-Shopify 3PL connections for high-volume operations. Route fulfilment events via the WMS and orchestration layer so the ERP retains the sales fact and the ledger remains auditable.
How do we manage returns that are partially accepted?
Ensure WMS grading events map to ERP credit memos and that the orchestration layer allows partial credit memo creation linked to the original sales order and inventory unit.
Final CTA
If reconciliation debt, oversells during drops, or protracted month-end closes are costing margin, book a Stack Architecture Audit. We will map your current ownership boundaries, surface operational drift, and produce a prioritised plan to move to a governed stack that scales with the business.