Every online order that gets retyped into the ERP is a mistake waiting to happen. Here is how store-to-ERP integration actually works - which direction each piece of data flows, what breaks first, and what it costs to build properly.
Key takeaways
- Store-to-ERP is not one integration. It is four separate flows - orders, inventory, products, customers - and each has its own direction, frequency and failure mode.
- Decide which system is the master for each data type before you write a line of code. Two systems that both think they own inventory will fight, and the customer sees the loser.
- Make every write idempotent and keyed on the store order number. Networks fail mid-request, and the recovery path must never create a duplicate invoice.
- Budget for the error queue and the alerting, not just the happy path. The integration is only useful if someone finds out the same day that 12 orders did not sync.
The pattern is always the same. The store runs on Shopify or WooCommerce. The business runs on Priority, SAP Business One or Hashavshevet. Between them sits a person with two browser tabs, copying order details from one into the other. At 20 orders a day it is annoying. At 200 it is a full-time job that produces typos in customer addresses and invoices with the wrong VAT.
This guide covers what a proper store-to-ERP integration looks like, the decisions that determine whether it works, and what it costs.
It Is Four Integrations, Not One
The single biggest scoping mistake is treating "connect the store to the ERP" as one project. It is four flows, and you do not need all of them on day one.
| Flow | Direction | Typical trigger | Priority |
|---|---|---|---|
| Orders | Store → ERP | Webhook on order paid | Build first |
| Inventory levels | ERP → Store | Scheduled, every 15-60 min | Build second |
| Products and prices | ERP → Store | Scheduled, nightly | Only if the catalogue changes often |
| Customers | Both, with rules | On order creation | Usually rides along with orders |
Shipping status and returns are a fifth flow that most businesses can keep manual far longer than they expect.
Decide the Master System First
For each data type, exactly one system is the source of truth and the other is a mirror. Getting this wrong is the cause of most of the pain people blame on "the integration being buggy".
- Inventory: the ERP wins. It knows about warehouse stock, reserved units, goods in transit and returns. The store gets a number pushed to it and never decides stock on its own beyond the checkout reservation.
- Orders: the store wins. The order was placed there, the customer got that confirmation email. The ERP receives it and must not silently modify the line items.
- Prices: usually the ERP, unless marketing runs promotions in the store. If both need to set prices, split it explicitly - base price from the ERP, discounts owned by the store - and never let both write the same field.
- Customers: messy. The store creates guest checkouts; the ERP has an accounting-grade customer master. The workable rule is to match on a normalised email or tax ID, create in the ERP when no match exists, and never overwrite ERP customer records from store data.
The Israeli Stack in Practice
Priority has a well-documented REST API and is the smoothest of the local ERPs to integrate. Orders, customers, items and stock are all reachable. The usual friction is form and field naming - Priority installations are heavily customised, so the field you need is often a customer-specific extension rather than a standard one.
SAP Business One exposes the Service Layer (OData). Capable and well structured, but heavier: sessions, stricter object models, and less forgiving error handling. Expect more time on the ERP side than on the store side.
Hashavshevet is the oldest of the three and the most variable. Depending on version and installation you may be working against a local API, an ODBC connection, or a file-based import. Confirm which one you actually have before scoping - this single fact can double or halve the estimate.
Rivhit and cloud invoicing services generally offer a straightforward HTTP API and are the easiest case, though they cover invoicing rather than full ERP functionality.
Stock - harder than it looks
Stock sync is one-way and apparently trivial, but three questions decide whether it works:
- Which stock? Physical, available-to-sell, or physical minus open orders? Online selling almost always wants available - otherwise you sell items already allocated to another order.
- Which warehouses? With several, you must decide which ones the store sells from. Blindly summing everything commits you to stock sitting in another branch.
- What happens at zero? Mark out of stock, hide the product, or allow backorder? That is a business decision, not a technical one, and it is worth getting in writing.
On frequency: every 15-60 minutes suffices for most businesses. Anyone selling single-quantity items in high demand needs more, but at that point the real question is whether the system should be selling that stock without allocation at all.
Orders - the only flow that must be fast
An order placed in the store needs to reach Priority quickly, because the entire operational process depends on it. The pattern that works:
- The store sends a webhook on a new order.
- Your endpoint validates the signature, writes the raw order to a queue or table, and responds immediately.
- A separate worker processes the queue: matches the customer, maps items, and creates the document in Priority.
- The created document ID is stored alongside the store order ID.
The reason for the split: creating a document in Priority involves customer matching, validations and sometimes several calls. If all of that happens inside the webhook, any slowdown on the ERP side becomes a failure on the store side. The platform-by-platform version - Shopify and WooCommerce into Priority, SAP B1 or Hashavshevet - is in connecting an online store to an ERP.
Atomic creation: the Priority API lets you create a document with its lines in a single request by nesting the subform array in the body. Use it. Creating a header and then lines in separate calls leaves a partial document behind if something fails midway.
The part that is all the work: customers
This is the expensive part, and the part that stays invisible until it detonates. A store customer is identified by email; a Priority customer is a customer card with a number. Matching between them is business logic, not technical logic.
The safe rule: never let the integration create a new customer card blindly. When no confident match is found, it is better to book the order under a walk-in customer and flag it for review than to create a duplicate. Duplicate customer cards do not surface in testing; they surface six months later, in a report that does not add up.
Fulfilment - the flow most often forgotten
When a shipping document is created in Priority, the store order should move to "shipped" and receive a tracking number. This is the flow most often deferred to phase two, and also the one that generates the most support contacts when it is missing.
Here Priority webhooks fit precisely: there is a clear document status transition, which is exactly what the mechanism is built for. On an installation without the Webhooks module licence, scheduled polling of the last day's shipping documents does the job.
What every integration of this kind must have
- A documented two-way link. The store order ID on the Priority document, and the document number on the store order. Without it, every enquiry becomes a manual comparison.
- Idempotency. The same order arriving twice must produce one document. Webhooks get redelivered; this is not an edge case.
- A daily reconciliation job. Compare store orders against Priority documents for the last 24 hours and alert on gaps. That is what catches whatever the silent failures missed.
- An error queue a human sees. An order that failed to import must appear somewhere someone looks every morning. An order stuck in a log is a lost order.
The same principles apply to WooCommerce and any other store platform - what changes is the store's API, not the shape of the integration.
The Parts People Skip
Idempotency
A webhook fires, your service starts creating the ERP order, the connection drops before the response comes back. Shopify retries. Without protection you now have two orders and two invoices. The fix is to key every write on the store order number, check for an existing record before creating, and store the resulting ERP document ID so a retry becomes a no-op.
The error queue
Orders will fail to sync - an item missing from the ERP catalogue, a customer with an invalid tax ID, a temporary outage. They must land in a visible queue with the error text and a retry button, not disappear into a log file. This is the single feature that separates an integration people trust from one they check manually anyway.
Alerting
A daily summary is not enough. If nothing has synced in two hours during business hours, someone should get a message. Silent failure is the expensive one.
Partial failures
An order syncs but its customer record does not. Decide up front whether that is a hard failure that rolls back, or a soft one that flags for review. Both are defensible; being undecided is not.
What It Costs
| Scope | Typical build |
|---|---|
| Orders only, standard ERP fields, no customisation | 1-2 weeks |
| Orders + inventory, error queue, alerting | 2 - 3 weeks |
| All four flows, heavily customised ERP, multi-warehouse | 5 - 8 weeks |
Off-the-shelf connectors exist and are worth evaluating first. They tend to work well when your ERP is close to stock configuration and break down when it is not - which, for Priority and SAP B1 in Israel, is most of the time.
Start With Orders Only
Ship the order flow alone, run it in parallel with the manual process for a week, and compare. You will find the field mismatches and the edge cases with no risk. Then turn off the manual process and add inventory.
The businesses that get burned are the ones that switch on four flows at once and then cannot tell which of them is producing the wrong stock numbers.
If you want the flows mapped for your specific store and ERP, book a free call. Related reading: CRM, ERP and app integration for small business and how to automate inventory management.
Frequently asked questions
Should I use an off-the-shelf connector or build a custom integration?
Evaluate the connector first - it is always cheaper when it fits. It fits when your ERP is close to its stock configuration and you need only standard fields. It stops fitting when your Priority or SAP B1 installation has customer-specific fields, when you have multi-warehouse logic, or when your customer matching rules are unusual. In Israel that describes most established installations, which is why custom integrations are common here.
How often should inventory sync from the ERP to the store?
Every 15 to 60 minutes covers almost every business. Push more frequently only for genuinely scarce items where overselling is expensive - and for those, a targeted event-driven update on stock movement is better than shortening the interval for the whole catalogue. Full catalogue syncs every few minutes create load on the ERP for no practical benefit.
What happens to orders placed while the ERP is down?
Nothing should be lost, and the store should keep selling. The integration receives the webhook, writes the order into its own queue, and acknowledges immediately. A worker then drains the queue into the ERP with retries and backoff. Orders that still fail after the retry budget land in a visible error queue with the failure reason. This is why the integration needs its own storage rather than being a pass-through.
Can the integration create the invoice automatically?
Technically yes in every one of these systems, and it is a common requirement. The caution is that an invoice is a financial and regulatory document, so automatic issuance should be reviewed with your accountant before it goes live, and it must be strictly idempotent - a duplicate invoice is a real problem, not just a data error. Many businesses start by creating a draft document automatically and having a person approve issuance for the first few weeks.
Which flow should I build first?
Orders, store to ERP, and nothing else. It removes the most manual work, it is the easiest to validate against the existing manual process, and it does not risk showing customers wrong stock. Run it in parallel with the manual entry for a week and compare the results before switching off the manual process. Inventory comes second because a bug there is customer-visible.
Can Priority ERP be connected to Shopify?
Yes. Priority exposes a REST/OData API for reading and writing items, stock, customers and documents, and Shopify exposes its own admin API plus webhooks. The integration is built as four separate flows - catalogue and stock from the ERP to the store, orders from the store to the ERP, and fulfilment status back to the store.
What is the most expensive mistake in an ERP to store integration?
Letting the integration create ERP customer cards automatically when it cannot confidently match an existing one. Duplicate customer records do not fail any test - they accumulate silently and surface months later as reports that do not reconcile. Booking an unmatched order under a walk-in customer and flagging it for review is far cheaper to fix.
How do you stop the same order being imported twice?
Store the store's order ID on the ERP document and check for it before creating anything. Webhooks are redelivered as a matter of course, so idempotency is a requirement rather than an edge case. A daily reconciliation job comparing store orders against ERP documents catches whatever slips through.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.