E-commerce order management from checkout to return

The customer sees the right price at checkout and completes the purchase. Even so, the order gets stuck with your finance team. The business system is expecting a different item number, a different unit or a delivery address it can use.

Order management in e-commerce requires the website, business system, warehouse, carrier and portal to make consistent decisions. When something deviates, you need to know who may change the order and what the customer should see.

An order passes five steps before it is complete

Swedish e-commerce turned over SEK 153 billion in 2025, according to PostNord's E-barometer. As order volumes grow, every manual order fix is repeated across more orders. That is why decisions and responsibility need to follow the order through the whole chain.

Registration happens at the website checkout or in the portal. Customer, item, quantity and chosen delivery method must come along. A typical error is that the order is marked confirmed before the price is approved and the stock reserved. So separate a received order from an accepted order when the process requires it.

Validation means the website checks the data against the business system's rules. Contract price, discount and available stock must be approved together. Otherwise checkout may show an amount that is recalculated later. Decide which system gives the final answer and how a rejection is shown to the customer.

Transfer to the business system requires item number, unit, customer terms and address to match the recipient's fields when the sales order is received. Business Central, Monitor and Jeeves are examples of recipients. If the website sends single units while the recipient expects packs, someone has to fix the order. A difference like that should be caught before the order reaches the warehouse.

Picking and shipping follow the delivery rules you have set. The warehouse owns the picking decision, while the carrier is responsible for transport events after handover. Order line, shipment details and the promised time need to follow the shipment. A common gap is that a partial delivery is shipped while the whole order still shows as being processed.

Follow-up requires the portal, finance and warehouse to share delivery date, tracking, invoice details and any credit. Each piece of data should have a designated source. If "delivered" closes the whole case, there is no room left for a return or a financial adjustment.

The order also needs a shared identity across the systems. Store the link between the website's order number, the business system's order number and the carrier's shipment number. Then you can trace an error without searching by customer name and amount. Mapping your most recent order across these five steps makes it clear where a decision owner is missing.

Price and stock are settled before the order is created

The customer sees a price and a stock message. With that, you have made a promise the business needs to be able to keep. Item number, sales unit and pricing logic must mean the same thing on the website and in the business system.

Core data decides how the calculation works. A customer-specific price can apply to a certain pack or a certain quantity. A contracted discount may take precedence over a campaign. Tiered pricing can be calculated per line or across several items together. Rules like these need to be written down before anyone builds the connection.

Say an order contains a stocked item with a contract price and a back-ordered item. The website prices the stocked item at list price while the business system uses the customer's contract. After payment, the order amount differs between the systems. Finance then has to deal with a problem that started at checkout.

The back-ordered line also needs a clear answer. You can allow ordering with later delivery or require the customer to remove the line. A positive total stock level is not enough to go on. In the simple model, available stock is stock on hand minus reservations. Blocked goods and other stock restrictions also need to be subtracted where they apply.

The price and stock message the customer sees while buying should be fetched in real time. How often stock needs updating depends on how quickly other channels use up the same stock. At the moment of ordering, though, you need a locked value that both systems can account for afterwards.

So store which price, which discount and which reservation were accepted. Also record when the answer was given and which pricing rule was used. If the answer arrives late, checkout needs to show a pending status. A retry must recognise the same order so the customer does not end up with duplicates.

PIM keeps names, units and product attributes in order. The link between product information and the business system's item register needs to be explicit. A sales-oriented product description may well differ from the warehouse name. Both must still point to the same item and sales unit.

Ready-built order functions work when the rules can be described with known fields. Glanser's Function Library has the levels Standard, Adapted and Customer-unique, with fixed scope and fixed price. Adapted means a standard function is adjusted to your process. Customer-unique logic is isolated so it does not affect the rest during upgrades.

A useful check is a real order where you compare price, unit and the accepted stock message. The differences need an explanation before you let more orders through the same flow.

The delivery choice follows the order line

More delivery options help little when no rule decides which ones work for the order. In 2025, on average 40 percent of e-commerce consumers had their most recent purchase delivered to a pickup point, according to Svensk Handel's e-commerce indicator. That makes the option relevant, but every order still needs to be checked against the properties of the goods.

Weight, dimensions and dangerous goods limit which shipments can be booked. The customer's address decides which services the carrier offers. Capacity, shipping cost and promised time then decide which options you can stand behind at checkout. Missing dimensions therefore need to be handled as an error with an owner.

A mixed order makes the trade-off clear. The stocked item can ship now while the back-ordered item is expected later. A complete delivery reduces the number of shipments but delays the available item. A partial delivery gets the customer the item sooner and can also raise shipping and handling costs.

The rule needs to state who may split the order. It should also govern how shipping is allocated and whether the customer must approve the extra cost. The remaining quantity and the new shipment must be written back to the business system and the portal. Otherwise customer service may have to ask the warehouse what was actually sent.

A warehouse confirmation means the goods have left the warehouse. The carrier's subsequent events show whether the parcel is on its way, delayed or delivered. That information needs to reach the customer under the same shipment identity. A delayed parcel must be distinguishable from an order line still waiting to be picked.

Track delivery precision against the promise the customer got at purchase. Also measure shipping cost per order and the share of manual order changes. A cheap shipment can become expensive if staff have to fix every booking. Many manual changes can also show that the rules are missing a common order case.

A first delivery rule can describe exactly that mixed order. It needs to state when you wait, when you split and who may approve the exception. Then the rule can be tested against both the cost and the customer's wishes.

The return continues after the order is delivered

"Delivered" needs to be the start of a possible follow-up case. For distance purchases, consumers normally have a 14-day right of withdrawal, counted from the day after receipt or collection, according to the Swedish Consumer Agency's guidance on e-commerce. The right of withdrawal applies when the buyer is a consumer. When the customer is a business, the agreed terms govern what may be returned and when. The order therefore needs to keep relevant delivery events and be able to open a return case.

Withdrawal can also be notified before delivery, as the Swedish Consumer Agency describes in its guidance on withdrawing before delivery. The notice needs a timestamp and a link to the current order status. Customer service must be able to request a stop to picking, packing or shipping while that is still possible.

For click-and-collect in a store, the right of withdrawal normally depends on when the contract was entered into, according to the Swedish Consumer Agency's guidance on store pickup. A binding web order and a reservation ahead of an in-store purchase therefore need to be separate order types. The terms should follow along to customer service when the case is opened.

Returns should be treated as a recurring order process. The status "initiated" means the system checks the order line, the applicable withdrawal period and the case type. The return gets its own identity linked to the original order. Complaints and warranty claims need to be handled according to their own rules.

The status "in transit" links tracking and return shipping to the case. When the item is marked "received", the warehouse records its condition and any relevant serial or batch numbers. Receipt needs a responsible person or function. Otherwise a box can sit in the warehouse while the customer waits for an answer.

"Quality checked" means someone has decided the item's next step. That can be restocking, selling as outlet, scrapping or continued complaint handling. When restocked, the sellable stock level in the business system increases. A received item should not automatically become available to the next customer.

"Scrapped" requires a stored disposition and a closed stock decision. The financial case may still need handling. "Credited" means finance has registered the correct adjustment against the original order. For an exchange, the replacement item can be reserved immediately while the credit is registered only once the return is approved.

Store the return reason, condition and disposition as structured fields. Then purchasing and product managers can tell picking errors apart from poor product information. PIM can then get corrected dimensions, compatibility details or clearer descriptions. For spare parts, RMA number, warranty reason and serial number may need to follow the case all the way.

The same order should show in the portal

After go-live, a returning customer logs in to check a back-ordered item. The customer finds the original order but sees no updated delivery. Your salesperson can see at the same time that the warehouse has shipped the available part. Both need the same information to plan the next step.

The portal should read orders, invoices and shipments from their designated sources. There the customer can follow the delivery, download the invoice and see how much quantity remains. The salesperson needs to be able to open the same order view. A local copy of the order maintained separately means every change has to be handled in several places.

When the customer reorders from their history, the earlier line needs to identify the right item. The new order should get current terms and a chosen delivery address. A discontinued item or changed pack size needs to be caught before the order is sent on. The history helps the customer find the right product, but the old order should stay unchanged.

A fault report should carry the order line's identity and the relevant shipment. Then customer service can understand which delivered item the case concerns. The customer avoids copying item numbers from a delivery note. Images and comments can also be linked to the same case.

A digital customer portal fits when customers return and have their own terms or several delivery addresses. Permissions also need to follow the customer's organisation. The person who orders might, for example, need different access from the person who downloads invoices.

A pure product website can be enough when visitors need product information and the purchase is handled in another channel. The portal becomes worthwhile when customers actually need to follow and manage their business with you. That requires you to decide which data customers may change and which changes need internal approval.

This approach requires clean order rules

Someone on your side must own item numbers, units, price lists and delivery terms. Technical connections can move the data, but someone needs to decide which values apply. Without that work, the same error spreads across more systems.

You also need to state which exceptions are allowed. Partial delivery, back orders and credits should have permissions and documented decisions. Finance, sales and the warehouse need to agree on rules that affect several departments. One person must be able to settle the question when the departments' wishes clash.

A ready-built connection fits when the order can be expressed with known fields. Truly unusual terms may need isolated customer-unique logic. That boundary is central when you connect e-commerce and the business system. Every special rule needs a test case and a named owner on your side.

The order integration should wait if range and prices are still recalculated in spreadsheets before every deal. The same applies when the order is in practice a quote the salesperson has to work on. A clear quote flow fits better until the rules can be written down.

After go-live, someone needs to track versions, compatibility and bug fixing. That responsibility should describe how errors at the boundary between systems are investigated. The customer also needs to be able to contribute example orders, approve rule changes and take part in testing. The supplier can take product ownership, but your commercial decisions still need to be made by you.

Three questions reveal whether the integration holds

Which field or confirmation locks price, unit and available stock when the order is created, and what happens if the business system responds late? The answer shows whether the accepted order can be recreated from stored data. The supplier needs to be able to describe both the pending state and how a retry avoids duplicates.

How are partial delivery, back orders and cancelled picking written back to the business system, carrier and portal, and who owns the rule? The answer shows whether delivery changes follow a decided process. A concrete example also needs to explain what customer service sees when something fails.

What is included when the platform or business system changes version, and does the order connection come along without a new quote? The answer shows how far the supplier's responsibility reaches after go-live. It needs to be clear which tests the supplier runs and which decisions you have to provide.

A vague answer is a reason to stop before the scope is set. Ask for a walkthrough of an order case with statuses and error handling. Then finance, warehouse and IT can assess the same sequence of events. A technical description only becomes useful once the colleagues involved understand what to do when something is rejected.

Test the order flow against the business system

An existing mixed order is enough as a first test. The material needs to show the item, accepted price, stock message, partial delivery and any return status in both systems. With the order's events in time order, you can tell delayed updates apart from wrong decisions.

Each deviation needs a description and an owner. If the difference comes from an unclear business rule, the rule needs to be written down before any technical work. If the rule is clear, the test can show exactly which transfer fails. That gives a well-defined basis for work on e-commerce integration.

With us, product ownership includes keeping product and customer data, prices, stock levels and order flows in sync even when the systems are updated. For you, that means the same test order can be used as a check at later upgrades. The expected result needs to be saved with the material, so the next test can be assessed without verbal explanations.

Glanser connects the order flow to the business system and takes long-term product ownership of the solution. On the integrations page, we describe how items, prices, stock and orders fit together and how the scope is set from the start.