In short and in plain language
After a shop goes live, faults show up. Some are in the shop when you accept it. That is a defect. The agency has to fix it.
Other faults come later. A browser changes. The server gets a new version. A law asks for something new. That is mostly maintenance.
When you accept the shop, you write down what works and what does not. You list the faults you know. If you do not, you can lose rights.
We look after your shop from the first day. We write down what we change. That way it stays clear where a fault comes from.
The shop has been accepted, the agency has sent its final invoice, the first orders are coming in. Then checkout fails for one payment method, a browser update shifts the product page, and the hosting provider announces a move to a new PHP version. Three faults, three different answers to the question of who pays. The first may be a defect from the project that the agency has to fix as part of subsequent performance. The second and third usually arise only after acceptance and belong to ongoing maintenance. This article shows where the line runs, why acceptance draws it, which limitation period applies under section 634a of the German Civil Code (BGB) and how to set up defect claims and maintenance so that no gap opens between project and operations. It describes the legal position based on the wording of the statute and published case law and is not a substitute for legal advice in an individual case.
Key takeaways
- A defect exists if the shop did not have the agreed quality at acceptance (section 633 BGB). Whatever arises afterwards through new browsers, PHP versions or laws is usually a matter for maintenance.
- Defect claims for a work that produces, maintains or alters a thing become time-barred after two years (BGB) from acceptance. Whether a shop project falls under this or under the regular period of three years (BGB) is disputed.
- Known defects belong in the acceptance record with an explicit reservation. Without it, section 640(3) BGB removes subsequent performance, self-remedy, withdrawal and price reduction for that defect.
- A defect notice describes the fault reproducibly and gives the agency a reasonable deadline for subsequent performance. Under section 637 BGB, the costs of self-remedy can usually only be claimed once it has expired.
- Chrome ships a new major version every two weeks (Chromium), a PHP branch ends after four years (PHP Group). A maintenance contract that starts on the day of acceptance absorbs these changes, which no warranty covers.
- When the project agency hands over to maintenance, open defects, credentials and version states belong in a handover record. If maintenance fixes a project defect without a deadline to the agency, the costs often stay with the operator.
Three cases after go-live: defect, change request, maintenance
Whether a fault is a defect is decided first by the contract. Under section 633 BGB a work is free from material defects if it has the agreed quality. Where nothing was agreed, the question is whether it is suitable for the use assumed under the contract or for ordinary use, and whether it has the quality that is usual for works of the same kind. For a shop this means: if the specification says that buying on invoice through a particular payment provider works, and exactly this route has failed since launch, much points to a defect. Even without an explicit agreement, accepting orders is part of the ordinary use of a checkout.
The second case is the change request. After go-live, the team notices things nobody considered during the project: an extra filter, a different sort order, a new field in the customer account. That can be sensible and still not be a defect. Whatever was not agreed and is not part of ordinary use is a new service and therefore a new order, however small.
The third case is maintenance. Here it is not the shop that changes but its environment: browsers release new versions, the server gets a new PHP, payment providers change their interfaces, the legislator demands new functions. The accepted work was fine; it simply no longer fits a world that has moved on since acceptance. These adjustments are upkeep and belong in a maintenance contract, not in the warranty.
| Case | Example in the shop | Benchmark | Who usually bears the cost |
|---|---|---|---|
| Defect | A payment method fails in checkout and has done so since the shop went live | Agreed quality at acceptance (section 633 BGB) | The project agency as part of subsequent performance |
| Change request | An additional filter or a different product page layout | Not part of the agreed service | The operator, as a new order |
| Maintenance | A new browser version, a PHP upgrade, a new legal requirement | Change in the environment after acceptance | The operator, on an ongoing basis through the maintenance contract |
Why acceptance draws the line
In the law on contracts for work, acceptance is the moment at which the customer approves the work as essentially in line with the contract. Under section 640(1) BGB the customer is obliged to accept if the work has been produced in accordance with the contract, and may not refuse acceptance because of insignificant defects. Acceptance makes the fee due (section 641 BGB), transfers the risk from the contractor to the customer (section 644 BGB) and, in the cases of section 634a(1) no. 1 BGB, starts the limitation period for defect claims (BGB). For telling the cases apart, this is the decisive point: as a rule, what matters is whether a fault was already present in the accepted state.
An explicit declaration is not the only route to acceptance. If the agency sets a reasonable deadline after completion and the operator does not refuse acceptance within it by naming at least one defect, section 640(2) BGB treats the work as accepted. Leaving an acceptance request unanswered in the inbox can therefore amount to accepting without noticing. The opposite route also starts the clock: according to a decision of the Higher Regional Court of Hamm, a final refusal of acceptance starts the limitation period even if the refusal is justified (OLG Hamm).
Reserve known defects explicitly
Acceptance also shifts the burden of proof. Under section 363 BGB, a creditor who has accepted a performance as fulfilment bears the burden of proof if they later want to argue that it was not fulfilment. For the shop this means that after acceptance it is usually the operator who has to show that a fault was already present in the accepted state. That is much easier with a record of this state than with memories of test sessions.
Limitation under section 634a BGB and the dispute over software
For defect claims under a contract for work, section 634a BGB distinguishes by the type of work. If the result consists in producing, maintaining or altering a thing, claims for subsequent performance, self-remedy and damages become time-barred after two years (BGB). Buildings have their own, longer period, and all other works fall under the regular limitation period. This is three years (BGB) and, under section 199 BGB, only begins at the end of the year in which the claim arose and the creditor learned of it or would have learned of it without gross negligence. For the two-year period, by contrast, the clock starts at acceptance.
The catch lies in the word thing. Under section 90 BGB, things in the legal sense are only tangible objects, and a shop consists largely of code, configuration and data. Whether a shop project therefore falls under the period from acceptance or under the regular period is disputed in case law and legal literature. In its judgment of 26 February 2014 (OLG Hamm), the Higher Regional Court of Hamm applied the shorter period to the delivery and adaptation of standard software together with hardware:
The delivery and individual adaptation of hardware and standard software owed by the contractor under a contract for work is conceptually the processing of a thing within the meaning of section 634a(1) no. 1 BGB.
The judgment can only be transferred to shop projects to a limited extent. The case concerned a complete IT system of adapted standard software, a server, workstations and card readers, and the court expressly relied on the work being embodied in a combination of hardware and software. For the creation of custom software, the same judgment reports the opposing view: there, the catch-all rule of section 634a(1) no. 3 BGB is sometimes applied because software development as an intellectual service is in the foreground (OLG Hamm). A shop built on a standard system with its own theme, its own extensions and interfaces, but without supplied hardware, sits between the two constellations.
On top of this comes the question of whether there is a contract for work at all. According to the case law summarised by the Higher Regional Court of Hamm, the permanent transfer of standard software for a one-off payment is treated as a sale, while individually created or extensively adapted software regularly leads to a contract for work (OLG Hamm). Under sales law, defect claims also become time-barred after two years (BGB) as a rule, but the period starts with delivery instead of acceptance. Between two merchants, section 377 of the German Commercial Code also requires the buyer to inspect the goods without undue delay after delivery and to give notice of a defect without undue delay, otherwise the goods are deemed approved (HGB).
Plan with the shorter period
Not legal advice
The acceptance record captures the state
Because defect and maintenance are separated by the state at acceptance, the acceptance record is the most important document of the transition. Later on it answers the question of whether a fault was already present in the accepted state or arose from a change made afterwards. A record that consists only of the line "shop accepted" does little to help. These points belong in it:
- Date and participants: who accepted, in which role and on which day.
- Version state: version of the shop system, the theme and every extension, plus the identifier of the delivered release or commit.
- Environment: PHP version, database version, hosting and the browsers tested, each with its version number.
- Test cases: checkout with every payment and shipping method, customer account, order emails, invoices and the interfaces to inventory management and payment providers.
- Known defects: every fault with a description, severity and the explicit reservation of rights.
- Outstanding work: what is still missing, with a date and listed separately from the defects.
- Handover: credentials, repository, documentation and who is responsible for operations from which day.
The environment is the point that later separates defect from maintenance. If the record states that checkout was tested in the browser version current at the time and on the PHP version of the time, a fault that only appears with a later version can be cleanly assigned to maintenance. If that information is missing, the discussion begins. A fixed set of test cases helps here, run at acceptance and then again after every major update, ideally on a copy of the shop as described in the article on staging environments. How to test updates in a structured way is covered in the article on update testing and regressions.
Reporting defects: set a deadline, preserve your rights
If a defect appears after acceptance, the first claim is subsequent performance. Under section 635 BGB the agency may choose whether to remedy the defect or produce the work anew, and it bears the expenses required for this. The operator sets a reasonable deadline for it. Only once this has expired without success may the operator remedy the defect, or have it remedied, under section 637 BGB and claim reimbursement of the necessary expenses, on request also as an advance. A defect notice that keeps this route open follows a fixed order:
Describe the fault reproducibly
What happens, in which browser, with which payment or shipping method and since when. Attach screenshots, error messages from the log and the order numbers of affected transactions.
Link it to the contract
Name the agreed function or the test case from the acceptance record that is not met. This decides whether it is a defect or a new request.
Demand subsequent performance with a deadline
In writing and with a specific date. What is reasonable depends on severity: a checkout that accepts no orders warrants a shorter deadline than a display fault in the footer.
Withhold part of the payment
If the final invoice is still open, section 641(3) BGB allows a reasonable part of the fee to be withheld, as a rule twice (BGB) the costs required to remedy the defect.
Decide once the deadline has passed
Self-remedy, price reduction, withdrawal or damages generally only come into consideration after the deadline has expired. At this point at the latest, legal advice pays off.
Keep an eye on limitation
Negotiations about the defect suspend the limitation period, while an acknowledgement by the agency restarts it under section 212 BGB. Document both in writing.
What happens, in which browser, with which payment or shipping method and since when. Attach screenshots, error messages from the log and the order numbers of affected transactions.
Name the agreed function or the test case from the acceptance record that is not met. This decides whether it is a defect or a new request.
In writing and with a specific date. What is reasonable depends on severity: a checkout that accepts no orders warrants a shorter deadline than a display fault in the footer.
If the final invoice is still open, section 641(3) BGB allows a reasonable part of the fee to be withheld, as a rule twice (BGB) the costs required to remedy the defect.
Self-remedy, price reduction, withdrawal or damages generally only come into consideration after the deadline has expired. At this point at the latest, legal advice pays off.
Negotiations about the defect suspend the limitation period, while an acknowledgement by the agency restarts it under section 212 BGB. Document both in writing.
The deadline is not a formality. Without it, there is usually no basis for reimbursement of self-remedy costs, unless subsequent performance has failed, has been seriously and definitively refused or is unreasonable for the operator (section 637(2) BGB). Even when a defect is slowing down sales and another provider could fix it quickly, the request to the agency therefore comes first. If checkout fails completely, a short deadline is reasonable; in parallel, emergency support can keep operations safe as long as the fault and the measures taken are documented.
Where maintenance takes over
A shop's environment does not stand still after acceptance. Chrome ships a new major version to the stable channel every two weeks (Chromium). If a layout breaks because a browser changes its behaviour, the work was usually not defective at acceptance. It can be different if the contract promised the function in specific browsers and the fault already existed in exactly those versions at acceptance. Ongoing adaptation to new versions is upkeep, and in a shop with its own theme and extensions it is needed regularly.
The same applies to PHP. A release branch reaches its end of life after four years (PHP Group) of support. For PHP 8.2, security support ends on 31 December 2026 (PHP Group). A shop accepted on PHP 8.2 was therefore not defective, but it has to be upgraded, and this upgrade is work that someone has to commission and pay for. Who handles which layer is clarified in the article hosting provider vs maintenance, and planning the upgrade itself in the article on PHP EOL management. The same holds for major core updates, as the article on WordPress 7.2 in the Christmas season shows.
The third source of change is the legislator. Under Directive (EU) 2023/2673, shops that conclude distance contracts with consumers via an online interface must offer a withdrawal function; member states apply the provisions from 19 June 2026 (EU Directive 2023/2673), and in Germany the obligation is set out in section 356a BGB. For a shop accepted before that date, the obligation did not yet apply at acceptance. Retrofitting is therefore usually not a defect but upkeep or a separate order, unless the contract expressly included implementing future obligations. What to check when retrofitting is described in the article on the withdrawal button in the shop.
Fault in one browser only
If the browser was within the agreed test scope and the fault already occurred at acceptance, much points to a defect. If it only appears with a later version, it points to maintenance.
Extension broken after update
If a function breaks after an update installed after acceptance, the cause usually lies in that change and not in the accepted work.
Slow under load
A defect is more likely if loading time or load capacity was agreed and the accepted state already missed it. Without an agreement, the usual quality is the benchmark.
New security vulnerability
If a vulnerability in a component in use only becomes known after acceptance, closing it is usually a task for maintenance through regular security updates.
Wrong data since launch
If the import during setup transferred prices or tax rates incorrectly, the fault was in the work. That goes to the agency as a defect.
Request for a new feature
A filter that was not in the contract is not a defect even if it seems standard today. It is a change request and a separate order.
What a maintenance contract covers from day one
Defect claims and maintenance do not exclude each other; they run side by side. The agency's warranty covers the accepted state, not its upkeep. The maintenance contract covers upkeep, not the project's defects. If maintenance only starts once the defect period has expired, the shop is left until then without updates, monitoring and a contact for everything that is not a warranty matter. Conversely, if the maintenance contract is structured as a contract for work, faulty maintenance services can also trigger defect claims, because section 634a(1) no. 1 BGB expressly mentions the maintenance of a thing. Whether a maintenance contract is a contract for work or for services depends on whether a result or an activity is owed (sections 611, 631 BGB).
Under the SLA maintenance contract, support starts with system documentation: platform, extensions, hosting configuration, external services and critical dependencies are recorded. After that, the contract includes among other things security updates for the shop system, extensions and server software, monitoring with alerting, backup verification, incident handling by priority and monthly status reports, for Shopware as well as for WordPress. New features and complex migrations to new platform versions are offered separately on a time-and-materials basis. This split mirrors the one between maintenance and change request.
| Task in the first year | Project agency | Maintenance | Operator |
|---|---|---|---|
| Defects in the accepted state | Subsequent performance | Document and report to the operator | Set a deadline, reserve rights |
| Security updates | Only if contractually agreed | Review and install | Commission maintenance |
| Browser and PHP changes | Not owed unless promised | Test, adapt or quote the effort | Approve the upgrade |
| New features | New order | New order | Commission and accept |
Which content a contract needs, from service catalogue to term, is covered in the article maintenance contract: what to include. Which response times can realistically be promised and how incidents are classified by severity is explained in the article on the response time SLA.
Handover from the project agency to maintenance
Project and operations are often in different hands: one agency builds the shop, another provider takes over maintenance. The handover is then the moment that decides whether defects and upkeep stay cleanly separated later on. Maintenance needs credentials, the repository and documentation, and it needs the list of open defects so that it does not quietly fix them along the way.
Quietly fixing them is a typical trap. If the maintenance provider repairs a project defect before the agency has had a deadline for subsequent performance, there is usually no basis under section 637 BGB for reimbursing these costs. At the same time, the fault that would be needed as evidence disappears. The better order is: document the fault, report it to the operator, set a deadline for the agency, and only in genuinely urgent cases put a temporary safeguard in place that records the fault beforehand. The handover record should contain:
- Transfer credentials for hosting, shop administration, repository, domain and payment providers to the operator and pass them on to maintenance.
- Take over the version state and environment from the acceptance record and check them against the running system.
- List open defects, reservations and running deadlines towards the agency separately.
- Record responsibilities: who reports faults, who fixes them and who approves changes.
- Log the first maintenance run with backup verification and update status so that the starting state is documented.
When switching from another provider, we coordinate the handover under the SLA maintenance contract directly with the previous provider. How a takeover works step by step is described in the article on taking over shop maintenance. If you want to clarify before go-live how project and operations fit together, you will find an overview of all services or can write to us via the contact page.
Sources
Related Articles
What Does Shop Maintenance Cost? The Key Cost Drivers
What shop maintenance costs depends on extensions, custom code, integrations and response time. How to plan a 2027 maintenance budget you can justify.
Fake Service Provider Calls: Protecting Shop Access
Fake hosts and agencies call asking for a password, a code or an MFA reset. Callbacks, a code word and two-person approval keep your shop access protected.
Statutory warranty label 2026: keeping product pages current
From 27 September 2026 product pages need the harmonised warranty notice and, where it applies, the durability label. Three zones, checkpoints, evidence.