01 / Perimeter
Cluster: data integration
ERP and CRM integration: the two archives update each other
The ERP knows what you have invoiced. The CRM knows what you are negotiating. Until the two write to each other, somebody is the bridge by hand — and a salesperson finds out on the phone that the customer they are calling back is two invoices overdue.
Systems I work on most often
- SAP Business One
- Dynamics 365 Business Central
- NetSuite
- Odoo
- Sage
- Xero and QuickBooks
- HubSpot, Salesforce, Pipedrive
- Custom CRMs
This is not a closed list. If your system exposes an API, a reachable database or even a scheduled export, it can be integrated. Which route is viable is settled during the analysis, before quoting.
- What I deliver
- The synchronisation layer between the two systems, with the field mapping documented and the precedence rules written down in black and white.
- What I don't do
- In this engagement I don't touch the two systems and I don't sell you licences: if they work, they stay. What is missing is the connection.
- Indicative time
- An estimate, not a contractual commitment: three to eight weeks from analysis to the first flow in production, depending on how many entities are synchronised.
- Where I work from
- Italy, on Central European Time: a working day that overlaps with the whole of Europe, the UK and the first half of the US day. Remote by default, on site where the analysis needs it.
02 / Diagnosis
Why two archives always drift apart
Two archives holding the same fact will drift apart. It is a matter of time.
It takes no serious mistake: an address updated only in the ERP, a discount agreed only in the CRM, and from that moment the two versions of the truth no longer match. Nobody knows which one is right.
Double entry is not a time problem, it is a trust problem
Whoever enters the customer record twice loses a few minutes. The real cost comes later: when somebody has to decide and doesn't know whether to look at the CRM or the ERP, and so phones a colleague to confirm a fact the system should already have held.
Sales work from an old photograph
If payment status lives only in finance, the people selling don't know whether a customer is in good standing. At best they ask, and lose half a day. At worst they promise a delivery to a customer on hold, and they are the one who has to take it back.
An order passes through three pairs of hands before it becomes an invoice
Three human steps on a fact that was already structured the moment it was born.
Nobody notices until it becomes the customer's problem
A manual flow has no log. If an order is dropped, the news arrives from the customer who phones, not from the system. It is the kind of error that always surfaces at the worst possible moment.
Before and after, on the same processes
These are not results measured on clients: they are the process changes this integration produces, described for what they are.
| Process | Before | After |
|---|---|---|
| New customer | The record is created in the CRM by sales and rewritten in the ERP by finance. | Created once and propagated to the other system, with an explicit rule on who wins in a conflict. |
| Payment status | Sales phone finance before calling a customer back. | It is on the customer record in the CRM, updated by the ERP without anyone copying it. |
| Opportunity won | Somebody rewrites lines, quantities and discounts into the ERP. | The order is created by the flow with product codes and terms already correct. |
| Price lists and discounts | A shared file somebody updates when they remember. | Read from the ERP, which is the only place where they are decided. |
| Customer details changed | Updated wherever, with the two records drifting apart over time. | The change travels in the direction decided during the analysis, entity by entity. |
| A flow in error | There is no flow, so there is no error: there is a person who forgets. | The rejected record is logged with its reason and flagged to whoever can fix it. |
How an order travels today
03 / Solution
A layer in between, not a new system
A synchronisation layer between the systems you already run
Both systems already exist. I make them talk, and I write down who is right when they disagree.
Integration is not «connecting two pieces of software»: it is deciding, for every entity the two systems share, who creates it, who may change it, in which direction the update travels and what happens when two conflicting changes arrive. Those decisions are the hard part and they are taken with you, during the analysis, before I write a line of code. The code comes afterwards and is the easy part: it reads from one system, reshapes the data into the format the other expects, writes it, records what it did and retries if the destination doesn't answer.
Flusso dei dati
Field mapping, documented
Every source field ends up on a precise destination field, with the conversions declared: codes, units of measure, tax rates, date formats. The document is yours, and it is what lets another supplier understand the flow without calling me.
Explicit precedence rules
For each entity we decide which system is the source of truth. If both can write, we settle what happens in a conflict: last write wins, one system wins, or the case goes into a queue a person looks at.
Idempotency and retries
A flow that runs twice must not create two orders. Every record travels with a key that makes it recognisable, so a retry after a network error updates instead of duplicating.
Readable logs and alerts
Every run leaves a trace: what went through, how many rows, which rejects and why. When something breaks, the alert reaches a person rather than sitting in a file nobody opens.
Typical ERP–CRM integration cases
- SAP Business One or Dynamics 365 Business Central connected to the CRM with customer records aligned both ways and a clear rule on who creates the customer
- Xero or QuickBooks updating payment status on the CRM's customer records on their own
- Odoo or Sage kept in step on price lists and customer-specific discounts, read where they are decided
- Orders created in the ERP from won opportunities, with product codes already validated
- E-commerce platforms such as Shopify or WooCommerce aligned with the ERP on products, stock and orders
- An ageing report that shows sales the credit risk before the negotiation rather than after it
04 / Specifications
What can be done, and on what terms
The specifications, before the promises
What follows is what decides whether an integration is simple or complicated. They are the same questions I will ask you in the first half hour.
Access to the data
- REST/SOAP APIs
- The best route: structured data, authentication handled, near real-time updates if the system exposes webhooks.
- Database
- Viable for reading where the vendor allows it. For writing it is judged case by case: writing underneath the application can break its own constraints.
- Files and SFTP
- Scheduled exports and imports as CSV or XML. It always works, but real time is lost: the frequency is the scheduler's.
- None of the three
- Interface automation is considered as a last option. It is fragile, and I tell you that before the quotation rather than after.
How the flow behaves
- Direction
- Decided per entity: one-way or two-way. Which system wins in a conflict is always established.
- Frequency
- From near real time on webhooks to a sync every N minutes or overnight, depending on how fresh the information needs to be.
- Typical entities
- Customer and supplier records, products, price lists, orders, documents, due dates and payment status.
- Volumes
- The flow works incrementally: after the first alignment only changed records move, so the load stays low.
Reliability
- Errors
- A bad row does not stop the flow: it is rejected, logged with the reason and flagged to a person.
- Duplicates
- Every record travels with a stable key. A re-run updates, it does not duplicate.
- Auditability
- A log of every run, readable by you: what went through, when, how many rows, which rejects.
- Test environment
- The flow is proved on real data in a separate environment before it touches production.
Ownership and continuity
- Code
- Source and documentation handed to you. No encrypted components, no licence that forces you to stay.
- Infrastructure
- In your name. The credentials are yours from day one, not mine with a delegation.
- Changing ERP
- The logic sits in the integration layer, not inside the ERP: when you change system you rewrite the connector, not everything else.
- Data residency
- Hosting can be pinned to an EU region, or another region if your own rules require it, with what is logged and for how long written into the architecture document.
Included in an integration project
- Process analysis and a map of the data flows between the two systems
- An architecture document with the field mapping and the precedence rules
- Development of the synchronisation layer, testing and code review done by me
- Error handling with readable logs and alerts that reach a person
- A gradual release, with the manual process still running as a safety net
- Technical documentation, handover of code and credentials, and an agreed post-release support period
Not included, and I say so up front
- Licences for the ERP and the CRM, and subscriptions to any third-party services
- Hosting and infrastructure, which stay in your name
- Replacing either of the two systems: that is not this engagement, and it is a project in its own right
- Clean-up of dirty historical data beyond what the flow needs, unless agreed separately
- Work on the vendor's own software when it is they who must enable an access route
- Any promise of a financial result: it cannot be guaranteed and I don't make it
05 / Route
Four phases, three of them mine
How you get from the problem to a flow in production
The durations are estimates to help you plan, not contractual commitments. The variable that moves the dates most is not the code: it is how long access and answers take to arrive from the vendor of your ERP.
- 01
Analysis
I look at how people actually work and where data is retyped. I check what the two systems really expose, not what the brochure says.
- Cosa ricevi
- A map of the flows, a list of the entities to synchronise and the hours of manual work involved.
- Durata
- 1–2 weeks (estimate)
- 02
Architecture
Field-by-field mapping, direction for each entity, conflict rules, frequency. I also document the limits: what will not be possible, and why.
- Cosa ricevi
- An architecture document with diagrams, limits and a release plan.
- Durata
- 1–3 weeks (estimate)
- 03
Development
We start from the entity that costs the most manual work, not the easiest one. At every milestone there is a flow you can try on real data.
- Cosa ricevi
- Milestones you can try in a test environment, one entity at a time.
- Durata
- Varies by project
- 04
Code review and release
Every line passes through my review. The release is gradual, and the manual process stays live until the flow has proved itself on your data.
- Cosa ricevi
- The flow in production, logs running, documentation and credentials handed over.
- Durata
- 1–2 weeks (estimate)
One thing worth agreeing before we start: who talks to your ERP vendor. Credentials, sandbox access and API documentation almost always come from them, and a request that travels through your own account manager moves faster than the same request from an external supplier they have never heard of. It is the single cheapest way to protect these dates.
06 / Frequently asked
The same ones I get on the phone
Questions about integrating an ERP and a CRM
Here are the answers to what nearly everyone asks in the first half hour. If yours is missing, write to me.
01Our ERP has no API. Can it still be integrated with the CRM?
Almost always yes. APIs are the best route, not the only one: you can read the database where the vendor allows it, work on scheduled file exports and imports, on feeds dropped on SFTP or into a mailbox. What changes is the quality of the result: with files you lose real time and the sync becomes periodic. If a route is too fragile to be honest about, I tell you during the analysis, before quoting.
02Is the integration two-way, or does it go one way only?
It is decided entity by entity, not for the project as a whole. Customer records often travel both ways while payment status goes only from the ERP to the CRM, because the ERP is where it is decided. The real question is not «two-way, yes or no», it is «when the two systems disagree, who is right»: that answer goes into the architecture document, and it is the part that prevents the problems that surface six months later.
03What does an ERP–CRM integration cost?
I have no price list, and I would be wary of anyone who has one for bespoke work. Four things set the price: how many systems are touched, how the data is reached, how many entities are synchronised and in which direction, and whether users also need an interface. After the analysis you get a fixed figure for the project, not an open hourly rate. If the analysis shows the spend makes no sense against what the manual work costs you today, I tell you and we stop there.
04How long until the first flow is in production?
As an estimate and not a commitment: three to eight weeks from the analysis, when both systems expose usable APIs. The variable that moves the dates most is rarely the development: it is how long the ERP vendor takes to release credentials and documentation. The real dates are set at the end of the analysis, when we know what is actually inside the systems.
05What happens if an order doesn't go through?
The flow does not stop. The row that fails is rejected, logged with the reason and flagged to a person, who fixes it at source and lets it through again. The point is that the system finds the error, not the customer phoning three days later. Every run leaves a readable log, so what went through and when can always be reconstructed.
06Could we lose data during the first alignment?
The first alignment is run against a copy, not against production. We start read-only, compare the results with what is already there, and only enable writing when the numbers match. During the release the manual process stays live as a safety net: it is switched off when the flow has proved itself on your data, not on the day of delivery.
07What if we change ERP in two years?
That is exactly why an integration is built in layers. The logic of your processes lives in the synchronisation layer, not inside the ERP: when you change system you rewrite the connector to the new one, not everything else. That point is explicit in the architecture document, so you know in advance what a change would cost and what it would not.
08Our Italian subsidiary runs a local ERP. Can you work on it?
Yes, and it is one of the few places where being based in Italy is a practical advantage rather than a detail. TeamSystem, Zucchetti, Danea and Arca are systems I work on regularly: their documentation, their support and their partner network are in Italian, which is the usual reason an integration involving an Italian subsidiary, supplier or distributor stalls. On the group side the CRM stays whatever you already run — the flow simply has one more connector.
09Where does the data that crosses the flow live?
In your systems. The synchronisation layer holds as little as it can: enough to recognise a record between one run and the next, and the logs needed to reconstruct an execution. The infrastructure it runs on is in your name and can be pinned to an EU region, or another region if your own rules require it. Where personal data is involved the flow is designed to carry the minimum needed, which is both a GDPR requirement and the simplest way to keep the system small.
07 / Related
Where to go next
Pages connected to this one
This integration is a specialisation of custom software: if the problem in your head is broader, start from the parent page.
08 / Contact
Half an hour, no automated quotation
Tell me which two systems need to talk
There is no automated quotation to generate, and I won't send you a brochure. We spend half an hour: you tell me which systems you run and where the data is retyped, I tell you whether the integration is viable, by which route and whether the spend makes sense. If the answer is no, I say so straight away.
Or write to me: I answer, usually within one working day.
All the contact detailsHow the call works
- Length
- Thirty minutes, video call or phone, in English.
- Who is there
- Me. No salesperson, no handover afterwards.
- What I need
- To know which ERP and which CRM you run, and which data is retyped by hand today.
- What you get
- An honest view on feasibility and order of magnitude. The quotation comes after the analysis, not before.