Skip to content
Shop integration & processes

What Does an ERP Integration Cost? Planning for 2027

What does connecting an ERP to your online shop cost? Six cost drivers, recurring items, 2027 deadlines and a budget frame per integration type for planning.

18 min read KostenERP-AnbindungBudgetplanungSchnittstellenbetrieb

In short and in plain language

What does it cost to link your inventory system to your online shop? The article helps you plan the money for it.

There is no fixed list price for this. The cost depends on how much data flows, in which way and how often.

Special rules for prices, variants and pack sizes also add work. Then there are tests and the way errors are handled.

After the launch, there are costs each year. The article also names dates that cause work on links you already have.

In a free analysis, we look at your systems. Then we tell you the cost of each part on its own.

The fourth quarter is when budgets for 2027 are allocated, and many planning rounds contain a line nobody can put a reliable figure on: connecting the ERP or inventory system to the online shop. The honest answer to "what will it cost?" starts with "it depends", but it depends on factors you can name. How many data objects flow, in which direction, how often, with which special logic, and how thoroughly are errors handled and tested? On top of that comes the part that returns every year after go-live. This article breaks the effort down into these building blocks, shows which dates in 2027 will create work on existing interfaces anyway, and turns both into a budget frame per integration type. A return-on-investment calculation is deliberately left out: the question here is what an integration costs and why, not when it pays for itself. If the basic choice between a platform and a custom build is still open, see the article on iPaaS or custom development.

Key takeaways

  • Six factors determine the effort of an ERP-to-shop integration: number of data objects, direction, sync frequency, special logic for prices, variants and pack sizes, error handling, and testing. A price quoted without looking at them is an estimate.
  • Of companies with 10 or more employees that use cloud services, 23 percent use ERP software as a cloud service (Destatis). Business Central online allows 6,000 OData requests per user within five minutes (Microsoft Learn).
  • Business Central online receives two major updates per year, in April and October (Microsoft Learn). From version 30 in 2027 release wave 1, Microsoft pages can no longer be exposed as OData endpoints (Microsoft Learn).
  • Public TLS certificates issued on or after 15 March 2027 may be valid for no more than 100 days (CA/Browser Forum). Without automated renewal, every certificate change at an interface becomes a recurring manual task.
  • In 2027 the transitional rule for paper and other invoice formats in domestic B2B trade only applies up to 800,000 euros of prior-year turnover (Section 27(38) UStG). Above that, plan e-invoicing into the integration document flow.
  • A 2027 budget separates analysis, implementation, third-party licences, internal effort, operations and a reserve. Prices for software development and programming in Q2 2026 were 0.8 percent above the same quarter of the previous year (Destatis).

Why there is no list price for an ERP integration

Shop software can be priced by licence and term; an ERP integration cannot. It is not a product but a set of data flows between two systems, each with its own rules, fields and interfaces. Two companies running the same inventory system and the same shop software can therefore receive quotes that are far apart without either being dubious. The difference rarely lies in the technology of the connection itself. It lies in what is supposed to flow through it and in the rules that have to apply before it does.

For budget planning, that is good news. If you know the factors that drive the effort, you can roughly place a project yourself before the first quote arrives, and you can compare quotes with each other. The cost blocks are the same in every project: analysis, mapping, development, testing and operations. How large each block becomes is decided by the cost drivers. The diagram at the top of this article shows the relationship schematically: the further the sliders for data objects, sync frequency and special logic move to the right, the taller the bar becomes, and not evenly but mainly in mapping, development and testing.

  • Analysis: review the systems, check available interfaces and fields, define the leading system per data type and set the scope in writing.
  • Mapping: assign fields, convert values, record rules for conflicts and special cases. The article on data mapping between ERP and shop describes this in detail.
  • Development: build retrieval, transformation and delivery of the data, plus the queue, retry logic and logging.
  • Testing: set up a test environment, create test data with real edge cases and run acceptance with the business team.
  • Operations: monitoring, adapting to new versions of both systems, certificates and third-party licences. This is the only block that comes back every year.

Data objects and direction: the scope of the integration

The first and usually biggest lever is the number of data objects. Items, prices, stock levels, customers, orders, delivery status, invoices and returns are each separate data flows with their own mapping, their own error handling and their own test cases. An integration that only sends stock levels to the shop and orders to the inventory system is a different project from one that also synchronises customer accounts, documents and returns. Each additional data object adds not only its own development but also its interactions: a return touches stock, order and credit note at the same time.

The second lever is direction. A one-way flow, such as stock from the ERP to the shop, needs a clear source system and a robust transfer. As soon as data flows in both directions, conflict rules come in: what happens if a customer address is changed in the shop and in the ERP almost simultaneously? Which system wins, how does the other one find out, and who cleans up duplicates? These questions cost design time, code and above all test cases. The article on bidirectional synchronisation shows which patterns have proved themselves.

Data objectTypical directionWhat drives the effort
Items and master dataERP → shopFields, languages, media, categories, variants
PricesERP → shopCustomer groups, tiers, contract prices, promotions
Stock levelsERP → shopWarehouses, reservations, buffers, sync frequency
OrdersShop → ERPPayment methods, shipping methods, partial deliveries, cancellations
CustomersBoth directionsDuplicates, B2B hierarchies, approvals
Documents and statusERP → shopInvoice, delivery note, tracking number, customer account
ReturnsBoth directionsCredit note, stock posting, refund

For the budget this means: first write down the list of data objects and their direction, then decide on stages. Many projects sensibly start with items, stock and orders and add documents, returns and customer accounts in a second stage. That spreads the cost over two budget years without the first stage having to be rebuilt later, provided the mapping is designed for the second stage from the outset.

Sync frequency and cloud ERP: when limits set the effort

The third driver is sync frequency. A nightly reconciliation of a few hundred items is technically different from stock changes that should reach the shop within seconds. The shorter the interval, the more calls, the more important deltas become instead of full reconciliations, and the more often the integration runs into the limits of the other side. Whether a data flow is triggered by an event or by regular polling is a separate decision with its own costs.

With cloud ERP these limits are fixed. 54 percent (Destatis) of companies in Germany with at least 10 employees used paid cloud services in 2025. Of these cloud users, 23 percent (Destatis) use ERP software as a cloud service. The figure therefore does not describe all companies, only the share that uses cloud services at all, and within that group cloud ERP is still comparatively rare. It still matters for cost planning: anyone moving into this group, or already part of it, plans an integration under different conditions than with an ERP in their own data centre.

One example of such conditions: Business Central online allows 6,000 OData requests (Microsoft Learn) per user within a sliding five-minute window. When the limit is exceeded, the system responds with status code 429 (RFC 6585), which according to the specification indicates that too many requests were sent in a given amount of time. An integration that ignores this often runs smoothly in testing and can fail on the first promotion day. Batching, deltas, retries with waiting periods and spreading the load cost development time that should be in a cloud integration budget from the start. The article on cloud ERP API limits describes what this looks like in practice.

Set the sync frequency per data object

Not every data object needs real time. Stock levels and orders benefit from short intervals, while master data and prices usually work well with a delta reconciliation at fixed intervals. Setting the frequency per data object instead of ordering "real time" across the board saves calls, development time and running costs.

Special logic: prices, variants and pack sizes

Special logic is a driver that is often missing from early estimates, because it is taken for granted in day-to-day business. In the ERP, a quantity tier for a customer group looks like a row in a table. In the shop, the same rule has to apply at runtime: for the logged-in customer, in the basket, in search and on the invoice. The more such rules there are, the more work moves from mapping into development and from development into testing.

Customer prices and tiers

List prices are transferred quickly. Contract prices, customer groups and quantity tiers require either complete price lists per customer in the shop or a price lookup against the ERP.

Variants

Sizes, colours and versions multiply the number of records. Whether the ERP keeps variants as separate items or as attributes determines the reconciliation logic.

Pack sizes and units

Piece, carton, pallet: if the shop sells in different units from those the ERP stores, you need conversions that work the same way in stock, price and order.

Promotions and discounts

Time-limited prices, vouchers and discounts must reach the ERP as order lines in a way that keeps accounting and reporting correct.

Tax and documents

Reverse charge, deliveries abroad and credit notes bring their own posting and validation rules into the document flow.

Process exceptions

Special approvals, minimum quantities, surcharges or items blocked for individual customers are small per case but often add up to a work block of their own.

Several of these topics have their own articles, for example on B2B price synchronisation. For budget planning, a simple inventory is enough to start with: which of the six points apply to you, and in how many variations? A few customer groups with one tier each are different from individual contract prices for every single customer, and a handful of pack-size items are different from a range that is sold in several units throughout.

Error handling and testing: the underestimated block

An integration that only works in the normal case is built quickly. The rest is where the effort lies: what happens if the ERP does not respond during an update, if an item was deleted in the shop while an order for it is still in transit, or if a transfer is repeated after a timeout although it had long arrived? Each of these cases needs a rule, code and a test case. A queue, retries with increasing intervals, a store for messages that cannot be processed and unique keys against duplicate processing are standard; the article on error handling in interfaces describes the building blocks.

In testing, what counts is less the number of test cases than how close they are to reality. A test environment of the ERP with realistic master data, edge cases such as items without stock or customers with a different delivery address, and a load test with real data volumes all take time, including on your side. The business team has to describe test cases, check results and sign off acceptance. The article on test environments for ERP interfaces shows how such an environment can be set up.

Internal effort belongs in the budget

Many plans only include the external service share. Cleaning up master data, writing test cases, running acceptance and changing processes after go-live costs working time in-house. These hours are real even if no invoice arrives for them, and they often fall exactly when day-to-day business leaves the least room.

Ongoing operations: what is due in 2027 anyway

Operations is the only block that does not end at go-live. Shop and ERP keep evolving, certificates expire and legislation changes document rules. Several such dates for 2027 can already be named today. They do not affect every company, but they belong in every budget plan at least as a checked line.

Business Central online receives two major updates per year, with new major versions every April and October (Microsoft Learn). The period in which administrators can reschedule such an update lasts five calendar months (Microsoft Learn). Specific breaks for integrations have been announced: from version 29.0, Microsoft pages can no longer be exposed as SOAP endpoints (Microsoft Learn), and from version 30 in 2027 release wave 1 no longer as OData endpoints either (Microsoft Learn). If your shop integration was built on such pages, plan the move to your own API pages or the standard APIs within this period. Our page on Dynamics 365 integration describes how we connect Business Central via OData endpoints and custom APIs.

At SAP, mainstream maintenance for the core applications of SAP Business Suite 7 ends at the end of 2027 (SAP), followed by optional extended maintenance until the end of 2030 (SAP). If your shop is connected to such a system, migrating the interfaces is a project with its own budget; the article on the end of SAP ECC maintenance sets out the options.

Public TLS certificates issued on or after 15 March 2027 may be valid for no more than 100 days (CA/Browser Forum); from 15 March 2029 the limit drops to 47 days (CA/Browser Forum). Every interface that serves such a certificate therefore needs automated renewal, otherwise certificate changes become a recurring manual task with a risk of outages. The article on shorter certificate lifetimes describes the steps required.

For domestic invoices between businesses in Germany, the transitional rule allowing invoices on paper or, with the recipient's consent, in another electronic format applies in 2027 only if prior-year turnover was no more than 800,000 euros (Section 27(38) UStG). Above that, the issuing system must, as a rule, produce e-invoices unless invoicing takes place via EDI with the recipient's consent. Whether the shop or the ERP writes the invoice is an architecture question covered in the article invoice from shop or ERP; in the budget it appears as an extension of the document flow.

With cloud ERP there is a contractual point as well: from 12 January 2027, providers of data processing services may no longer charge switching fees for the switching process (Art. 29 Data Act). That lowers the fees charged by the previous provider when you switch, but not the effort of moving the interfaces to another system. Whether a specific contract falls under the rule has to be checked case by case. If you are considering a switch, budget the rebuild of the integration as a separate line.

From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process.

Regulation (EU) 2023/2854 (Data Act), Article 29(1)

Budget frame per integration type

From the drivers, a frame can be derived for typical projects. The overview below places five integration types by their decisive drivers and by the ratio of one-off to recurring effort. It deliberately gives no amounts, because those only become reliable after looking at the specific interfaces. Our entry prices per integration type are listed with their price date on the pricing page.

Integration typeDecisive driversOne-off effortRecurring effort
Document or payment export to accountingOne data object, one direction, tax rulesLowLow, adjustments when the law changes
Inventory system with items, stock and ordersSeveral data objects, stock sync frequencyMediumMedium, releases of both systems
ERP with pricing conditions, variants and pack sizesSpecial logic, both directions, test scopeHighMedium to high
Cloud ERP with short sync intervalsAPI limits, deltas, vendor update cycleMedium to highHigh, adapting to new major versions
Additional channel on an existing integrationMapping onto existing data flowsLow to mediumLow

Two notes on reading the table. First, the classification applies per connection, not per project. A project with an inventory system, an accounting export and a payment integration consists of three rows of this table. Second, the type is determined by the drivers, not by the ERP. A lean integration with a large ERP can cost less than an integration with a lot of special logic for a small inventory system.

This is also how we calculate: we quote a fixed price per connection after reviewing the interfaces that are actually available in a free system analysis, whether for an inventory system integration or a large ERP. Third-party licences for connectors or middleware are shown separately, individual extensions are billed by project day or hourly rate, and maintenance and monitoring in operation are separate, optional items. What each module includes is listed in our services overview.

If you roll forward quotes from the previous year, keep an eye on price trends. Producer prices for services as a whole were 3.7 percent (Destatis) higher in Q2 2026 than in the same quarter of the previous year. For the items that make up an interface, the increase was smaller: prices for software development and programming were 0.8 percent (Destatis) above the same quarter of the previous year, prices for software and software licences 1.1 percent (Destatis), and those for data processing, hosting and related services 1.4 percent (Destatis). Besides general cost increases, the companies surveyed also cited higher licence costs as reasons (Destatis).

For planning, the main consequence concerns the recurring items. Licences for connectors, middleware or cloud services are usually billed annually and follow their providers' price adjustments. They therefore belong in a separate line with its own projection, apart from the one-off implementation. That line is also the place to record which licence is tied to which connection, so that it is clear which costs disappear when a channel is switched off.

From estimate to budget line in five steps

A reliable budget does not start from a single figure but from a list. The following five steps lead from the first idea to line items that can be justified in the budget meeting.

From project idea to a justified budget line

  1. 1

    List data objects and direction

    For each data object, record which system leads, in which direction data is transferred and which fields are needed. The list is also the basis for every quote.

  2. 2

    Assess sync frequency and special logic

    Set the required interval per data object and count the special cases: pricing rules, variants, pack sizes, tax cases and process exceptions.

  3. 3

    Have the interfaces checked

    Clarify which endpoints, fields and limits both systems actually offer. Only then is a fixed price per connection reliable.

  4. 4

    Split the budget into lines

    Keep analysis, implementation per connection, third-party licences, internal effort, operations and a reserve for release changes as separate lines.

  5. 5

    Cross-check the 2027 dates

    Match update cycles, certificate lifetimes, e-invoicing and cloud providers' contract terms against your own systems and add to the affected lines.

The reserve deserves a thought of its own. It is not a buffer for poor estimates but for what the analysis identified as open: a special case nobody could describe completely, an interface whose behaviour under load is still unknown, an announced version change without a fixed date. The shorter this list is after the analysis, the smaller the reserve can be.

Typical budget mistakes in interface projects

  • Only implementation budgeted. Operations, licences and adjustments to new versions are missing, and the first major update after go-live becomes an unplanned expense.
  • Real time ordered for everything. Short intervals for master data and prices increase calls and effort usually without the shop selling more as a result.
  • Special logic discovered during the project. Customer prices, pack sizes or exceptions surface after the quote and turn into change requests.
  • Testing seen as the provider's job alone. Test cases and acceptance need the business team; if their time is missing, go-live slips.
  • Licences hidden in the service price. Without separate line items it is impossible to see which part of the budget goes to third parties permanently.
  • Error handling treated as optional. Without a queue, retries and monitoring, every outage costs manual work that no budget accounts for.

An integration whose costs can be traced in advance is easier to defend internally. If you know what each block stands for, you can explain in the budget meeting why an item should stay and where a later stage is enough. For monitoring in operation, a middleware with monitoring is worth a look, as it makes data flows visible so that errors are ideally noticed before they reach the customer.

This article is based on data from: Federal Statistical Office of Germany (Destatis), press release No. 416 of 24 November 2025 on the use of cloud services and press release No. 329 of 18 September 2026 on producer prices for services; Microsoft Learn, pages on operational limits, update cycles and deprecated features of Business Central online; RFC 6585 (Additional HTTP Status Codes); CA/Browser Forum, Baseline Requirements for TLS Server Certificates, version 2.3.1; German VAT Act (Section 27(38) UStG) as published on gesetze-im-internet.de; SAP News of 4 February 2020 on maintenance for SAP Business Suite 7; Regulation (EU) 2023/2854 (Data Act), Article 29. This overview is not legal or tax advice.

Related Articles

Shop integration & processes

Invoice from shop or ERP? Setting the leading system

Shop or ERP: which system issues the invoice and assigns the number? A decision matrix for partial delivery, cancellations, marketplaces and e-invoicing.

20 min read
Law & compliance

Withdrawal button in the shop: cancellation as an ERP record

Withdrawal function under Section 356a BGB: how the click becomes a record that blocks order lines in the ERP, proves the deadline and triggers the refund.

16 min read
Law & compliance

Right to Repair: Spare Parts and Price Guides From the ERP

The repair rules have applied since 31 July 2026 to eleven product groups. How spare parts, guide prices and repair orders flow from the ERP into shop and portal.

16 min read