Website Acceptance: Secure the Burden of Proof

What acceptance actually triggers

A relaunch, a new shop, a booking portal: whoever owes a result works under the law of contracts for work. Section 631(1) of the German Civil Code (BGB) puts it briefly - the contractor is obliged to produce the promised work, the customer to pay the agreed remuneration. Acceptance is the moment at which the customer takes delivery of that work as substantially in conformity with the contract. A German legal dictionary defines it as a declaration by the customer that the work meets the contractually agreed requirements and was therefore performed in conformity with the contract (JuraForum). That declaration needs no form and no calendar entry: it can be express, it can follow from conduct, or it can arise by operation of law. Which is precisely why, in website projects, it often happens without either side noticing.

The consequence is not symbolic but procedural. Section 363 BGB shifts who has to show what: once the creditor has accepted a performance offered as fulfilment, the burden of proof is on that creditor if they later wish to argue that the performance was a different one than owed, or incomplete. Translated into project life: before acceptance, the agency shows that its work is free of defects. After acceptance, the client shows that a defect exists - and that it already existed at the time of acceptance. The same dictionary states that after acceptance the burden of proving that defects actually exist lies with the customer (JuraForum). Read that sentence once properly and it becomes obvious why an acceptance meeting without measured values is a bad idea for both sides.

• Express acceptance - a declaration, usually a signed report. The clean case, because date, scope and any reservations are on record.
• Acceptance by conduct - the client goes live, publishes content, advertises the site and settles the final invoice. A declaration without words that carries the same legal weight.
• Deemed acceptance - after completion the contractor sets a reasonable period, and the customer stays silent or names no defect at all (Section 640(2) BGB).
• Partial acceptance - separable parts of the work are accepted on their own, for example accessibility before the editing system, or the interface before the front end.
• Completion instead of acceptance - where the nature of the work rules acceptance out, completion of the work takes its place (Section 646 BGB).

Four of those five routes work without any report at all. That is the real finding: in website projects acceptance is rarely a meeting and usually a point in time that only the dispute reconstructs afterwards. A dated measurement report turns that point in time into a verifiable fact - for both sides, because it protects the agency against late assertions just as much as it protects the client against an acceptance they never meant to declare.

Five effects that all start on the same day

Acceptance is first of all a duty of the customer: under Section 640(1) sentence 1 BGB the customer is obliged to accept work produced in conformity with the contract, unless acceptance is ruled out by the nature of the work. The next sentence draws the line - acceptance may not be refused on account of insignificant defects. A slightly different shade of grey in the footer is insignificant; a checkout that breaks on a phone is not. Refuse acceptance over trivia and you fall into default of acceptance yourself; declare it while knowing about a material deviation and you lose rights.

The same declaration starts four further effects. Remuneration falls due - under Section 641(1) sentence 1 BGB it is payable upon acceptance of the work - and from that point it bears interest unless payment has been deferred (Section 641(4) BGB). Risk passes: the contractor bears the risk until acceptance of the work (Section 644(1) sentence 1 BGB). And the limitation period starts: claims for defects in a work whose result consists in the production, maintenance or alteration of a thing become time-barred in two years (Section 634a(1) no. 1 BGB), and that period begins with acceptance (Section 634a(2) BGB). Only where the contractor fraudulently concealed a defect does the standard limitation period apply (Section 634a(3) BGB).

Deemed acceptance has long been the normal case

Since 2018 nobody has to wait for the client's signature. Under Section 640(2) sentence 1 BGB a work is also deemed accepted where the contractor has set the customer a reasonable period for acceptance after completion and the customer has not refused acceptance within that period while naming at least one defect. So anyone who reports completion and sets a period gets their acceptance even if the contact person is on holiday. That sounds convenient, and it is - as long as there is a record of which condition was actually accepted.

1. Report completion - in writing, with a date and a list of what is finished. Without completion no period runs.
2. Set a reasonable period - for a typical corporate website two weeks is a common approach; complex shops need more. The period has to fit the inspection task, not the payment terms.
3. Attach the measurement report - a client can only inspect what they can see. A dated report makes the period robust because it describes the object of acceptance.
4. Give consumers the extra notice - in text form, together with the request, otherwise the effect does not arise.
5. Record the expiry - one entry in the project log with date and time. It later anchors both limitation and interest.

The fourth point gets missed regularly. Where the customer is a consumer, Section 640(2) sentence 2 BGB makes the effect conditional on the contractor having pointed out, together with the request for acceptance, the consequences of not declaring acceptance or refusing it without naming defects - and that notice has to be in text form. With sole traders, associations and medical practices it pays to look at the client's role before relying on the fiction. Anyone who ties completion to a planned maintenance window anyway has already documented the point in time cleanly.

Which measured values belong in the report

The yardstick for a defect sits in Section 633(2) BGB: the work is free of material defects if it has the agreed quality. Agreed means what the contract says - and in website projects the contract usually says prose. "Modern, fast and accessible design" is not a quality, it is a statement of intent that anyone can argue about. It becomes measurable only once a target value from a named source stands next to it. Accessibility offers exactly such a yardstick: "Level AA conformance For Level AA conformance, the web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided" (W3C). That makes WCAG 2.2 level AA an agreeable quality. An adjective is not.

• Text contrast - "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1" (W3C, success criterion 1.4.3). The report carries the lowest measured value per template, not an average.
• Target size - "The size of the target for pointer inputs is at least 24 by 24 CSS pixels" (W3C, success criterion 2.5.8). Measure on the phone, because that is where the exceptions bite.
• Structure and operability - heading hierarchy, keyboard-only operation, form labels. A WCAG scan as an annex fixes the state of findings with a date.
• Transport encryption - protocol versions, certificate validity, redirect chain. A certificate check returns a value rather than an impression.
• Security headers - which headers are set and with what content. This is the part a client never verifies themselves and the first thing questioned after an incident.
• Availability across the acceptance period - a measurement series over the period instead of a glance on the afternoon of the meeting.

These values share one property that makes them usable in a report: they are reproducible and they are datable. A scan with a report produces them in one pass and stores them as a file, instead of demonstrating them in a meeting. Whatever was shown on screen and not saved does not exist once there is a dispute.

Thresholds that work as agreed quality

With speed it gets more precise, because there are published thresholds and a published measurement rule. For assessment, web.dev states that "a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices". That sentence is the real gain for an acceptance report, because it anticipates the most common objection. A single reading proves nothing, neither for nor against - so the sensible agreement is a percentile over a period, separated by phone and desktop.

Move those rows into the statement of work and an argument about impressions turns into a re-measurement. The values are not an end in themselves: they accumulate anyway once Core Web Vitals are collected continuously, and by the acceptance date they already exist as a series. One caveat belongs in the contract: field data does not arise in every browser, and the gap is systematic rather than random - what that means for assessment is set out in the analysis of the blind spot in field data.

The annex: a dated report instead of an assertion

An acceptance report has two parts. The first is the declaration: who accepts what on which date, subject to which reservations. The second is the annex, and that is where the evidential weight sits. What works is a single self-contained document that stays readable without the tool that produced it - a report as a PDF with generation date, measurement period, address list and raw values. Whatever exists only inside a software account may no longer be retrievable in three years; whatever sits as a file in the project folder still is.

The annex should be machine-generated rather than assembled. A report someone built by hand always carries the suspicion of selection; a report from a running process does not. The same applies to continuation: keep the measurement series running after acceptance and send the reports automatically, and every later point of dispute has an intermediate state attached - the mechanics behind that are covered in the article on client reports sent automatically.

{
  "project": "Corporate website relaunch",
  "acceptance": {
    "date": "2026-09-28",
    "basis": "Period set on 2026-09-11, 14 days",
    "scope": ["home", "services", "contact form", "blog detail"]
  },
  "measurement_period": { "from": "2026-09-14", "to": "2026-09-28" },
  "targets": {
    "text_contrast": "4.5:1",
    "target_size_px": 24,
    "lcp_seconds": 2.5,
    "inp_milliseconds": 200,
    "cls": 0.1,
    "basis": "75th percentile, separated by phone and desktop"
  },
  "findings": {
    "contrast": { "met": true, "lowest": "5.1:1", "page": "/services/" },
    "target_size": { "met": true, "lowest_px": 44 },
    "tls": { "versions": ["TLSv1.2", "TLSv1.3"], "certificate_until": "2026-12-19" },
    "headers": ["strict-transport-security", "content-security-policy", "x-content-type-options"]
  },
  "reservations": [
    { "item": "Print view of the detail page", "due": "2026-10-12" }
  ],
  "annexes": ["report-2026-09-28.pdf", "visual-state-2026-09-28.zip"]
}

Two fields in this structure carry the weight later. "basis" anchors what the date rests on, which makes a deemed acceptance just as provable as a signed one. "reservations" is the list that stops a known issue from being extinguished by acceptance - more on that in a moment. Everything else is measured value, and measured values age well as long as they are dated.

An acceptance report without measured values records that somebody agreed. It does not record what they agreed to. That gap is the space in which later claims grow.

— XICTRAQ

Reservations: what they save and what they do not

The harshest provision on this topic is Section 640(3) BGB: where the customer accepts defective work under subsection 1 sentence 1 although they know of the defect, the rights designated in Section 634 nos. 1 to 3 are available only if they reserved their rights on account of that defect at the time of acceptance. So anyone who knows the print view is broken and accepts without a reservation loses, for that item, subsequent performance, self-remedy and reduction of price. Damages remain, but that is the hardest route of all. In practice the damage rarely comes from bad faith; it comes from schedule pressure: it has to go live, the rest will sort itself out.

• Name it precisely - "layout shift in the offer grid on the phone", not "display problems". A vague reservation carries nothing.
• Attach a deadline - one date for the rework and one for the re-measurement. Without a deadline the item stays open forever and is forgotten anyway.
• Put it in the annex - the reservation belongs in the same file as the measured values, otherwise it is buried in an email thread within six months.
• Withhold payment proportionately - the route for that is in the statute and is a right, not an insult.
• Date the re-measurement - only the second measurement closes the item. An email saying "done" does not close it.

The baseline: what was added after acceptance

The most common real dispute is not the hidden defect but the later change. Six weeks after go-live the client reports that the site has become slow and a form no longer works. In the meantime their editorial team uploaded forty images, a service provider added a consent banner and somebody renewed the certificate. Without a baseline that is one assertion against another; with a baseline it is a difference. A change monitor with visual comparison records that starting state automatically, without anyone having to remember.

Those three lines do not replace a measurement series, but they show the principle: every value in the report is one the other side can reproduce at any time. That is what makes it robust. Keep the collection running and you also get the history of changes - the mechanics and their pitfalls are covered in the article on the automatic website changelog.

Partial acceptance, use, and the completion case

Larger projects run in stages, and acceptance can follow them. Partial acceptance needs separable parts of the work: the interface to the merchandise system, the accessibility work, the content migration. For each part the limitation period starts on its own, and for each part the reversal of the burden of proof applies on its own. That is an advantage for the agency and a risk for the client - so both sides should decide deliberately whether to agree partial acceptances instead of letting them arise in passing. Anyone migrating content knows the sequence from the article on switching over without losing traffic anyway.

One special case concerns ongoing services with no work character. Section 646 BGB applies there: where acceptance is ruled out by the nature of the work, completion of the work takes the place of acceptance in the cases of Section 634a(2) and Sections 641, 644 and 645. For maintenance and support contracts that means the clean cut is not an acceptance declaration but a clear description of what is owed - plus a measurement showing that it was delivered. Where the same question arises in continuous operation, the answer is an agreed measurement point; the article on the measurement point in the SLA works through that in detail.

Why a measurement report speeds acceptance up

The standard objection is that a measurement report merely hands the client ammunition. Experience says otherwise, for one simple reason: without a report the client inspects on their own, with a tool the agency does not know, on a device the agency does not know, at a moment the agency does not know. The result is a list of findings whose origin nobody can reconstruct. With a report the basis is fixed, the discussion revolves around named criteria, and acceptance becomes a comparison rather than a search.

Then there is the commercial side. Remuneration falls due with acceptance, and from acceptance it bears interest (Section 641(4) BGB). Every week an acceptance hangs undecided is a week of unpaid advance performance. A report that travels with the completion notice shortens that phase, because it fills the period with substance - the client does not first have to work out what to inspect. Anyone who hands over projects regularly knows the same effect from the handover protocol during an agency change: documented states end conversations, undocumented ones extend them.

What belongs in the contract before the first run

A measurement report is only as strong as the agreement it measures against. The most effective lever therefore sits in the proposal, not in the acceptance meeting. Four lines in the statement of work save four weeks of correspondence later, and they cost a quarter of an hour to write.

1. Name the target values - contrast ratio, target size, speed thresholds and the basis of assessment. Each with its source, so the value does not read as a house opinion.
2. Define the measurement scope - which templates, which device classes, which period. One address is not a scope.
3. Name the measurement method - who measures, with what, from where. Two measurement points return two numbers; without a rule, the less pleasant one wins.
4. Describe the acceptance procedure - completion notice in text form, the period, the form of a reservation, where the annex is stored.
5. Separate ongoing operation - whatever is measured after acceptance belongs in the maintenance contract, not in the acceptance report. Continuous availability measurement is a service of its own with a price of its own.

For agencies running several projects in parallel a template pays off: the same structure, the same target values, the same annexes. The report then becomes a standard part of the final invoice rather than an extra, and acceptance loses its exceptional character. How that can be organised across client accounts is shown in the overview for agencies - and anyone already running the measurement series across all client projects has the baseline for every new project ready on the day it goes live.