Ecommerce Inventory Sync and ERP Integration

Why inventory drifts between your store and your ERP

Most sellers do not have one inventory number. They have the ERP’s on hand count, the warehouse system’s bin quantities, the storefront’s sellable quantity, a separate figure on Amazon and whatever each retail location’s point of sale believes. Every one of those changes at a different moment: an order on the site, a return at a store, a receiving dock scanning a late container, a cycle count adjustment, a wholesale order allocated in the ERP. Tepia starts by tracing each of those events, because drift always comes from an event that one system saw and another missed.

The common symptoms are familiar. A bestseller oversells on a promotion day because the storefront only refreshed once an hour. Stock sits invisible online because a store transfer never posted. A bundle stays live after a component sold out. Customer service spends mornings cancelling orders and writing apology emails, and marketing stops trusting the site enough to run promotions.

Fixing it is less about a faster connector and more about deciding which system owns each piece of data, then making every other system listen to it. Tepia also looks at the physical side: if receiving scans happen at the end of a shift, or stores batch their returns, no integration will be faster than the slowest human step, so Discovery names those steps and proposes small process changes alongside the code.

What syncs, which system owns it, and how often

Tepia documents ownership for every data object before writing integration code. A typical map for a brand selling on its own site, a marketplace and in stores looks like this:

The sync layer in the middle is usually what Tepia builds. It holds the rules your ERP and storefront were never designed to share: safety buffers per channel, allocation priorities when stock is short, and which locations may ship online orders.

Engineering details that prevent overselling

The difference between an integration that works in a demo and one that survives a holiday weekend is in a handful of details. Tepia builds each of these in from the start:

• Idempotent events: every order and adjustment carries a unique key, so a retried webhook never decrements stock twice.
• Queues and retries: changes go through a queue such as AWS SQS or Azure Service Bus, so an ERP outage delays updates instead of dropping them.
• Rate limit awareness: Shopify, BigCommerce and Amazon all limit API calls, so updates are batched and prioritized by how close a SKU is to zero.
• Channel buffers: a few units held back on fast movers absorb the seconds between a store sale and the site update.
• Kits and bundles: availability calculated from components, including shared components across several bundles.
• Audit trail: every change logged with its source, so a mismatch can be traced to the event that caused it.

For connectors that need to do more than move numbers, our middleware and integration layer page explains how Tepia structures the service, and webhooks and event driven integration covers the event design.

How Tepia approaches ecommerce inventory sync

Tepia uses the same six phase process here as on any build, with a US based project manager accountable for the timeline and the cutover.

1. Discovery: an inventory of every system that touches stock, a review of API limits and webhooks on each, and interviews with ecommerce, warehouse and finance staff. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a store return becoming sellable online within minutes.
2. Design: a design questionnaire, the data ownership map, sequence diagrams for each event and wireframes for the exception dashboard your operations team will watch.
3. Development and Testing: an Alpha against sandbox stores and a copy of the ERP, then a Beta on a subset of SKUs in production, with test plans that replay a busy sale day of orders and confirm no SKU goes negative.
4. Training: sessions for operations and customer service on reading the dashboard, resolving flagged mismatches and adjusting buffers.
5. Launch: a full stock reconciliation, a channel by channel switch from the old connector, and support reps on watch through the first promotion.
6. Support: issue resolution, bug tracking and feature requests such as adding a new marketplace or warehouse.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months, and launch about a month, with integration only projects often shorter. See our process.

Connector apps or a custom sync layer

Plenty of sellers do well with an off the shelf connector between their storefront and accounting system. If you run one warehouse, one storefront and no bundles, Tepia will usually recommend a packaged connector and configuring it carefully.

A custom sync layer pays off when you sell through several channels from shared stock, ship online orders from stores, sell kits built from shared components, run an ERP such as NetSuite or Dynamics 365 with custom fields the connector ignores, or keep losing sales to oversells during promotions. It also helps when you have outgrown tools like Zapier, as described in Zapier vs custom integration.

If you are deciding on the ERP side first, read NetSuite integration or ERP integration services, then talk to Tepia about where your numbers drift today.

Frequently asked questions