Acceptance Drift
Milestone payments decouple from formal acceptance testing. Payment becomes the de facto acceptance event.
Milestone payments decouple from formal acceptance testing. The vendor creates urgency around payment; the customer pays "in good faith" to maintain the relationship, losing contractual leverage. Payment becomes the de facto acceptance event.
Recognition signals
- Payment processed before acceptance verified. The invoice arrives, Finance processes it, and nobody checks whether the deliverable was formally accepted.
- "We paid in good faith." The project team uses relationship language to justify a contractual shortcut — and doesn't realise what they surrendered.
- Vendor invoices against PO dates not acceptance dates. The payment schedule runs on the calendar, not on evidence of delivery.
- Finance processes payment without checking deliverable status. They have an invoice, a PO, and a budget line. Nobody told them acceptance was a prerequisite.
- Warranty ticking from payment not acceptance. The clock started when Finance released funds, not when the customer confirmed the deliverable met specification.
Structural cause
Why this happens
Payment systems operate on calendar dates and invoice triggers. Acceptance systems operate on quality evidence. The two are managed by different teams with different incentives. Without a named person connecting payment to acceptance, payment defaults to the calendar.
Finance wants to process invoices on time — late payment reflects badly on their metrics and damages supplier relationships. The project team wants to maintain a collaborative relationship with the vendor — withholding payment feels adversarial. The vendor wants cash flow. All three incentives point the same direction: pay now, verify later. The contract says otherwise, but nobody in the payment chain has read the acceptance clauses.
The damage is invisible at the point of payment. It surfaces weeks or months later when the customer discovers a defect and reaches for the warranty — only to find it started ticking from the payment date, not the acceptance date. Or when they try to enforce a remedy and the vendor points out that payment constituted acceptance. The leverage was surrendered permanently, but it felt like goodwill at the time.
Risk mapping
| Risk | Description |
|---|---|
| P3 | Acceptance-payment disconnect — payment processed without formal acceptance verification |
| CO1 | Leverage gap — contractual enforcement position weakened by premature payment |
| V3 | Visibility gap — payment status disconnected from deliverable acceptance status |
| G6 | Delegation gap — nobody delegated to connect acceptance authority to payment authority |
Self-assessment
When to worry
- A milestone payment was processed before acceptance testing completed
- Finance processes vendor invoices without checking deliverable status
- "Payment does not constitute acceptance" is in the contract but nobody told Finance
- Warranty period started from payment date not acceptance date
When you're OK
- Payment authorisation requires documented acceptance sign-off
- Finance has been briefed on acceptance terms and holds payment until sign-off
- Named acceptance authority exists for each milestone
Related reading
- Leverage Erosion — each premature payment permanently reduces the customer's enforcement position
- Contract-as-Filing — the contract contains acceptance clauses that nobody on the delivery team has read
- Specification Gap — vague acceptance criteria make it easier to argue that "close enough" constitutes delivery
Every payment released without acceptance is leverage surrendered permanently.
A contract management review maps payment workflows to acceptance gates and identifies where money is flowing without evidence. 10fifteen — programme governance assessments.