Everyone selling integration work answers this question with "it depends", and then changes the subject. It does depend. But it depends on a short list of things you can assess yourself, before you speak to anybody — and once you can see that list, you can tell a fair quote from a bad one and a cheap job from a false economy.
This article does not give you a price. It gives you the things that set the price, a way to work out whether the work pays for itself using your own numbers, and the questions worth asking before you commit.
What actually drives the cost
Five things move the number far more than anything else.
How many systems, and in which direction. Connecting two systems one way — orders flowing from your shop into your accounts — is a fundamentally smaller job than keeping two systems in agreement in both directions. Two-way sync means deciding what happens when both sides change the same record, and that decision has to be made for every field that matters. Each additional system does not add to the work, it multiplies it, because every new pair of systems is another relationship to define.
Whether the systems have a real API. Modern software offers a documented interface designed for exactly this. Older or cheaper software often does not, and the workarounds — scheduled file exports, screen automation, database access — are slower to build, more fragile in use, and break when the vendor changes something. The difference between "this has a good API" and "this does not" is often the single largest factor in the estimate, and it is knowable in an afternoon.
Data volume and history. Moving today's transactions is straightforward. Bringing across five years of history, with the corrections and oddities that accumulated in it, is a different job. It is also the part most often left out of a cheap quote, and the part you notice missing three months later.
How many exceptions your business actually has. Every business believes its process is standard until someone writes it down. The trade customer who is invoiced monthly, the product sold by weight rather than unit, the one supplier who still sends a PDF — each exception is a branch that has to be built, tested and maintained. The number of exceptions, not the number of transactions, is what makes an integration complicated.
Who cleans the data. If two systems disagree about a customer's address, an integration will faithfully replicate the disagreement. Someone has to decide which system is authoritative and fix what is wrong before the connection goes live. That work is real, it takes time, and it is usually cheaper for you to do than for anyone else, because you know which one is right.
The cheap option that costs more
The lowest quote is frequently the one that treats the happy path as the whole job. It connects the two systems, demonstrates a record moving across, and stops.
What it leaves out is everything that happens when the record does not move: the rejected order, the duplicate customer, the field that arrives blank. A connection with no error handling does not fail loudly — it fails quietly, accumulates a backlog nobody is watching, and reports success the entire time. You find out from a customer, weeks later, and then you pay someone to work out what has been wrong and for how long.
Ask what happens on failure. If the answer is vague, the quote is not comparable to one that includes it.
How to work out whether it pays back
You do not need anyone's rate card to do this. You need three numbers, all of which you already have.
1. The hours. How long does the manual work take each week — the re-keying, the reconciliation, the chasing of things that do not match? Be honest and include the checking, not just the typing. 2. What an hour costs you. Use the real cost of the person doing it, or what you would rather they were doing instead. 3. What errors cost. How often does something go wrong because two systems disagreed, and what did the last one cost to put right — in refunds, credit notes, or goodwill?
Multiply the first two, add the third, and annualise it. That figure is what the problem costs you every year whether you fix it or not. Any quote can now be judged against it: if the work costs less than a year of the problem, the decision is straightforward. If it costs more than two, the case needs to be about something other than time savings.
That framing also tells you when *not* to integrate. If the manual process takes twenty minutes a week and never goes wrong, leave it alone. Integration is worth doing where the pain is recurring, growing, or expensive when it fails — not everywhere it is technically possible.
What you are actually buying
Time saved is the easiest benefit to calculate and rarely the most valuable.
Numbers you can trust. When the same figure means the same thing everywhere, you stop reconciling and start deciding. Most businesses do not realise how much time they spend establishing what is true before they can act on it.
Errors that surface immediately. A good integration tells you at once when something has not gone through. The failure still happens; you simply find out from the system instead of from a customer.
Capacity without headcount. The manual work usually scales with volume. Automated work does not. That is what makes integration compound: it is worth more at twice your current size than it is today.
An estate you can build on. Once systems talk properly, the next thing is easier — reporting, a customer portal, automated invoicing. The first integration is the expensive one because it establishes the plumbing.
Questions worth asking before you commit
- What happens when a record fails to transfer? Who finds out, and how?
- Is this one-way or two-way, and if two-way, what wins when both sides change?
- What history is included, and what is not?
- Who is responsible for cleaning the data first — you or them?
- What happens if a vendor changes their API next year?
- When it is finished, can we maintain it ourselves, or are we tied to you?
The last one matters more than the price. A cheaper integration that only its author can maintain is not cheaper — it is a subscription you did not agree to.
The honest summary
The cost of an integration is set by how many systems are involved, whether they were built to be connected, how much history and how many exceptions you carry, and how much of the work is handling the cases where things go wrong rather than the case where they go right.
The value is set by how often the manual process runs, what it costs when it fails, and whether you are growing. Work out the second before you ask anyone about the first — you will have a much better conversation, and you will know a thorough quote when you see one.
If you want a straight answer about your own situation, tell us which systems are in play and what currently gets done by hand. The call is free, and if the honest answer is that the integration is not worth doing yet, we will tell you that.