ERP Integration

Common ERP integration problems

Integration problems usually look like operational problems at first. Sales says the customer was updated; finance says it was not. The online store shows stock that the warehouse does not have. Bank receipts sit unmatched because the gateway settles in batches with fees deducted. Typical root causes include:

• No agreed system of record. Customers or items can be edited in two places, so they drift apart.
• Point-to-point connections built ad hoc. Each one solved an urgent problem, but nobody has the full picture.
• Silent failures. A sync stops, nobody is alerted, and the gap is found at month-end.
• Mismatched data models. The CRM has one account with many sites; the ERP needs separate billing and shipping customers.
• Timing assumptions. Real-time sync where daily batches would do, or nightly batches where stock needs to be near real time.

These are design issues, not coding issues. That is why I start ERP integration work with the business rules and only then decide on technology. For a broader view of connecting systems beyond ERP, see my system integration service.

Master data ownership: deciding the system of record

Before any integration is built, each important data object needs a clear owner. The owner is the only system where that data is created and changed; other systems receive copies. A simple ownership matrix might look like this:

The right answer varies by business, which is why this is a workshop with sales, finance, operations and IT rather than a technical decision. Some objects, such as customers, may be split: the CRM owns relationship data while the ERP owns billing, tax and credit fields.

Once ownership is agreed, the rest follows: which direction each flow runs, which fields can be edited where, and how conflicts are resolved. I record these rules in the integration design so future changes do not quietly break them. If you are still choosing between CRM and ERP responsibilities, my article on ERP vs CRM explains the typical split.

APIs, webhooks and middleware: choosing the method

There is no single right way to integrate an ERP. The choice depends on volumes, timing needs, available connectors, internal skills and how many systems are involved.

• Native connectors. Many platforms, including Zoho, Odoo and Microsoft Dynamics 365, offer built-in or marketplace connectors for common tools. They are quick to set up but may not handle your edge cases, so I test them against real scenarios before relying on them.
• Direct APIs. Custom code calling each system's API gives full control. It suits a small number of well-defined flows, but every connection becomes something your team must maintain.
• Webhooks. Event-driven notifications, for example when an order is created or a payment is received, let systems react quickly without constant polling. They need careful handling of retries and duplicate events.
• Middleware or iPaaS. An integration platform sits in the middle, handles mapping, scheduling, logging and retries, and makes it easier to add systems later. It adds a subscription and another tool to manage, but often pays off once several systems are connected.
• File-based exchange. Still common and valid for bank files, payroll journals and some legacy systems, as long as it is automated and monitored.

I compare options on reliability, cost drivers, maintainability and who will support each one after go-live, then recommend a mix that fits your business rather than one approach everywhere.

Key integrations: CRM, eCommerce, banks, payroll and BI

Each integration type has its own details that are worth getting right in the design.

CRM. Decide the point at which a prospect becomes an ERP customer, whether quotes are created in CRM or ERP, and which order and invoice statuses flow back so sales can see payment and delivery progress. See CRM consulting for the CRM side of this design.

eCommerce. Agree how often stock and prices sync, how taxes, discounts and shipping charges map to ERP lines, and how returns and refunds are handled. Marketplaces often add their own fees and settlement cycles.

Banks and payment gateways. Bank feeds or statement imports support reconciliation; payment files support supplier runs. Gateways usually settle in batches net of fees, so the integration must split gross receipts, fees and payouts for clean matching.

Payroll. Most businesses post summarized payroll journals by cost center rather than individual payslips. The mapping of pay elements to accounts needs finance sign-off.

BI. Reporting tools need stable, documented data with agreed definitions of revenue, margin and stock value. I define those definitions with finance so dashboards match the ERP.

Each flow gets a specification: trigger, direction, frequency, field mapping, transformation rules, error conditions and the owner responsible for it.

Error handling, monitoring and testing

Every integration fails sometimes. A system is down for maintenance, an API limit is reached, a record has a missing field or a product code does not exist on the other side. What matters is whether anyone notices and how quickly the issue is fixed. I design for that from the start:

• Validation before sending, so obviously bad records are stopped and reported instead of half-processed.
• Retry rules for temporary errors, with limits so a broken record does not loop forever.
• Idempotency, so a repeated webhook or retry does not create duplicate orders or payments.
• Error queues and alerts sent to a named person or team, not to a shared inbox nobody reads.
• Daily control checks, such as comparing order counts or payment totals between systems.
• A runbook describing common failures and how to resolve them.

Integrations are tested as part of end-to-end business scenarios, not in isolation. An order placed online should flow through to the ERP, be picked, invoiced, paid through the gateway and reconciled in the bank, with each step checked. That testing sits within my ERP testing and UAT approach, and the integration design itself fits inside the wider ERP implementation plan.