# Paying contractors in five countries, on bank and stablecoin

URL: https://www.orla.finance/en/guides/contractor-payouts
Markdown twin of that page. Append `.md` to any Orla page URL to get one.

A setup kit for a small company with no finance team: which rail each contractor gets, how to take their details without getting robbed, the payout policy on one page, the monthly run, and what lands on your accountant's desk.

Field guide 01, October 2026 edition: 10 pages · 6 steps · 7 checklists · 4 templates. Free: a PDF and its templates in one ZIP, sent by email from https://www.orla.finance/en/guides/contractor-payouts.

#### Most payout mistakes are made once, at onboarding

For a founder who pays contractors abroad, some by bank and some in a stablecoin, and is still the only person who can press send.

Nobody designs a contractor payout process. It accretes. The first designer wanted a wire, the second asked for USDT because her bank takes a week, and by the twentieth contractor the founder is the process: the only person who knows who gets paid where.

That holds until payout day lands on a flight, or until a message arrives from a contractor's address saying the wallet changed. The fixes are not clever. They are a few decisions written down before the second rail goes live, and a form that replaces email for anything involving payout details.

#### The short version

- Pay by bank unless the contractor asks for a stablecoin and can turn it into local money cheaply.
- Bank details arrive through a form the contractor fills in, never from an email, a chat or a PDF. A wallet address arrives in writing with its network named, and nobody pays it until it's confirmed on a call.
- New payout details are handled like a new payee. Someone confirms them by calling a number you already had.
- One approval rule above both rails, written before the second rail exists.

#### What's inside

1. A rail for each contractor: Decided once, written into the agreement. Template 1, the rail worksheet (page 3).
2. Onboarding a contractor: The one moment details are allowed to arrive. The onboarding checklist, in order (page 4).
3. The payout policy: One page, written before anyone needs it. Template 2, the payout policy, and a checklist before you switch it on (page 5).
4. The monthly run: A calendar, so payout day is boring. Template 3, the payout calendar, and Template 4, the batch import (page 6).
5. The stablecoin leg: Cheap to send, impossible to call back. Checklists for the first send to a new address and for every run (page 7).
6. The book and the handoff: Each rail is confirmed by something different. Checklists for the first of the month and for what the accountant needs (page 9).
- What the October run caught: Two warnings in one run: first payments that looked like any other, and a brand-new wallet two days before an invoice. Neither said no, and both were right to ask. (page 8).

#### The templates

- 01-rail-worksheet.csv: Picking and recording each contractor's rail
- 02-payout-policy.csv: Your policy, one decision per line
- 03-payout-calendar.csv: The run, by day and by person
- 04-payout-batch.csv: Importing a batch of payouts

#### The illustrative case

Northwind Studio is a 12-person brand and packaging studio, a Delaware LLC, with about twenty contractors in Portugal, Serbia, Cyprus and two other countries. Four of them are paid in USDT on TRON from one wallet; the rest are paid by bank from Mercury and Airwallex.

Northwind is a demo company. Its books are seeded in Orla, and every screenshot in the guide is a frame recorded from the working product on those books. The names, amounts and addresses are invented.

The guides are general information, not legal, tax or financial advice. What applies to your company is a question for your accountant and, where a country's rules come in, a local adviser.