Systems integration for SMEs: ERP, CRM and more

Systems integration means connecting your ERP, CRM, online store, invoicing and other tools so that data flows between them without anyone retyping it. A good integration decides which system owns each piece of data, how changes travel and what happens when something breaks. Those three decisions matter far more than the technology you pick.

This guide covers how to spot disconnected systems, the main integration patterns, security and GDPR, what Spain’s VeriFactu and e-invoicing rules mean for invoicing integrations, and how to run the project step by step.

Signs your systems are disconnected

Most small and mid-sized companies start with separate tools: an ERP or accounting package, a CRM, an online store, a spreadsheet for the warehouse. That works until volume grows. These are the usual symptoms:

• Double data entry. Someone creates the same customer in the CRM, the ERP and the online store.
• Data that does not match. Stock on the website differs from stock in the warehouse, or a customer has a different address in each system.
• Manual exports. Every week someone downloads a CSV, fixes it in Excel and imports it somewhere else.
• Errors your customers see. An order that never reaches the warehouse, an invoice with old details, an email to a customer who unsubscribed.

If two or more sound familiar, not integrating already has a real cost: hours of skilled people and mistakes that reach customers.

Integration patterns and when to use each

No pattern is best in general. Each one fits a type of problem:

A practical rule: use APIs or events for operational processes (orders, customers, invoices) and keep files and database sync for reporting or for systems that offer nothing else. Writing straight into an ERP’s database usually breaks its validations.

With three systems, a few direct connections are fine. With six or eight, nobody knows what calls what, and a central layer (an iPaaS or an in-house integration service) that holds transformations, logs and alerts pays off.

Master data: who owns each record

The most expensive integration mistake is not deciding which system is the source of truth for each piece of data. If both the CRM and the ERP can edit a customer’s address, sooner or later you will have two addresses and nobody will know which one is right.

Before writing any code, build a table like this:

Two rules prevent many problems:

• A shared identifier. Every record needs a reference that all systems store (for example, the ERP ID). Without it, the integration has to match on names or emails, and that fails.
• One writer per field. Other systems read it or send change requests to the owner.

Errors, retries and monitoring

An integration does not fail when something goes wrong. It fails when something goes wrong and nobody notices. APIs go down, tokens expire and data arrives in unexpected shapes. Design for it:

• Retries with backoff. If a call fails for a temporary reason, retry after a few seconds, then after longer.
• Idempotent operations. Receiving the same order twice must not create two orders. Use the source ID to detect duplicates.
• A dead-letter queue. Messages that keep failing go to a queue where a person reviews and replays them.
• A log of every exchange. What was sent, when, and what the other system answered. Without it you cannot audit or debug.
• Alerts and a status dashboard. Raise an alert when the error queue grows or a job does not run on time.
• Periodic reconciliation. A job that compares, say, store orders with ERP orders and flags differences.

Security: credentials and least privilege

Every integration is a door between systems. Treat it like one:

• Keep credentials out of code. API keys belong in a secrets manager, not in source code or shared spreadsheets.
• Use OAuth where available. OAuth 2.0 (RFC 6749) gives an application limited access without sharing the user’s password, with narrow scopes and expiring tokens.
• Least privilege. One technical user per integration, with only the permissions it needs. If it only reads orders, it must not be able to delete customers.
• Rotation and revocation. Rotate keys regularly and revoke them when an integration is retired.
• Validate input. Webhooks should verify the signature or origin of each call before processing it.

GDPR: processors and international transfers

Integrations move personal data about customers, employees and suppliers. The GDPR applies as it does to any other processing:

• Processors (Article 28). Every SaaS vendor or iPaaS platform that handles that data on your behalf is a processor. You need a contract that meets Article 28.
• International transfers (Chapter V, Articles 44 to 49). If a SaaS tool processes data outside the European Economic Area, the transfer needs a legal basis: a Commission adequacy decision, standard contractual clauses or another Chapter V safeguard. For the United States there is the EU-US Data Privacy Framework, which only covers certified companies and is under appeal at the EU Court of Justice (case C-703/25 P). Check where each vendor processes data.
• Data minimisation. Each system should receive only the fields it needs. The online store does not need the bank details held in the ERP.
• Consistent erasure. When a customer exercises the right to erasure, the integration must propagate it to every system holding their data.

VeriFactu and e-invoicing in Spain

If you invoice in Spain, invoicing is now regulated at software level. This affects any integration that creates or changes invoices.

VeriFactu. Royal Decree 1007/2023 requires invoicing software to guarantee the integrity, retention, traceability and immutability of invoice records. Under Royal Decree-law 15/2025, the deadlines in force are:

On 5 October 2026 the Spanish Ministry of Finance published a briefing note forecasting a postponement to October 2028. As of this article’s publication, that postponement has not been published in the Official State Gazette (BOE), so the 2027 dates still apply. Check the Tax Agency’s VERI*FACTU page before planning.

B2B e-invoicing. Order HAC/1028/2026, in force since 6 October 2026, regulates the public e-invoicing solution and starts the clock on Royal Decree 238/2026. According to the Tax Agency, businesses with turnover above EUR 8 million must issue, send and receive e-invoices from 6 October 2027, and everyone else from 6 October 2028. Invoice and payment statuses must also be reported.

What this means for integrations:

• One system issues invoices. If the store, the CRM and the ERP can all issue invoices, each one must comply. The usual design is for all of them to send an “invoice this” request to a single compliant invoicing system.
• Issued invoices are not edited. An integration must never edit or delete an issued invoice. Corrections go through corrective invoices.
• Structured formats. The order requires the EN 16931 semantic model in UBL syntax for the public solution. Source data (customer, tax ID, lines, taxes) has to be clean and complete.
• New return flows. Invoice and payment statuses become data that must travel between invoicing, accounting and the CRM.

Buy a connector or build custom

A bought connector is faster to start. But if your process does not fit what the connector does, you end up bending the process to the tool or paying for patches on top.

What drives the cost of an integration

We do not quote generic figures because they depend on each case. These factors move the budget most:

• Number of systems and flows. One-way customer sync is very different from two-way orders, stock and invoices.
• API quality. A system with a documented API is far cheaper to integrate than one that only exports files.
• Data quality. Duplicates and incomplete records require cleanup or migration first.
• Business rules. Each transformation or exception means analysis, development and testing.
• Availability and monitoring needs. Real time, alerts and reconciliation cost more than a nightly job.
• Maintenance. Vendors change their APIs. Integrations need ongoing maintenance.

We go into more detail in how much custom software costs.

Steps in an integration project

1. Map systems and flows. Which systems exist, what data moves, who moves it today and how long it takes.
2. Define master data. The ownership table and the shared identifier.
3. Pick one flow. Start with the one causing the most hours or errors, for example store orders into the ERP.
4. Choose the pattern. API, events, iPaaS or files, depending on the systems and how fresh the data must be.
5. Review security and GDPR. Technical users, permissions, processor contracts and data location.
6. Build error handling and logging from day one. Retries, error queue, alerts.
7. Test with real anonymised data and edge cases: duplicates, empty fields, a system going down.
8. Run in parallel for a while and reconcile against the manual process.
9. Measure and move on to the next flow.

Integration, automation and AI

Once systems are connected, you can automate processes on top. At LCApps we have built AI automations that process messages, forms and documents and create records, tasks or alerts in other systems, and document data extraction: we process documents with AI, extract the relevant information for the case file and write it straight into it. We explain when to use AI and when fixed rules are enough in AI process automation vs RPA.

The next step is connecting AI assistants to your systems. For that we use MCP servers: we built one for our own CRM that lets an assistant query and act on customers, tasks, invoices and expenses with the user’s permissions. See what MCP (Model Context Protocol) is and our guide to AI agents for business. We design and operate all these projects in line with the GDPR and the EU AI Act.

If your systems have no API or your process does not fit a standard connector, the integration is a custom software development project.

Frequently asked questions

What is ERP integration?

It means connecting the ERP with other systems (CRM, online store, warehouse, invoicing, banking) so that orders, customers, products, stock and invoices are exchanged automatically, with a single owning system for each piece of data.

Is an iPaaS better than a custom integration?

An iPaaS fits when you connect popular tools with simple flows. Custom development fits when you have specific business rules, systems without connectors, high volume or data that should not pass through third parties. Many projects combine both.

Can I integrate a system that has no API?

Yes, through scheduled files, read-only database access or, as a last resort, automating its user interface. These options are more fragile, so they need closer monitoring.

Does VeriFactu apply if my online store generates the invoices?

Yes. Whatever system issues the invoices must comply with Royal Decree 1007/2023. If the store invoices, it must be compliant or hand the invoicing to a compliant system.

Conclusion

Integrating systems is not about connectors. It is about deciding which system owns each piece of data, how changes travel and how errors are caught. Once that is clear, the technology choice follows. And with Spanish e-invoicing and VeriFactu on the horizon, sorting out your invoicing flow now avoids a rush later.

At LCApps we build custom software and integrations between the systems you already use, adding automation and AI where they add value. Tell us which process you want to improve and we will help you plan the integration.