Selling is only the visible edge of retail. The difficult work is maintaining trustworthy availability, applying channel-specific commercial rules, routing each order and reconciling cash, fees, tax and returns. We build systems that keep those decisions coherent across stores, websites and marketplaces.
Physical stock is not the same as stock available to promise. Reservations, safety buffers, pending picks, damaged units and store transfers must be reflected quickly enough to prevent overselling while avoiding unnecessary channel-wide buffers.
Style-colour-size variants, bundles, regional assortments and vendor packs create relationships that a flat SKU list cannot express. Promotions add precedence, eligibility, stacking and rounding rules that must agree at checkout, refund and financial posting.
An order may be split between a warehouse, a shop and a supplier according to stock, cut-off time, delivery promise and fulfilment cost. Substitutions, short picks and cancellations require the route to be recalculated without losing customer communication or payment state.
A return can be resalable, refurbishable, vendor-returnable or a write-off, and its refund may differ from today’s price. Fraud controls, original tender, tax reversal and inventory disposition must stay linked even when the item is returned through another channel.
Marketplace remittances combine sales, commissions, advertising, fulfilment fees, withholding and adjustments on different schedules. Matching those statements to orders and refunds is a reconciliation problem, not merely a daily sales journal.
Packaged commerce products are effective at presentation and transaction capture, but often assume a single stock pool, simple fulfilment and one version of price. Retailers encounter trouble when shops also fulfil web orders, ranges differ by channel, bundles consume components, or a promotion must be reconstructed months later for a return.
We separate product content, commercial offers, physical inventory, available-to-promise and order orchestration. Each has a clear authority and history. This allows a channel to present quickly while operational services make durable allocation, routing and refund decisions.
A retail ERP usually coexists with commerce platforms, store POS, marketplace APIs, warehouse systems, payment gateways, tax services, loyalty tools and carrier networks. Webhooks can arrive late or repeatedly, marketplace statuses differ, and rate limits make constant full synchronisation impractical. Integration must therefore be stateful and observable.
We use source identifiers, versioned mappings, idempotent commands and reconciliation jobs. High-frequency availability can travel through events while financial and catalogue data follow controlled batches where appropriate. Operations teams receive queues for unmapped SKUs, rejected orders and settlement differences instead of discovering them in month-end totals.
A sensible first boundary is often catalogue and inventory visibility, followed by order routing for one channel or fulfilment node. Historical orders can remain in their original platform while open orders, gift balances and outstanding returns receive explicit migration treatment. Peak periods are avoided for high-risk cutovers.
Further phases add shops, marketplaces, advanced replenishment, loyalty and automated settlement. Parallel reconciliation compares orders, tenders, stock movements and tax postings at daily control totals and sampled transaction level. Operational playbooks cover queue ownership, manual release and recovery when an external channel is unavailable.
It maintains reservations and available-to-promise by location, channel and fulfilment rule rather than publishing raw on-hand stock. Event updates, safety thresholds and periodic reconciliation address both speed and inevitable integration gaps.
Yes, where the platforms provide suitable APIs, webhooks or export mechanisms. The design defines which system owns products, prices, orders, inventory and refunds, then handles retries, rate limits and exceptions explicitly.
Settlement lines are matched to orders, shipments, refunds and prior adjustments using marketplace references and amount rules. Unmatched or tolerance-breaking lines enter an exception queue before accounting entries are finalised.
They can share a central rule model when channels expose enough pricing control. Where a POS or marketplace cannot represent a rule exactly, the difference is documented and channel-specific behaviour is tested rather than hidden.
Legacy lookup or a limited migration can preserve the original price, tender and tax evidence needed for a return. The chosen approach depends on return windows, data access and the operational cost of keeping the old platform readable.
Share the workflows, records, exceptions and integration boundaries the system needs to support. We will help define the technical scope.