How to divide responsibility between e-commerce and the business system

A salesperson promises delivery of an item that looks available in the customer portal, but customer service sees a different stock level in the business system and the website shows a third.

It usually starts as small discrepancies. Then it becomes a pattern, especially when several channels share the same data, and no one clearly owns what counts as master. Among companies with at least ten employees, 36.7 percent sold through e-commerce in 2024, according to Statistics Sweden, and larger companies ran that part of their business considerably more often than small ones.

What a typical Swedish e-commerce chain looks like in practice

The chain needs to be described from start to finish. The business system holds the base data. The PIM enriches product content. The e-commerce platform presents it to the customer. The portals provide logged-in self-service with agreements, order status and documents.

When responsibility is unclear, the things that eat up operational time appear. Someone updates product copy in the wrong place. A price file arrives too late. An order has to be reconciled by hand. The knock-on errors, with corrections and reconciliations, often take more time than the sync itself.

It shows in Swedish statistics too. Companies with at least ten employees turned over SEK 2,718 billion through web sales and EDI in 2024, according to Statistics Sweden’s business statistics, and consumer e-commerce is also substantial according to Svensk Handel’s E-commerce Indicator for full-year 2024. When the channels already carry that much business volume, data quality becomes a central part of operations.

Item numbers and financial attributes should have their master in the business system and be synced on change and on publication to the PIM, e-commerce and portal. Product copy and images should be owned in the PIM and passed on at publication to e-commerce and the portal. Prices and agreements should be governed from the business system and transferred on change or on a schedule to e-commerce and the portal. Stock levels should also be owned in the business system and synced frequently, or event-driven for critical items, to e-commerce and the portal. Orders and order status can have different masters depending on the flow, but need to be sent immediately or in batches to the warehouse, finance and customer service.

What the business system, PIM, e-commerce and portal actually do

In many projects, the roles get mixed up already at the requirements stage. Every integration then becomes heavier than it needs to be, and errors often only surface when several teams try to own the same field. A better model starts by giving each system a clear responsibility.

The business system holds what has to be correct for the business to work: item numbers, stock levels, purchase prices and financial attributes. The PIM holds the product content to be published across channels, meaning descriptions, images, languages, technical specifications and relationships. The e-commerce platform shows the catalogue, cart, checkout and presentation. The portal handles login, customer-specific terms, documents and self-service.

An item is first created in the business system. That is where finance, stock logic and the foundation of the range sit. Product data is then sent to the PIM, where market-adapted copy, media and languages are added. After that, the information is published to the website, customer portal and reseller portal.

This is often where projects go wrong unnecessarily. When the PIM has to carry financial fields, editorial work becomes risky. When the business system has to carry the whole product story, the content becomes rigid. When the e-commerce platform stores too much logic, upgrades become difficult.

For a Swedish manufacturer, the boundary is therefore fairly simple. The business system should own the values that govern transactions. The PIM should own what governs presentation and channel publishing. The platform should display products and take orders. The portal should give the right customer access to the right content.

The integration layer should relay, validate and log. If the same rule needs to exist in three systems, the design has already lost its way.

This becomes clear in Swedish e-commerce. Channels are often combined, so the integration has to handle several routes out. That is why a clear division of responsibility works better than trying to move everything into a single application. When the business measures value, you need to track whether errors decrease, manual corrections disappear and the order flow becomes easier to run. In practice, this often shows most clearly in how ERP and integrations fit together in a governed flow.

Four integration patterns that govern the whole chain

When a project moves from pilot to operation, the same four flows usually come back: product data, prices and agreements, stock levels and order flows. Everything else is a variation on those patterns.

Product data should almost always be governed centrally. Item numbers, units, variants and technical attributes should not be updated in several places. When the same field is edited in the web platform and in the business system, sooner or later you get an item that is right in one channel and wrong in another.

The common mistake is mixing product copy with master data. Changes then become hard to test. A headline change can accidentally affect pricing logic or export formats. That is unnecessary and hard to troubleshoot.

Price lists should be fetched from the system that owns the commercial terms. If they are duplicated in the platform, it quickly becomes unclear which version applies. This is especially true when customer-specific prices and agreements need to be visible in the portal or when logged in.

Manual handling here is almost always more expensive than it looks. A wrong discount hurts the margin. A late price update damages trust. A local fix only creates more exceptions next time.

Stock levels need more thought than product copy. For some ranges, batch transfer is enough. For others, the sync needs to be frequent or event-driven. It depends on how fast items sell and how much risk an incorrect display carries.

What fails in practice is often the tolerance for discrepancies over time. If the stock level is allowed to drift too long, the customer sees an item that is already sold out. Support then starts taking calls that should have been avoided.

The order flow has to do more than pass on an order. Confirmation, picking, invoicing and returns should be able to move through the chain without double entry. Otherwise finance spends time on reconciliation and customer service on explanations after the fact.

This is where the quality of the integration becomes very concrete. Either the order follows through all the way, or it gets stuck in an in-between state that requires manual handling. The latter sounds minor at launch and becomes expensive in operation.

Read more about how a governed integration flow is built.

Choose the right level of real time

Many buyers assume everything has to happen instantly. That sounds reassuring. Real time is right for certain stock levels and customer-specific order flows, but excessive speed also creates more sources of error.

Product copy, images and structured descriptions rarely need to be pushed through in real time. Stable transfer works better there. The same applies to price lists governed by planned updates. You often gain more from control than from milliseconds.

This shows clearly in day-to-day work. The more small changes are sent instantly, the harder troubleshooting becomes when something deviates. Someone then has to work out which version won, and why.

Stock levels for critical items need more frequent updates. The same goes for order flows involving customer-specific terms or tight delivery times. There, a late update often costs more than an extra integration event.

A good rule of thumb is simple. Sync quickly where an error directly hurts the business. Sync more calmly where the content mainly describes the range. That gives lower complexity and better control.

Why a shared data model becomes a competitive issue

Business customers compare suppliers on clarity, availability and how easy it is to place the right order. When product data, prices and delivery terms hold together, it becomes easier to build trust throughout the buying journey. When the information is inconsistent, uncertainty rises immediately, especially when the customer is comparing several options for the same need.

The comparison also increasingly crosses borders. The share of Swedish consumers who shopped online from abroad was 23 percent in August 2025 according to Svensk Handel’s August report, and in the November report the share had risen to 27 percent. Business customers, too, have alternatives close at hand when a supplier’s information falls short.

That means product data, prices and delivery terms have to hold together where the customer compares. If stock levels are uncertain or product information is inconsistent, the customer chooses a supplier that seems clearer.

It doesn’t matter how polished the integration looks in the project meeting. If a product lacks the right unit, the price doesn’t match or the delivery time is uncertain, the experience is weak immediately. The customer sees the result of your system choices without caring about your system names.

That is why a shared product and order model becomes a business decision. When the model is clear, the same content can be reused on the website, in the portal and in reseller flows without rebuilding each time.

This is closely linked to structure in product data, especially when several channels need to read the same information but present it differently.

How productised delivery changes time, price and risk

When delivery is built from finished, tested components, the calculation becomes clearer. Starting from reusable building blocks gives a different kind of control than starting every integration from scratch. Finished function blocks also mean the same foundation can be reused as you build further.

Glanser works with a Function Library where functions and integrations are delivered in three tiers: Standard, Adapted and Customer-unique. The customer-unique part is isolated so that it doesn’t affect the rest during upgrades. For projects where integrations need to last over time, this means scope and responsibility become clearer from the start.

When the work is split into reusable functions, you don’t have to negotiate every small connection. That makes the estimate easier to understand and reduces the risk of a change in one channel spreading to other parts. This is especially important in environments where the business system governs several flows at once.

We work with Litium, Optimizely and Magento and are a Litium Premium Solution Partner. For integration with business systems such as Business Central, Monitor and Jeeves, it is possible to build on the same foundation instead of starting over. Above all, this reduces uncertainty when the solution is developed further after go-live.

The delivery model is described in more detail in our whitepaper on moving from project to product.

It works best when you want to start with one solution and build on the same foundation. It also works well when you have several channels that need to share product and order data. Reusing functions then becomes a practical advantage.

It fits less well if every channel needs entirely its own logic at every step. It then becomes hard to keep components compatible over time. It is better to be upfront about that from the start than to pretend everything can be packaged.

Compatibility and product ownership are part of TCO

Many calculations stop at implementation. That is the wrong end point. The big cost often lies in ongoing management, upgrades and what happens when a new release breaks the integration.

When an e-commerce platform or a business system is upgraded, connections and functions have to keep working. If no one is responsible, the customer often gets the next quote instead of a controlled version step. That makes TCO hard to manage.

Glanser Care is a contracted responsibility at a fixed monthly cost. It covers version tracking, compatibility through upgrades and bug fixing, with no new quote for each upgrade. That kind of commitment changes the calculation, because ongoing management becomes planned and predictable.

That is also where many projects become more expensive than expected. It often happens when no one owns the solution over time. Every release then becomes a small new project with its own risk.

What the approach requires, and what you should ask

This approach requires you to properly own your product data. It also requires you to accept that parts of the functionality are delivered as finished blocks. The solution then becomes easier to manage and to build on.

It fits less well if your business relies on completely irregular logic in every channel. It also fits less well if no one in the organisation owns master data in the business system. Without that responsibility, the integration just becomes another layer of uncertainty.

Three questions to ask the supplier

How do you handle compatibility at the next platform and business system upgrade? The answer quickly shows whether the supplier has a model for long-term responsibility or mainly works from project to project.

How is your function library priced and updated? The answer shows whether reuse actually gives controllable costs and clear further development over time.

How do you measure that the integration actually improves the business? The answer shows whether the supplier follows up business value in operation or stops at delivering technology.

If you want to see how a current-state picture, a functional specification and a complete cost picture can be produced without starting a large project, use the Glanser 72-hour analysis. You set aside two hours for a meeting and, within 72 hours, receive an inventory of functionality and integrations, a functional specification, a prototype and a complete cost picture with a timeline, free of charge and based on your own material.