Payment terms and milestones in a data project

The payment schedule is the main lever you hold

In a data project the buyer rarely has operational control. The producer recruits, records, and annotates. What the buyer controls is the money and the acceptance decision, and the payment schedule is where those two meet.

Two default structures are both wrong. Everything up front means the buyer carries the entire risk of a producer who underdelivers. Everything at the end means the producer finances the whole project, which only producers with no queue will accept, and a producer with no queue is itself worth reading as a signal.

The workable structure is a series of payments, each attached to an event that has already happened and been accepted.

A phase structure that matches the work

The shape below is expressed as percentages because the amounts differ by project, and it is the proportions that carry the risk allocation. The proportions can move: a first project in a new population justifies a larger mobilization payment because recruitment is the least predictable cost, while a repeat project with a proven producer justifies a smaller one.

• Mobilization at signature, in the range of ten to twenty percent, covering recruitment setup and guideline work. That cost genuinely happens before any deliverable exists, so refusing to fund it means the producer funds your project.
• Pilot acceptance: a payment on the pilot at the same unit rate as production, released when the pilot passes the written criteria including one full review cycle.
• Production batches: payments per accepted batch, with the acceptance record attached to each invoice. Frequency should match the cadence, so a batch cannot be delivered without a corresponding payment event.
• Delivery acceptance: a payment when the full delivery is accepted and the manifest is reconciled against what was sent and what was received.
• A holdback in the range of ten to twenty percent, released after the acceptance window closes with no outstanding rejections. This is the clause that funds the last round of rework without a separate negotiation.

Tie each payment to an artifact, not a date

Calendar-based milestones fail in both directions: they pay for work that is late and they withhold payment for work that is early. Event-based milestones avoid both, provided each event is defined as an artifact. The rule behind the list fits in one sentence: no payment precedes the artifact it pays for, and every artifact is something you can inspect.

• Mobilization releases on a recruitment plan with named channels, screening criteria, and a lead-time estimate, not on a stated start date.
• The pilot payment releases on a pilot accepted under the written criteria, including a completed review cycle. A pilot delivered but not yet reviewed is not an event.
• Batch payments release on batch acceptance, with the acceptance record attached: what was sampled, what failed, and what was accepted with a deviation.
• The final payment releases on delivery acceptance plus manifest reconciliation, which is the step that catches files described in a summary but never actually transferred.
• The holdback releases on the close of the acceptance window, with a written statement that no rejections remain open.

Advances, and the difference between funding and lending

A mobilization payment is not a general advance, and the distinction is worth holding onto. Funding a named cost that happens early is reasonable: recruiters who must be paid before speakers appear, equipment for a specific recording condition, or travel to a field site.

A general advance against undelivered production is different. It has no artifact, no verification, and no way to detect a problem until the work arrives. The test is simple: ask what the money buys and when. A producer who cannot name the specific cost being pre-funded is asking you to finance their cash flow rather than their setup.

One related point on fairness: terms that make payment contingent on your own product outcomes, such as a model reaching a metric, are not payment milestones. They are revenue sharing, and they belong in a different agreement with a different risk structure.

When a milestone fails: cure before termination

There are two ways to get withholding wrong. Paying anyway, which makes the milestone decorative. And terminating at the first miss, which discards the setup cost and the recruitment time you have already paid for, and restarts the schedule from zero.

The middle path is a cure period written into the contract: written notice of the failure, a stated window to fix it, payment resumed only on re-acceptance, and a stated number of cure cycles. One cure cycle is normal. A second consecutive failure on the same criterion is a capability signal rather than a scheduling one.

For that second failure, the contract should offer a defined set of options decided in advance rather than during the dispute: reduce scope to the accepted portion, re-run a calibration round, or terminate with completed milestones settled. Deciding this while both sides are still cooperating is the entire point of writing it down early.

The buyer-side obligations nobody writes down

A payment schedule creates obligations in both directions, and the buyer-side ones are usually left implicit. Four are worth stating. Stated this way, the schedule stops being a payment mechanism and becomes a description of how the project runs, which is the version worth negotiating because both sides can check it against what actually happens.

• Pay within the agreed window. A producer financing your project runs a fragile schedule, and the fragility shows up as slower recruitment rather than as a line item anyone can point to.
• Approve or reject inside the acceptance window instead of letting it lapse. An expired window is an acceptance, and a producer who notices this will stop treating the window as a deadline.
• Keep the named approver available. Acceptance blocked on one person's calendar is the most common form of buyer-caused delay, and it stays invisible in the project record unless the record notes it.
• Route every change through the pricing clause, including the changes that feel small. A free change is still a change, and the precedent is what makes the change process real.