# Paying contractors on two rails: bank and stablecoin, one book

URL: https://www.orla.finance/en/blog/pay-contractors-bank-and-stablecoin-one-book
Markdown twin of that page. Append `.md` to any Orla page URL to get one.

Rubric: Back office. Published 2026-09-26. Written by Orla.

Half the roster wants a bank transfer and the other half asks for USDT on TRON. What a mixed roster costs is not a fee on either rail but a second book, and this is how to run both from one.

Guides pick a side; rosters do not. The second book is two lists of who was paid, two approval habits and a month the accountant closes twice, and the way out is one contact card per person, one rule above both rails and one journal at the end.

### Why the roster splits

Nobody plans to pay on two rails. It happens one contractor at a time. A developer in Buenos Aires asks for USDC because the bank leg on their side takes a week and a few percent. A studio in Leeds wants pounds in a business account, because that is what their accountant can reconcile. A translator who used to take a wire now takes USDT after another client showed them how. Each request is reasonable, and after six months you have two ways of paying people and one person who remembers which is which.

The fee comparison is on [the international contractors page](/en/pay-contractors/international), the network arithmetic on [the USDC page](/en/pay-contractors/usdc), and [the payment cost calculator](/en/international-payment-cost-calculator) runs both for your own amount and currency. This post is about the part those pages leave open: what changes when you run both at once.

### Which rail for which contractor

The rail is the contractor's decision more than yours, and four questions settle it.

**Can they turn it into money cheaply where they live?** A stablecoin transfer costs cents to send and costs the contractor an exchange, a withdrawal and a bank to cash out, which is what an [off-ramp](/en/glossary/off-ramp) is. Where that route is cheap and familiar, the rail makes sense. Where it is not, a transfer that saved you a wire fee costs them a few percent and a Saturday.

**How big and how often?** The network fee does not depend on the amount, but the contractor's cash-out usually has a flat part. Small weekly payments in stablecoins are a bad deal for them; one monthly payment is better. Small payments in their own currency through a bank or a transfer service are usually fine.

**Does the bank leg actually reach them?** Domestic schemes are cheap and boring, and boring is good. A wire abroad is the expensive rail on every page of this site ([ACH vs SWIFT](/en/glossary/ach-vs-swift) has why). When the wire is the only bank route, the stablecoin is often the honest alternative.

**Can you answer the legal question for their country?** Whether a contractor in a given country may be paid in USDT, and how it is reported, is a question for a local adviser and your accountant. If nobody can answer it, pay by bank. The paperwork about the person does not change with the rail: a W-9 or a [W-8BEN](/en/glossary/w-8ben) describes the payee, not the money.

Then write it down. One rail per contractor, named in the agreement, with the network named when the rail is a stablecoin. Changing the rail later is a change to the contact card, not a decision made in the payment form at 11pm.

### One contact, both rails

The contact card is where two rails become one book.

In Orla a contractor's card keeps several payout rails at once: a bank rail picked by scheme (SEPA and IBAN, UK sort code, US ACH, or SWIFT for everywhere else), a crypto address per network with one marked default, a PayPal email. Bank details are typed as fields, not as a note, and an IBAN or a US routing number with two digits swapped is refused when you type it. Their tax id and the W-9 or W-8BEN sit on the same card under Documents.

The account you pay from decides which of those rails a payment can use. A TRON wallet offers the contact's TRON address, a euro pocket offers their IBAN, and a payee with no address for that network is stopped in the form rather than after the send. The same card carries the trusted mark, and editing a trusted contact's rails drops the trust until an owner or admin confirms it again, because trust belongs to the exact details that were checked. A new USDT address added to a trusted contractor is therefore a new decision, which is the right way round.

### One rule on the way out

This is where two rails usually turn into two policies. The bank has its own approval flow, the wallet app has none, and the rule that says "above 2,000 a second person looks" lives in one of them.

In Orla the rule sits above both. An approval rule with a threshold and a signature count applies to a payment whatever account it leaves from, and to a batch it applies to the total, so a payout split into small rows still needs the signatures the whole amount would. Whoever proposes a payment cannot sign it. With "address-book only" switched on, any destination that is not a trusted contact collects signatures whatever the amount. And the signer's notification names the contact, the amount and the rail the send will use (the network and a shortened address for a wallet, the last digits of the account for a bank payee), so a signature given from Telegram or a lock screen is for the payment that will leave.

One rule with a threshold, a signature count and the address-book switch is on every plan. Bands, named approvers and per-person monthly allowances are on Scale and Enterprise, and against an allowance a batch counts as one act: its total, not each row.

### Two batches, one queue

A batch draws from one account and pays in one asset, so a mixed roster is two batches: the euro one from the bank, the USDT one from the TRON wallet. That is not a limitation to work around. It is what keeps a bank draft and an on-chain run from being confused for each other. Both land in the same queue as cards with their totals, both pass the same rule, both are signed with Sign batch, and both draw payees from the same address book.

Each batch takes up to 200 rows, typed or imported from a CSV, with a preview of which payees matched an existing contact before anything is created. A row that repeats a payment to the same contact for the same amount within three days is flagged before you submit, and submitting the same draft twice returns the same batch. A template with a schedule prepares next month's draft and tells its author it is ready; the send is always a person's press. Running a batch is on every plan; the breakdown of who was paid and which bills a batch settled starts on Pro.

### How each rail lands in the book

This is the part that differs, and the differences are worth knowing before the first of the month.

**A plain bank account.** Orla records the payment, the transfer is made in the bank, and the expense is booked when somebody presses Mark paid, which asks how much and on what day and takes the bank's confirmation as a file. Confirming less than the full amount records an instalment, and the payment reads "Partly paid". The trap is the obvious one: a bank payment nobody marked paid is a signed decision with no expense under it. The batch page names the payees with no bank details on file, and their rows say "recorded, not sent".

**A connected bank.** With a Revolut Business or Airwallex account connected, Orla prepares the run as a draft inside your bank and someone on your team sends it there; with [Mercury](/en/mercury), Orla requests each payment into your Mercury approval queue and an admin approves it there; with Slash, a person presses Send via Slash. In every case only what the bank actually paid is recorded as spent, and when the bank's statement arrives the payment you already have gains the bank's reference and date instead of being booked twice.

**Your own wallet.** The run screen sends every approved on-chain payment of one wallet, one transaction each, with the wallet unlocked once, and addresses never screened are screened first. The payment then carries its transaction id linked to the block explorer and, under it, what the network actually charged, read off the chain after it settled. The fee is also its own row in the transaction list, named Network fee, in the chain's coin, so cashflow agrees with how much the wallet went down by. A transfer the network rejected comes off the books and the payment returns to approved with a note; one that nothing confirms within an hour is flagged "not confirmed" rather than paid again.

In one sentence: the bank leg is confirmed by a person or by the statement, and the chain leg is confirmed by the chain. Once you know that, the first of the month has one question per rail. Is every bank payment marked paid or matched? Is every on-chain payment confirmed?

### What the accountant gets

One journal, both rails. A period of the ledger leaves as double-entry lines in a CSV that Xero and QuickBooks import: two lines per transaction, the amount that moved with its currency, its value in the space's base currency at that day's rate, and the rate itself. A bank payout and a stablecoin payout sit in the same file with the same columns. There is no Xero or QuickBooks login to connect; the handoff is a file.

The stablecoin leg brings two things a bank leg does not. The network fee is a row in SOL, TRX or ETH, and it is a small disposal of that coin. And when the base currency of the book is not the dollar, a USDT payout is a disposal of USDT priced against the lots it consumed, so the journal posts three lines instead of two: the proceeds, the cost basis leaving the books, and the realised gain or loss on its own line. That line needs an account code like every other. A disposal in the period with no code for "Realised gain or loss on crypto" stops the export rather than handing over an entry that does not balance.

The month itself leaves as one archive: the journal, a statement per account in both the QuickBooks Online and the Xero presets, the payments with who proposed and who signed, the crypto disposals by lot with the hash, and a README saying what is inside and why anything is missing. The [month-end checklist](/en/blog/month-end-close-checklist-small-business) walks the close; the [handover post](/en/blog/hand-the-month-to-your-accountant) walks what the accountant does with the files.

### Where this is not the tool

- Orla is not a rail for fiat money. A bank transfer is made in your bank. A Wise or Payoneer payout is recorded here and made there, and the month's statement is filed against that account.
- Mercury pays US dollars only, and a UK sort code cannot be paid from it. Revolut Business exposes its API only on its Grow, Scale and Enterprise plans.
- Bitcoin payments go out one at a time from the payment itself; there is no Bitcoin run.
- Card spending is outside approval rules by nature: by the time a charge reaches the books the money has moved. A card has its own ceiling.
- Orla does not classify anyone, withholds nothing and files no 1099s. The contractor's cost to cash out a stablecoin is theirs and is not on your side of the book.
- On payouts and bills Orla takes nothing. Its own fee sits in three places: a crypto swap and a card top-up, each named on the screen before you confirm, and what an AI agent's wallet spends on its own.

### The setup, on one page

1. Every contractor is a contact with the rail they chose, typed as fields, and the network named for a stablecoin rail.
2. The rail is in the agreement, with who pays the transfer fee on each side.
3. One approval rule above both rails, and the person who proposes never signs.
4. "Address-book only" on, so a new address collects signatures.
5. A batch per account and asset, from a CSV, up to 200 rows.
6. Bank payments marked paid with the confirmation attached, or matched by the connected bank's statement.
7. On-chain payments confirmed, the hash on the payment, the fee row in the chain's coin.
8. A code on the chart of accounts for the realised crypto gain before the first export.