When you hire a developer, designer, consultant, agency, or other service provider to produce a specific deliverable, one of the biggest mistakes you can make is allowing delivery to automatically trigger payment.
A file being sent does not mean the work is complete.
A better contract structure is:
Delivery → Review/Testing → Acceptance → Invoice → Payment
Each step serves a different purpose, and keeping them separate gives the buyer significantly more protection.
1. Delivery
Delivery should mean one thing only: the vendor has submitted the work for review. It should not mean the buyer has approved the work.
For example, if you hire a developer to build a customer portal, uploading the portal to a staging environment is delivery. It does not mean the portal works according to the agreed specifications.
Your agreement should clearly identify what must be delivered and how delivery occurs.
2. Review and Testing
Once the deliverable is submitted, the buyer should have a defined period to inspect or test it.
For example:
10 business days after delivery.
During that period, the buyer compares the work against agreed acceptance criteria.
For software, that might include:
- required features work properly;
- integrations function as specified;
- critical bugs have been resolved;
- security requirements are satisfied;
- performance meets agreed standards.
For a consulting engagement, acceptance criteria might instead require specific reports, analyses, recommendations, datasets, or documentation. The important point is that the contract defines what “finished” actually means.
3. Acceptance
If the deliverable satisfies the acceptance criteria, the buyer formally accepts it. If it does not, the buyer should have the right to reject it and identify the deficiencies. The vendor should then be required to correct those deficiencies at no additional cost and resubmit the work. The review process starts again.
This prevents a vendor from arguing:
“We delivered what we promised, so you owe us.”
The real contractual question becomes:
“Did what you delivered satisfy the agreed acceptance criteria?”
That is a much stronger position for the buyer.
4. Invoice
The vendor should only become entitled to invoice after the applicable deliverable or milestone has been accepted. This distinction matters.
Suppose a contract simply says:
Invoices are payable within 30 days.
The vendor delivers incomplete work on May 1 and immediately sends an invoice. Technically, the payment clock may already be running.
A stronger provision says:
Vendor may invoice only after the Buyer accepts the applicable Deliverable.
Now the commercial sequence is clear. The vendor first has to complete the work. Then the buyer verifies it. Then the vendor gets to invoice.
5. Payment
Only after acceptance and a valid invoice should the payment obligation begin.
For example:
Payment due within 30 days after receipt of a correct invoice following acceptance.
For larger projects, founders should also consider linking payments to milestones.
Imagine a $300,000 software project. Instead of paying:
- $150,000 upfront;
- $75,000 after 30 days;
- $75,000 after 60 days;
you might structure it around actual performance:
- $30,000 on commencement;
- $60,000 after architecture acceptance;
- $80,000 after MVP acceptance;
- $80,000 after production acceptance;
- $50,000 after final implementation and stabilization.
The vendor earns more money as more value is actually delivered.
Don’t Forget the Holdback
For significant implementations, buyers may also retain a small portion of the contract price until the product has been operating successfully for a defined period.
For example:
10% payable 60 days after launch, provided all critical defects have been resolved.
That gives the vendor an economic incentive to remain engaged after launch rather than disappearing immediately after the final milestone.
Acceptance Should Not Eliminate Warranties
There is another important distinction. Acceptance means the deliverable passed the buyer’s agreed testing process. It should not mean the buyer permanently assumes the risk of every defect that appears later. Your agreement should make clear that warranties, indemnities, confidentiality obligations, security obligations, and other remedies continue after acceptance where appropriate. A software system might appear to work during testing but develop serious problems after operating at scale. Acceptance should not automatically excuse those problems.
The Contract Structure Founders Should Remember
When negotiating deliverables-based engagements, keep these events separate:
- Delivery
The vendor submits the work.
- Review/Testing
The buyer verifies the work against objective criteria.
- Acceptance
The buyer confirms the work meets the contract.
- Invoice
The vendor becomes entitled to bill.
- Payment
The buyer pays the accepted amount.
The mistake is allowing these five events to collapse into one. A vendor saying “we delivered” should not automatically mean “you owe us.” Good contracts make payment follow performance.
For founders managing vendors, agencies, consultants, and technology providers, that simple distinction can preserve both leverage and cash when a project starts going wrong.
