The core of multi-channel ERP is not aggregation—it is an operating fact layer

Bringing data together is only step one

Channel APIs can download orders into one system, but platforms define cancellation, refund, preorder, bundles, tax and fulfilment differently. Concatenating tables creates a dashboard that looks unified while hiding semantic conflict.

ERP must define the enterprise’s own business objects and state machines while retaining channel-native states. The common layer supports operations; the source layer supports reconciliation and traceability. Neither replaces the other.

Govern products before unifying inventory

The same physical product may use different SKUs, titles, bundles and units across channels. The product master connects product families, sellable SKUs, inventory SKUs and channel listings with rules for kits, bundles and substitutes.

Available-to-promise is not warehouse on-hand. It also reflects reservations, inbound stock, quality holds, channel buffers, fulfilment time and oversell policy. Each inventory publication should record source, calculation version and target channel.

• Product mapping: family, sellable SKU, stock SKU and listing
• Stock state: on-hand, reserved, inbound, quality hold and unsellable
• Publishing policy: buffers, channel priority and frequency
• Exception policy: mapping failure, negative stock, rate limit and manual lock

Treat order synchronisation as a distributed system

Channel notifications can be delayed, duplicated, out of order or missing, while APIs impose rate and history limits. Synchronisation needs idempotency, cursors, replay, backfill and dead-letter handling—not an assumption that each order arrives once in order.

Bidirectional conflicts matter: a channel cancels after warehouse release, or service changes an address after carrier pickup. Use business time and system-of-record rules to determine authority, and send unresolved conflicts to an exception queue.

Fulfilment orchestration should explain every routing choice

Warehouse choice combines stock, market restrictions, delivery promises, carrier capability, cost, split shipment and tax rules. The rules engine should expose its reasons and allow controlled overrides rather than black-box allocation.

Actual delivery time, cost, refusal and return should flow back into route performance. Without that loop, routing relies on static assumptions and cannot adapt as channels and markets change.

Finance must enter at transaction time

Capture currency, tax, discount and payment at order creation; attach logistics and cost after shipment; add commission, refund and other fees at settlement. Finance is not a month-end channel export—it spans the event lifecycle.

Multi-currency operations distinguish transaction, settlement and functional currency and preserve rate type and date. Otherwise the same margin metric changes with query timing and cannot be reproduced.

A control tower earns its value through exceptions, not a big screen

A small number of exceptions often drive disproportionate impact: a high-value order stalls, a popular SKU fails mapping, stock stops syncing, a refund lacks its order or settlement does not reconcile. Prioritise by value, customer impact and age with clear ownership.

OmniTrek combines channel coverage, finance, analytics and private deployment on one fact layer. Dashboards are an output; reliable synchronisation, explainable rules and closed-loop exception handling are the competitive capability.