Since 19 June 2026 the provisions of Directive (EU) 2023/2673 apply (Directive (EU) 2023/2673, Article 2), and for online shops selling to consumers they contain a visible obligation: the electronic withdrawal function under Section 356a of the German Civil Code (BGB). The customer clicks a button labelled "Vertrag widerrufen" (withdraw from contract), enters or confirms three details, sends the declaration with "Widerruf bestätigen" (confirm withdrawal) and receives an acknowledgement of receipt with date and time without undue delay. The form is quick to build. What happens afterwards decides the workload: if the declaration lands as an email in the service inbox, someone looks up the order, retypes the line items, stops the shipment by word of mouth and has to remember the refund deadline. This article starts before the returned goods arrive at the warehouse. It describes how the click becomes a structured withdrawal record that the inventory and ERP integration assigns to an order or to individual line items, how the timestamp proves the deadline, how the acknowledgement of receipt is produced by the system and how the payment channel triggers the refund within the statutory 14 days (Section 357(1) BGB).
Key takeaways
- Since 19 June 2026 the rules on the withdrawal function apply (Directive (EU) 2023/2673, Article 2). In German law the duty sits in Section 356a BGB: labelled "Vertrag widerrufen" and permanently available throughout the withdrawal period.
- The withdrawal function requests three details: name, contract or part of the contract, and the means of communication for the acknowledgement of receipt (Section 356a(2) BGB). The ERP has to match them to an order and its line items.
- After the click on "Widerruf bestätigen", an acknowledgement with content, date and time goes out on a durable medium without undue delay (Section 356a(4) BGB) - generated from the record, not by hand.
- The receipt timestamp proves that the deadline was met (Section 356a(5) BGB) and also starts the maximum period of 14 days for the refund (Section 355(3) and Section 357(1) BGB).
- The refund uses the same means of payment as the original payment (Section 357(3) BGB). The retailer may withhold it until goods or proof of dispatch arrive (Section 357(4) BGB) - a release rule for the interface.
What Section 356a BGB requires from the shop
The provision applies to distance contracts concluded via an online interface - in other words, to shops that sell to consumers. The trader must ensure that the consumer can submit a notice of withdrawal there by using a withdrawal function. The function must be legibly labelled "Vertrag widerrufen" or with another equivalent unambiguous wording, and it must be permanently available, prominently placed and easily accessible for the whole of the withdrawal period (Section 356a(1) BGB). For the declaration itself, the statute provides that the consumer can supply or confirm three details: their name, details identifying the contract or the part of the contract they wish to withdraw from, and details of the electronic means of communication through which an acknowledgement of receipt is to be sent to them (Section 356a(2) BGB).
A second step follows. As soon as the details are provided, the shop must offer a confirmation function labelled "Widerruf bestätigen" or with another equivalent unambiguous wording (Section 356a(3) BGB). Only this second click transmits the declaration. Once the consumer activates it, an acknowledgement of receipt must be sent to them on a durable medium without undue delay, containing at least the content of the declaration and the date and time of its receipt (Section 356a(4) BGB). Finally, subsection 5 deals with the deadline: the declaration is deemed to have reached the trader in time if the consumer sent it via the withdrawal function before the withdrawal period expired.
Withdrawal function
Labelled "Vertrag widerrufen", permanently available throughout the withdrawal period, prominently placed and easily accessible (Section 356a(1) BGB).
Three details
Name of the consumer, contract or part of the contract, electronic means of communication for the acknowledgement of receipt - supplied or confirmed (Section 356a(2) BGB).
Confirmation function
Second step labelled "Widerruf bestätigen"; only this step transmits the declaration to the trader (Section 356a(3) BGB).
Acknowledgement of receipt
Without undue delay, on a durable medium, with the content of the declaration and the date and time of receipt (Section 356a(4) BGB).
The timeframe is set by EU law. Directive (EU) 2023/2673 inserted the withdrawal function as Article 11a into Directive 2011/83/EU on consumer rights. Member States had to adopt the necessary provisions by 19 December 2025 and apply them from 19 June 2026 (Directive (EU) 2023/2673, Article 2). For the interface, the date matters less than the fact that the function is not an add-on for particular contract types: it covers every purchase of goods in the shop that carries a right of withdrawal, and with it the daily business of selling to consumers. According to the wording of the directive, the consumer can also withdraw via the function - it is added to the existing routes and does not replace them.
From the click to the withdrawal record
An obvious first setup consists of a form, two buttons, one email to the customer and one to the service inbox. Legally that is a start, operationally it is a bottleneck. The declaration arrives as text, someone in customer service reads it, looks up the order in the ERP, checks which line items are meant and triggers the following steps by hand. Each of these manual steps delays the case, and each can corrupt the assignment: a mixed-up order number, an overlooked partial line, a withdrawal that stays unhandled between holidays and a change of shift.
The sturdier approach treats the withdrawal as a business transaction in its own right, with its own record. The shop accepts the declaration, assigns a case number, fixes the time of receipt and passes the record through the middleware to the ERP. There it is attached to the order like a delivery or an invoice, with status, line items and history. The handover is event-driven: a webhook reports the new withdrawal, the middleware adds the order data and creates the case in the ERP. If the handover fails because the ERP is temporarily unreachable, the record goes to the dead letter queue and is delivered again instead of being lost.
withdrawal
case_no unique, assigned by the shop
idempotency_key from session and form submission
received_utc time of the click on "Widerruf bestätigen"
received_local same time with time zone Europe/Berlin
name as entered or confirmed
contract_reference order number as the customer states it
contact_channel email address for the acknowledgement
erp_order_no matched in the ERP, empty until matched
lines[] order_line, quantity, match_certain
channel withdrawal_function | email | letter | other
period_end calculated from delivery and information
refund_due calculated from received_utc
acknowledgement
sent_utc time of transmission
content_checksum checksum of the document sent
template_version version of the text template
status received | acknowledged | matched | ...The channel field matters. The withdrawal function is an additional route, not an exclusive one: withdrawal is still made by declaration to the trader, and the declaration must clearly show the consumer's decision to withdraw from the contract (Section 355(1) BGB). A letter or an email with a clear declaration therefore remains a withdrawal. Anyone who creates the record only for clicks in the shop will run two procedures side by side. It is better to have one record for all incoming routes, into which customer service transfers declarations from the inbox, so that ERP, warehouse and accounting only know one structure.
Matching at line-item level
The second mandatory detail is the most demanding one: details identifying the contract or the part of the contract the consumer wishes to withdraw from (Section 356a(2) BGB). The statute therefore expressly provides for partial withdrawal. For the interface this means that a withdrawal does not necessarily relate to a whole order but to a selection of line items and quantities. A customer who ordered several shirts in different sizes and wants to keep one expects to be able to say exactly that - and the ERP then has to know which line item is affected and in what quantity.
The hurdle lies in the numbering. The customer knows the order number from the order confirmation, the ERP keeps its own sales order number, and with partial deliveries and partial invoices delivery notes and invoices with further numbers are added. Line items can be cut differently in the ERP than in the shop: a set is resolved into a bill of materials, a variant carries a different item number from the article the customer saw. The mapping table between shop line and ERP line is created when the order is imported and must be kept at least for as long as a withdrawal is possible.
- Shop order number as the key: the customer states the number they know. The middleware translates it into the ERP order number, not the customer and not customer service.
- Pre-fill the line items: if the customer is logged in or arrived via a link from the order confirmation, the form shows the order lines for selection. The details are then confirmed rather than typed - the statute allows both.
- Guest orders via order number and email address: together they identify the order sufficiently. A mandatory login before withdrawal sits poorly with the requirement that the function must be easily accessible.
- Flag uncertain matches: if the details fit no order or several orders, the withdrawal is still created, acknowledged and put on a clarification list with the flag match_certain = no. Incomplete details are no reason to hold back the acknowledgement of receipt.
- Quantities rather than whole lines: if the customer ordered several units of one line and withdraws some of them, the quantity belongs in the record. Only then can return and refund in the ERP use the correct quantity.
The order confirmation as the entry point
The timestamp as proof of the deadline
The withdrawal period is 14 days (Section 355(2) BGB). For a purchase of goods it begins once the consumer has received the goods; for several goods in a single order that are delivered separately, only on receipt of the last item (Section 356(2) BGB). If proper information on the right of withdrawal is missing, the period does not begin, and the right of withdrawal expires at the latest twelve months and 14 days after the regular start (Section 356(3) and (4) BGB). For the shop this means that the withdrawal function has to remain reachable for a different length of time per order - and that only the system that knows delivery data and the information given can calculate the end.
For a withdrawal via the function, the evidence is straightforward if the time is stored cleanly: the declaration is deemed to have reached the trader within the period if the consumer sent it via the withdrawal function before the period expired (Section 356a(5) BGB). What counts is the click on "Widerruf bestätigen", not the moment an employee opens the message or the ERP creates the record. The shop fixes this moment in coordinated universal time and keeps the local time with time zone next to it. How an interface protects itself against duplicated or missing hours when the clocks change is described in the article on timestamps in ERP interfaces.
| Case under Section 356 BGB | Start of the period | Data source in the system |
|---|---|---|
| One delivery | receipt of the goods (subsection 2 no. 1 point a) | delivery event of the shipment |
| Several goods, delivered separately | receipt of the last item (subsection 2 no. 1 point b) | last shipment of the order |
| One item in several lots | receipt of the last lot (subsection 2 no. 1 point c) | shipments per order line |
| Information missing | no start before the information (subsection 3) | information status per order |
| Upper limit | expiry at the latest after twelve months and 14 days (subsection 4) | calculated period end on the order |
The table leads to one operating principle: the form does not reject a late withdrawal on its own. Delivery data from carriers arrives late or not at all, older orders may carry differently worded information, and the customer may have received the goods later than the system assumes. The function therefore accepts every declaration, acknowledges it and passes it on with the calculated period end. If receipt lies after that date, a person decides on the basis of the records rather than a rule in the form.
The acknowledgement of receipt comes from the system
The acknowledgement of receipt has to be sent on a durable medium and must contain at least the content of the notice of withdrawal and the date and time of its receipt (Section 356a(4) BGB). Under the definition in the BGB, a durable medium is any medium that enables the recipient to store or keep a declaration addressed to them personally so that it remains accessible for an appropriate period, and that is suitable for reproducing the declaration unchanged (Section 126b BGB). The confirmation page in the browser shows the customer that the click arrived. The acknowledgement of receipt itself, however, is sent to the means of communication the customer named in the third detail, which in practice means their email address.
The acknowledgement is built from the record, not from the form. The shop inserts name, contract reference, selected line items and time of receipt into a versioned template, sends the message and writes the time of sending, the template version and a checksum of the content back into the record. This makes it possible to prove later what the customer received and when, without searching a mailbox. Without undue delay means, in technical terms: the message leaves the outgoing queue as soon as the record is created and does not wait for a nightly batch. If sending fails because the address cannot be reached, a task is created for customer service; the withdrawal itself is unaffected.
Double click, double withdrawal
Blocking in the ERP: order, line item, shipping
Once the withdrawal record exists, the work in the ERP begins. What happens there depends on how far the order has progressed. If the goods have not yet been picked, the interface blocks the affected lines for shipping, and none of them leaves the warehouse. If the order is packed but not yet handed over, the warehouse decides whether the shipment can be stopped. If the goods are in transit or delivered, the block turns into an expected return. In each of these cases the inventory system needs the same information: which lines are affected, in what quantity and since when.
Status of a withdrawal from receipt to refund
- 1
Received
The shop has accepted the declaration, assigned a case number and fixed the time of receipt.
- 2
Acknowledged
The acknowledgement of receipt has been sent; time of sending, template version and checksum are in the record.
- 3
Matched
Order, line items and quantities have been found in the ERP, or the case sits on the clarification list with a reason.
- 4
Shipping stopped or return expected
Depending on the order status, the ERP blocks the lines or announces the return to the warehouse as an advance notice.
- 5
Refund released
Goods received or proof of dispatch available, provided the retailer uses its right to refuse the refund until then.
- 6
Refunded
The payment service provider has confirmed the refund, the credit is posted and the case is closed.
Returns logistics thereby gains lead time. Instead of opening an unannounced parcel at goods receipt, the warehouse knows the expected lines, can generate a return label and prepare the inspection. How goods receipt, inspection and reversal then run is described in the article on the RMA process between shop and ERP. What has to be settled beforehand is who bears the cost of the return: the consumer bears the direct cost of returning the goods only if they were informed of this beforehand and the trader has not agreed to bear it (Section 357(5) BGB). Which information belonged to the order is therefore a field on the order, not a memory in customer service.
The refund via the payment channel
For reimbursement the statute sets a maximum period: the performance received has to be returned no later than 14 days (Section 357(1) BGB). What matters technically is when this period starts. Where the law sets a maximum period for restitution, it begins for the trader on receipt of the notice of withdrawal (Section 355(3) BGB). The receipt timestamp from the withdrawal function is therefore not only the customer's proof of the deadline but also the starting point of the refund period for the retailer. An ERP that creates the refund only at goods receipt does not know this moment and cannot monitor the period.
In a consumer sale of goods, the trader may refuse the refund until it has received the goods back or the consumer has provided proof of having sent them; this does not apply if the trader offered to collect the goods (Section 357(4) BGB). For the interface this is a release rule with two inputs: goods receipt from the warehouse, or proof of dispatch from the returns portal or the carrier. Whichever arrives first releases the refund. Any payments for delivery must also be reimbursed; excluded are only the additional costs that arise when the customer chose a type of delivery other than the least expensive standard delivery offered (Section 357(2) BGB).
For the refund, the trader must use the same means of payment the consumer used for the payment, unless something else was expressly agreed and the consumer incurs no costs as a result (Section 357(3) BGB). The refund therefore does not run as a free bank transfer from accounting but through the payment integration back to the payment service provider of the original payment - card, wallet, invoice or direct debit. The middleware passes on the amount, the reference of the original payment and the case number, the payment service provider reports the executed refund back, and reconciliation with the ERP follows the pattern described in the article on payment reconciliation.
The period runs from receipt, not from the return
The amount itself is a calculation per line item. Basket discounts, vouchers and shipping costs must be allocated proportionately to the lines, otherwise a partial withdrawal cannot be refunded cleanly. This allocation belongs to the order import, not to the refund: if it is calculated only at the time of withdrawal, it may differ from what was on the invoice. Whether and to what extent shipping costs have to be refunded for a partial withdrawal is a legal question; the interface keeps the rule as a setting so that it can be adjusted without changing the program.
Fashion, specialist retail, electronics: what counts per assortment
In fashion retail, partial withdrawal is an everyday case: an order may contain several sizes or colours of the same article, of which the customer keeps some. Line items and quantities in the record are not a detail here but the core. The ERP integration for fashion and textiles brings variants, size grids and sets on which the matching relies. Specialist retail adds goods that need explanation and accessory bundles, where a set is kept in the ERP as a bill of materials; the integration for specialist retail must be able to translate the withdrawal of a set into its components.
In electronics, a serial number can be attached to the withdrawal. The interface therefore passes on not only the line item but the serial number that was delivered, so that goods receipt can check whether the right device comes back. The ERP integration for electronics and technology keeps these numbers per delivery. Anyone who also maintains spare parts and repair information in the same assortment will find the data side of that in the article on spare parts and reference prices from the ERP.
One distinction applies to every assortment: the right of withdrawal, and with it the withdrawal function, concerns contracts with consumers. Shops that sell to business customers and consumers at the same time need a reliable customer type flag on the order. The interface does not hide the function on assumption but on the basis of this flag - and when in doubt, it stays visible.
What a project works through, in this order
- Capture the incoming routes: list withdrawal function, email, letter and returns portal and decide that all of them feed into the same record.
- Define the record: case number, time of receipt, the three details, line items with quantities, channel, acknowledgement data and status - agreed between shop, middleware and ERP.
- Secure the mapping table: store shop line to ERP line when the order is imported and keep it for as long as a withdrawal is possible, including bills of materials and variants.
- Calculate the period end per order: read delivery events and information status, keep the end of the withdrawal period on the order and offer the function until then.
- Automate the acknowledgement of receipt: versioned template, sending from the queue, writing back time of sending and checksum.
- Define the ERP reaction: shipping block, advance notice for the return and clarification list depending on order status.
- Connect the refund: release rule from goods receipt or proof of dispatch, refund via the original payment channel, monitoring of the maximum period from receipt.
- Test with real cases: play through partial withdrawal, guest order, double click, late declaration and undeliverable acknowledgement once in the test environment before the function goes live.
A withdrawal that sits as an email in the service inbox is a task for a person. A withdrawal with timestamp, line items and acknowledgement is a case the ERP can work through.
Sources and legal basis
Related Articles
Energy label and EPREL: required data from ERP to the shop
Energy label and product information sheet in the online store: which fields belong in the item master, how the EPREL number reaches every channel and how cut-over works.
Food Labelling Data from the ERP in Your Storefront
Ingredients, allergens and nutrition come from the item master, shelf life and lot number from the batch: how both mandatory data sets reach the shop.
Net terms and early payment discounts in B2B checkout
Read the payment terms code from the ERP, show it as a date at checkout, settle the early payment discount only on receipt and check the statutory limit on payment periods.