How to schedule recurring payroll in stablecoin: an operating guide

Pay day for a distributed team tends to look more like a logistics operation than a finance task. Someone opens the spreadsheet, copies amounts, checks destination details, fires transfers one by one and then waits. With five people it is tedious. With twenty-five across six countries, it is an operational risk repeating every month.

At Soulbit Academy we wrote this guide as a reproducible procedure. Soulbit is a stablecoin payments and treasury rail for businesses, not a labour advisory firm and not payroll calculation software. What follows explains how a recurring cycle is built on that rail, what has to be ready beforehand and what sits outside its scope.

What recurring payroll in stablecoin is, and what it is not

Recurring payroll is a payment cycle repeating on a fixed frequency to a stable list of recipients. The company defines who gets paid, how much and when, and the cycle runs without being rebuilt each time.

It is worth being precise about the function. It is payment disbursement: it moves money to a list of destinations. It is not payroll calculation software. It does not compute salaries, determine social security contributions, apply withholdings or produce payslips. That layer stays with the company, its system and its accountant, and the output of that calculation is the input to the payment cycle.

The concrete advantage shows up when the team is spread out. Instead of one international transfer per person, each with its own term and deduction, the cycle sends from a single digital dollar balance and every transfer settles in minutes. The cost context of the traditional route is measured by the World Bank in its Remittance Prices Worldwide series, which puts the average cost of sending money across borders at 6.36% of the amount and close to 15% through a bank channel, and by the BIS cross-border payments programme, which exists because the G20 considers these payments slow and opaque.

Before scheduling anything: the file you need first

Ninety percent of recurring payroll problems happen before the first cycle, and almost all of them are documentation problems.

The first is classifying each person. Employees and contractors are paid differently, with different documents and different obligations, and that classification depends on the facts rather than the signed contract. The full analysis is in contractor vs employee in LATAM, and it belongs before anyone touches a spreadsheet.

The second is verifying the company itself. Before operating, a KYB process validates the entity, its business activity and its ultimate beneficial owners. Without that file there is no operating account.

The third is a record for each recipient: identification, country, current contract or invoice, the currency or asset they are paid in, and a verified destination. That record is built once and maintained, and it is what prevents the most expensive mistake in the process.

Why do destination details deserve their own procedure?

Because the payment is irreversible. An on-chain transfer sent to the wrong destination is not recovered with a phone call to a bank. So the rule is to verify every addition and every change through a channel other than the one the request arrived on, record in writing who authorised it, and run a test transfer before adding the person to the full cycle.

Building the cycle, step by step

With the file ready, building the cycle is quick. What matters is the order.

Step	What the company does	What must be recorded
1. Calculate	Works out the net amounts payable for the period in its own system	Calculation approved by the responsible manager
2. Build the list	Loads recipients, amounts and the asset or currency of payment	Batch with its internal reference and period
3. Validate destinations	Checks each destination against the verified record	Validation log and exceptions
4. Fund	Confirms enough balance for the batch plus network fees	Evidence of available balance before executing
5. Approve	Applies dual control: whoever builds does not approve	Trace of who approved and when
6. Execute and reconcile	Runs the cycle and logs every on-chain identifier	Subledger with an identifier per recipient

The frequency is worth fixing in writing and respecting. A distributed team organises its own commitments around that date, and moving the cycle for internal convenience erodes trust faster than settlement speed builds it. If the date falls on a weekend, the advantage of the rail is that there is no banking window: the cycle can run anyway. The practical rule is to pick a fixed date, communicate it when each person joins and treat it as an operational commitment.

Two details separate a stable cycle from a troublesome one. The first is funding: the balance must cover the full batch plus network fees, verified before execution rather than during. The second is dual control: whoever builds the list should not be the one approving it, even when the finance team is two people.

Pay day and reconciliation

Once the cycle runs, each transfer generates its own on-chain identifier. That identifier is what turns a payment into a defensible accounting entry.

Reconciliation happens the same day, line by line: recipient, gross amount, network fee, date and identifier. A useful habit is closing the cycle with a single check: the sum of the lines recorded must match the total that left the balance, fees included. If the two numbers agree, the cycle is finished. If they do not, the gap is found while the context is still fresh rather than three weeks later. Recording gross and fee separately prevents mismatches, and using a single exchange rate criterion, documented in writing, prevents arguments at close. The full procedure is in how to reconcile stablecoin payments in accounting.

In Colombia the cycle can end in local currency, because V1 has a local banking rail there. The specific mechanics are in paying payroll with stablecoins in COP. Elsewhere the cycle ends in stablecoins or in fiat limited to USD, EUR and GBP, and each person handles the step into their own currency. For teams with contractors abroad, the detail is in paying international contractors in USDC.

The mistakes that break a recurring cycle

Cycles do not fail on the technology. They fail on file maintenance.

Mistake	What it causes	How to avoid it
Accepting a destination change through the same channel as the request	Fraud exposure and an irreversible payment to a third party	Verify through a different channel plus a test transfer
Insufficient balance at execution	The batch cuts off midway and leaves partial payments	Verify funding for the full amount plus fees before launching
Adding a person with no current contract or invoice	A payment with no documentary support for review	Complete record mandatory before joining the cycle
The same person building and approving the batch	No cross-check against an error or a diversion	Dual control with an approval trace
Reconciling at close instead of the same day	Costly reconstruction and fee-driven mismatches	Daily logging with an identifier per line
Assuming local currency deposit outside Colombia	An expectation the team will see broken	Communicate it when each person joins

What Soulbit V1 delivers and what it does not

V1 provides a business account holding stablecoin balances in USDC and USDT, plus fiat in USD, EUR and GBP. It includes KYB, recurring payroll, batch payments, payment links, payment QRs, crypto to fiat conversion by quote on request, AML/KYT monitoring and institutional custody. USDC is a digital dollar issued by Circle, backed by cash reserves and US Treasury bills.

What it does not deliver defines the project. It does not calculate payroll, compute contributions or withholdings, produce payslips or report to any authority. It does not classify employment relationships. It does not deposit in local currency outside Colombia. And it offers no cards, no yield on balances, no proprietary token and no native mobile app.

When is this route not the best option?

When the team sits in one country and is paid in local currency. Local banking already solves that, and adding a dollar rail introduces steps without removing friction. Recurring payroll in stablecoin pays off where there is genuine geographic spread, payments in dollars and a cycle that repeats. If the team fits inside a single bank, it is probably unnecessary. The two-currency disbursement case is developed in COP and USD payment disbursement.