Decide this before writing any code
For every field that exists in both systems: which one is authoritative? Integrations do not usually fail on technology. They fail because nobody decided who wins when both sides changed the same record.
Connecting Zoho to an ERP or accounting system removes double entry and gives sales visibility into what finance sees. It also creates a permanent dependency between two systems that were designed independently.
Direction and ownership
| Data | Usual master | Direction |
|---|---|---|
| Leads, opportunities | Zoho CRM | CRM only |
| Customer master | ERP | ERP → CRM |
| Products and pricing | ERP | ERP → CRM |
| Orders | ERP once confirmed | CRM → ERP, then ERP → CRM for status |
| Invoices and payments | Accounting | Accounting → CRM |
| Stock availability | ERP | ERP → CRM |
Bidirectional sync on the same field is where integrations go wrong. If both systems can edit a customer's address, you need conflict resolution — and every rule you invent will be wrong sometimes. Making each field one-directional wherever possible eliminates an entire category of problems.
The five hard problems
- Identity matching. The same customer exists in both systems with different names, spellings and IDs. You need a reliable key, and creating one is often the first real task.
- Conflict resolution. Both sides changed the same record. Last-write-wins loses data silently.
- Failure recovery. The ERP was down for an hour. What happened to everything that should have synced?
- Partial failure. The order synced, the line items did not. Now the ERP holds an order for nothing.
- Reconciliation. How do you prove, on any given day, that the two systems agree?
The reconciliation report is the piece most often skipped and most often needed. Without it, divergence is discovered by an angry customer rather than by you.
Architecture that survives contact with reality
- A queue between the systems so an outage delays rather than loses.
- Idempotent operations — the same message processed twice must not create two orders.
- Retry with backoff on transient failures.
- A dead-letter path for messages that keep failing, with someone responsible for reviewing it.
- Structured logging of every sync attempt, searchable by record.
- A daily reconciliation report naming records that disagree.
- Alerting on failure to a person, not a log file nobody opens.
Idempotency is worth insisting on. Retries, duplicate webhooks and manual re-runs all happen. If processing the same event twice creates a duplicate order, you will eventually find out from finance. An external reference key on the ERP side, checked before creating, prevents it entirely.
Scoping honestly
| Scenario | Typical effort |
|---|---|
| One-way sync, modern API both ends, few fields | 2–4 weeks |
| Order flow with status return, clean data | 5–8 weeks |
| Multi-entity sync with custom objects | 2–4 months |
| Legacy ERP without a usable API | Adapter first, then the above |
| Data cleanup before any of it | Frequently the largest item |
The data cleanup row is not a formality. If neither system has a reliable customer key, establishing one across existing records is genuine work and it must happen first.
A sequence that de-risks it
- Map the fields and decide ownership — on paper, signed off by both finance and sales.
- Establish matching keys and clean the existing data.
- Build one direction, read-only, for one entity. Prove it.
- Add the reconciliation report before adding more entities.
- Add write operations with idempotency, one entity at a time.
- Run in parallel with manual process for a period before switching off double entry.
Signs an integration is in trouble
- Nobody can say which system is right when they disagree.
- Failures are found by users rather than alerts.
- Manual fixes are applied routinely and undocumented.
- There is no way to replay a failed sync.
- Both systems can edit the same field.
Planning a Zoho–ERP connection, or repairing one that drifts? Tell us which systems and what data. See our Zoho service, Deluge guide, and integration strategy.