The payment terms can be the hardest part of a Statement of Work. It tells the clients how they pay, on what schedule, and what has to be true before each amount comes due. That section is the one that most directly decides when cash lands in your account.
In this guide we'll define what the payment terms section does, walk the four pricing bases, untangle the schedule-vs-net-terms confusion that quietly costs cash flow, and hand you a copyable payment schedule plus a sample clause you can adapt today.
Key takeaways
- The payment terms section explains how much the client will pay, when payments are due, and what must happen before each payment is released.
- Every payment schedule should clearly define amounts, payment triggers, invoice timing, net terms, deposits, and any expense or late-fee policies.
- CreateMySOW provides professional Statement of Work templates and guided forms that help you define pricing models, payment schedules, milestones, and payment terms in a clear and organized way.
What the payment terms section does in a SOW
Payment terms answer four questions: how much, on what basis, on what schedule, and what must be true before you get paid.
The payment terms section is where a Statement of Work stops describing the work and starts describing the money. It defines the price basis (how the fee is calculated), the payment schedule (when each amount is billed), the triggers (what event releases each payment), and the invoicing rules (how invoices go out and come due).
Done well, this section turns "the project costs X" into "you pay X this way, on these dates, when this is accepted." It doesn't guarantee payment — nothing on paper does — but clear terms tend to reduce dispute risk and settle the questions that otherwise turn into awkward emails three months in.
One note: anything touching late fees or enforceability is jurisdiction-specific, so treat the figures here as illustrative and confirm binding language with a qualified attorney. If you want the bigger picture first, here's what a Statement of Work is and how the payment section fits inside it.
Choosing your price basis
Before you can schedule anything, you have to decide how the fee is calculated. The price basis shapes everything downstream. A fixed fee bills against milestones, while time and materials bills against logged hours. Pick the basis first, then build the schedule to match it. Here are the four bases you'll choose from:
| Price basis | How it's calculated | How it shapes the schedule | Best when |
|---|---|---|---|
Fixed fee | One agreed price for a defined scope | Split into milestone or stage payments | Scope is well-defined and stable |
Time and materials | Hourly or daily rate plus expenses | Billed periodically against logged time | Scope is open-ended or likely to shift |
Milestone | Fee divided across named deliverables | Each milestone triggers a payment | Work breaks cleanly into stages |
Retainer | Recurring amount for ongoing access or capacity | Billed on a fixed cycle, often monthly | The relationship is continuing, not one-off |
Most SOWs settle on one basis, though hybrids are common, e.g., a fixed fee with a monthly retainer for support. Whichever you pick, the basis decides what your triggers can even be. For a deeper look at matching the model to the engagement, see our guide to SOW pricing models.
What the payment schedule should specify
The schedule is where the price basis becomes a concrete plan. A vague schedule ("payment on completion") is a common reason invoices stall, so spell out each element explicitly. A complete payment schedule should specify:
- Amounts. State each payment as a figure or a percentage of the total, and make the splits add up to 100%.
- Triggers. Tie each amount to a specific event — a signed kickoff, an accepted milestone, final acceptance. A verified trigger is what protects both sides.
- Invoice timing. Clarify when you may issue the invoice relative to the trigger (for example, within five business days of acceptance).
- Net terms. Set how long the client has to pay once invoiced — commonly net 15 or net 30. This is a separate clause from the schedule, and we'll untangle the two in the next section.
- Deposit. Note any upfront deposit and what it covers. A deposit protects your cash flow and signals the client is committed before you start.
- Late fees and expenses. Add a line for a late fee on overdue invoices and a line for reimbursable expenses, so neither becomes a surprise. Keep any rate illustrative and check enforceability locally.
Each of these is one or two sentences in the actual SOW. Together they remove the ambiguity that turns a friendly project into a collections problem.
Milestone payments vs net terms
One line to anchor this section: these two clauses get confused, and the confusion costs you cash flow.
People treat "milestone payments" and "net 30" as the same idea. They aren't. The payment schedule says when you may invoice. Net terms say when the invoice is due once you've sent it. A SOW needs both as separate clauses, or you'll have a trigger with no deadline — or a deadline with no trigger.
| Clause | What it controls | Example |
|---|---|---|
Payment schedule | When you may invoice | Invoice on acceptance of the design milestone |
Net terms | When that invoice is due | Payment due within 30 days of the invoice date |
Read together, they say: you bill when the client accepts the milestone, and they pay within 30 days of that bill. Keep them in the milestones section and the payment terms section respectively, and the timeline stays unambiguous for everyone.
How to write payment terms step by step
You don't need legal training to write a clean payment terms section — just a few decisions made in order. Here's the sequence we use.
- Pick the price basis. Decide whether the engagement is fixed fee, time and materials, milestone, or retainer. Everything else follows from this.
- Set the schedule against milestones. Break the fee into named payments and map each to a deliverable, so the client pays for progress they can see rather than for time passing.
- Define triggers as acceptance events. Tie each payment to a verified acceptance — not "on completion," which is open to interpretation. Define what "accepted" means by pointing to your acceptance criteria.
- Add net terms and late fees. State the net terms (net 15, net 30) and a late-fee line, keeping any figures illustrative since enforceability varies by jurisdiction.
- Note expenses and tax. Add a line for reimbursable expenses and one for how tax is handled, so the final invoice holds no surprises.
Work through those five steps and you'll have a section that defines how and when you get paid, with no gaps for a dispute to live in.
A fillable payment terms example you can copy
Here's the part you came for: a copyable payment schedule and a sample clause. Adapt the amounts, triggers, and net terms to your engagement — the figures below are illustrative, not prescriptive.
| Payment | Amount | Trigger | Net terms |
|---|---|---|---|
Deposit | 25% of total | On signature of this SOW | Due on receipt |
Milestone 1 | 35% of total | Acceptance of the design milestone | Net 15 |
Final payment | 40% of total | Final acceptance of all deliverables | Net 30 |
Sample payment terms clause:
The total fee for the work described in this SOW is [amount]. The Client will pay a deposit of 25% on signature, 35% on acceptance of the design milestone, and the remaining 40% on final acceptance of all deliverables. The Vendor may invoice within five business days of each acceptance event. Invoices are due net 30 from the invoice date unless stated otherwise above. Overdue invoices may accrue a late fee of [rate], subject to applicable law. Reimbursable expenses and any applicable tax will be itemized separately.
Swap in your own basis and split, then build the full document around it . You can build the whole SOW with the generator so the payment terms section sits in context with scope, milestones, and acceptance.
Common mistakes in the payment terms section
Most payment disputes trace back to the same handful of omissions. Scan your draft for these before you send it:
- No deposit. Starting work with nothing collected leaves your cash flow exposed if the client goes quiet.
- Vague triggers. "On completion" invites arguments over what "complete" means. Tie payments to a defined acceptance event instead.
- Dates not tied to acceptance. A calendar date can arrive before the work is accepted, which puts you in the position of invoicing for something the client hasn't signed off on.
- Missing net terms. A trigger with no due date means the client decides when to pay. State net terms as their own clause so the deadline is explicit.
- No late-fee clause. Without one, an overdue invoice carries no consequence. Add a line, and keep the figure illustrative pending local rules.
- Expenses unaddressed. If reimbursable expenses aren't mentioned, you'll either eat them or fight over them. Give them a line.
Fix these six and your payment terms section will do its job: getting you paid cleanly, on time, with the fewest arguments along the way.
How payment terms connect to the rest of your SOW
Payment terms don't stand alone. They sit on top of your milestones and acceptance criteria — each payment trigger is really an acceptance event, and each acceptance event releases a payment. Change the milestones and you change the schedule; tighten the acceptance criteria and you tighten the triggers.
Once the terms are agreed and the whole CreateMySOW document is drafted, the SOW moves into signature. Once your SOW is drafted, send it for signature and track approvals in PandaDoc. Routing the finished SOW through PandaDoc for signature and approval tracking gives you a clean record of who agreed to which terms and when — useful the day a payment question comes up.
