FairClauseGuides

Pay-When-Paid Clause: Why It's Risky for You

A pay-when-paid clause makes your invoice depend on a relationship you cannot see, cannot influence, and cannot chase — the client's own customer paying them.

What this clause looks like

A pay-when-paid clause makes your invoice conditional on the client receiving money from someone else — usually their own customer, sometimes a funder or an insurer. It's common in agency subcontracting, construction-adjacent freelance work, and any project where your client is themselves a vendor to a bigger company. A typical version reads:

6.3 PAYMENT. Client shall pay Contractor within fifteen (15) days of Client's receipt of payment from the end client for the applicable milestone. Payment to Contractor is expressly contingent upon Client's receipt of such funds.

The phrase to watch for is "contingent upon" — or any version of "upon receipt of payment from," "once we've been paid," or "pay when paid." It quietly moves a risk that has nothing to do with your work — whether the client's own customer pays on time, or at all — onto your invoice.

Why it costs you money

The mechanism is straightforward but the consequences compound. Say a design agency subcontracts you for $4,000 of work on a project they're billing their own client $20,000 for. You deliver on time, your work is approved, and under a normal contract you'd invoice and get paid within 15–30 days. Under a pay-when-paid clause, your payment instead waits on the agency's client — a company you have no relationship with, no visibility into, and no ability to follow up with. If that end client is slow (net-90 is common for larger companies), disputes an unrelated line item, or simply goes quiet, your $4,000 sits unpaid through no fault of your own and no action you can take.

The worst case is worse than slow: if the end client never pays at all — goes out of business, disputes the whole invoice, or simply refuses — a strict pay-when-paid clause can mean you're never paid either, because the condition that triggers your payment (their receipt of funds) never occurs. You did the work, it was accepted, and you can still end up with nothing, because your contract tied your fee to somebody else's creditworthiness rather than to your own delivery.

This is fundamentally different from ordinary payment risk. Every contract carries some risk that a client is slow or unreliable — that's priced into who you choose to work with. A pay-when-paid clause adds a second layer of risk you can't evaluate at all: the creditworthiness and payment habits of a company you've never spoken to and can't vet before signing.

Pay-when-paid vs. pay-if-paid — the distinction that matters most

Contract law treats these as meaningfully different, and the wording difference is subtle enough to miss. "Pay-when-paid" is usually read as a timing clause — your payment is delayed until the client is paid, but you're still eventually owed regardless. "Pay-if-paid" is a conditional clause — if the client is never paid, you may never be owed at all. Courts in some jurisdictions refuse to enforce pay-if-paid clauses against subcontractors as unconscionable; others enforce them as written if the language is explicit enough. Either way, don't rely on a favorable court reading to protect you — the safer move is removing the contingency entirely before you sign, covered below.

The counter-language to send

The fix isn't to negotiate a longer contingency window — it's to remove the contingency completely and replace it with a fixed timeline you control. This is the base language FairClause's Pro check suggests when it flags a pay-when-paid clause:

Payment obligations under this agreement are unconditional and are not contingent on Client's receipt of funds from any third party.

Pair that with an explicit fixed timeline — "payment due within 15 days of Contractor's invoice" — so the clause doesn't just remove the bad condition but replaces it with a clear, client-independent one. If the client resists removing it entirely because their own cash flow genuinely depends on their end client paying first, a workable middle ground is a hard cap: payment is due on receipt from the end client, but no later than 45 days from your invoice regardless. That protects the client's stated cash-flow concern while guaranteeing you're never left waiting indefinitely on a company you've never met.

What to ask before you even get to the contract

If a prospective client is themselves a subcontractor or agency reselling your work to an end client, it's fair to ask directly, before signing anything: who is the end client, what's their typical payment timeline, and has this client ever had a payment dispute with them. A client who bristles at those questions, rather than answering them plainly, is telling you something about how comfortable they are with the arrangement themselves.

When to walk away

Treat a client's refusal to remove or cap a pay-when-paid clause as a real signal, not paperwork friction. If they won't agree to even a capped fallback — payment no later than a fixed number of days regardless of their own receipt — you're being asked to fully underwrite a stranger's creditworthiness for free, with no upside if that risk doesn't materialize and total loss if it does. That's rarely a trade worth taking, especially early in a client relationship where you have no track record to fall back on. A large deposit can partially offset the risk if you decide to proceed anyway, but it doesn't fix the underlying problem for the remaining balance.

Frequently asked questions

Is pay-when-paid the same as slow payment terms like Net 60?

No — they're different risks stacked on top of each other. Long payment terms (Net 60 or more) are a known, fixed delay you can plan around. Pay-when-paid is an unknown, unbounded delay tied to a third party's behavior — it could resolve in a week or never resolve at all. A contract with both is significantly riskier than either alone.

Is this clause common, or a sign of a bad client?

It's genuinely common in subcontracting relationships — agencies and prime contractors use it to manage their own cash flow — so its presence alone isn't a red flag about the client's intentions. What matters is whether they're willing to cap or remove it when you raise the issue. Reasonable clients usually will; the ones who won't are the actual signal.

Can I ask for a bigger deposit instead of fighting the clause?

Yes, and it's a reasonable partial mitigation — a 50% deposit up front means at least half your fee isn't exposed to the end client's payment behavior. It doesn't solve the risk on the remaining balance, so combine it with a capped fallback date where possible rather than relying on the deposit alone.

What if the contract doesn't mention pay-when-paid explicitly but the client verbally implies it?

Get it in writing either way — as a fixed, unconditional term. A verbal "we'll pay you once we're paid" with no written contingency clause is actually easier to fix, since you're not removing existing language, just proposing the clean version described above before anything is signed.

Does a kill fee help if the end client never pays at all?

Only for a different scenario — a kill fee protects you if this client cancels the project outright, not if they simply can't pay because their own customer didn't pay them. The two risks need two separate protections; see the kill fee guide for the cancellation side of this.

Check your own contract first. FairClause reads it in your browser, names the clauses that hurt you, and drafts the counter-language for each one. Nothing is uploaded.

Run a free contract check →

Also see: 21 contract red flags freelancers shouldn't sign, unlimited revisions clause: how to push back, freelance non-compete: should you sign it?, kill fee clauses: what's fair, and how to negotiate a freelance contract.

FairClause is automated pattern analysis and drafting help, not a law firm and not legal advice. Pay-when-paid and pay-if-paid enforceability varies by jurisdiction. For anything binding, talk to a licensed lawyer where you are.