Zoho CRM ERP integration: Navision, SAP and Oracle

There is a scene that repeats in almost every one of these projects. A salesperson closes a deal in Zoho, walks over to finance, and reads out the customer details so someone can type them into the ERP a second time. Sometimes with a spreadsheet in between. And when anyone asks how much was sold this month, two different figures come back depending on who you ask.

Integrating Zoho CRM with the ERP fixes that, but not where people expect. The problem is almost never technical: the APIs exist and they work. The problem is that nobody has decided who owns each field. Without that decision, connecting the two systems only makes them overwrite each other faster.

What actually decides the project: who owns the master

Before looking at a single page of documentation, there is one question to answer for every shared entity: if this field changes on both sides at once, which one wins?

In most projects we build, the ERP owns the customer. It is where the accounting, the validated tax ID, the assigned credit risk and the payment terms live. That does not mean the sales team cannot create anything: Zoho creates prospects freely, because a lead is not yet a customer. But the moment the opportunity is won, the accounting record is created in the ERP, which returns the customer code to Zoho.

That code is the keystone of the whole integration. From then on, both systems refer to the same customer with no ambiguity, and every later sync has a solid reference instead of trying to match on name or email. In Zoho we store it in a dedicated indexed field; without it, every sync becomes guesswork.

If you let both systems create customers on different criteria, six months later you have two masters and no truth. It is the most expensive mistake to unwind, because by then there is accounting history hanging off the wrong records.

What syncs in each direction

The split that works is almost always asymmetric, and it is worth writing down before anything gets built.

From the ERP into Zoho goes what the sales team needs to know but must not edit: the product catalogue, applicable price lists and discounts, and the customer’s financial status. That last one is the most appreciated and the one almost nobody asks for up front: showing outstanding balance, consumed credit and overdue invoices on the record stops a salesperson spending three weeks on a deal that finance will block on delivery day.

From Zoho into the ERP goes very little, but it is critical: the won opportunity turned into an order, with its lines, its customer and its terms. Low volume, high responsibility.

Notice how little of this needs to travel both ways. Two-way sync multiplies the edge cases — write conflicts, update loops, clocks out of sync — and in practice it is needed far less often than it is requested. We build it when the business justifies it, not by default.

Where it breaks in practice

On-premise Navision and Business Central in the cloud

This is the distinction that derails the most projects, because people say “Navision” for both and they are different worlds.

With on-premise Dynamics NAV you work against SOAP or OData web services published from the NAV server itself. Technically that is straightforward; the real work is infrastructure. That server lives inside the corporate network and Zoho is on the internet, so the first thing to solve — usually with the client’s systems team rather than their applications team — is how to expose that endpoint outward without opening a hole: VPN, reverse proxy, a middle layer of your own. Add Windows authentication, which is not what a modern HTTP client expects, and the first two weeks are spoken for.

With Business Central in the cloud that problem disappears: there is a modern REST API, OAuth2 authentication against Microsoft Entra ID, and everything is reachable from the internet. The problem moves elsewhere: request limits and token management. A better starting point, certainly, but not a free one.

What matters is that the architectural decisions are identical in both cases. Who owns what, what syncs, how often, what happens when it fails. Only the transport changes. If someone frames the project the other way round — starting from the API and leaving the model for later — expect surprises.

SAP: Business One and S/4HANA are not alike

Same pattern, same misunderstanding. “Integrate with SAP” means nothing until you know which one.

SAP Business One, the SME product, exposes its OData-based Service Layer, which is what we work with today. You can still meet installations built on the older DI API, a Windows library that constrains where your integration is allowed to run.

S/4HANA publishes OData services through its gateway, and there the work is as much negotiation as code: getting the client’s SAP team to enable and expose the services you need is rarely immediate. On older ECC installations the route is still RFC or BAPI, and there you almost always end up adding a middle layer.

With SAP more than anywhere else, the project timeline depends on a third party. We say so in the first meeting.

Oracle: work out which one first

“Oracle” covers NetSuite, E-Business Suite and Fusion Cloud ERP, and they have nothing in common. NetSuite has its own REST API and SuiteTalk; Fusion Cloud exposes REST services; E-Business Suite, depending on the version, leaves you with considerably more hand-built integrations.

The first task on any project that arrives saying “we want to connect Zoho with Oracle” is pinning down which product and which version. It sounds obvious, and it is exactly where the first few weeks go when nobody asks in time.

The initial load is where everything breaks

Day-to-day syncs are low volume and rarely cause trouble. What breaks is the first load: twenty thousand customers, fifty thousand items and the order history, all at once.

Two things we always do. First, treat the initial load as a process separate from the incremental one, with its own pacing and batching, rather than reusing the normal flow and burning Zoho’s daily API credit in the first hour. Second, do not migrate history by default. Almost nobody needs eight-year-old orders in the CRM; they need the current financial year and a link to consult the rest in the ERP. Every record you do not migrate is a record you never have to clean, de-duplicate or keep in sync forever.

How we approach it

We start with a table, not the API. One row per shared entity — customer, product, price list, order, invoice — and three columns: who owns it, which direction it travels, how often. That table is agreed with the client before any code is written. It is the least glamorous part of the project and the one that decides whether it still works in year two.

Everything anchored on external identifiers. The ERP customer code stored in Zoho, and the Zoho ID stored in the ERP where possible. With that, any operation can be repeated without duplicating anything: if a process is cut off halfway and you rerun it, it updates instead of creating. An integration you cannot safely rerun is an integration nobody dares to touch.

Separate rhythms per kind of data. A won order is written immediately. The catalogue syncs in overnight batches, and only what changed. Putting both in the same process is the fastest way to bring the sync down on a Tuesday morning.

A nightly reconciliation job. However well designed, a continuous flow accumulates drift: a lost event, a write that failed and nobody retried. A job that compares both systems each night and reports the differences catches the problem before the client does. It is cheap to build, and it is what separates an integration people trust from one that gets checked by hand every week.

Errors that never fail silently. Retries with progressive backoff, queues so no event is lost while a system is down, and an alert to a named person when something jams. Without this, the first sign that the integration has been broken for ten days comes from the client.

Mistakes worth avoiding

• Connecting before deciding the master. Without that rule written down, both systems overwrite each other and within three months nobody trusts any figure.
• Matching customers on name or email. “García Construction Ltd” and “GARCIA CONSTRUCTION LTD” are the same company and will not match. Matching goes by code, always.
• Integrating before cleaning. If you carry over duplicates and junk fields, the integration only spreads them faster — and into an accounting system.
• Making everything two-way “just in case”. It multiplies edge cases in exchange for flexibility that is almost never used.
• Migrating the full history. It inflates the project, exhausts API limits and fills the CRM with data nobody will look at.
• Reusing the incremental flow for the initial load. The classic that leaves the sync down on day one, in front of everyone.
• Not validating the tax ID at the source. A tax identifier captured wrongly in the CRM becomes a compliance problem weeks later, once it has already generated invoices.

Closing

At LMNHUB we treat Zoho CRM and ERP integration as what it is: an engineering project over the data your accounting rests on. We agree the masters before touching code, build the synchronisation on external identifiers with nightly reconciliation, and document what every flow does so you depend on no one.

If you want the full picture of every Zoho connection, we cover it in our Zoho CRM integration guide.

And if you are weighing up connecting Zoho with Navision, Business Central, SAP or Oracle, tell us about your case and we will get back to you with a concrete approach and a senior team — not a generic quote.