What does an integration between two systems cost?

You ask three suppliers what it costs to connect your online store to your accounting software and get three completely different answers. That isn't because anyone is guessing. It is because the word integration can mean anything, from a daily export to a flow handling a thousand messages an hour.

Why do the answers vary so much?

An integration isn't a product but an agreement between two systems. What that agreement costs depends on how much goes back and forth, how precise it has to be and what needs to happen when it goes wrong.

So two companies that both want to connect their online store to their accounts can be a factor of ten apart. One posts a daily total. The other wants the VAT per country, the shipping costs and the returns sent back for every order.

Which five factors set the price?

• The number of flows: every direction you connect is a separate piece of work, with its own failures.
• The number of fields per flow: moving ten fields is different from moving eighty, especially if they need mapping.
• The frequency: once a night is simple; real-time on every change needs a queue and monitoring.
• The state of your data: duplicate contacts and mismatched item numbers take more time than the programming itself.
• The control requirements: logging, recovery and a screen where someone can see what is stuck.

Indicative prices per type of integration are on what it costs to have an integration built. That page works with the five factors above.

Step 1: count the flows, not the systems

Write down exactly what goes from A to B, and what needs to come back. Orders out, invoice status back. Items out, stock back. Every line you write is a flow, and every flow has its own price.

Pick one to start with. An integration that tries six flows at once breaks six times in the first month, and you won't know why.

Step 2: count the fields per flow

For each flow, go through the fields that really need to go across. Not everything on the screen, but what the receiving side needs to do its job.

Watch the fields that are quietly expensive: VAT codes, general ledger accounts, currencies, cost centres and payment terms. Each package names them differently and allows different values. Every mapping is work, and every mapping has to be editable by an administrator later.

What comes as standard and which fields are available is set out per system. For accounting, for example, under Exact Online; for the online store, under Shopify. If the package already handles that mapping for you, that saves on the price too.

Step 3: decide how often and how fast

The fresher the data needs to be, the more technology sits underneath. A nightly batch is a simple program. Real-time transfer needs a queue, retries and monitoring of throughput time.

Ask yourself what goes wrong if a piece of data is four hours old. If nobody would notice, a batch is enough, and that saves a lot in both build and maintenance.

Step 4: budget for maintenance, not just the build

The build is a one-off amount; maintenance is a subscription. Systems release updates, fields change, tokens expire and a new financial year changes the structure on one side or the other.

So budget an annual amount for maintenance on top of the build. Without that budget the integration doesn't stop working, but it does stop being trusted, and then someone starts doing things by hand next to the system again.

Agree who owns it on your side, too. Someone has to make decisions about the mapping tables and be the one called when a flow goes silent. Without that person, every change becomes a project.

What does it cost to do nothing?

That side of the sum is the one most often forgotten. Count the minutes per task, the number of tasks per week and the hourly rate. Add the cost of fixing mistakes and the delays your customers notice.

The calculator on what manual work costs takes you through it step by step. Put the result next to the build cost plus five years of maintenance and you will see straight away whether it is a debate or a decision.

An example sum, entirely fictional

Take a fictional company that re-keys orders into its accounting system. Say forty orders a day, three minutes per order, five days a week. That is ten hours a week, roughly half an FTE over a year, before counting the mistakes that need fixing later.

These numbers are made up to show the shape of the sum, not to suggest a price or a result. Fill in your own figures and put the result next to a quote.

When is an integration not worth it?

When the volume is small. Re-keying ten items a week costs less than building and maintaining an integration. If either system will be replaced within a year, wait. And if a standard connector already does what you need, use it: what is available per package is listed under integrations.

Building your own makes sense when you need to combine several systems, need your own logic in the mapping, or when the standard connector lacks exactly the fields you care about. If you also need custom software around the integration, see custom software. What such an integration looks like in practice is set out in connecting Exact Online to your own software.