ERP integration means connecting your ERP to the other systems your business runs on (online store, CRM, banks, carriers, BI) so data flows between them automatically. On paper it sounds easy ("just get the ERP talking to the online store"). In practice it can spiral out of control within three weeks if you are not clear on which system owns each piece of data, which one writes it first, and what happens when a customer changes their tax ID halfway through an order. At Interconecta we have spent years stepping into companies that had already tried to connect their ERP to other systems two or three times. The problem is almost never technical. It is about judgment.
In this article I walk you through eight real-world scenarios, the ones that come up most often in Spanish SMEs, with the approach we usually take, the usual traps, and when enterprise middleware is worth it and when it isn't. The goal is not to sell you hype. It is to help you walk into the meeting with your IT person or your vendor knowing exactly what to ask.
I'll cover SAP, Holded, Odoo, Sage, Salesforce, PrestaShop, WooCommerce and a few smaller CRM systems. Whichever one you use, the patterns repeat. If your ERP isn't on the list, the same principles still apply.
Before you integrate anything: three questions that save you headaches
If I called you tomorrow and said "let's integrate your ERP with your CRM", the right first answer would not be "sure". It would be: "hang on, what for?" It sounds obvious, but half of the ERP integration projects we see fail because nobody sat down for 45 minutes to answer three basic questions.
First: which system holds the master data? In other words, if a customer has one address in the CRM and another in the ERP, which one wins? It sounds trivial, but it isn't: it shapes the whole architecture. Second: how often does the data need to update? Syncing stock every 5 minutes is very different from pushing orders in an overnight batch. The cost difference can be anywhere from 3x to 10x.
Third: what happens if the integration goes down? If your online store keeps taking orders but the ERP doesn't receive them for two hours, will you handle that manually, or do you need a queue with automatic retries? The answer completely changes the kind of enterprise middleware you will build.
80% of the failed integrations we have inherited from clients had one thing in common: nobody had defined which system was the master for each piece of data.
Before you touch a single line of code, sit down with the people who use each system every day and write this down on a sheet. If you aren't sure who to ask, that is already the project's first red flag.
Scenario 1: ERP + ecommerce (the classic everyone wants done right)
This is the most common case and, ironically, the one where SMEs stumble the most. You run Holded, Odoo or Sage 50 and a store on PrestaShop or WooCommerce. You want orders to flow into the ERP on their own, stock to flow back the other way, and invoices issued in the ERP to be marked as paid in the store.
What usually works
An off-the-shelf connector can cover catalogs and simple flows. Before you sign up, check which platforms it supports, the subscription terms and exactly which data it syncs.
When it gets complicated
When you sell through a configurator (size + color + custom engraving), when you use customer-specific price lists, or when you run more than one warehouse with stock reservations. That is where the standard connector falls short and you need custom development. If you want to dig deeper, see our guide on how to integrate your ERP with your ecommerce store, with concrete cases.
An aesthetic clinic in Murcia we work with sold treatment packages online and treatments in the clinic. Stock was not an issue (there was no physical product), but a package bought online had to show up as available in the clinic's booking calendar in under a minute. A generic connector can't do that: we had to build two-way webhooks and a Redis queue to make sure no package was ever lost.
Scenario 2: ERP + CRM (the day sales and finance start talking)
The pattern here: sales reps log opportunities in HubSpot, Pipedrive or Salesforce. When a deal is won, the customer has to be created (or updated) in the ERP, the order generated and the billing cycle started. And the other way round: paid invoices have to flow back to the CRM so reps know who is up to date on payments and who isn't.
The most common mistake here is duplicate customer master records. A rep creates "Construcciones López SL" in the CRM, finance already had it as "CONSTRUC. LOPEZ S.L." in the ERP, and two weeks later you have two records and nobody knows which one is right. The fix is to use the tax ID (CIF/NIF in Spain) as the unique key and block new records that fail that check.
SAP–Salesforce integration case
In organizations with several systems, integrating SAP and Salesforce may call for enterprise middleware. The right choice depends on the applications involved, the approval workflows and who owns each piece of data.
To sync contacts and opportunities, a tool like Zapier or Make may be enough. If you also need price lists, discounts and approvals, consider an integration that covers those business rules.
Scenario 3: ERP + e-invoicing and the Spanish Tax Agency (Veri*Factu and what comes next)
This is no longer optional in Spain. With the phased rollout of the "Crea y Crece" law and Veri*Factu, Spain's new invoicing compliance system, every invoice issued by a Spanish company must meet requirements for integrity and traceability and, depending on the timeline, be sent immediately to the Spanish Tax Agency (AEAT). If your ERP isn't ready or isn't connected properly, you risk fines starting at €6,000 per breach.
The big ERPs (Sage, SAP, Holded, Odoo, A3) are releasing certified modules. Custom-built and older ERPs need someone to add that layer. The usual pattern: the ERP generates the invoice, a middleware module converts it to Facturae 3.2.2 (Spain's e-invoice format) or whatever format the AEAT requires, signs it with a digital certificate and submits it. The response comes back and is recorded in the ERP.
Watch out for a detail that often slips through: GDPR. If you send customer data to a cloud-based middleware, make sure the provider is in Europe or has signed Standard Contractual Clauses (SCCs). This isn't paranoia: the Spanish Data Protection Agency (AEPD) has already fined SMEs for not having this formalized. If you want to see in detail how we approach these API and systems integration projects, that page covers the services we offer.
Scenario 4: ERP + logistics and carriers
SEUR, MRW, GLS, Correos Express, NACEX. Each with its own API, label system and quirks. The typical flow: when an order moves to "ready to ship" in the ERP, you request a pickup from the carrier, receive the tracking number, print the label and send the customer the tracking link by email or WhatsApp.
If you work with several carriers (and you should, for price and risk reasons), building this one integration at a time turns into a nightmare. The smart move is usually a shipping aggregator such as Sendcloud, Packlink Pro or Outvio: they give you a single API and you route shipments with rules (weight, postcode, order value). The ERP only talks to one system.
What we almost always forget
- Returns. Hardly any standard connector handles the reverse flow well, so it ends up being manual.
- Delivery exceptions. If the driver marks "not at home", what happens in your ERP? Does it get reassigned to customer service?
- Carrier invoices. If they arrive as PDFs, someone keys them in by hand. If they arrive via EDI or API, you save 4–6 hours a month per carrier.
In companies shipping more than 100 parcels a day, automating the matching of carrier invoices against orders usually pays for itself in under 6 months. It's one of those quick wins almost nobody tackles first because it isn't "sexy".
Scenario 5: ERP + banks (reconciliation, Bizum and SEPA)
Bank reconciliation means downloading bank transactions and matching them against invoices. Check which APIs or file formats your bank offers, and the terms of any banking aggregator, before you design the integration.
Second, generating and sending SEPA batches (direct debit collections and supplier payments). Any serious ERP can generate them, but be careful with mandates: if you don't have them signed and on file, the bank can reject the batch and the customer can claim the money back.
Third, Bizum (Spain's mobile payment system) and instant payments. This area is evolving fast. Bizum for businesses works through a payment gateway, and the ERP integration usually runs through the bank's virtual POS. If you sell lots of small tickets (hair salons, hospitality, freelancers and sole traders in general), automatically posting Bizum payments to your accounts saves hours.
Good automatic bank reconciliation is probably the fastest ROI you'll get from any ERP integration: in an SME issuing 200 invoices a month, it saves the finance team 4 to 8 hours a week.
Scenario 6: ERP + manufacturing, IoT and production
If you have a plant, however small, this scenario applies to you. The classic pattern: machines (CNC, packaging lines, ovens) produce production data that someone currently writes down by hand or in an Excel sheet. Connecting that data to the ERP lets you close production orders with real figures, not estimates.
How complex it gets depends on the age of the machines and their protocols. Machines that support OPC UA or MQTT are easier to connect; older equipment may need gateways and dedicated work.
This is where enterprise middleware really makes sense: you don't want your ERP talking directly to a Siemens PLC, because if the ERP goes down production stops, and vice versa. The usual setup is an MES (Manufacturing Execution System) layer or an MQTT broker in the middle that decouples both sides. If you want to see how we approach ERP and business management systems in industrial environments, that's the place to start.
Scenario 7: ERP + BI and reporting (when management wants the full picture)
At some point the ERP's built-in reports aren't enough. The managing director wants margins by product family, broken down by sales rep and marketing campaign, and the ERP simply can't produce that, no matter how hard you try. Here the integration runs one way only: from the ERP (and other systems) into a data store that Power BI, Looker Studio or Metabase query.
Recommended pattern for SMEs
- Nightly extraction from the ERP into a data lake or analytical database (PostgreSQL, BigQuery, or Snowflake for larger volumes).
- Transformation with tools like dbt or, if volumes are small, simply with SQL views.
- A visualization layer in Power BI (the most widespread in Spain) or Looker Studio if you want something free and good enough.
The budget for a reporting system depends on the data sources, the data model and hosting. Avoid querying the production ERP directly: a separate data layer reduces the impact on day-to-day operations.
Scenario 8: ERP + AI and automation (already gaining ground fast)
The last scenario is the newest and the fastest-growing. You connect the ERP to AI models to automate tasks a person does today: reading supplier invoices in PDF and entering them into the ERP with OCR + an LLM, classifying support tickets, forecasting product demand to adjust purchasing, or suggesting customer discounts based on purchase history.
The typical pattern: the ERP exposes an API or an event ("a PDF has arrived in the purchasing inbox"), a serverless function (Azure Functions, AWS Lambda) picks up the document, runs it through an OCR service + an LLM with a tuned prompt, returns structured JSON and writes it to the ERP, optionally after human review.
The important part: always keep a human in the loop at first. Never let the AI write straight to production without someone reviewing it during the first few weeks. Measure the hit rate, refine the prompt or retrain the model, and once you are above 95% on standard invoices, you can switch to approval by exception.
To budget an invoice automation pilot, you need to assess document volume, OCR quality and the ERP connection. Keep implementation costs separate from API usage and measure how much time human review takes.
An ERP integration needs planning and a solid understanding of your processes. Sometimes a scheduled export is enough; other times you need continuous sync. Define the need first, then the architecture.
If you are considering connecting your ERP to other systems, my advice is to start by mapping your real workflows (not the ones in the manual) and prioritize by pain: which process eats up the most hours each month. Start there, not with the flashiest integration.