1. What we actually solve
Four problems that almost always show up together:
- “The same data lives in four applications and nobody knows which one is right.” The ERP says one thing, the CRM another and the sales rep’s spreadsheet a third. Discrepancies give no warning: they surface on the day a decision has to be made.
- “We copy and paste between systems every day.” Mechanical work done by expensive people, with the transcription error included in the price.
- “The data reaches where it is needed too late.” It updates when somebody remembers to export, not when the data changes.
- “Every report gives a different number.” Because each one was fed from a different source at a different moment.
2. How it works
The integration is built around the systems you already have, and connects wherever each one allows: API, database access or file exchange. If one of them exposes none of the three, we say so before starting and not halfway through the project.
What separates an integration that holds from a script that breaks every fortnight is three things you do not see in the demo:
- Retries without duplicating. Connections fail: the network drops, the ERP is in maintenance, the API returns a temporary error. The synchronisation has to be able to repeat without creating the order twice.
- Reconciliation of discrepancies. When the two systems do not agree, the data is neither forced through nor silently discarded: it lands in a queue with both versions for a person to decide. That queue is what stops you discovering the mismatch three months later.
- A log of what moved. What was read, what was written, when and with what result. Without that, the first argument about an odd figure has no way of being settled.
Put side by side, the change is easier to see. Notice that the data is born in the same place and ends up in the same place: what disappears is the step in the middle.
- The data is born in one systemAn order in the ERP, a contact in the CRM
- Somebody exports it and types it inWhenever they remember, and however they understand it
- It reaches the other systemLate and, sometimes, different
Discrepancies give no warning: they surface on the day a decision has to be made with that data.
- The data is born the same wayNobody changes system or habits
- The sync picks it upBy API, database or file, whichever the system allows
- It is reconciled and retriedIf something fails, it repeats without duplicating
- It reaches the other systemWithin minutes, with a record of what moved
↳ Whatever does not match is neither forced through nor silently discarded: it lands in a discrepancy queue with both versions of the data, for a person to decide.
Nobody exports anything. And when somebody asks which figure is the right one, there is an answer.
Both paths run at the same time and on the same time scale: the top one is still on its second step when the bottom one has already finished and is waiting. The proportions are illustrative — what we claim is that one takes considerably longer than the other, not exactly how much longer in your case.
3. What we do NOT do with your ERP
Worth saying early and plainly: we are not specialists in any particular ERP and we do not claim to be. We have integrated with the usual ones in the industrial world, but what we know how to do is talk to the one you already have — read, write and synchronise — not configure or parameterise it from the inside.
That means we are not going to touch your chart of accounts, your approval flows or your warehouse setup. That is what your implementation partner is for, and we work alongside them without any friction: in fact, projects go better when they are in the conversation from the start.
If somebody offers you both the integration and the parameterisation of your ERP, ask them about the second one in detail. It is a different speciality and it shows quickly.
4. Typical cases
Our clients are currently in manufacturing — discrete and process: automotive, food and drink — which is where our track record is. The others are patterns that repeat in any sector.
Manufacturing: automotive, food and drink
Production data lives in the shop-floor system and invoicing in the ERP, and somebody cross-checks them by hand at every close. The close depends on one person and on a file only they know how to build.
Production and ERP synchronise on their own, and the close moves from being assembled to being reviewed.
Sales and operations
The CRM and the ERP hold the same customer with different data: address, terms, credit risk. The sales rep promises a price the ERP does not recognise, and the problem shows up on the order.
A single origin for each field, with reconciliation of whatever does not match instead of blind overwriting.
Administration
Reports are fed by manual exports taken at different moments. Every report gives a different number and the meeting argues about the figure instead of the decision.
They all drink from the same synchronised source, so the conversation goes back to what to do.
5. What you need before we start
- Systems that let you in. An API, database access or a scheduled export. One of the three is enough; with none of them there is no project and that has to be said.
- Credentials, and permission to use them. It sounds obvious and it is what most often delays the start, especially when the system is maintained by a third party.
- Knowing which system is the reference for each field. If price is governed by the ERP and contact details by the CRM, that has to be decided first. It is a business decision, not a technical one, and we cannot take it for you.
- Somebody who knows what each field means. Half the problems in an integration are about meaning, not connection.
- Tolerance for things sitting in a queue. There will always be discrepancies; what matters is that somebody looks at them.
6. When this is NOT the answer
- You are changing ERP in the next few months. Integrating what is about to disappear is throwing money away. Better to wait and design the integration against the new system.
- The volume is low. If it is five records a week, copying them by hand is cheaper than maintaining a synchronisation.
- Nobody wants to decide which figure is right. Without that decision, the integration only spreads the disagreement faster.
- The real problem is the process, not the systems. If the data arrives wrong because nobody knows who should enter it, integrating two systems does not fix it: the process has to be sorted out first.
7. How the return is measured
- Hours per month that stop going into exporting, typing and reconciling, with their equivalent cost.
- Discrepancy rate between systems, before and after. It is usually the number that surprises people most when it is measured for the first time.
- Data latency: how long a change takes to be available where it is needed.
- Errors avoided and what each one used to cost: rework, credit notes, wrongly served orders.
The full framework is in how the return is measured in the guide. And if the data moving around is personal data, the applicable obligations are on the AI compliance page.
Note: this page is for information only; it is not legal advice nor a guarantee of results. The figures quoted are usual ranges in real projects, not contractual commitments, and they depend on the scope and the starting point of each company.
8. Frequently asked questions
Which ERPs and CRMs do you integrate with?
With the one you already have, through whatever it allows: API, database or file exchange. And the usual clarification: we are not specialists in any particular ERP and we do not claim to be. We know how to talk to yours — read, write and synchronise — not to parameterise it from the inside; that is your implementation partner’s job and we work alongside them without friction.
Does the system need to have an API?
Not necessarily. With database access or a scheduled file export a solid synchronisation can also be built. What cannot be done is integrate a system that lets you in through none of the three routes, and that is checked before anything is quoted rather than halfway through the project.
What happens if the synchronisation fails halfway?
It retries without duplicating. Connections fail by definition — the network drops, the ERP is in maintenance, the API returns a temporary error — so the synchronisation is designed to repeat without creating the same order twice. And whatever does not match is neither forced through nor silently discarded: it lands in a discrepancy queue with both versions of the data for a person to decide.
How often does the data synchronise?
It depends on what it is used for. If the data drives an operational decision, within minutes or on every change; if it feeds a daily report, once a day is enough and cheaper to maintain. Synchronising everything by the second because it sounds better is an expensive way of not deciding.
Can you integrate with an old or custom-built system?
Usually yes, and it tends to be the most frequent case in manufacturing. Old systems rarely have a modern API, but almost all of them allow their database to be read or files to be dropped in a folder, and that is enough. We check before committing to anything.
Who maintains the integration afterwards?
It can stay with your team or with us, and that is decided before it is built, because it changes how it is built. If your people are going to maintain it, it is written in the language they already use and documented for that. An integration only the person who built it understands is a dependency, not a service.
Services that usually go with this one: process automation · advanced analytics and BI.