Controlled pilot
A practical guide for operators managing rotating contractor crews. This version reflects the current pilot payment controls rather than older pre-launch workflows.
Kelvaro connects several records that are often scattered across spreadsheets, text messages, payment apps, and accounting files: who the contractor is, whether required onboarding is complete, what work was approved, what amount is owed, whether customer funding has settled, whether the contractor transfer was created, and whether the final state reconciles.
The controlled pilot is deliberately narrower than a global payroll platform. It is focused on supported U.S. contractor operations, and native 1099 e-filing and native QuickBooks/Xero sync are not part of the current pilot product.
Money-safety rule: approval is not payment. Kelvaro keeps payout approval, customer funding, funding settlement, contractor transfer, and reconciliation as separate steps.
Sign in to Kelvaro and confirm the organization that will own the contractor, job, payout, and reporting records. During the first controlled pilots, Kelvaro personally verifies this setup with each customer before live money movement is enabled.
Give users only the permissions they need. Payout creation, payout approval, user management, billing, and sensitive contractor records should not be treated as interchangeable privileges. Tenant boundaries and role checks remain active even when a customer asks for a shortcut.
The customer organization is not the contractor payout recipient. Contractor payout destinations are handled through Stripe-hosted connected-account onboarding. Customer funding is a separate platform funding flow used to fund approved payout obligations.
Use only the funding methods Kelvaro has explicitly enabled and tested for the current environment. Card funding is the initial rollout path; ACH customer funding should not be assumed available until asynchronous settlement and failure behavior have been separately validated.
Add the contractor using accurate identity and contact information. The organization is responsible for ensuring that the person or business being onboarded is the intended payee.
Kelvaro supports W-9 and W-8 documentation workflows and tracks readiness for year-end reporting. The customer remains responsible for determining which form is appropriate, the worker's legal classification, and whether professional tax or legal advice is required.
Contractors use Stripe-hosted onboarding for payout-destination information and Stripe-required verification. Kelvaro does not mark the contractor payout-ready merely because an onboarding link was opened or submitted.
A contractor is considered ready for the supported transfer flow only when Kelvaro retrieves the current Stripe recipient state and the required transfer capability is active. Restricted or incomplete accounts fail closed to a non-ready state.
Never paste full bank-account numbers, card details, tax IDs, Stripe secrets, or other payment credentials into Kelvaro notes, support messages, incident records, or internal chat. Use the designated provider-hosted flows and approved product fields.
Create the job, assignment, or other source work record that explains why the contractor is owed money. Record the applicable date, work context, rate, amount inputs, and operational evidence the organization needs to review the obligation.
If the organization uses Kelvaro check-in/check-out or location evidence, treat it as operational evidence supporting the work record—not as an automatic legal determination about employment, hours, or worker classification. Review exceptions before approving money.
Review the contractor, amount, currency, source work, and payout destination before creating or approving the obligation. If any of those are ambiguous, correct the record before continuing.
Approval means the business has authorized the obligation. It does not mean a Stripe transfer has been initiated and it does not mean the contractor has been paid.
After approval, use the Kelvaro customer-funding flow for the approved payout. Kelvaro records the funding attempt separately from the payout obligation so the system can distinguish an approved amount from money that is actually available for transfer.
Funding can pass through intermediate states such as CREATED or PROCESSING. A successful payment event alone is not enough to bypass the settlement gate. Kelvaro requires the funding record to reach SETTLED and rechecks amount/currency and other transfer prerequisites before allowing the contractor transfer path.
Never transfer against PROCESSING, FAILED, missing, mismatched, or otherwise ambiguous funding. If Stripe or Kelvaro state is unclear, stop and reconcile first.
Once the obligation is approved, funding is SETTLED, the amount and currency agree, and the contractor remains payout-ready, the controlled transfer flow can be initiated. The transfer path uses idempotency and recipient controls intended to make safe retries possible without creating a second obligation.
Kelvaro uses Stripe webhook state and scheduled reconciliation to compare external money state with the internal payout record. Do not treat a browser timeout, missing response, or delayed webhook as evidence that a transfer failed. Reconcile the existing transfer before taking another money action.
Do not promise a contractor that approval means receipt within a fixed number of minutes or by the next business day. Timing depends on customer funding settlement, Stripe status, payout eligibility, destination/bank schedules, the selected rail, and any provider review.
Leave the contractor transfer blocked. Refresh/reconcile the funding state and wait for the settlement path. Do not manually mark funding SETTLED to make the payout proceed.
Confirm the failure and verify that no contractor transfer was created. Correct the customer payment issue through the normal funding flow rather than editing the payout ledger manually.
Do not create a new manual transfer. Search/reconcile the existing payout and Stripe transfer state first. Network uncertainty is exactly when idempotency and reconciliation controls matter most.
Compare the Kelvaro payout, funding record, payout legs, Stripe transfer identifiers, recipient, amount, and audit history. A nonreceipt report is not resolved by sending a second payment before the first obligation has been reconciled.
Stop affected money movement immediately. Treat confirmed or credible duplicate/wrong-recipient concerns as SEV-1 money-safety incidents and follow the incident process.
Keep contractor identity/contact records, required tax-document status, and year-to-date payment records current instead of waiting until January to repair the roster.
Kelvaro can help identify documentation gaps, monitor year-to-date payment thresholds, and prepare reporting/export data for an accountant or filing provider. Review the report before relying on it for filing decisions.
Native 1099 e-filing remains post-pilot work. The customer is responsible for the filing population, deadlines, corrections, backup-withholding questions, state requirements, and final submission to the appropriate filing provider or government authority.
See the year-end workflow for the current readiness/export handoff process.
During the controlled pilot, email support@getkelvaro.com. The address routes into the monitored Kelvaro support inbox. For suspected duplicate/wrong payments, unauthorized money movement, or material data-integrity issues, stop affected money movement and escalate immediately.
For payment support, provide the Kelvaro organization, payout ID, job/work context, and relevant Stripe object identifiers when available. Never send full bank details, full tax IDs, card data, webhook secrets, API keys, or passwords.
| Severity | Examples | Action |
|---|---|---|
| SEV-1 | Duplicate/wrong payment, unauthorized money movement, material data-integrity or tenant-isolation issue | Stop affected money movement and escalate immediately |
| SEV-2 | Blocked payout workflow, worker/webhook outage, repeated production failure | Restore service and reconcile affected records |
| SEV-3 | Isolated invite, document, or non-money user issue | Resolve without bypassing safety controls |
Need a shorter overview?
The FAQ summarizes the current product boundaries, payment flow, and tax-readiness scope.