A complaint is rarely just a technical problem. It is a case with running deadlines, several people involved and a question of proof - and in many companies it travels through channels that leave no trace: a call to reception, a forwarded email, a note on the machine, a promise made in passing. When someone asks weeks later on which day the defect was reported, who inspected it and what happened next, the search begins. This article describes which periods run from the delivery of goods, which records should be created on the case so that your own position stays provable, and how to map both in a digital workflow without turning it into a large project. It sets out the legal framework in descriptive terms and does not replace legal advice on an individual case. How we record such a workflow on site is described under process analysis.
Key points
- Claims for defects in the sale of movable goods become time-barred after two years, and after five years for a building and for goods used for a building; the period starts on delivery (German Civil Code).
- In a consumer sale, if a deviating condition appears within one year of the passing of risk, the goods are presumed to have been defective at that moment; for goods with digital elements this presumption covers a period of two years (German Civil Code).
- In a sale that is a commercial transaction for both sides, the buyer must inspect the goods without undue delay after delivery and give notice of any defect without delay; dispatching the notice in good time preserves the buyer's rights (German Commercial Code).
- Withdrawal in distance selling is a different matter from a complaint: consumers have 14 days to withdraw without giving any reason (Consumer Rights Directive).
- What decides a case in practice is not knowledge of the sections but the record: date of receipt, source document, batch, inspection result and outcome of the remedy, all on one numbered case.
What a complaint actually sets off
Behind the word complaint sits a chain of at least six steps. The report arrives and has to be accepted. It has to be linked to a source document, meaning an invoice, a delivery note, a batch or a serial number. The reported condition has to be inspected, either in house or at the customer site. A decision has to be made on how to respond. The remedy has to be provided and documented. And the case has to be closed with an outcome that is still readable later. Anyone who writes this chain down once usually sees straight away that it crosses three to five departments and that responsibility becomes unclear between the handovers. How such handovers can be mapped cleanly is described in our article on digitising approval workflows.
The real problem is rarely the processing. It is the trail. A report by telephone leaves no date. An email forwarded to three colleagues leaves three different versions. A photo on a work phone leaves no link to the source document. When a case becomes contentious later, exactly three pieces of information are wanted: when it was reported, what was found, what was supplied. A company that already captures incoming paperwork in a structured way - we describe that approach under document digitisation - takes the shorter route here, because the filing structure already exists and only one more case type is added.
The commercial lever sits in processing time. Companies in manufacturing and the service sector in Germany paid an average of 45.00 euros for one hour worked in 2025 (Federal Statistical Office). A complaint that is picked up, searched for and explained again four times between sales, warehouse and service quickly consumes four hours of pure processing time - around 180 euros in staff costs alone, before anything has been replaced or repaired. Across 200 cases a year that adds up to a five-figure sum. How to estimate such costs per case in a defensible way, without getting lost in assumptions, is set out in our article on what a single case really costs.
Why this gets left undone
Which periods run from delivery
The starting point is a single provision. If the goods are defective, the buyer may under section 437 of the German Civil Code demand a remedy, withdraw from the contract or reduce the purchase price, and claim damages or reimbursement of futile expenditure (German Civil Code). These three routes are not freely interchangeable but staged: the remedy comes first, and under section 439(2) the seller has to bear the expenditure required for it, expressly including the costs of transport, travel, labour and materials (German Civil Code). For a company that means these costs arise, they belong in the calculation, and they belong on the case so that they can be evaluated afterwards.
How long claims can be pursued is governed by section 438. Claims for defects become time-barred after two years as a rule; for a building, and for goods that have been used for a building in accordance with their customary use and have caused its defectiveness, the period is five years; a period of 30 years applies where the defect consists in a right in rem of a third party on the basis of which the goods can be reclaimed (German Civil Code). The start of the period is the real trap in day-to-day work: the limitation period starts on transfer of possession for land and, in all other cases, on delivery of the goods (German Civil Code) - so not on the invoice date, not on the order date and not on the day the item was put into service. A system that does not know the delivery note cannot calculate the period correctly.
Reference date = delivery per delivery note (not the invoice date)
Standard case delivery + 2 years limitation of claims for defects
Building delivery + 5 years building and goods used for it
Right in rem delivery + 30 years third party claim for return
Burden of proof risk + 1 year consumer sale, presumption
Digital elements risk + 2 years goods with digital elements
Commercial sale delivery + without undue delay inspect and notify
Distance selling receipt + 14 days withdrawal, no defectThe rule that matters most in practice sits in section 477. If a condition deviating from the requirements appears within one year of the passing of risk, the goods are presumed to have already been defective at the passing of risk, unless that presumption is incompatible with the nature of the goods or of the deviating condition (German Civil Code). For goods with digital elements where continuous provision has been agreed, the presumption applies if the deviating condition appears during the period of provision or within two years of the passing of risk (German Civil Code). That reverses the burden of proof: within this period the seller has to show that the goods were sound on handover. Anyone without that record loses the case regardless of how good the product actually was. For the same reason it is worth looking at how long documents have to be retained at all; we have put that together in our article on meeting retention periods digitally.
Commercial sales: notice sets the pace
Between businesses an additional duty applies that many companies underestimate. If the sale is a commercial transaction for both sides, the buyer must inspect the goods without undue delay after delivery by the seller, to the extent this is practicable in the ordinary course of business, and give notice of any defect without undue delay (German Commercial Code). If notice is omitted, the goods are deemed approved. One provision takes the pressure off: dispatching the notice in good time is sufficient to preserve the buyer's rights (German Commercial Code). The proof of dispatch is therefore the decisive document for both sides - and it is precisely what is missing when the notice was given by telephone.
For your own workflow this leads to a very concrete requirement. Every incoming complaint needs a machine-generated date of receipt, the channel it came through, and the wording or at least a structured summary of the condition being complained about. Anyone buying goods needs the counterpart - the documented time of their own incoming goods inspection. On the shop floor this often exists already and is simply not read out; how such feedback can reach a system without paper is described under shop floor feedback without paper.
At European level the same orders of magnitude apply. Under the Sale of Goods Directive the seller is liable to the consumer for any lack of conformity which exists at the time of delivery and which becomes apparent within two years of that time (Sale of Goods Directive). Where a lack of conformity becomes apparent within one year of delivery, it is presumed to have existed at the time of delivery (Sale of Goods Directive). In addition, member states may maintain or introduce provisions under which the consumer has to inform the seller of a lack of conformity within a period of at least two months from the date on which it was detected (Sale of Goods Directive); the German legislator has not made use of that option for consumer sales. Withdrawal has to be kept strictly separate: in distance selling the consumer has a period of 14 days to withdraw from the contract without giving any reason (Consumer Rights Directive) - no defect is needed for that. Anyone who mixes both case types ends up measuring metrics that say nothing. That deadline-bound reporting duties are also spreading outside sales law is shown by the 24-hour reporting process under the Cyber Resilience Act.
Date of receipt
Set by the system, not typed in afterwards. It anchors every deadline and every later evaluation of throughput.
Document link
Invoice, delivery note, batch and serial number on the case. Without that link the day of delivery cannot be established.
Condition on arrival
Photos, measurements, inspection report. Dated and attached to the case, not sitting in a folder on one device.
Wording of the report
What the customer complained about, in their own words. Later summaries lose exactly the detail that matters.
Decision with reasons
Remedy, goodwill or rejection, each with a reason and the name of the person who decided.
Outcome of the remedy
What was supplied or repaired, when it reached the customer and which expenditure was incurred.
Evidence is created during the case, not after
The most common mistake in complaint handling is trying to produce the record retrospectively. Six months after delivery a colleague is asked whether he remembers if the seal was replaced back then. Even if he does remember, a memory is not a record. Solid evidence is created at the moment the work is done, and it is only created when capturing it costs less effort than not capturing it. That is where many rollouts fail: the form has 24 mandatory fields, the inspection takes two minutes and filling in the form takes seven.
The counter-test is simple. Take a closed case from last year and try to answer five questions from the existing documents alone. On which day was it delivered? On which day did the complaint arrive? What exactly was complained about? What was inspected and with what result? What was provided, when and at what cost? If you have to call someone for any of these questions, the record is incomplete. In practice it is usually the fourth question that fails - the inspection result exists as a note, not as a dated entry.
Two moves reduce the effort of capturing data noticeably. First, pre-fill fields wherever the information already sits in the system - customer data, item and delivery date come from the source document, not from the keyboard. Second, read incoming paper and PDF attachments automatically instead of retyping them; what is realistically recognised and where the limits are is described in our article on text recognition in practice. Together the two bring a complaint form down to three to five entries, and from that size on it actually gets used. Which further steps can be repeated without human intervention is set out under process automation.
From a note to a case with a number
The difference between an unstructured and a structured complaints process comes down to a handful of points. It is not about documenting more, but about documenting the same things in one place where they will be found again. The comparison below shows what changes in practice.
The decisive technical point is the connection to the merchandise management or accounting system. If the case knows the invoice number, it also knows the delivery note and therefore the delivery date - and the period calculates itself. If it does not, someone types in a date, and the whole apparatus of deadlines rests on a manual entry. How such connections between existing systems can be built without replacing everything is set out under integrations. The documents created along the way are subject to the same requirements as other records that must be retained; we have described that in detail for GoBD-compliant document storage.
Three metrics that steer the workflow
A complaints process can be run on very few numbers. The first is the time from the report to the first substantive response to the customer. It says nothing about the solution but a great deal about perception: a customer who receives a reply with a case number within one working day gets in touch a second time less often - and every second report creates the same effort all over again. The second is the time from report to closure. That is the actual throughput time and shows at which station cases get stuck. The third is the share of cases with a recorded cause category. This metric is uncomfortable because it starts out low, but without it there is no basis for improving the product or the supplier relationship.
The reference population matters. A throughput time across all case types is worthless when distance-selling withdrawals and commercial notices of defect sit in the same list: one case ends with a return and a refund, the other can run for months. Calculated separately, both numbers say something. Which metrics smaller companies can realistically sustain and which ones nobody maintains after four weeks is described in our article on metrics that actually help; the technical side of the evaluation is set out under metrics and reporting.
Deadlines are not a matter of discretion
A second point is regularly underestimated. The knowledge of how a particular type of complaint should be handled often sits with one experienced person. When that person leaves, the judgement of which complaint is production-related and which is transport-related leaves with them. How to capture that knowledge before it goes is described under retaining company knowledge before people leave; the formal frame for it grows out of solid process documentation.
Which lever changes what
Not every step is worth the same. From our experience with process reviews in mid-size companies, the largest effect sits in the first two points of the list below, while the last two only make sense once the foundation is in place. The order is therefore not accidental.
- One shared inbox for all channels. Telephone, email and web form feed into the same set of cases. This is the step that turns scattered reports into a countable quantity in the first place.
- Automatic document links. Case creation pulls customer, item, delivery note and delivery date from the leading system instead of having them retyped.
- Deadlines on the case rather than in someone's head. The dates are derived from the delivery date and set as follow-ups, visible to the stand-in as well.
- Attachments where the case sits. Photos and inspection reports are stored on the case; an image in a chat thread does not count as a record.
- A short list of causes with eight to twelve entries. Longer and it stops being maintained, shorter and it says nothing. It is the precondition for any later evaluation.
- A monthly extract with three numbers. Response time, throughput time and the share with a recorded cause, split by case type and sent to the same recipients.
These six points can usually be built into existing systems. A dedicated complaints area inside the merchandise management system already in use is usually the calmer route than an additional tool, because customer and item master data then do not have to be maintained twice. Where the merchandise management system cannot do it, a lean interface of your own that reads and writes through an integration is enough.
What a company can prepare itself
Before any technical implementation comes a stocktake that needs no tools and can be done in house. Depending on company size it takes half a day to a full day and provides the basis for every later decision about systems.
- Pull ten closed cases from last year and run the five questions from the section on evidence against them. Note at which point someone had to be asked.
- List all the channels through which complaints actually arrive - including the informal ones: a call to the field sales rep, a message to the fitter, a remark during the next delivery.
- For each channel, record where the report currently lands and who moves it into the official workflow. Channels without a named person are the gaps in the system.
- Check whether the delivery date is available to a machine at all. If the delivery note exists only on paper, that is the first item on the implementation list.
- Draft a first list of causes and have two experienced colleagues read it back. Categories that cause arguments should be merged.
- Decide who receives the monthly extract and what happens with it. A metric without a recipient stops being maintained after a short time.
We did not document more than before, we documented it in one place. The difference showed up with the first contested case: instead of two days of searching, the complete history was on the table in four minutes.
The complaints process has more in common with dunning than it first appears. Both are deadline-bound, both live on a complete history, and both are handled reluctantly in smaller companies. Anyone who tidies up one has done half the groundwork for the other - we have described how to automate dunning for faster payment without sharpening the tone towards customers.
Sources and studies
Related Articles
Retaining company knowledge before experience leaves
Capturing head knowledge, documenting critical workflows and testing the stand-in before an experienced colleague leaves: schedule, metrics and sources.
Choosing Business Software: Requirements Come First
How to decide before you buy: measure the volume baseline, write a lean requirements document in a week, score vendors by weight and check the contract terms.
Reading processes from system data: where it snags
How to reconstruct the actual workflow - loops and special paths included - from the timestamps your systems already record, instead of guessing or estimating.