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.

Connecting Your Online Store to an ERP: Shopify and WooCommerce to Priority, SAP B1 and Hashavshevet

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.

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.

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	3-5 weeks
All four flows, heavily customised ERP, multi-warehouse	8-12 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.