Connecting your store to the system that actually runs the business

The most useful artefact in an ERP project is a table with one row per data field and one column that says which system owns it. Product descriptions and imagery usually belong to the store, because that is where merchandising happens. Cost, stock and internal pricing usually belong to the ERP. Customer records depend on where your service team works. Orders originate in the store and are fulfilled in the ERP, which means they flow one way and their status flows back. Ambiguity in this table is where integrations go to die.

• One row per field, one owner, written down before any code
• Merchandising content: the store
• Cost, stock, internal pricing: the ERP
• Orders out, fulfilment status back

Not everything needs to be real-time, and pretending otherwise makes integrations fragile and expensive. Orders should flow to the ERP quickly, because fulfilment waits on them. Stock should flow to the store frequently, because overselling is expensive. Product catalogue data can often move on a schedule, because a description that is four hours stale harms nobody. Pricing depends on how often it changes and whether it drives promotions. Choose deliberately, and write the chosen frequency next to each field in the same table.

Point-to-point integrations look cheaper until the third system arrives. A middleware layer — an integration platform or a small service you own — gives you one place where mapping rules live, where failures are logged and retried, and where you can replay a batch that failed without hand-editing records. It also decouples release cycles, so an ERP upgrade does not require a storefront deployment. For anything beyond a single simple connection, this is usually the cheaper architecture within a year.

Ask any vendor what happens when the ERP is unavailable for two hours during a promotion. The good answer involves queuing, retries with backoff, idempotent operations so a retry cannot duplicate an order, alerting a human when a queue stops draining, and a way to replay. The bad answer is that it should not happen. Orders that silently fail to reach fulfilment are the single most expensive failure mode in this entire category, and they are invisible until a customer asks where their parcel is.

ERPs and storefronts model products differently, and the mismatch is where most of the effort goes. SKUs may be structured for warehouse logic rather than customer logic. Variants may exist as separate ERP items that must present as one product with options. Units of measure, case packs and pricing tiers all need explicit translation rules. Do this mapping on paper with real examples from your own catalogue — including the products everyone agrees are weird — before anyone writes a connector.

Start read-only: let the integration write nothing while you compare what it would have done against reality for a week. Then enable one direction for one entity, usually stock. Then orders. Keep the manual process alive in parallel until each stage has proven itself for a full business cycle, including a month-end. A big-bang cutover on an ERP integration is the version that ends with someone re-keying two days of orders at midnight, and it is entirely avoidable.

If your ERP is really an accounting package, connecting the store to accounting is a smaller and cheaper project with a different shape. If the pain is stock accuracy across sales channels, an inventory platform may solve it without touching the ERP at all. And if the current manual process costs a few hours a week, an integration that costs a developer's ongoing attention may not be a saving. Price both sides before committing.