Connecting your store to the ERP that actually runs the business

The most useful artifact 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, fulfillment status back

Not everything needs to be real-time, and pretending otherwise makes integrations fragile and expensive. Orders flow to the ERP fast, because fulfillment waits on them; stock flows to the store often, because overselling is expensive. Product catalog data, by contrast, can move on a schedule. A description that is four hours stale harms nobody, and pricing sits wherever its change rate and promotions put it. 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.

How an integration behaves when something fails decides whether it can be trusted at all. 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 fulfillment are the single most expensive failure mode in this entire category, and they are invisible until a customer asks where their package is.

ERPs and storefronts model products differently, and the mismatch is where most of the effort goes. SKUs are often built for the warehouse, which does not think like a customer, and variants may exist as separate ERP items that have to 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 catalog — 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. Under roughly 50 orders a day, a nightly export and a person who checks it beats an integration nobody owns.