Software Warranty & Defect Liability Clauses Singapore

Short answer: in a Singapore custom software contract, the warranty clause should promise that the delivered system conforms to the requirements you accepted, for a defined period that starts at acceptance or go-live (not at signature). It should come with a severity matrix, cure clocks that start when the vendor has reproducible evidence, and a clear line between defects, change requests and AMS work. Defect liability then sets who pays for remediation and how that sits under the liability cap.

This guide is for Singapore IT, legal and procurement sponsors negotiating a build with a custom software partner in Singapore, including teams with Philippines delivery capacity. It is buyer guidance, not legal advice, and it invents no uptime or defect-rate figures. If you are still choosing a vendor, start with the SOW red flags Singapore procurement teams should catch, then come back to the warranty schedule.

What “warranty” should actually cover

Separate workmanship warranty (the build conforms to agreed specs and acceptance criteria) from ongoing service commitments that belong in AMS. Mixing them creates disputes when a “defect” is really a change request or an environment issue outside the vendor’s control.

Conformance to documented functional and non-functional requirements accepted at UAT or go-live.
Material deviation from agreed architecture constraints that were signed as baselines.
Regressions introduced by vendor-delivered patches during the warranty window.
Security defects that violate stated controls in the security schedule—not every CVE ever published.
Clear exclusion for buyer-caused changes, third-party SaaS outages, and undocumented integrations.
Named environments and data classes the warranty assumes (production versus lower environments).

Defect severity and cure periods buyers should negotiate

Sev-1: production stoppage or data integrity risk—response and restore clocks in hours, not “best effort.”
Sev-2: major feature degraded with workaround—cure window measured in business days with escalation.
Sev-3/4: minor defects and cosmetic issues—batched into scheduled releases with transparent queues.
Cure period starts when the vendor has reproducible evidence, not when a chat ping arrives.
Define “workaround accepted” so Sev-1 is not artificially open forever.
Require a written root-cause note for Sev-1/2 before closing the ticket.

Map severity language to how your Singapore operations actually declare incidents. If your NOC uses different labels, align the contract glossary or you will argue definitions during an outage.

Evidence and acceptance of a fix

Steps to reproduce, expected versus actual, and environment identifiers attached to every defect.
Regression evidence for the failing scenario plus neighbouring critical paths.
Buyer sign-off owner named for Sev-1/2 closures—not informal chat approval alone.
Retention of defect artefacts for the warranty term for audit and AMS handover.
Explicit rule when a fix is rejected and the cure clock pauses or restarts.
Link every closed Sev-1/2 to a runbook update when the failure mode is repeatable.

Liability caps, exclusions, and IP interplay

Defect liability should sit beside indemnity and IP assignment schedules—not contradict them. Caps often exclude wilful misconduct and data breach categories; make sure warranty remediation costs and breach remedies are not double-counted or accidentally waived. Pair with exit metrics and change-order discipline so warranty does not become a free backlog for new scope.

State whether warranty remediation burns remaining fixed-price contingency or is uncapped within a liability ceiling.
Exclude enhancements dressed as defects via a joint triage rule.
Preserve buyer IP and environment access needed to validate fixes after vendor staff rotate.
Require knowledge transfer of fixes into runbooks before warranty ends.
Align change-order schedules so disputed “defects” have a commercial path.

How Singapore sponsors should run warranty readiness

Before go-live, freeze the accepted baseline, defect backlog disposition, and known residual risks. During warranty, hold a weekly triage with legal visibility only when commercial disputes appear. Keep the warranty tracker in the same place as the UAT defect log, and connect delivery expectations to how you buy custom software in Singapore.

Common failure modes

Warranty that starts at contract signature instead of acceptance or go-live.
No severity matrix—everything becomes “urgent” or nothing does.
Cure clocks that ignore missing reproduction steps from the buyer side.
Warranty used as a substitute for an AMS schedule after month three.
Silent waiver of rights through informal email approvals without schedule updates.
No link between warranty exit and AMS handover artefacts.

Negotiation checklist before you sign

Glossary aligned with your incident and UAT severity language.
Start and end dates, extensions for Sev-1 open items, and Singapore holiday calendars.
Named contacts and escalation ladder on both sides.
Change-order path when “defect” is actually new scope.
Exit metrics and documentation pack when warranty closes.
Overlap hours for Singapore and any Philippines delivery remediating under warranty.

Singapore-specific points to raise with counsel

Most warranty disputes are commercial, not legal, but a few Singapore realities change how the clauses should be drafted. Bring these to your counsel rather than relying on a vendor template.

Governing law and forum. State Singapore law and the dispute forum explicitly (Singapore courts or arbitration seated in Singapore), and make sure the warranty, AMS and SOW schedules all point to the same clause.
Exclusion and limitation clauses. Broad exclusions can be tested for reasonableness under the Unfair Contract Terms Act, particularly on one side’s written standard terms. Negotiated, specific exclusions are easier to defend than blanket ones.
PDPA overlap. A security defect that exposes personal data is also a data breach question. Under the PDPA, organisations must notify the PDPC within three calendar days of assessing that a breach is notifiable, so security defects cannot wait for a weekly warranty triage. Write a fast path into the severity matrix.
Business days and holidays. Define “business day” against the Singapore public holiday calendar, and say how Philippines holidays affect remediation if part of the team sits in Manila.
Acceptance evidence. The warranty only works if acceptance was evidenced. Pair the clause with an acceptance-test evidence pack so “conforms to requirements” has something to point at.

From warranty to AMS: closing the window cleanly

The warranty window should end with a handover, not a cliff. Before it closes, agree which open defects carry over, which become backlog items, and which service levels take over under an AMS schedule. Use hypercare exit criteria for the first weeks after go-live, then negotiate the steady-state terms with the Singapore AMS SLA negotiation guide. If continuity risk is high, add software escrow release events so a vendor failure after warranty does not strand the codebase.

Open Sev-1/2 items at warranty end extend the warranty for those items only.
Every closed Sev-1/2 has a root-cause note and a runbook update before handover.
Regression suites and test data are handed over so the AMS team can prove fixes. A quality engineering baseline makes this far easier.
Repository, pipeline and environment access is confirmed for the buyer, not only the vendor.

Ownership and licence scope also affect what the vendor can actually remediate. See background IP and open-source licence-backs when warranty schedules assume full control of the codebase.

Frequently asked questions: software warranty clauses in Singapore

When should a software warranty period start in a Singapore contract?

At acceptance or go-live, whichever the contract treats as the point the buyer relies on the system. A warranty that starts at signature can expire before real users touch production. The length is a commercial decision; the start trigger and the rule for extending open Sev-1 items matter more.

What is the difference between a defect and a change request?

A defect is a failure to meet requirements or acceptance criteria that were agreed and evidenced. A change request is new or different behaviour. Agree a joint triage rule and a change-order path so disputed items have a commercial route instead of a stand-off. Our change orders guide covers the mechanics.

Is a warranty the same as application support or AMS?

No. Warranty covers the vendor fixing its own non-conforming work for a limited period. AMS is an ongoing service with response and restore clocks, monitoring and problem management. Mixing them usually means the warranty quietly turns into unpaid support.

How do warranty clauses interact with the PDPA?

If a defect exposes personal data, the organisation may have to assess and notify a data breach to the PDPC within three calendar days of deciding it is notifiable. Give security defects that touch personal data their own fast path, named owners, and evidence rules in the warranty schedule.

Does the liability cap limit warranty remediation?

It depends on the drafting. State whether remediation costs sit inside or outside the cap, whether they draw down fixed-price contingency, and which categories (for example data breach or wilful misconduct) are carved out. Avoid wording that double-counts or accidentally waives remedies.

Singapore Software Warranty and Defect Liability Clauses: A Buyer’s Negotiation Guide