What an accounting integration costs, and what the price actually depends on

In short. A simple one-way exchange — regular export of products, stock and prices from the accounting system to a website — takes three to five weeks. A full two-way integration of a website, CRM or WMS, with logging, alerts and reconciliation, takes two to three months and costs several times more. The spread inside those ranges is set not by the volume of programming but by the state of the accounting system itself: how heavily the configuration has been customised, whether a test environment exists, and whether anyone on the client side owns the system. Those three factors move an estimate more than the number of entities in the exchange.

What follows is what makes up the price, what inflates a project quietly, and how to compare proposals when there are several.

What the budget is made of

It helps to see an estimate not as “so many development hours” but as five different kinds of work. Vendors who name a price immediately are usually counting only the second.

1. Audit and exchange design — 10–20% of the budget. Which version and which configuration, what has been customised in it, which objects take part, who owns each field, what counts as the source of truth on a conflict. This stage feels optional right up to the moment it turns out the price is stored in three places and all three occasionally differ.

2. Development on the accounting side — 25–40%. HTTP services or OData, scheduled jobs, export processing. This is also where the project’s main constraint surfaces: who is allowed to change the configuration.

3. Development on the external side — 20–30%. The receiver, the queue, reference data mapping, handling retries and partial failures. Usually cheaper than the accounting side, because there is no legacy there.

4. The scaffolding: logs, alerts, reconciliation — 10–20%. The most underestimated line. Without it the integration works right up to the first silent failure, and then nobody notices for a month that orders are not arriving.

5. Launch and the parallel period — 10–15%. The time when the old exchange is still alive, the new one is already running, and the two are compared. Saving on this item costs more than the item.

Three typical scenarios

One-way: accounting to website. Three to five weeks. Products, stock and prices leave the accounting system for the storefront on a schedule. There is no return flow, no conflicts and almost nothing to reconcile. This is the most predictable scenario on price, and the only one where a fixed estimate is reasonable.

Two-way with a website or CRM: two to three months. Orders go into the accounting system, statuses come back, customers and counterparties synchronise both ways. The price grows not because of the second direction as such but because of the questions it raises: what to do when an order was changed in both systems, how not to create a duplicate counterparty, what counts as successful delivery of a message.

Integration with a WMS or a production system: more again. Here movement documents appear — receipts, shipments, transfers — which means different reliability requirements. A lost line in warehouse stock costs money immediately, not “whenever somebody notices”.

In all three cases this is the cost of the project, not of ownership. Ownership is below, and it is a separate conversation.

What inflates a project quietly

The list below is not scaremongering but what regularly turns up during an audit and moves an estimate by half again or double.

A heavily customised configuration. A stock trade edition and “the trade edition that three different contractors customised for seven years” are different systems with the same name. In the second, every change has to be checked against breaking somebody’s customisation, and documentation for those customisations usually does not exist.

No test environment. Developing straight in production is not a saving, it is a transfer of risk to the accounting department. If there is no test environment, creating one is part of the project, and that is a week or two.

Nobody on the client side owns the accounting system. The most expensive item on the list. An integrator cannot decide which system owns the price — that is a business decision. When that person does not exist, the project does not cost more on the estimate, it takes longer on the calendar, and that is what turns into money.

An old platform version. On legacy versions the usual HTTP services are unavailable and the exchange has to be built through files or an intermediate layer. It is doable, and it costs more than a direct API.

“Like the spreadsheet, only automatic”. An attempt to reproduce the existing manual exports one to one. Those exports usually accumulated over years, half of them have long been unnecessary, and sorting that out is cheaper at the start.

What brings the price down

A clear source of truth. If the company has already decided that prices live in the accounting system and product cards live on the website, half the contentious questions never arise.

A willingness to cut scope. Of fifteen reference books in the exchange, usually four are critical. A pilot on those gives a working system in three to five weeks, and the rest is added as needed — and some of it never is.

Your own in-house team. If somebody inside maintains the configuration, splitting the work makes sense: we do the external side and design the exchange, they do the changes inside. That is cheaper and it keeps the knowledge in the company.

Dropping real time where it is not needed. “Stock must update instantly” raises the price noticeably. Ask what actually breaks with a five-minute delay: most often, nothing.

Why a fixed price without an audit is a bad sign

A vendor who names an exact figure before seeing the configuration is doing one of two things. Either they are adding the risk of the unknown on top — usually 20–40%, which is honest but expensive. Or they will name a low price and bill everything that surfaces as additional work, and the total will come out higher.

The correct form of answer at the start sounds duller: a range, the named factors that make it so wide, and a fixed price for an audit after which the range narrows. The audit should be a deliverable in its own right — an exchange diagram and an estimate you could take to a different vendor.

This is the same logic as the choice between the project and the product approach: what gets fixed is not the scope but the way decisions are made along the way.

What it costs afterwards

An integration is not a one-off purchase, and that belongs in the calculation from the start.

Platform and configuration versions change. The APIs of marketplaces and external services change, usually without warning and not in your favour. Processes inside the company change: a new warehouse, a new discount scheme, a new legal entity.

A reasonable estimate for support is 5–15% of the project cost per year, depending on how many external systems are in play and how volatile they are. An exchange with one stable service sits near the bottom of that; a bundle of four marketplaces near the top.

The “build it and forget it” option exists, but only for fully isolated exchanges between two systems that nobody develops.

How to compare proposals

If there are several proposals, comparing them on the bottom line is meaningless — they have costed different things. Three questions level the picture.

“What is included in the scaffolding: logs, alerts, reconciliation?” If that is not in the estimate, the proposal is cheaper for a reason other than vendor efficiency.

“What happens when the exchange fails at night?” The answer “we will see it in the log in the morning” and the answer “an alert fires and the message goes to a retry queue” describe two different products on the same line of an estimate.

“Who owns the code on the accounting side, and will documentation remain?” An exchange only its author can support is a hidden cost stretched over years.

Common questions

Can we get by with the standard exchange? Sometimes. For a simple online shop on a stock configuration the built-in exchange closes the task and there is no reason to pay for development. Custom integration starts where you need non-standard fields, your own pricing logic, several external systems, or an exchange that does not fit an export schedule.

Our accounting system sits inside the network with no external IP. Is that more expensive? Slightly, but not fundamentally. You need a VPN tunnel, a message bus or file exchange through an intermediate server. Exposing the system to the internet is not required in any of the options, and no vendor should demand it.

How long is a pilot and what counts as success? Three to five weeks on one direction. Success is not “the data started flowing” but “the data started flowing and a week’s reconciliation matched”. The second is checked with numbers, the first with a feeling.

Can we start small and extend later? That is the right order. The only requirement is that the pilot is built on an architecture designed to grow: an exchange over a queue can be extended, a one-off export script gets rewritten.

In short

The market range is honest, from a one-way exchange to a full two-way integration costing several times more. But where you land inside the range is determined by the state of your accounting system and whether anyone owns it, not by the size of the task.

So the only sensible first step is an audit: it costs a fixed amount, takes weeks rather than months, and after it the conversation is about a specific figure rather than a range.

How we do it is on the accounting integration page; the technical side of the exchange is covered separately in integrating your accounting system with a website, CRM and marketplaces, and on a live project it is visible in the WMS replacement case.