How to Connect Your Online Store to Warehouse or ERP Software: Automating Inventory, Prices and Orders

The aim is to move inventory, prices and orders between systems under clear rules. Before development, define the authoritative source for each type of data, when stock is reserved and what happens when an operation fails.

An order arrives in the store. An employee enters it into the warehouse application, checks availability and then prepares a document and shipping label. Meanwhile, the same item may have been sold in a physical shop. The customer has already received confirmation, and the team now has to explain why the product is unavailable.

Integration can reduce this manual work. To be useful, it needs to connect the actual sales process, including the exceptions the team handles every day.

Why should your online store and warehouse system work together?

Integration is useful when online sales and warehouse operations share products, prices and quantities, but information moves manually or arrives late.

The problem often becomes visible as order volumes grow or the business starts selling through several channels. Typical signs include:

• orders being entered again in a separate application;
• the website showing products that have already been sold;
• price changes needing to be made in several places;
• staff matching payments, orders and shipments in spreadsheets;
• warehouses and shops providing conflicting views of stock;
• customers calling for information that already exists in another system.

Warehouse software generally manages stock movements and quantities. An ERP system may also cover purchasing, sales, finance or manufacturing. The specific product and installed modules determine which information can actually be exchanged.

You do not necessarily need to replace every system. A limited connection for inventory and orders may be the right first step.

What data can be synchronized?

Products, variants, quantities, prices, orders, customers, statuses and documents can be exchanged when the systems provide the required access.

Each field needs a defined direction of exchange and an agreed system responsible for changing it.

This is an example arrangement, not a universal architecture. Product descriptions and images may be maintained in the store while the ERP owns prices and inventory. Updating warehouse data should not accidentally overwrite edited product content.

For prices, define whether amounts include tax, which currency is used and which system controls promotions. In B2B sales, negotiated customer prices must apply to the correct account and must not be exposed to other customers.

How are products matched between systems?

Products are matched using stable identifiers, such as an item code, SKU or a verified mapping table. Names alone are insufficient: the same product may have different names in the two applications.

Each size or colour with separate inventory needs its own mapping. Bundles need a rule defining whether their availability depends on component stock. A shared barcode should not automatically be treated as sufficient if packaging or units differ.

Which stock quantity should the website display?

The store should receive the quantity the business actually permits customers to buy. Physical stock may include reserved, damaged or otherwise unavailable units.

Example: the warehouse holds 20 units, 5 are reserved and 2 form a safety buffer. If those quantities have not already been deducted, 13 remain available for online sale. When the ERP already supplies a sellable quantity, reservations must not be deducted a second time.

20 on hand− 5 reserved− 2 buffer= 13 sellable

With several warehouses, define which locations can fulfil an order and whether combining stock changes the delivery lead time.

How does an order move through an automated integration?

An automated order moves through validation, recording, reservation, fulfilment and status updates back to the store.

The sequence depends on payment methods and the merchant's rules. The following is an illustrative scenario for a business selling online and through a physical shop:

The customer places an order. The store records a unique order number, items, prices, discounts and delivery method.

The processing condition is checked. An online payment may require confirmation from the payment provider. Cash on delivery follows a separate rule.

The order is sent to the ERP. The integration records the relationship between the store order number and the internal record.

Stock is checked and reserved. The responsible warehouse is selected. Insufficient stock becomes an exception requiring a decision.

The order is prepared. Permitted documents are generated and, if a courier integration is available, a shipping label is created.

The store receives an update. The order status and tracking information are returned when available.

Cancellations and returns are handled separately. Reservations are released or returned goods are processed under a defined procedure.

Prices in an accepted order should be preserved. A later change to a product's current price should not automatically alter the agreed order totals. Shipped, delivered and paid are also separate states.

Scheduled synchronization alone does not eliminate the risk of two channels selling the last unit. Reservation rules, a final availability check and, where appropriate, a safety buffer are needed.

Which systems can be integrated?

Integration feasibility must be checked against the specific versions, modules and access permissions.

An API in the store does not prove that the warehouse system supports every required operation.

Microinvest Warehouse Pro

Microinvest describes two-way exchange with external applications through Utility Center, including e-commerce modules in the Plus package. Its published WooCommerce integration guide covers connector setup, export and import. The product is known as Microinvest Склад Pro in Bulgarian.

This is a specific documented option. Implementation still requires checking current versions, licensing, configuration and operation coverage. An older guide does not guarantee compatibility with every current installation. See the official Utility Center overview.

WooCommerce

WooCommerce provides a REST API for connecting external systems and webhooks: notifications triggered by specific events. API keys and permissions control access.

Installed extensions, variants, custom fields and their impact on exchange must be checked. An older connector may depend on an interface that now requires additional compatibility support.

Shopify

Shopify provides the GraphQL Admin API and webhooks for apps and integrations. Inventory relates to product variants and locations, and the documentation distinguishes inventory quantity states.

Connecting a particular ERP requires checking access, the chosen app or connector and platform limits. An official Microinvest module for WooCommerce does not establish a ready-made Microinvest–Shopify connection.

Other ERP systems and custom stores

Possible approaches include a supported API, a vendor connector, file exchange or an intermediate integration service. Locally installed warehouse software may require a local agent that communicates securely with the store.

Direct database writes should not be treated as a standard substitute for a supported interface: they can bypass business rules. The method should be selected after checking with the vendor, without exposing the warehouse database directly to the internet.

Ready-made connector or custom development?

A ready-made connector is suitable when it covers the required data and processes with verified compatibility.

A custom integration makes sense when important rules are missing from the available connector.

Check how partial shipments, order changes and returns are handled. A demonstration using one product does not prove that a module supports the store's actual operations.

Custom integration does not mean building every component from scratch. An existing foundation can handle standard exchange, with specific business rules developed separately.

How much does online store ERP integration cost?

The total budget includes the connector or licences, analysis, data preparation, configuration or development, testing and deployment.

A module's purchase price is not the price of a working business process. The main cost factors are:

• systems, versions and available interfaces;
• warehouses, sales channels and directions of exchange;
• variants, bundles and units of measure;
• price groups, promotions and currencies;
• data quality and required mapping;
• order volume and acceptable synchronization delay;
• cancellations, returns, documents and monitoring.

When an interface is unclear, start by checking a small scenario: one product, one inventory change and one test order. The purpose is to confirm access and identify limitations before estimating the whole project.

A quote should separate initial implementation from licences, infrastructure, maintenance and future changes. Without that distinction, a low initial price can appear more attractive than the complete cost warrants.

What happens when the integration stops working?

A reliable integration should detect failures, retain unfinished operations and support controlled recovery.

Staff need to see what has been processed and what requires intervention.

Retries without duplicate orders

An ERP can record an order while its confirmation fails to reach the store. Resending that order must recognize the existing record. This is called idempotency: repeating an operation with the same identifier does not create a second result.

Shopify explicitly documents the possibility of duplicate webhook deliveries. Receiving a notification and completing the business operation should therefore be tracked separately.

Alerts and reconciliation

Useful controls include an exchange log, an alert for prolonged delays and a separate list of records with invalid data. Retries need limits: endlessly resending an invalid item will not fix its mapping.

Periodic reconciliation compares orders and quantities across systems. Shopify also recommends a reconciliation job for missed data. WooCommerce can automatically disable a webhook after repeated delivery failures, another condition that needs monitoring.

Define a threshold and response for stale inventory: an additional check, purchasing restrictions or processing subject to confirmation. The appropriate policy depends on the risk and product category.

Can AI automation be added to the integration?

AI is useful for unstructured requests, summaries and exception detection when it uses authorized data and verifiable tools.

Core synchronization of quantities, prices and payment records should follow defined rules. Practical applications include:

• extracting line items from an email or document and preparing a request;
• suggesting matches between supplier items and the product catalogue;
• summarizing why orders are blocked;
• answering natural-language questions using permitted data;
• drafting a customer reply about a delay.

Example: AI reads a B2B enquiry, identifies products and prepares a draft. The integration checks codes, quantities and prices. Ambiguous items go to an employee before an order is created.

AI should not invent stock quantities, arbitrarily change prices or mark an order as paid based on email text. Reading, proposing and performing an authorized action are different access levels. For background, see what an AI agent is and how MCP connects AI to business systems.

Frequently asked questions

Can the systems be integrated without an API?

Yes, if there is a suitable supported file exchange, connector or local mechanism. Check which operations it supports, the exchange frequency and failure recovery. Without an API, some scenarios may remain limited.

Does inventory need to update in real time?

Not always. Acceptable delay depends on sales volume, stock shared between channels and the risk of selling the last units. Agree a measurable update requirement rather than a general promise of real-time synchronization.

Can a physical shop and online store share warehouse stock?

Yes, when sales and reservations are accounted for consistently. A shared database alone does not prevent two channels from selling the last unit simultaneously; a complete inventory and reservation process is required.

Do you need to replace the ERP?

Not necessarily. First check whether the current system provides the required exchange capabilities. Replacement becomes relevant when significant limitations cannot be resolved sustainably or adaptation costs are not justified.

How can Sirius Software help?

Sirius Software can help analyze, develop and maintain the integration as part of the complete e-commerce platform.

The approach starts by tracing an order from the customer through inventory, payment and delivery.

Next come authoritative data sources, interface checks, the choice of a connector or custom extension, normal and failure scenario testing, and controlled deployment. After launch, monitoring and clear responsibility for failures are necessary. Read more about the approach in our software development services.

Measure the result through order processing time, the share of orders requiring no duplicate entry, inventory update delay, and mismatched or duplicate records. Record the baseline before implementation so there is a meaningful comparison.

For an initial assessment, prepare the store URL, platform and version, warehouse or ERP product, number of warehouses, approximate order volume and a description of manual steps. Sample items and orders are also useful, with unnecessary personal data removed.

Request an assessment of your online store and warehouse or ERP integration →

We will discuss which operations can be automated, what needs checking and which first phase offers practical business value.

About the author

Georgi Papucharov is the founder of Sirius Software, a Bulgarian software company developing web systems, e-commerce platforms, CRM/ERP solutions and integrations since 2011. This article presents a practical approach to connecting systems. Its examples are illustrative and are not presented as measured client results.