Integrating your ERP with marketing without breaking the ERP
Read-only first, the middle layer that prevents the tangle, the four problems you will actually hit, and the five things never to do.
Every serious marketing project reaches the same place eventually: the data that matters — what was sold, to whom, for how much — lives in the business system, and the business system talks to nothing.
Connecting it is one of the highest-return things you can do, because it closes the loop between spend and revenue. It is also one of the easiest to get wrong, because on the other side sits a system the company depends on to invoice.
Why the ERP is not one more integration
Connecting an email tool to a CRM is reversible: if something breaks, disconnect and start again. The business system does not have that property.
- It is the system of record. What it says is what the company considers true. A badly written value is not a marketing bug: it is an accounting problem.
- It is usually old and alive. Many have run for years, with customisations nobody documented that daily processes depend on.
- It was not designed for constant traffic. It was designed for a handful of people entering operations. An enthusiastic integration can degrade it for everyone.
- Nobody wants to be the one who broke it. And that aversion, properly understood, is what should govern the integration’s design.
Read-only first, always
The first version writes nothing. It reads — and that alone delivers most of the value: knowing which of your leads bought and for how much is exactly what is needed to close the conversion loop and to compute a real CAC.
That first stage also buys something you cannot buy any other way: trust.
- Read for a few weeks and compare against what people see on their screens.
- The real inconsistencies surface, and they are always different from the expected ones.
- Only with that settled do you discuss writing.
Skipping this is the project’s most expensive mistake. Writing against a data model you do not yet understand produces duplicate records somebody later cleans up by hand.
The four problems you will actually hit
| Problem | How it shows up | How to handle it |
|---|---|---|
| API without webhooks | You have to ask periodically instead of being told | Scheduled sync with a watermark, not a full pull |
| Inconsistent fields | Empty or zeroed dates, text where a number should be | Validate in the middle layer and discard what fails, with a log |
| Concurrent writes | Two processes touch the same record and one overwrites the other | One writing path only, and search before create |
| Maintenance windows | The system stops responding during closing hours | Retries with backoff and a queue that loses nothing |
The API without webhooks is the most common. It forces periodic polling, and there is a trap there: pulling everything each time becomes unsustainable as soon as the table grows. The right shape is a watermark — “give me what changed since last time” — stored and advanced only once processing finished cleanly. Advance it early and an error leaves a gap nobody will notice.
Inconsistent fields produce the longest surprises. Business systems with years behind them accumulate empty or zeroed dates, text fields where someone typed a comment, and records loaded three different ways depending on the era. The rule that saves you: validate in the middle layer and discard what fails while logging it. Discarding silently is how data disappears without anybody noticing.
Concurrent writes appear when there is more than one path to the same record: the integration, a person entering data by hand, and possibly an old automation nobody remembers. The discipline is boring and it works: one writing path, and always search before create.
The layer in the middle
The temptation is to connect the ERP directly to every tool that needs it. With two tools that seems reasonable; with five it is a tangle where nobody can say what touches what.
A middle layer — a small service, your own database, an automation flow — solves four things at once:
- The ERP has one consumer, not five.
- Validation and normalisation live in one place.
- You can reprocess without bothering the business system again.
- Swapping a marketing tool does not touch the ERP.
That last point is the one you appreciate two years later, when the CRM changes and it turns out the integration does not have to be rebuilt.
What not to do, ever
- Write straight into the database. You bypass the system’s logic: validations, calculations, history. It works until it does not, and by then the data is inconsistent.
- Automate clicks on the interface. It breaks with the next update, and it breaks silently.
- Use somebody’s personal login. Nothing is traceable and everything falls over when that person changes their password or leaves.
- Test in production. Obvious, and yet it is what happens when there is no test environment and the project has a date.
- Leave it unmonitored. A dead integration does not announce itself: it simply stops bringing data, and the reports show fewer sales without saying why.
FAQ
- My ERP has no API. Is it hopeless? No, but the options get worse in a predictable order: a scheduled export, a read-only view on the database, or a file drop. All three work. What does not work is automating clicks on the interface, which breaks with the next update.
- Can we write straight into the ERP? Eventually, and never as the first step. The system of record is where the business keeps its truth; earning write access means first proving you read it correctly for a while.
- Should the integration be real time? Rarely. Marketing decisions are made daily at best. A scheduled sync every few hours is more robust, easier to re-run and far cheaper than pushing a system that was never designed for constant traffic.
- Who owns the integration once it works? Someone has to, by name. Integrations break when a field is renamed or a version changes, and an ownerless integration fails silently until somebody notices the numbers stopped moving.