Insight
What an ERP integration project needs before development starts
27 May 2026
- ERP
- Integration
- Operations
ERP integrations are often described as a list of objects: customers, products, stock, orders, invoices. That list is useful for estimating API work. It says very little about whether the connected process will survive normal business activity.
Before development starts, the team needs answers to a more awkward set of questions.
Which system is allowed to be right?
“The data should stay in sync” is not an ownership rule. If a customer changes a delivery address in a portal while an administrator changes it in the ERP, one system must win or a person must resolve the conflict.
Decide ownership field by field where necessary. The ERP may own invoice details and credit status. The customer application may own marketing preferences and a draft basket. Product descriptions might come from a catalogue system while prices remain in the ERP.
This mapping feels slow compared with writing the first API call. It prevents much slower arguments after records begin overwriting one another.
Write down what happens to a bad order
A clean demonstration usually uses an active customer, an in-stock product, and a price that exists. Production brings discontinued items, expired discounts, credit holds, duplicate customer accounts, and orders submitted while the ERP is unavailable.
For each important failure, decide what the user sees and what operations can do. Should the order wait and retry automatically? Can staff correct a mapping and continue it? Does the customer need immediate confirmation, or is “received for review” more honest?
Do not send every problem to a generic technical log. The people operating the process need a small reconciliation view that uses their language and shows what action is possible.
Use real records early
Test systems are often much cleaner than production. Ask for a representative export early in discovery, with sensitive fields removed where appropriate. Look for old identifiers, inconsistent units, missing tax data, manual notes, and products that should not appear in a customer channel.
The purpose is not to clean the whole ERP before a project can proceed. It is to find the assumptions the new application must not make.
One useful exercise is to follow several recent orders from the original request through fulfilment and invoicing. The route through the business may differ from the documented process, especially when something changed after submission.
Agree on the operating responsibility
After launch, somebody needs to know whether an integration is healthy. That does not require a wall of monitoring charts. It does require answers to practical questions:
- Who receives an alert when jobs have failed for an hour?
- Who can safely retry or cancel a record?
- How can finance confirm that yesterday’s invoices all arrived?
- How long is integration history kept?
- Who contacts the ERP vendor when its behaviour changes?
These responsibilities can belong to the client, the delivery partner, or both. Leaving them implicit is what turns a manageable API problem into a recurring operational surprise.
The first development task should begin after these decisions are visible. The code will still encounter unexpected cases. It will encounter fewer cases for which nobody knows the correct business answer.