Are Post-Delivery Bugs Fixed Free? Liability & Warranty

After a system is delivered, you may find defects: a screen that misbehaves, a calculation that comes out wrong. The first question most business owners ask is whether the developer will fix it for free or whether it will cost extra. The answer depends on two things: "nonconformity liability" (契約不適合責任) in a contract for work under Japanese civil law, and the warranty period written in your contract. This article explains, for non-IT readers, what changed in the 2020 Civil Code reform, which problems are usually fixed free of charge and which are not, how a warranty period differs from a maintenance contract, and what to check in the contract. Because defects are first caught during acceptance testing, we also cover how the two relate.

Whether a post-delivery bug is fixed for free is mainly decided by three points: (1) whether the contract is a contract for work (請負) or a quasi-mandate (準委任), (2) whether the problem is a failure to conform to the contract, and (3) whether it falls within the warranty period and outside the contract's exclusions. "There is a bug" alone does not automatically mean a free fix. Conversely, even if the contract is silent, the Civil Code may still give you remedies. Keeping these three viewpoints in mind makes it easier to read your contract and your deliverables calmly.

The Civil Code reform that took effect on April 1, 2020 replaced the old "defect liability" (瑕疵担保責任) with "nonconformity liability" (契約不適合責任). It was not merely a rename. Previously the question was whether there was a "hidden defect." Now the standard is whether what was delivered conforms to the contract in type, quality, and quantity. In other words, the test is not whether a flaw is visible, but whether it matches what was promised. In software projects the promise is usually found in the requirements document or specification, so well-maintained documents matter a great deal.

As the table shows, in a contract for work the client generally preserves its rights by notifying the contractor within one year of learning of the nonconformity. That year is a deadline for giving notice, not a deadline for finishing the repair. The time limit is generally said not to apply if the contractor knew of the nonconformity at delivery, or was grossly negligent in not knowing. After notice, the rights themselves are usually described as subject to the ordinary statute of limitations for claims: five years from when you learn of them, or ten years from when they could first be exercised.

When there is a nonconformity, the client is generally said to have the following four options. Which one is actually available depends on the circumstances, so the conditions and order should be checked.

- Request for cure (repair): ask the contractor to fix the problem. In software this means bug fixes or rework
- Price reduction: in principle, you first ask for a cure and may ask for a reduction if it is not made within a reasonable period
- Damages: compensation for losses caused by the defect. This generally requires a reason attributable to the contractor
- Rescission: ending the contract when the defect is serious and the purpose of the contract cannot be achieved. Minor nonconformities are unlikely to qualify

In practice, the usual path is to ask for a fix first rather than jump to a price reduction or rescission. Rebuilding software takes time and money, so both sides typically discuss the scope and deadline of the fix.

The Civil Code period (notice within one year of learning of the problem) is generally considered a default rule that the parties can change by agreement. That is why software contracts usually state a period such as "within six months after acceptance is completed" or "within one year of delivery." Two things deserve attention: a short period, and the starting point, whether it is the delivery date or the acceptance date, which changes the time you actually have. If you start using a system months after acceptance, a defect in a feature used only once a year, such as year-end processing, may not surface within the warranty period. Compare the contract period against your own business calendar.

Nonconformity liability is typically at issue in a contract for work (請負), where the contractor promises to complete a result. A quasi-mandate (準委任) is a promise to perform services, not to deliver a finished product. A liability of the same form is therefore less likely to arise; instead the question is whether the contractor exercised the care expected of a professional (the duty of care of a prudent manager). Lab-type and agile development are often contracted as quasi-mandates, so a free bug fix is not guaranteed. To tell which you have, look beyond the contract title to how payment works (per deliverable, or by effort or monthly fee) and whether completion is an obligation. See contract for work vs. quasi-mandate for details.

The most common point of confusion in practice is where to draw the line. The basic idea is whether the result differs from what the contract or specification promised. The following are general guidelines, and the final judgment depends on the contract and circumstances.

Disputes tend to arise over "obvious behavior that was not in the specification" and over performance. A request made only verbally is hard to prove later as part of the promise. Recording requests in email or meeting minutes often decides whether a free fix is possible. For how to tell these from extra work, and how to avoid cost disputes, see patterns that trigger extra costs.

A warranty period does not mean you are covered forever. It is an agreement that fixes for deliverables that do not match the contract will be done free of charge for a set time. A maintenance contract, by contrast, is an ongoing, fee-based arrangement that covers not only defect repair but also inquiries, monitoring, minor changes, and update support. The two are easily confused, so the table below compares them.

If a defect is found after the warranty period, a shortened contractual period generally takes precedence even if the Civil Code period would still be running. It is also wise to decide before the warranty ends whether to sign a maintenance contract, so you are not caught unprepared afterward. For what to check in a maintenance agreement, see maintenance contract checkpoints.

Clauses on nonconformity liability and warranty are often grouped under headings such as "Nonconformity Liability," "Warranty," "Defects," "Damages," and "Exclusions." Before signing, check the following.

- Period and starting point: from the acceptance date or the delivery date, and for how long (3 months, 6 months, 1 year)
- Notice method: in writing, by email, or through a form; whether notice within the period is enough or the fix must be completed in it
- Remedy: whether free repair is the baseline, and whether replacement or price reduction is mentioned
- Exclusions: when the contractor is not liable (client instructions, third-party services, user fault, force majeure)
- Damages cap: often limited to the contract price; whether lost profits are included
- Scope of liability: how defects caused by third-party libraries, open-source software, or cloud services are treated
- Recurrence: whether the same defect returning is covered free, and how regressions caused by a fix are handled

The damages cap is easy to overlook. Even if a defect causes large business losses, compensation may be limited to the development fee. For systems that run core operations, check this cap in advance, along with fallback procedures such as manual workarounds.

Before contacting the contractor in frustration, organize the facts as follows. It is especially important to leave a record that you gave notice within the period.

1. Record the symptoms: when, who, which screen, what action, what result. Keep screenshots or video
2. Write down the steps to reproduce: confirm it happens again and list the steps
3. Assess the impact: does it stop operations, is there a workaround, how urgent is it
4. Give notice in writing or by email: do not rely on phone calls alone; use the method specified in the contract and leave a record
5. Check the period and scope in the contract: within the warranty, not excluded, and when the period started
6. Discuss and agree: confirm in writing the scope, deadline, cost responsibility, and prevention of recurrence

The contractor may also respond that the behavior matches the specification and is not a defect. In that case, ask where the specification or meeting minutes say so, and if the views still differ, consider getting an opinion from an independent expert.

Fixes made after the warranty period, or fixes that are not nonconformities, are generally paid work. Costs vary widely by system size, structure, and content, but they are commonly described roughly as follows. These are guidelines only; confirm actual amounts in a quote.

- Minor fixes (wording, display adjustments, small bug fixes): roughly tens of thousands to a little over 100,000 yen
- Mid-size changes (screen revisions, added reports, data integration adjustments): from several hundred thousand yen as a guide
- Maintenance contract (with a fixed allowance of support and minor fixes): commonly tens of thousands to over 100,000 yen per month
- Urgent response (night or holiday outage recovery): may carry a surcharge

Whether to pay per fix by quote or sign a flat-rate maintenance contract depends on how often you need changes and how badly downtime would hurt your business. If changes are frequent, maintenance can end up cheaper. It is reassuring to ask about the pricing approach before a fix is actually needed.

Whether a post-delivery bug is fixed free of charge can be sorted by three questions: the contract type (work or quasi-mandate), whether it is a nonconformity, and whether it is within the warranty period and exclusions. The 2020 reform turned defect liability into nonconformity liability, and for contracts for work the baseline is notice within one year of learning of the problem. Since the period can be changed by contract, the written terms come first in practice. Before signing, check the period and its starting point, the notice method, exclusions, and the damages cap, and keep specifications in writing. For pre-delivery checks, see also how to run acceptance.

Note: this article provides general information and is not legal advice. For the interpretation of a specific contract or an actual dispute, please consult a lawyer or other qualified professional.