Running payroll for a distributed team sounds like it should be straightforward. Every contractor knows their rate, every pay period is the same, and you just need to send money to the right place. In practice, the process involves more steps than it should, most of which only exist because the tools available were not built for this specific situation.
This guide walks through how to set up and run a global pay run from scratch — from adding your first contractor to funding a single transfer that reaches everyone. The tool used throughout is betrworkr, because it is the most direct path from a roster of international contractors to actual payments on the right rails, including mobile money wallets.
Step 1: Build your roster with country-correct records
Before any payment happens, each worker needs a record that includes their country, engagement type, pay details, and payout method. This is also the step most companies skip, which is why they end up with a spreadsheet of SWIFT codes and a recurring problem when one of them changes.
In betrworkr, you go to the Roster page and add each person. For each worker, you enter their name, email, country, engagement type (contractor or EOR employee), role title, pay rate, pay currency, and pay frequency. The country selection is important because it restricts the payout options to the rails that actually work in that jurisdiction.
For a worker in Kenya, the platform shows bank transfer and M-Pesa as options. For a worker in Germany, it shows bank transfer only. For a worker in the Philippines, it shows bank transfer with BancNet or local bank rails. The account format is validated against the country's format rules before the record is saved, so you are not finding out three days after payday that an IBAN was entered incorrectly.
If a country is not yet supported for payout, the platform still lets you store the worker record and generate a contract — it just marks the payout as unavailable and shows you what is missing.
Step 2: Generate and send the contract
Once the worker record is saved, you generate a contract from the jurisdiction-specific template for that country and engagement type. This is where a significant amount of manual work disappears. A US contractor template used for someone in Colombia or the Philippines is legally incorrect — those countries have their own rules about what distinguishes a contractor from an employee, and the language in the agreement matters.
betrworkr renders the contract using a versioned clause pack for each jurisdiction. It fills in the worker's details, your company details, the pay rate, and the currency automatically. It uses AI to draft the jurisdiction-specific schedule language, but every variable is filled — there are no unresolved placeholders in the finished document.
Clicking "Send contract" emails the worker a tokenized signing link. They sign without needing an account. Both signature timestamps and the signer's IP are recorded and attached to the worker's record. Signed PDFs are stored and available to download at any time.
Before you send, the platform also runs a misclassification risk check. If the worker's country and engagement type combination presents high risk — meaning the arrangement looks more like employment than contracting under local law — you see a risk level and a plain-language recommendation. For high-risk situations, the platform surfaces an option to consider EOR employment instead.
All of this is available on the free Roster tier for up to three workers.
Step 3: Build a pay run
When payday arrives, you go to Pay Runs and create a new run for the period. The platform auto-populates one line per active worker — their gross in their currency, their default payout method, and the amount. You can edit any line, add a bonus, or exclude a worker from this run.
The most useful step before approving anything is getting a quote. Clicking "Get quote" fetches live FX rates and the payout partner's current fees for each target currency. What you see after that is a per-worker breakdown: the gross in local currency, the exact FX rate used, the fee, the total amount debited from your account in USD, and the expected settlement time for each corridor.
At the top of the run, there is one number: the total you need to fund in USD. This is what leaves your account. Every conversion, every fee, every rail is accounted for inside that number. You are not estimating and hoping the amounts land correctly — you are approving a specific figure with the details visible per worker.
FX quotes expire, so if you build a run and come back to it the next day, the platform will ask you to re-quote before approving. If rates moved significantly, it shows you the delta against the previous total.
Step 4: Fund the run
Funding options are ACH debit, card, or wire transfer. ACH and card move the run to "funded" once the payment confirms through Stripe's webhook. Wire transfers generate a unique reference code; the run stays in "awaiting funding" until a matching transfer is confirmed.
If a wire arrives short — which happens when correspondent banks deduct intermediary fees — the run shows the exact shortfall in dollars and cents, with a top-up action. Nothing is sent until the full amount is confirmed.
Once funded, you approve the run. The platform debits your company wallet, creates one payout record per worker with an idempotency key (so no double-debit is possible), and submits each payment to the payout partner on the correct rail. For a 25-worker run, that submission happens within 10 seconds of approval.
Step 5: Track statuses and handle failures
Payouts stream back through the payout provider's webhooks. Each worker's status updates from "processing" to "paid" as settlements confirm. The pay run shows you the current state of every line in real time.
When a payout fails — wrong account number, closed wallet, rejected by the beneficiary bank — the platform credits the exact amount back to your company wallet automatically, with the failure reason translated into plain language rather than a raw error code. You see a "Fix payout details and retry" action on the failed line. Fixing the detail and retrying creates a new payout linked to the original. The original is never re-sent.
Once all payouts are settled, the run status moves to "completed" or "partially failed" if some lines are still unresolved. Every worker who was paid receives a payslip they can download from their portal.
What this looks like in practice
For an ops lead paying twelve contractors across Nigeria, Kenya, the Philippines, and Colombia, the full process from run creation to approval takes about fifteen minutes — most of which is reviewing the per-worker quote breakdown before approving. The alternative is twelve separate Wise transfers, a SWIFT wire for the one person whose country Wise does not support well, and three follow-up messages over the next 48 hours.
The Global Payroll plan at $149 per month also includes Google Sheets hours import if your contractors log variable hours, Slack notifications when a payment fails or a funding deadline is approaching, and journal sync to QuickBooks or Xero after each completed run.
If you want to see what the pay run preview looks like before committing to anything, the free Roster tier shows the live FX preview — including per-worker rates, fees, and settlement times — without requiring you to fund anything. You can build the roster, generate contracts, and preview a pay run for free, and only upgrade when you are ready to move money.