ERP for Beginners: Integration — Where the ERP Ends and Everything Else Begins

For the first three episodes of this season we’ve been looking inside the ERP. We’ve argued about whether to customise or configure it, we’ve separated master data from transactional data, and we’ve walked a single sales order through every module it touches. Everything has been about the world bounded by the ERP’s own borders.

This episode turns the camera around. We look at where the ERP ends, and at the enormous tangle of other systems that sit around it. CRM, warehouse management, business intelligence, e-commerce, payroll, banks, tax authorities, government e-invoicing portals. A modern enterprise stack is never just the ERP — it’s the ERP plus fifteen or twenty other applications that each do one thing better than the ERP does, and the wiring between them is, more often than not, where the expensive complexity actually lives.

This is episode four of Season Two of ERP for Beginners — Going Deeper.

Why the ERP doesn’t do everything

One of the great misunderstandings that beginners carry around is the idea that once a company installs an ERP, the ERP becomes the system — and everything else either goes away or gets pulled inside it. That isn’t how it works in practice. An ERP is an extraordinarily good system of record — it’s where the authoritative ledger of the business lives, and where the backbone processes like order-to-cash and procure-to-pay run. But a lot of what happens at a modern company happens outside that backbone.

Sales teams live in a CRM because the CRM is built for tracking pipelines and conversations, not for posting invoices. Marketing teams live in automation platforms that do things no ERP would ever try to do. Warehouse operators use specialist WMS software because it’s optimised for wave-picking and slotting in a way a generic inventory module never will be. Data teams pull every table they can reach into a data warehouse because the ERP’s reporting tools are painful. Customers place orders on e-commerce platforms that the ERP never sees until the order is already paid for.

The ERP, in other words, is the trunk of the tree. A lot of the actual leaves — the customer-facing apps, the specialist workflow tools, the analytics — live on branches that bolt into the trunk. The question of how those branches bolt in is the subject of this episode.

The landscape around the ERP

Before we talk about the how, it’s worth drawing the landscape. In a typical mid-to-large enterprise running any mainstream ERP, you’ll find something like the following in the wider stack.

A CRM — Salesforce, Dynamics 365 CE, HubSpot — holding the customer-conversation side: leads, opportunities, quotes, contact history. A WMS — Manhattan, Blue Yonder, SAP EWM — running the physical warehouse. A BI or data warehouse stack — Snowflake, BigQuery, or an on-prem Oracle warehouse — aggregating data from every source for management reporting. One or more e-commerce platforms — Shopify, Magento, a B2B portal — where external customers place orders directly. A payroll or HCM SaaS — Workday, ADP, BambooHR — running the people side. Connections to one or more banks for cash management and payments. Connections to one or more tax authorities or e-invoicing portals for statutory compliance. Maybe a treasury system, a CPQ tool for configure-price-quote, a separate expense management tool, a field service platform.

None of this is going away when the ERP goes in. The ERP enters an existing ecosystem, stakes a claim to being the system of record for the finance and core operations backbone, and has to talk to everything else. That talking is what we mean when we say “integration”.

Batch — the nightly file

The oldest integration pattern, and still the most common by volume, is batch. At some agreed cadence — usually nightly but sometimes hourly — one system produces a file, the other system consumes it. A CSV of yesterday’s invoices lands in an SFTP folder for the data warehouse to pick up. An XML of today’s goods receipts is dropped for the WMS to import. A fixed-width file of the current day’s payment file is generated for the bank.

Batch is attractive because it’s simple. You don’t need to keep two systems permanently connected, you don’t have to worry about the receiving system being down at exactly the moment you try to send. If something fails, you rerun the batch the next morning. Reconciliation is easy — both sides just compare totals at the end of the day.

The cost is latency. A nightly batch means the downstream system is always up to twenty-four hours behind the ERP. That’s fine for management reporting, where yesterday’s numbers are what you want anyway. It’s not fine for a customer-facing system that needs to show real-time stock availability, and it’s not fine for a warehouse that needs to react to an order within the hour it was placed. When a business needs tighter synchronisation, the conversation moves to real-time.

Real-time — APIs and events

The modern alternative is real-time integration. Instead of producing a file once a day, each system exposes an API — a set of endpoints that other systems can call to read or write data as things happen. An e-commerce platform posts each order to the ERP’s sales-order API the moment the customer checks out. A CRM calls the ERP’s customer-master API the moment a sales rep creates a new lead. A WMS updates the ERP’s inventory API as goods are received at the dock.

Real-time is often described in two flavours. Request-response APIs — the classic REST pattern — are like a phone call: system A asks system B a question, waits for the answer, then continues. Event-driven integration is more like a radio broadcast: the ERP emits an event every time something meaningful happens — “invoice posted”, “stock updated” — and any system that cares subscribes. Event-driven scales better because the ERP doesn’t need to know who is listening; it just broadcasts. Systems that didn’t exist when the ERP was installed can subscribe to its events later without the ERP having to change.

Real-time integration is more powerful but more fragile. If the ERP’s API is down, the e-commerce checkout page has to cope. If events are delivered out of order, the receiving system has to handle that. Real-time introduces failure modes that batch simply doesn’t have, and most of the engineering effort in an integration project goes into the boring work of handling those failures gracefully.

Middleware — what sits between

In theory, every system could call every other system directly. A CRM calling the ERP’s API, the e-commerce platform calling the CRM’s API, the WMS calling the ERP’s inventory API, and so on. In a small environment, this is exactly what happens, and it works fine.

But as the number of systems grows, point-to-point integration gets unmanageable. Ten systems with everyone-to-everyone connections is forty-five separate integrations to build, test, and maintain. When one system changes, every other system that talks to it has to be updated. Most organisations, past a certain size, introduce middleware to tame the tangle.

Middleware sits between the applications and acts as a translator and traffic-controller. It takes many forms. A simple message queue like RabbitMQ or Kafka lets systems post messages without caring who consumes them. An integration platform — Boomi, MuleSoft, Workato, Azure Logic Apps — provides pre-built connectors, scheduled flows, and transformation tools for mapping one system’s data shape to another’s. An older on-premise pattern is the enterprise service bus, which served the same purpose in the 2000s. The buzzword of the moment is iPaaS, integration-platform-as-a-service, which is essentially the same idea delivered as a cloud tool.

Whatever the flavour, the goal is the same. Systems stop talking to each other directly. They talk to the middleware, and the middleware handles the shape-shifting, the retries, the monitoring, the audit trail. When a system changes, the middleware configuration changes; the other systems don’t have to know. One interface to maintain instead of many.

Who owns what — the system-of-record question

Introduce a second system into the conversation and you immediately have a data governance problem. If a customer’s address exists in both the CRM and the ERP, and a sales rep updates it in the CRM, what happens in the ERP? If product data lives in a product-information system and also in the ERP’s material master, which one is authoritative? If an inventory level is tracked in both the ERP and the WMS, and they disagree, which one is right?

This is the system-of-record question, and every integration project has to answer it for every piece of shared data. The ERP is usually the system of record for financial postings — the ledger is legally and practically authoritative. But it isn’t automatically the system of record for everything else. The CRM is usually the system of record for customer-conversation data. The PIM is usually authoritative for product descriptions and marketing attributes. The WMS is usually authoritative for real-time stock positions inside the warehouse. A well-designed integration decides this up front and only lets the authoritative system write to the shared field — everyone else reads.

Getting this wrong produces the classic integration pathology: the same field getting updated from two sides, integrations fighting each other, master data decaying into inconsistency. Done well, the system-of-record question yields clarity: one owner per field, a predictable flow, problems that are findable when they appear.

Where the complexity actually lives

There’s a saying in enterprise software that goes: the ERP implementation is where the money is, but the integrations are where the project is. It sounds flippant but it reflects a real pattern. The ERP itself is a well-understood product with vendor documentation, an implementation methodology, and thousands of consultants who have done it before. The integrations, by contrast, are bespoke to every company. They connect the ERP to whatever the particular company happens to use, in whatever combination, with whatever historical baggage.

On a typical enterprise ERP program, the integration track will easily consume a third of the total budget, sometimes more. It also generates a disproportionate share of the project risk, because integrations span system boundaries and therefore span team boundaries — the ERP team, the CRM team, the e-commerce team, the data team, and whoever owns the middleware all have to coordinate to make a single end-to-end flow work. And they continue to consume budget long after the go-live, because every new system added to the stack needs another integration, and every upgrade to an existing system needs the integrations re-tested.

Treating integration as an afterthought — a thing you worry about near the end of the implementation — is one of the most common and most expensive mistakes a company can make with an ERP program.

Why this matters

For anyone new to ERP, it’s tempting to think of the ERP as the system and everything else as peripheral. The more accurate picture, once you’ve seen a real enterprise stack, is that the ERP is one large node in a graph of systems, and the graph edges — the integrations — are as important to understand as the nodes themselves.

When someone shows you an ERP screen in a demo, the right question isn’t just “what does this screen do?” It’s also “what systems outside the ERP feed data into this screen, and what systems downstream read data out of it?” The answer to that question is almost always more interesting than the screen itself, and it’s the answer that tells you whether the ERP is really going to fit into the environment you’re actually running.

This is also the connective tissue that makes the earlier episodes of this season concrete. The customisation-versus-configuration tradeoff gets sharper when you realise that most of the customisation in a real project isn’t in the ERP itself — it’s in the integrations to everything around it. The master-data-versus-transactional-data distinction becomes more urgent when the master data has to be synchronised across five systems. The document flow we traced in the last episode often spills out beyond the ERP: the sales order might originate in a CRM, the delivery might be executed by a WMS, the invoice might be rendered on an e-commerce portal, the payment might come from a PSP. The ERP’s job is to hold the authoritative ledger regardless, and the integrations are what make that possible.

What’s next

Integration, then, is the wiring. It’s what turns a single piece of enterprise software into a system of systems. It’s where batch and real-time, APIs and events, middleware and point-to-point connections, and the never-ending system-of-record question all come together.

Episode five shifts scale. We’ve looked at one sales order inside one company. Next we look at what happens when the company isn’t one company — when it’s ten subsidiaries across seven countries, with different currencies, different tax regimes, and a parent that wants consolidated accounts at the end of the quarter. Multi-entity, multi-country ERP. The thing that makes global finance teams grey before their time.

See you there.