ERP integration: connecting your ERP to the rest of the business
01 / Integration · ERP
The ERP is usually the system that holds the most truth in a company and has the fewest connections. Everybody reads from it, almost nobody is allowed to write to it, and so a layer of spreadsheets grows around it doing the work of glue.
How you recognize it from outside
The signal is always the same: someone exports a CSV out of the ERP every morning. Sometimes it is two people and two different CSVs. That file is an integration — it just happens to be run by a human, it never fails in any visible way, and nobody knows what happens the day that person is off sick.
Why
Why switching ERP doesn't fix it
The standard pitch is to migrate to a modern ERP that already comes integrated. The problem is that an ERP with years on it is not a program: it is the real logic of the business, with its exceptions, its strange discounts and its flows that nobody ever documented. Migrating means rediscovering all of that under pressure, with the operation still running. When the ERP works and the only thing missing is that it talk to the other systems, building that connection layer costs a fraction and puts nothing about next month's invoicing at risk.
Flows
The flows that have to be solved
Each one with the design decision that determines whether it survives production.
- 01
Inbound orders into the ERP
The order is created somewhere else —online shop, POS, marketplace, a rep on a phone— and it has to land in the ERP exactly once, with its lines, its taxes and its customer resolved correctly.
Where it breaks
Without an idempotency key derived from the external reference, a retry creates the order twice. It is the most common failure and the most expensive one to unwind.
- 02
Stock from the ERP out to the sales channels
The stock figure lives in the ERP and the website, the marketplace and the shop floor all need it. The design question is not how to copy it, it is how stale it is allowed to get and what you do with stock that is reserved but not confirmed.
Where it breaks
Publishing real stock with no reservation logic produces oversell during campaigns. Publishing a conservative figure leaves money on the table. It is a business decision wearing the costume of a technical one.
- 03
Invoicing and payment reconciliation
From order to invoice, and from payment to reconciliation. This is where the ERP touches the payment gateway, the bank feed and whatever currently stands in for the link between the two.
Where it breaks
The same payment arrives twice —once from the gateway, once from the bank statement— and without a stable reference on both sides it gets matched twice. Nothing crashes: a customer who still owes money is marked as paid, or a customer who paid gets chased. Reconciliation drifts quietly, and by the time somebody notices, the gap is months deep and has to be untangled by hand.
- 04
Reporting without touching production
Reports get built against a replica database or an analytical store, never against the database that is serving the operation.
Where it breaks
One heavy query fired at the production database at eleven in the morning blocks invoicing. This happens more often than anyone admits in public.
Delivery
What you get
- Map of the data flows between the ERP and every connected system
- Connectors with a queue, retry and idempotency per operation
- A data contract per flow: which fields, who decides, what happens on conflict
- Status dashboard with an alert on the age of pending items
- Integration documentation and hand-off to the internal team
Principles
How we build it
Idempotent by default
Every operation can be repeated without duplicating anything. That is what makes a retry safe, and without it no integration survives its first dropped connection.
Observable state
Every message has a state you can query: pending, sent, confirmed, failed. An integration you only notice when it breaks had already been breaking for a while.
One owner per field
For each field there is one system that decides and the others follow. Bidirectional sync without that rule ends in loops and in data that changes on its own.
AI where it judges, not where it calculates
Classifying, extracting and drafting are model work. Adding up, validating and routing are code work. Swapping them round is expensive and impossible to audit.
Method
How we work
The people who run the diagnosis are the people who build it. No hand-offs. The full method and the rest of the capabilities are on the systems integration page.
- 01 · 3–5 days
Diagnosis
We map systems, data flows and the dependencies that actually exist, including the ones nobody wrote down. Output: a closed scope and the list of what is broken today.
- 02 · 1 week
Integration design
Data contracts, direction of sync, retry policy and who owns each field. This is settled before any code gets written, because it is the expensive thing to change later.
- 03 · 2–6 weeks
Build and testing
Built against the real edge cases, not the happy path. Tested against the actual systems and rolled out in stages.
- 04 · ongoing
Production and observability
Status dashboard, alerts when something has gone too long without confirmation, and maintenance of the integrations when third-party APIs change under you.
- Node / TypeScript
- Queues with retry
- Supabase / PostgreSQL
- n8n
- Signed webhooks
- LangChain
- Docker
- Vercel
Related
Related to this case
What usually comes before or after, with the reason we link it.
APIs and webhooks
The plumbing underneath: how each connector handles retries, signatures and duplicate events.
02Digital X-Ray
When it isn't clear how many systems there are or which ones talk, the diagnosis comes before the connector.
03Legacy systems
If the ERP exposes no API and all you have is database access, the pattern changes.
04Implementation
How the connector layer actually gets built, tested against the real systems and rolled out in stages.
Questions
Questions about this case
Does the ERP need an API to be integrated?
It helps a great deal, but it is not a hard requirement. In order of preference: documented API, events or webhooks, read-only access to the database, and file exchange. Each step down adds work and fragility, and the last one requires agreeing a processing window. What is genuinely required is some controlled way to write: if the ERP is a sealed box with no entry point at all, the integration becomes a project with your vendor rather than with us.
Are you going to touch the ERP database?
Read only, and preferably against a replica. Writing directly into an ERP's tables bypasses its internal validations and produces data the application itself cannot interpret. When there is no write API, the right conversation is with the ERP vendor, not a hand-written INSERT.
How long does an ERP integration take?
Three to eight weeks including the diagnosis, depending on how many flows are in scope and how accessible the ERP is. What stretches these projects is almost never the connector: it is the business exceptions that surface once you look at real data —the customer who invoices under a different legal entity, the discount applied by hand, the order that splits into two delivery notes.
What if we change ERP next year?
Then it is worth designing the integration with that assumption on the table. A connector layer with explicit data contracts survives an ERP change far better than a pile of automations coupled to today's table names. It isn't free, but it is the difference between rebuilding one piece and rebuilding everything.
Your next project
Start with the diagnosis
Three to five days to know what gets connected first, with scope and price closed before a line of code is written.
Talk to a specialist