What Is A Deemed Acceptance Clause?

Jess runs a small software studio in Manchester. Her team builds a custom booking platform, sends the client a test version on time, and then... silence. Two weeks pass, then four. The client keeps saying they're too busy to review it, but Jess can't raise the final invoice until the work is approved.

If you deliver projects, software, design work, marketing assets or other client deliverables, this can feel incredibly frustrating. You have done the work, but your payment and next steps are stuck because the client hasn't formally signed off.

A deemed acceptance clause can help with this. Used properly, it gives your client a fair window to review your work, while stopping approval delays from dragging on indefinitely.

What Is A Deemed Acceptance Clause?

A deemed acceptance clause is a contract term that says your work will be treated as accepted if the client doesn't reject it, or request valid changes, within a set review period.

In plain English, it means silence can count as approval after a certain point.

For example, your contract might say:

• You submit a project milestone to the client.
• The client has 10 business days to review it.
• If the client doesn't give written feedback within that period, the milestone is deemed accepted.
• Once accepted, you can issue the next invoice or move to the next phase.

This kind of clause is common in deliverables-based contracts, such as:

• software development agreements
• website build contracts
• branding and design projects
• marketing retainers with campaign deliverables
• video, photography and creative production agreements
• consulting or implementation projects

The aim isn't to trap your client. A well-drafted deemed acceptance clause gives your client a real chance to review the work, while giving your business a clear process for moving forward.

How Does Deemed Acceptance Work In A Contract?

Deemed acceptance works by linking delivery, review, feedback and approval to clear deadlines in your contract.

Most clauses follow a simple process:

1. You deliver the work. This might be a software build, design file, report, campaign plan or other agreed deliverable.
2. The review period starts. The contract should say when the clock starts, such as when the deliverable is emailed, uploaded to a project portal or made available for testing.
3. The client reviews the work. The client can approve it, reject it, or request changes if the work doesn't meet the agreed specifications.
4. The client must respond within the deadline. Common review periods are 5, 7, 10 or 14 business days, depending on the size and complexity of the work.
5. If the client doesn't respond, acceptance is deemed. The deliverable is treated as approved, and the next contractual step can happen.

The exact deadline isn't set by UK law. It depends on what is reasonable for the project. A one-page design concept might only need 5 business days. A complex software release might need 10 to 20 business days, especially if your client needs to involve technical staff or run internal checks.

You can also connect deemed acceptance to practical outcomes, such as:

• your right to issue a milestone invoice
• the start of a warranty or support period
• handover of final files
• moving to the next project phase
• limiting later change requests to paid variation work

For business-to-business contracts, payment timing also matters. If you don't agree a clear payment date, the Late Payment of Commercial Debts (Interest) Act 1998 can allow statutory interest to run after 30 days in many B2B situations. Still, it's usually better to spell out your payment triggers clearly rather than relying on default rules later.

When Is A Deemed Acceptance Clause Useful?

A deemed acceptance clause is useful when your business depends on client approvals to keep projects, cash flow and team capacity moving.

It's especially helpful where your work is delivered in stages. If each stage needs approval before the next one begins, one delayed sign-off can disrupt the whole project.

For example, say Omar runs a branding agency in Bristol. His contract says the client must approve the logo concept before his team starts the website design. The client loves the logo in a meeting but never sends written approval. Without a deemed acceptance clause, Omar may be unsure whether to proceed, invoice or keep chasing.

With a clear clause, Omar could say:

• logo concepts must be reviewed within 7 business days
• feedback must identify specific changes against the agreed brief
• if no feedback is received, the concept is deemed accepted
• any later changes are treated as a paid variation unless Omar agrees otherwise

This gives both sides certainty. The client still gets a proper review window, and Omar isn't left in limbo.

Deemed acceptance can also help where clients use the work without formally approving it. If a client publishes your design, launches the website, circulates the report internally or starts using the software in live operations, your contract can say that use counts as acceptance.

That said, your clause should be carefully written. If it's too aggressive, unclear or one-sided, it may create more risk than protection.

What Should An Acceptance Of Deliverables Clause Include?

An acceptance of deliverables clause should set out what you're delivering, how the client reviews it, what counts as valid rejection, and when acceptance happens.

The best clauses are practical. They match how your projects actually run, rather than using generic wording that looks tidy but doesn't fit your workflow.

Clear Deliverables And Specifications

Your client can only fairly accept or reject work if the contract says what you promised to deliver.

Try to define:

• the deliverables, such as designs, code, reports, content, training sessions or campaign assets
• any agreed specifications, statement of work, brief, scope or functional requirements
• the format for delivery, such as PDF, editable files, staging environment or live deployment
• any exclusions, such as features or revisions that aren't included

If the scope is vague, a deemed acceptance clause may not solve the real problem. You may still end up arguing over whether the work matched the brief.

A Fair Review Period

Your clause should give the client enough time to review the work properly.

There's no single correct period, but these are common starting points:

• 5 business days for straightforward documents, small design items or minor revisions
• 10 business days for larger creative deliverables, website pages or project milestones
• 10 to 20 business days for software builds, technical deliverables or work requiring testing by several people

If your client is a large organisation, you may need to allow extra time for internal approvals. If your project is fast-moving, a shorter timeframe may make sense, but it should still be realistic.

Specific Feedback Requirements

Your contract should explain what the client must do if they reject the deliverable.

Usually, you want feedback to be:

• in writing
• sent to a nominated contact or email address
• specific enough for you to understand the issue
• linked to the agreed scope, brief or specifications
• provided within the review period

This helps stop vague comments like not quite right from delaying the project without giving you something concrete to fix.

What Happens After Feedback

Your clause should also say what happens if the client asks for changes.

For example:

• you fix genuine defects or non-conformities at no extra cost
• you provide one or two rounds of included revisions
• new requests outside the original scope are charged separately
• the client gets another limited review period after you resubmit the work

This is where many templates fall short, especially without careful clause drafting. They say work is deemed accepted after a deadline, but they don't explain how revisions, defects or out-of-scope changes are handled.

How Do Software Acceptance Testing Clauses Work?

A software acceptance testing clause works by giving the client a defined period to test whether the software meets the agreed requirements.

This is slightly different from approving a design or document. Software may need functional testing, bug reports, user acceptance testing and sometimes security or integration checks.

A good software acceptance testing clause should cover:

• what environment testing will happen in, such as staging or production
• who is responsible for preparing test data
• which requirements or user stories the software will be tested against
• how bugs must be reported
• the difference between critical defects and minor issues
• how long the client has to complete testing
• when the software will be deemed accepted

For example, your contract might say the client has 15 business days to test a release against the agreed functional specification. If the client reports a critical defect during that period, you fix it and resubmit the release. If the client doesn't report any critical defects within the timeframe, the release is deemed accepted.

Critical Defects Versus Minor Bugs

Your contract shouldn't treat every small issue as a reason to reject the whole project.

You might define a critical defect as something that prevents the software from performing a core agreed function. A minor bug might be a visual alignment issue, typo or non-critical inconvenience that doesn't stop the client using the main features.

This distinction matters because clients sometimes delay sign-off over minor points. Your contract can say that minor defects don't prevent acceptance, but you'll fix them within an agreed timeframe.

Live Use As Acceptance

For software projects, live use can be a strong acceptance trigger.

Your contract can say that if the client deploys the software to live users, processes real customer data, starts taking bookings or otherwise uses the system in a live business setting, the software is accepted unless you have agreed in writing that the use is only for testing.

If personal data is involved, make sure your data protection terms also line up with the project. UK GDPR and the Data Protection Act 2018 may affect your roles, security obligations and processing instructions, especially for SaaS platforms and customer data systems.

Can A Deemed Approval Clause Be Unfair?

Yes, a deemed approval clause can be unfair if it gives your client no real chance to review the work, removes key rights too broadly, or tries to excuse poor performance.

A clause is more likely to be reasonable if it balances both sides' interests. It should protect your business from delay, not allow you to push through incomplete or defective work.

Business-To-Business Contracts

In B2B contracts, UK law generally gives businesses freedom to agree commercial terms. That doesn't mean every clause will always work exactly as drafted.

If your clause sits in your standard business terms and conditions and tries to exclude or limit liability, the Unfair Contract Terms Act 1977 may require the clause to be reasonable. For example, you should be careful if your deemed acceptance wording says the client loses all rights to complain about defects forever, even hidden defects they couldn't reasonably have found during testing.

Under the Supply of Goods and Services Act 1982, many B2B service contracts include an implied duty to carry out the service with reasonable care and skill, unless the contract validly deals with that point. A deemed acceptance clause shouldn't be used as a shortcut for avoiding basic quality obligations.

Contracts With Consumers

If your business sells to consumers, you need to be more cautious.

The Consumer Rights Act 2015 says consumer contract terms must be fair and transparent. An unfair term isn't binding on the consumer. Consumers also have statutory rights for services and digital content, including rights around reasonable care and skill, fitness for purpose in some cases, and remedies where digital content doesn't meet the required standard.

For consumer-facing businesses, a deemed acceptance clause that's hidden in small print, gives an unrealistically short review period, or takes away statutory remedies is risky. If you work with consumers, your clause should be tailored carefully.

Hidden Defects And Later Problems

A fair clause usually deals with visible issues differently from hidden defects.

For example, it may be reasonable to say the client can't reject a design concept 30 days later because they changed their mind. It may be unreasonable to say the client can never raise a serious hidden defect that couldn't have been discovered during the original review period.

A practical middle ground is to use deemed acceptance for approval, invoicing and project progression, while still having separate warranty, support or defect correction wording for genuine issues discovered later.

Common Mistakes To Avoid

The biggest mistake is treating deemed acceptance as a magic fix for unclear contracts.

If your scope, deliverables and payment milestones are unclear, a deemed acceptance clause may not stop disputes. It may simply move the argument to a different part of the contract.

Watch out for these common issues:

• No clear start point. Say exactly when the review period begins, such as when the deliverable is sent by email or uploaded to a nominated platform.
• Unrealistic deadlines. A 24-hour approval period may be fine for a tiny amendment, but risky for complex work.
• No feedback standard. Ask for specific written reasons, not vague dissatisfaction.
• No process for resubmission. Say what happens after you make changes and how long the next review period lasts.
• Mixing up acceptance and payment. If acceptance triggers payment, say so clearly and include invoice due dates.
• Ignoring out-of-scope changes. Make it clear that new features, new concepts or changed instructions may cost extra.
• Using the same wording for every client. A software testing process won't look the same as a logo design approval process.

You should also make sure your project communications match the contract. If the contract says feedback must go to a particular email address, use that channel. If acceptance happens through a project management tool, make sure everyone knows how that tool is being used.

Good records help too. Keep copies of delivery emails, upload confirmations, client comments, meeting notes and invoices. If a payment dispute comes up later, you'll be in a much stronger position if you can show the timeline clearly.

Key Takeaways

• A deemed acceptance clause treats work as approved if the client doesn't respond within the agreed review period.
• It's useful for deliverables-based work where approval delays can hold up payment, handover or the next project phase.
• Your clause should define the deliverables, review period, feedback process, revision rights and payment triggers.
• Software contracts often need extra detail around acceptance testing, critical defects, minor bugs and live use.
• A one-sided deemed approval clause can be risky, especially if it tries to remove statutory rights or excuse poor work.
• The fairest clauses protect your cash flow while still giving your client a genuine opportunity to review the work.

If you'd like help with your client contracts, acceptance testing wording, payment milestones or project approval process, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.