How to Build a Payout SLA for Contractor Payment Timing

Promise the part of the journey you can measure#

A contractor asking “when will I get paid?” needs a date and a useful status, not an internal processing average. Start with the contractual due date. Then explain the platform’s commitment for releasing the payment and the expected bank-arrival window. If those dates conflict, solve the funding or operating problem before publishing the SLA.

An SLA measures a service obligation; it does not replace the underlying payment obligation. An approval backlog, missing platform funding or a provider incident can be a service failure even when a later operational clock looks fast. Record invoice acceptance, amount due and due date separately so delay before payout initiation remains visible.

Define the events before the number#

For a provider example, Stripe’s payout object exposes an expected arrival date and failure information. An expected date is not a bank-credit receipt. Its schedule documentation also distinguishes settlement availability from automatic payout scheduling and uses different day conventions by country. Map the actual provider fields to your event model rather than calling every successful API response paid.

Store the amount, currency, payee, destination version, service path, due date, clock start and applicable policy version in one payout record. Assign the path at start, using the requested method and known conditions. Do not move a late payout into a slower band at release to make the report look better.

A worked release commitment#

The following is an invented SLA design for one corridor, not a provider guarantee: release eligible standard requests within four operating hours. Operating hours are 08:00–18:00 UTC, Monday to Friday, excluding the published holiday calendar. Requests outside those hours begin their operating-time count at the next opening; preserve their original submission timestamp and total wait.

A request starts Friday at 17:00 UTC. One hour counts on Friday, and the remaining three count on Monday, making the release deadline Monday at 11:00. If Monday is a listed holiday, that deadline becomes Tuesday at 11:00. Cutoffs and calendars must therefore be shown with the promise, not buried in a support macro.

A separate bank-arrival estimate might say two receiving-bank business days after accepted release, only for a method whose supported timing justifies it. Define the bank calendar and start event for that estimate independently. Do not substitute the four-hour release target for a claim that money reaches every contractor within four hours.

Pause only a defined clock for an evidenced reason#

A permitted operational pause needs a specific cause, affected amount, start, clearance event, owner and notice. An invalid destination supplied by the recipient may qualify under the agreed policy; an internal queue, ordinary provider slowness or a missing platform prefund should count as platform delay. A broad compliance label does not establish that a hold is lawful.

Use the union of valid pause intervals clipped to operating hours; overlapping pauses are counted once. Net operating elapsed time = operating time between start and completion − approved paused operating time. Display calendar waiting time and pause duration too. No operational pause changes a payment due date or permits a hold beyond the applicable contract and law.

In the Friday example, suppose a documented destination issue pauses processing Monday 09:00–10:30 and Monday is an operating day. Without the pause, the deadline is 11:00; subtracting those 1.5 hours moves the operational deadline to 12:30. At release then, gross operating time is 5.5 hours and net operating time is four hours. The contractor still sees the original due date and total waiting time.

Missing platform records must not be relabelled recipient-caused delay. Where a required restriction prevents release, identify the lawful basis and scope, keep the liability recorded, communicate the next permitted step and review the case regularly. Release undisputed eligible amounts where permitted; stop new work separately if necessary.

Measure the entire cohort#

Freeze the monthly cohort by clock-start date and business payout ID. Define a maturity date when each applicable deadline has elapsed. Count retries as attempts under the same payout, not new successful payments. Show immature requests separately until their deadline has passed.

If 100 requests have matured, 95 released on time, three released late and two remain unknown past their deadline, on-time release is 95/100 = 95%. It is not 95/98. The two unknown cases need an owner and remain overdue. A median calculated only from completed payouts must be labelled that way and accompanied by pending counts and age; otherwise it hides the longest waits.

Retain the event export, calendar version, pause evidence and calculation query with each report. Correct late-arriving facts with a dated revision rather than silently deleting the original failure. When records disagree, publish the unresolved count and qualify the affected metric instead of suppressing the whole report.

Write a remedy people can use#

Name the person who owns an at-risk payment, the time for the next update and the recovery action. A provider timeout requires investigation of the original operation before a replacement; the SLA deadline does not justify a second payout with an unknown first outcome.

An illustrative negotiated remedy is a credit equal to 5% of the affected platform service fee for a missed release commitment. On a $20 fee that is $1, payable by the platform to the party that paid that fee. The contractor’s $2,000 principal remains $2,000. Specify credit caps, claim process, notice dates and any exclusions; this example is not a mandatory or universally enforceable remedy.

Keep the service-credit remedy separate from contractual interest, statutory late-payment rights and recovery of the underlying debt. Broad exclusions can make a fast headline promise meaningless, so test the clause against an internal approval failure, a bank holiday, a recipient-detail correction and an unknown provider result before signing.

Pilot the calculation, then widen the promise#

Run the proposed rules over one country-method cohort before rollout. Have two operators independently calculate the Friday/pause example and the same real monthly sample. Inspect every overdue case, verify the recipient-facing status, and confirm that the credit can actually be issued to the correct party. Widen coverage only when the clock, reports and recovery agree.