How to integrate your physical store (POS), e-commerce and ERP without breaking inventory, pricing or invoicing

When a retail company opens an online channel, the first thing it integrates is the most visible part: the catalogue and the checkout. What almost never gets planned in time is what happens underneath: how the in-store POS, the e-commerce platform and the ERP are going to agree on available stock, the current price and the invoice that needs to be issued.

When that conversation between systems is not properly designed, the outcome is predictable: products sold without real stock, prices that differ between channels, and invoices that do not reconcile with what was actually charged. Integrating POS, e-commerce and ERP is not a matter of connecting three cables: it means defining who owns each piece of data, how quickly it is updated, and what happens when one of the three does not respond.

This guide explains how to design that integration so inventory, pricing and invoicing stay consistent as the business adds channels, SKUs and volume, and closes with a five-step roadmap to put it into practice.

Quick summary

• In practice, omnichannel means the physical store and the online store work on the same data. Without that integration, adding channels only multiplies the errors.
• The source of almost every stock, pricing and invoicing error is not technical: it is the absence of a source of truth defined per data point.
• The five flows you have to resolve no matter what are stock, prices, orders, tax documents and customers.
• Direct connections between pairs of systems scale badly: with four systems you already have up to six integrations to maintain.
• The sign that a simple integration has hit its limit is operational, not technical: weekly hours of manual reconciliation and customer complaints about overselling or inconsistent pricing.
• The recommended roadmap moves in five steps: diagnosis, core data, a quick-win service such as in-store pickup, unified customer data, and measurement.

Omnichannel: why it all starts with integration

For the customer, omnichannel means checking stock online and picking up in store, buying on the website and returning at the shop, or starting a purchase in one channel and finishing it in another without noticing the difference. For operations, it means the POS, the e-commerce platform and the ERP agreeing on every one of those transactions.

That customer is already the majority. According to Katana, 73% of shoppers use several touchpoints before completing a purchase, and those who do spend 4% more in store and 10% more online than single-channel shoppers. Expectations are high too: 74% of consumers expect to be able to do online everything they would do in person or over the phone, according to Salesforce.

The profit in omnichannel does not come from being everywhere, but from connecting those places. Retailers that have moved to a unified commerce model, where e-commerce and point of sale run on the same database, report an average sales uplift of 8.9%, according to Shopify. That shared foundation is also what makes high-value services possible, such as BOPIS (buy online, pick up in store) or BORIS (buy online, return in store), which cannot be sustained if every channel keeps its own stock.

Why POS, e-commerce and ERP end up out of sync

In most cases, each system was born separately. The POS was implemented for the physical store, the e-commerce launched later on a different platform, and the ERP arrived to bring order to accounting and purchasing. When they are connected through manual exports, spreadsheets or one-off integrations between pairs of systems, each one ends up acting as a different source of truth for the same data.

The problem is not having three systems. It is not having defined which one owns each piece of data and how often it is updated. Without that rule, falling out of sync is only a matter of time. It happens even when one system covers two of the three roles: many retail chains use ICG as POS and ERP and have the link between the shop counter and accounting under control, yet as soon as the e-commerce goes live on another platform, two stock figures that do not match and misaligned prices across channels start to appear.

There is a second, less obvious factor: the three systems have different data models. The ERP thinks in accounting stock per warehouse, the POS thinks in physical units per branch, and the e-commerce thinks in publishable availability. All three numbers can be correct and still not match, simply because they measure different things. An integration that does not make that difference explicit will produce permanent discrepancies that nobody can explain.

What data should travel between POS, e-commerce and ERP

Before choosing a tool, it is worth defining the data contract: what travels, in which direction, how often, and who owns each field.

Data	Usual source of truth	Direction	Recommended latency
Stock per SKU and per warehouse	ERP or WMS	ERP → e-commerce, POS	Real time or near real time
Prices and commercial price lists	ERP	ERP → e-commerce, POS	Minutes
Active promotions per channel	ERP or promotions engine	Central → channels	Minutes
Orders and their status	Originating channel	Channel → ERP → channel	Real time
Payments and reconciliation	Payment gateway or acquirer	Gateway → channel, ERP	Real time to confirm, daily to reconcile
Tax documents	ERP or invoicing system	ERP → channel	Minutes
Customer data	CRM or Customer 360	Bidirectional with rules	Near real time

Two clarifications that prevent most later arguments:

• Stock per warehouse, not total stock. Publishing consolidated stock without distinguishing branches later makes it impossible to enable in-store pickup or ship-from-store. If the data model does not account for the warehouse from the start, adding that capability means rebuilding the integration.
• Normalised order statuses. Each system names the same statuses differently (confirmed, approved, paid, in preparation). Defining a single equivalence table, in the integration layer, prevents every new channel from bringing its own vocabulary.

The most common mistakes when integrating these three systems

Double manual entry of prices. Someone updates the rate in the ERP and forgets to replicate it in the e-commerce, or the other way round. It is the most common error and the most expensive in margin terms, because it tends to surface only at the accounting close. And the cost is not only margin: when the online price differs from the in-store price, customers stop trusting both, and the channels end up competing with each other instead of adding up.

Stock that does not decrement in real time. If the e-commerce syncs stock every 30 or 60 minutes, during a high-demand campaign that interval is enough to sell the same unit several times. Overselling does not show up at normal volume: it shows up exactly on the day it costs the most.

Duplicate invoicing or orders with no associated document. This happens when the integration retries a failed operation without an idempotency mechanism, that is, without a unique key that lets it recognise that the order has already been invoiced. The retry generates a second document for the same sale.

No end-to-end traceability. Nobody can reconstruct the full path of an order when a customer complains. Without a centralised log, the answer to the customer depends on three teams checking three different systems.

Inconsistent SKU mapping. The same product is ABC-123 in the ERP, abc123 in the e-commerce, and has its own code in the POS. Every unmapped variation becomes, sooner or later, a phantom product or a stock movement that does not land where it should.

These five are the mistakes that hit inventory, pricing and invoicing hardest. For the wider picture, which also covers the role of store staff and aligning marketing across channels, see the 7 most common integration mistakes in omnichannel retail.

How to tell when a simple integration is no longer enough

A direct connection between two systems can work well at first. The sign that this approach has hit its limit is not a magic number of orders, but several of these conditions appearing at the same time:

• The catalogue goes past a few thousand SKUs or changes price frequently.
• A third system was added (marketplace, WMS, CRM) that also needs the same data.
• The team spends hours a week manually reconciling stock or invoicing between systems.
• Overselling or inconsistent pricing errors have already generated customer complaints.
• Every small change (adding a field, adding a branch) requires asking a third party for development work.

There is a quick test: count how many integrations you would have to maintain if you added a fourth system. With direct connections between pairs, three systems require up to 3 connections; four systems, up to 6; five systems, up to 10. The growth is not linear, and that is the real reason a setup that used to work stops working.

Recommended architecture: from point-to-point connections to a centralised flow

The sustainable alternative is not to connect the POS to the e-commerce, the e-commerce to the ERP and the ERP to the POS separately, which in integration terms is known as a point-to-point setup, but to centralise the exchange in an intermediate layer that defines explicit rules:

1. Which system is the source of truth for each piece of data. One per data point, with no exceptions negotiated case by case.
2. How often each flow syncs. Stock needs real time; the descriptive catalogue can tolerate minutes; reports, hours.
3. What happens if a system is down. Message queues and retries with progressive back-off, so a ten-minute ERP outage does not translate into lost orders.
4. How each piece of data is transformed. Mapping rules (units, taxes, branch codes, statuses) live in one place and are not duplicated in every connection.
5. How it is audited. One record per transaction that makes it possible to answer what happened to a specific order without opening three systems.

That is exactly the role of an integration platform (iPaaS): it acts as the single point where the flows between POS, e-commerce and ERP are orchestrated, so adding a fourth or fifth system does not mean rebuilding the existing connections. It is the approach behind Weavee’s omnichannel retail integration: a layer that connects physical stores, e-commerce, marketplaces, ERP and logistics with a single source of truth for stock and prices. If you want to go deeper into when that step makes sense, it helps to review the criteria for deciding between enterprise iPaaS and standalone connectors based on volume, risk and governance.

Example flow: an online sale with in-store pickup

A concrete case helps to see where the chain breaks. An online purchase with branch pickup goes through this path:

1. The customer selects a product. The e-commerce shows availability per branch, not consolidated.
2. Payment is confirmed. The gateway notifies the integration layer, not the ERP directly.
3. The integration layer reserves the stock at the chosen branch before creating the order, so that item stops being available in any other channel.
4. The sales order is created in the ERP with the unique key of the originating order, which prevents duplicates if there is a retry.
5. The branch POS receives the picking order and decrements physical stock at the moment of handover.
6. The ERP issues the tax document and returns the number to the e-commerce, where it becomes visible to the customer.

The critical point is step 3. If the stock reservation happens after the order is created, or does not happen at all, the same unit can be sold through another channel in the meantime. It is the most common cause of overselling in omnichannel operations.

A 5-step roadmap to integrate your physical store, e-commerce and ERP

The architecture above is not implemented in one go. This sequence lets you move in stages, validate each one with concrete results and avoid spreading the investment too thin.

Step 1. Diagnosis: map your systems and touchpoints

Before writing a line of code, draw the full map: which systems are involved (POS, e-commerce, ERP, marketplaces, WMS, CRM), what data they exchange today, through which channel (API, spreadsheet, manual export) and at which touchpoints the customer experience breaks. In most retailers that map turns out to be a spider web of connections, and drawing it shows where manual reconciliation piles up and what to fix first. The data table in this guide is a good starting point.

Step 2. Integrate the data core

Pick a first use case with visible impact, such as in-store pickup, and integrate the core data behind it: stock per branch, prices, the SKU master, order statuses and a shared customer identifier. This is the moment to set the source of truth for each data point and to put in place the integration layer that will enforce it. Start with one channel and one pilot branch before rolling it out.

Step 3. Launch a quick-win service: BOPIS or BORIS

With the core integrated, switch on the service that tests the whole chain: buy online and pick up in store, or buy online and return in store. Advatix notes that these options strengthen customer trust and encourage repeat purchases, because they give certainty about stock and timing. Operationally, they are also the best test of the integration: if the example flow above works end to end, the model is ready to scale. Cross-channel returns have their own pitfalls (restocking, credit notes, refunds), which we cover in the guide to omnichannel returns across physical store, e-commerce and ERP.

Step 4. Unify customer data and personalise

With inventory visible and channels connected, the next lever is relevance. Bringing online and in-store purchase history together in a single customer profile lets you tune campaigns, prices and cross-selling with the full picture, not the half each channel sees. According to Shopify, recommendations powered by a single profile can lift the average order value by up to 20%. This stage depends on a decision made in step 2: without a customer identifier shared between the POS and the e-commerce, there is no single profile.

Step 5. Measure, iterate and align incentives

Define omnichannel KPIs and look at them together: omnichannel GMV, in-store pickup rate, margin per order, oversells, orders without a tax document and hours of manual reconciliation. Measuring every interaction is what makes results attributable: BigCommerce documents the case of Veronica Beard, which reached a 35% conversion rate when customers moved from digital contact to the store, a figure it could only measure because it tracked interactions in both channels. Finally, align internal incentives: if the store and the e-commerce are measured and rewarded separately, they will compete for the same sale and erode the margin the integration was meant to create.

Frequently asked questions

What is the difference between multichannel and omnichannel? In a multichannel model, each channel sells on its own, with its own stock, prices and customers. In an omnichannel model, they all share the same data in near real time, so the customer can buy in one, pick up in another and return in a third. The difference is not the number of channels, but how well they are integrated.

Can POS, e-commerce and ERP be integrated without changing any of the three systems? Yes. That is precisely the goal of an integration layer: to coordinate the existing systems without replacing them. The requirements are that each system exposes an API or a data exchange mechanism, and that a unique shared identifier can be defined for product, order and customer.

How long does an integration like this take? It depends less on technology than on the state of the data. If the catalogue has consistent SKUs and customer duplicates have already been cleaned up, the work concentrates on configuring flows. If master data has to be normalised first, that stage is usually the longest in the project.

Is it better to sync in real time or in batches? Both, depending on the data. Stock and orders justify real time. The descriptive catalogue, costs or reports work well in batches. Putting everything in real time makes the solution more expensive with no real operational benefit.

What happens if the ERP goes down in the middle of a sale? With a centralised architecture, the transaction stays queued and is retried when the system comes back, instead of being lost or blocking the checkout. Designing that behaviour is an architecture decision, not a feature that comes by default.

Should the POS or the e-commerce be integrated with the ERP first? What makes sense is to integrate first the flow with the greatest impact if it fails, which in almost every case is stock. Starting with the critical data point, in one channel, lets you validate the approach before extending it.

Checklist before integrating POS, e-commerce and ERP

• Is it defined which system is the source of truth for stock, and at warehouse or branch level?
• Are price lists updated in a single place and replicated automatically?
• Is every order linked to a unique tax document, with a key that prevents duplicates on retries?
• Are SKUs identical across the three systems, with no formatting variations?
• Is there a customer identifier shared between the POS and the e-commerce?
• Is there a centralised log to audit the full path of an order?
• Is it defined what happens to a transaction if one of the systems does not respond?
• Does the architecture allow adding a new channel without rebuilding existing integrations?
• Are omnichannel KPIs defined, with incentives shared between the store and the e-commerce?

You may also be interested in reading:

• “OMS in retail: what data it must sync with ERP, POS and the online store to avoid stalled orders”

• “Promotions and pricing in omnichannel retail: how to avoid inconsistent discounts between channels”

• “VTEX and ERP integration in LATAM retail: composable architecture and critical flows”

• “Homemade integrations vs. iPaaS: the real cost of ‘saving’ on technology you need to know”

If your POS, your e-commerce and your ERP still talk to each other through spreadsheets or loose integrations, Weavee’s Universal Connection centralises stock, pricing and invoicing in a single flow, without replacing the systems you already use.