Batch Payroll Disbursement: From Employee File to Execution

A finance lead paying a distributed team rarely thinks of month-end as one event. They think of it as a file: rows of people, columns of amounts, and if something is off, one row that has to be found before the rest of the payment gets stuck behind it. Scheduling the date or repeating the cycle every month is the easy part. The file itself is what decides whether the payment goes out clean.

In Soulbit Academy we wrote this guide about that specific piece: how a payroll batch file is built, what the system validates before accepting it, what happens when a row fails, and what evidence remains for the accounting close. Soulbit is a payment and treasury rail in stablecoins for companies, not payroll calculation software and not an integration with a company's HR or payroll system.

What batch payroll disbursement is and when to use it

Batch payroll disbursement is the execution of a mass payment, in a single operation, from a file that lists every beneficiary of a period. The company uploads the file once, with amounts and recipient data already defined, and the system disburses to each destination without individual transfers.

It is worth distinguishing it from recurring payroll. A batch is a one-off execution: it fits a company's first payroll run, an extraordinary payment such as a bonus or a severance, or a month where the roster changed entirely. Recurring payroll, instead, reuses the same beneficiary list cycle after cycle without rebuilding the file. The operational detail of that second mechanism is in how to schedule recurring stablecoin payroll, and it is worth reading before deciding which mechanism to use each month.

A batch is not a way around legal payment periodicity either. Colombia's Código Sustantivo del Trabajo sets a maximum payment period of one month for a salary and one week for a daily wage (art. 134), and every jurisdiction where a company pays a team sets its own limit. A batch lets the company execute a payment when its list changes, but the legal cadence remains the same whether it runs on a recurring cycle or a one-off upload.

A typical case shows the difference. A company with a distributed team on a recurring cycle across Colombia, Mexico, and Brazil pays an end-of-year bonus to a subset of contractors, with amounts that have nothing to do with the recurring monthly cycle. That bonus goes out as a separate batch: its list, its amounts, and its timing do not belong in the recurring cycle. The same logic applies to a final payment for a contractor whose engagement ends mid-month, or to a one-time settlement with a group of providers that will not repeat.

The columns your payroll batch file needs

A payroll batch file needs six minimum columns for the system to validate it without a clarifying call or email.

Column	What it holds	Why it gets validated
Period reference	The company's internal reference for the month or payment run	Lets the batch be cross-checked against the company's own payroll run
Recipient identification	A unique document or identifier per person	Prevents paying a duplicate recipient or one without a complete record
Relationship type	Employee or contractor, per the company's own classification	The system does not make this call, it only records it
Payout currency or asset	USDC, USDT, or fiat in USD, EUR, or GBP, as defined	Determines the settlement channel used for that row
Net amount	The amount the company has already calculated for that period	Checked against the funded balance before execution
Verified destination address	The already-validated payout address or account on file	The irreversible field: a transfer to the wrong address cannot be reversed

The net amount in every row arrives already calculated by the company. The file does not recalculate wages, apply withholdings, or determine social security contributions: it receives the output of that calculation, produced by the company's own system or accountant, and turns it into an executable batch. For the Colombian part of that upstream process, see how to pay payroll in Colombia.

This point deserves a direct answer, because it is the first question a systems team asks when evaluating the mechanism.

Why a file instead of a direct connection to our payroll or HR system?

Because Soulbit does not offer an API or an ERP connector today. The file is the V1's intake mechanism: the company exports its already-calculated payroll to this format and uploads it manually. That is not a hidden limitation, it is the product's real scope today.

What the system validates before accepting the batch

Before accepting a batch, the system runs two blocking checks: each recipient's identity against the verified record on file, and whether the funded balance covers the total. File format and destination address errors do not stop the whole upload: they are flagged row by row, as the next section details.

Identity verification depends on prior onboarding. No new recipient enters a batch without first completing a record with their document, their active contract or invoice, and a destination address confirmed through a channel separate from the one the request arrived on. That record is built once and reused in every later batch, and its full logic is documented in the recurring payroll guide cited above, because the underlying record is shared between the two mechanisms.

The balance check happens before execution, not during it. The system compares the batch total, network fee included, against the funded balance in the operating account. If funding falls short, the whole batch is held, not only the rows that exceed the balance: it is the one check that does affect the entire file, because funding is a condition of the whole batch, not of a single row.

Company verification is the precondition that must be completed before any identity or balance check. Without completing KYB, which validates the entity, its activity, and its beneficial owners, there is no operating account to upload any file from. That record is resolved once, at onboarding, and does not repeat batch by batch.

What happens when a row in the file fails

A row that fails does not block the entire batch. It is flagged as pending, with the specific reason for the rejection, while the remaining rows continue toward approval.

Row error	What it causes	How it gets resolved
Unverified destination address	The row stays pending until the recipient's record is confirmed	Verify through a separate channel and, for a new recipient, run a test transfer
Zero or negative amount	The system rejects the row as an invalid value	Correct the amount in the file and resend only that row
Duplicate recipient in the same batch	Risk of paying the same person twice	Remove the repeated row before approving the batch
Unsupported currency or asset for that recipient	The row stays pending definition	Adjust the payout currency to what was agreed with the recipient
Incomplete recipient record	The row cannot be validated against any reference data	Complete the record before adding the person to the batch

Can you resend just the corrected row without rebuilding the whole batch?

Yes. The correction applies to the specific row, and the batch keeps the rows already validated. That avoids the most costly scenario operationally: rebuilding a forty or a hundred-row file because a single one carried a bad value.

Approval and dual control: the step between upload and execution

No batch executes on the strength of the upload alone. It first goes through approval by someone other than whoever built the file, even when a company's finance team is just two people.

That dual control exists because an on-chain payment, once executed, cannot be reversed with a call to a bank. The approver reviews the batch total, the count of pending rows against validated ones, and the funded balance, and only then confirms execution. The trail of who approved and when is logged with the batch.

Once a batch executes, each recipient in Colombia receives real pesos or dollars through local banking channels, as defined row by row by the company. That conversion and local rail are documented in COP and USD payment disbursement, which is worth reading alongside this guide because the file is the input and the local rail is the output of the same process. Outside Colombia, a batch settles in stablecoins or in fiat limited to USD, EUR, and GBP, and each recipient handles the conversion to local currency on their own.

The accounting close: the evidence each executed batch leaves

Every executed batch leaves an on-chain identifier per recipient, the piece that turns a mass payment into a set of accounting entries a company can defend under audit.

Reconciliation happens row by row, matching recipient, gross amount, network fee, and date against that identifier. The full procedure, including how to separate gross amounts from fees, is in how to reconcile stablecoin payments in accounting.

That evidence does not replace a company's own tax obligations in each country, which run in parallel to the batch. For recipients in Colombia, the DIAN requires generating and transmitting the electronic payroll supporting document within the first ten days of the month following the period paid, per DIAN. The detail of that obligation, already covered on its own, is in electronic payroll before the DIAN.

Social security contributions through PILA run on a separate calendar: they fall due between business day 2 and business day 16 of the following month, depending on the employer's tax ID, under Decreto 1990 de 2016. The full guide to that obligation is in PILA contributions for Colombian employers.

Why keep evidence for each batch beyond the month-end close?

Because Colombia's UGPP can audit payroll contributions up to five years back, and equivalent labor authorities elsewhere in the region keep their own look-back windows. A batch without a traceable identifier, a verified recipient record, and an approval trail is a documentation gap that surfaces exactly when it is no longer easy to reconstruct.

What Soulbit V1 delivers for batch payroll and what it does not

The V1 executes batch payroll disbursement from a file uploaded by the company, with format, identity, destination address, and balance validation, plus dual control before execution. It includes institutional custody, balances in USDC and USDT, fiat in USD, EUR, and GBP, and local banking rail only in Colombia.

What it does not deliver defines the mechanism precisely. It does not calculate wages, contributions, or withholdings. It does not generate Colombia's electronic payroll supporting document or the PILA form: those obligations stay with the company. And, the limit that generates the most questions from systems teams, it does not offer an API or a connector to the company's ERP or payroll software. The file is, today, the only intake mechanism.

Not offering an API is not a flaw to hide. A standardized file, validated row by row, with dual control and on-chain evidence, solves the same problem an automatic integration would, with less surface area for human error than copying and pasting amounts one at a time. The difference is who builds the file: today, the company does, not an automatic connector.

For a finance team paying a team spread across three or four countries, that trade-off is usually acceptable. The file replaces a stack of individual international transfers, each with its own delay and deduction, with one validated upload and one execution. It does not replace the company's own payroll and tax obligations in each country, and it is not meant to.