The funding gate is a sourceBOLD invariant — a guarantee written into the platform, not into a policy doc. Every contractor payout and every approved reimbursement is anchored to a specific client invoice, and the platform refuses to dispatch a payment until that linked invoice has settled.
It's enforced as a state transition every payout has to clear:
FUNDING_PENDING → PAYMENT_READY
// requires that linked invoice to be PAID
A row sitting in FUNDING_PENDING cannot be moved to PAYMENT_READY by anyone — the Payments Manager included — until the client invoice for that engagement has come in. The data model carries a foreign key from every payout row to the funding invoice, so there's no path through the platform where a developer gets paid out of float and we're chasing the client invoice afterward.
What it means for clients
You're never funding the platform. Your invoice settles, then the developer is paid out of your settled funds. We don't pre-pay developers on your behalf and reconcile later. If a payment is reversed — charged back, or returned by your bank — the invoice becomes due again and we suspend the engagement until it is resolved.
What it means for developers
Developers are paid bi-weekly out of the client invoice that funded that engagement. If a client hasn't paid in full for a period of service, sourceBOLD tells the developer and suspends the engagement for that period, and the developer stops work until the payment arrives. If a suspension lasts more than 30 days, either party may end the affected engagement under the Independent Contractor Agreement.
That's the contractual escape valve. Developers don't carry sourceBOLD's collection risk indefinitely.
Who has override authority
Only the Executive Administrator. A funding-gate override requires a non-empty override_reason captured at the moment of the action, plus the full audit trail of the original gate failure — which invoice, which payout, what state. The Payments Manager has no override authority. Strictly bound by the gate.
Why it's a system invariant, not a policy
A policy is something a company promises to follow. An invariant is something that can't be violated without rewriting the data model. The funding gate is the second — the state machine refuses payouts that don't have a settled invoice behind them, regardless of which operator runs the action.
For the full walkthrough of the money flow — invoice cycles and IC payout dates — see How it works. The client-side terms (suspension, reversals) sit in the MSA and SOW, both available on request before the first SOW is signed; the developer-side terms sit in the developer's own Independent Contractor Agreement with sourceBOLD.