Connecting an Israeli ERP to Anything: The Decisions Before the Code

"Connect the ERP to X" is a request that sounds simple and is almost always priced wrong. The reason is that most people price the code, while the real cost sits in four decisions that get made - or do not get made - before a line is written.

This article is a map. For each system's technical detail there are dedicated guides: Priority, SAP Business One, the invoicing systems and the payment gateways.

Question 1: who owns each field

This is the most commonly missed decision, because it looks like it has already been answered.

Someone says "the ERP is the source of truth", everyone nods, and a month later the sync overwrites the product descriptions, images and SEO text the marketing team built. The problem is not the sync - it is that the decision was made at system level instead of field level.

The split that works:

The practical consequence: the sync updates fields, not records. A product update should push only the fields the ERP owns - not a full object that flattens the rest. It sounds obvious and it is exactly what breaks in practice.

Question 2: where is the handover point

The natural request is two-way sync: a change here updates there, and the reverse. It sounds symmetrical and has no clean solution:

• Conflicts - both sides edited the same field between runs. Any resolution you pick is wrong in some cases.
• Loops - an update on one side triggers a sync that fires an event that triggers a sync back. You need a mechanism that recognises "this is a change I caused", and that is delicate code which fails silently.
• Loss of trust - and this is the worst. Once users cannot tell which system is right, they start keeping a spreadsheet on the side. At that point the project has failed, even if the code works.

The fix: one handover point. A single moment where ownership passes - usually "deal won" or "order confirmed". Before it one system owns; after it the other. And everything flowing back is read-only.

Once the returning fields cannot be edited, there is no conflict, no loop and no argument about who is right. Lock them in the interface too - a field that looks editable will be edited.

Question 3: what is genuinely urgent

A typical integration decomposes into four one-way flows, and only one is urgent:

That is a significant relief: you do not need a real-time architecture for the whole system, only for one path. Simple readable scheduled polling covers the rest, and it is far easier to debug.

Question 4: push or poll

The answer depends on the system. Priority has a built-in webhooks mechanism through BPM rules - with caveats: a module licence is required, there is no documented retry, and the error log keeps seven days. In SAP Business One the prevailing model is polling.

The deciding question: does the process you want to capture manifest as a document status transition? If so, you have a natural trigger. If not, you will poll, and that is entirely fine.

And regardless: a daily reconciliation job

This is the most important point in the article. No event mechanism is reliable enough on its own. Webhooks fail, servers are unavailable, and events are lost without anyone knowing.

A job that runs daily, pulls both sides for the last 24 hours, and compares - that is what turns an integration from an "optimisation" into something you can rely on. It is also cheap to build, roughly a day's work.

An integration without a reconciliation job is not reliable, even when it works. The difference between the two shows up in month three.

Three things every such integration must have

• A documented two-way link. The external order id on the ERP document, and the document number on the order. Without it every enquiry becomes a manual comparison of two lists.
• Idempotency. The same event arriving twice must produce one result. Events get redelivered - this is not an edge case.
• An error queue a human sees. A failed record must appear somewhere someone looks every morning. A record stuck in a log is a lost record.

The matching that is all the work: identity

This is the expensive part, and it stays invisible until it detonates.

An external system identifies a customer by email or by whatever someone typed. The ERP identifies them by a numbered card. Matching between them is business logic, not technical logic - and if a company registration number exists on both sides, that is the best key.

The one rule that holds: if there is no confident match, do not create a new customer card automatically. Book the record under a walk-in customer and flag it for review. Duplicate customer cards do not fail tests; they accumulate silently and surface six months later in a report that does not reconcile, at which point someone must merge invoice history by hand.

What is specific to the Israeli context

• Tax documents cannot be deleted. Any integration that issues documents needs duplicate protection - a timeout is not a failure, it is an absence of knowledge.
• Allocation numbers. The Tax Authority requirement applies regardless of the systems - see invoice allocation numbers for developers.
• Hebrew and RTL. Names usually pass fine; mixed Hebrew-and-identifier text breaks in PDFs, exports and text messages.
• The installation, not the product. Customised forms and fields differ between sites. Do not price an integration without seeing the specific installation's schema - the gap between an estimate from documentation and one from the real schema is a multiple.

An order of work

1. Decompose into one-way flows and mark which is urgent.
2. Decide ownership per field, in writing.
3. Set one handover point; everything returning is read-only.
4. Solve the identity key before writing code.
5. Read the installation's schema.
6. Build idempotency and an error queue from the start, not as an improvement.
7. Build a daily reconciliation job before going live.

And if your system has no API at all, see my software has no API, what now.