Case: An Edtech Collects Tuition in Three Countries and Pays Its Tutors
Collecting tuition from students in three countries and paying sixty tutors the same week: what actually changes.
An online education platform juggles two money flows that rarely fit the same tool. On one side it collects tuition from thousands of families across several countries, in small, repeated amounts. On the other, it pays dozens of freelance tutors every month, often living in countries different from their students. When both flows grow at once, the operations team absorbs friction from both directions.
In Soulbit Academy we present this case as an illustrative, synthetic example, not a real client. The company does not exist and the figures are reasonable assumptions, consistent with typical costs and timelines for international collection and payment. The goal is to show the scale of the problem when an edtech collects tuition in three countries and pays its network of tutors through mass disbursement.
The company profile (illustrative case)
Let's call the company "Vireo Learning," a platform headquartered in Bogotá selling exam-prep and professional certification courses by subscription. It has a 22-person core team and annual revenue near 2.6 million dollars.
Its students are in Mexico, Chile, and the Dominican Republic: roughly 4,100 active enrollments, with an average ticket equivalent to 38 dollars a month per student. Content is delivered by 60 freelance tutors spread across five countries: Colombia, Argentina, Guatemala, the Philippines, and Portugal. None of the tutors are direct employees; all invoice as independent contractors under their own country's rules.
The finance function is run by a single controller and one assistant. Between the two of them, they manage tuition collection, monthly tutor payouts, and reconciling both flows against the company's internal enrollment system.
The problem: collecting from thousands of families and paying dozens of tutors
The visible symptom was late payments to tutors. The real symptom was that the company ran two completely separate money circuits with no point where they crossed.
On the collection side, each country brought its own method: local bank transfer in Mexico, card payments in Chile, and a mix of digital wallets and cash deposits in the Dominican Republic. On the payment side, the controller manually assembled a batch of 60 international transfers every month, with different forms for each destination bank and country.
Why does this problem hit an edtech harder than most digital businesses?
Because volume runs high on both sides at once. A company that only collects can scale collection without touching payments. A company that only pays suppliers can negotiate terms. Vireo Learning did both every month, with thousands of small incoming payments and dozens of medium outgoing ones, and any delay on one side was felt immediately on the other: without tuition collected on time, the tutor payout batch slipped too.
What the old model actually cost
The company had never measured the combined cost of both flows, so the first step was putting it on a spreadsheet. The figures below are illustrative, but the calculation method is one any team can replicate.
A public reference exists to size the fee side of cross-border payments. The World Bank calculates in its Remittance Prices Worldwide series that sending money between countries costs 6.36% of the amount on average, and up to 15% through a traditional banking channel. The Bank for International Settlements' CPMI cross-border payments programme documents why the G20 prioritizes making this kind of payment cheaper and faster: it remains slow, costly, and opaque across most corridors.
| Concept (illustrative case) | Before: separate circuits | After: collection and disbursement with Soulbit |
|---|---|---|
| Days to assemble the payout batch for 60 tutors | 3 full business days | Under 1 day |
| Fee per international transfer to a tutor | 12 to 32 dollars depending on receiving bank | Network fee known before sending |
| Tutors in Argentina with delayed pay per month | 1 to 3, due to recurring currency controls | 0, they settle in USDC and choose when to convert |
| Distinct tuition collection methods per country | 3 methods with no cross-check | Uniform payment link and QR, same reference |
| Monthly hours spent reconciling both flows | About 22 | About 7 |
| Unidentified tuition payments at month close | 6 to 10 | Fewer than 2 |
The number that weighed most on the controller was not the fees but the delayed tutors. A tutor who is not paid on time stops teaching or moves to another platform, and Vireo Learning had already lost two strong tutors in a year for that reason.
The change: tuition through payment links and QR, tutor pay through disbursement
The company did not migrate everything at once. It first fixed tuition collection, and two months later centralized tutor payouts.
On the collection side, three rules stuck. Each billing cycle generates an individual payment link per student, with the enrollment number in the reference. In-person service points in Santo Domingo added a collection QR code for families who prefer to pay on the spot. Families who cannot pay that way keep their usual bank method, with no pressure or penalty.
What happens when a family misses the billing cutoff date?
They receive a new payment link generated by Vireo Learning's own academic system, not by the payment platform. The company had to schedule that step itself, since there is no automatic recurring charge: each cycle depends on someone, or some internal process, generating and sharing the link again.
On the payout side, the company uses Soulbit Salaries, the payroll disbursement module, to settle the monthly payment to all 60 tutors in a single file, described in detail in batch payroll: from file to disbursement. Each tutor receives their pay in USDC the same day; those operating in Colombia can convert to pesos through the platform's local banking rail, while everyone else converts through their own bank.
How the relationship with tutors and families changed
What the controller values most is not speed but predictability across both flows landing on the same date each month.
Before, tuition collection and tutor payouts ran on independent calendars: if families paid late, tutor pay slipped with them. Now the company closes the collection cycle five days before the tutor payout date, leaving enough margin so a one-off tuition delay does not affect the whole batch.
How does the company avoid treating a freelance tutor as a disguised employee?
The company reviews every contract with legal counsel before setting the monthly payment. The payment method does not change the nature of the relationship: a tutor with fixed hours, exclusivity, and subordination can be classified as an employee under the law of the country where the service is performed, regardless of whether they are paid in pesos or USDC. In Colombia, the UGPP can audit the real nature of a service contract up to five years back, as detailed in independent contractors in Colombia: UGPP and social security. Vireo Learning formalized a service agreement with each tutor that reflects the real autonomy of their work.
With collection and payment ordered, reconciliation changed in nature too. Every payment link and every tutor payout leaves an on-chain identifier that gets matched against the academic system the same day, instead of at month close. The company documented a single exchange-rate criterion for its books and applied it equally to tuition revenue and tutor payments.
What the change did not solve
The change did not solve automatic recurring charges, integration with the academic system, or automatic conversion to local currency. Vireo Learning closed the project with a clear list of limits it decided to manage differently.
| Initial expectation | Actual result | How the company handled it |
|---|---|---|
| Charge tuition with an automatic recurring debit | No automatic direct debit exists in the V1 | Its academic system generates and sends a new link every cycle |
| Integrate collection and payment with its academic CRM | No API or SDK for ERPs exists in the V1 | Reconciles by operation identifier with an in-house script |
| Migrate every family to the payment link | Migrated 68% within five months | Keeps traditional bank collection for the rest |
| Convert balances to local currency automatically | No automatic fiat conversion exists | Each tutor and the company convert through their own bank |
| Earn yield on the balance while it sits | Does not exist in the V1 | The balance is kept as working cash, unremunerated |
| Manage everything from a mobile app | No native app is available in the V1 | Operates from the web platform |
What another company can take from this case
Three conclusions carry over well to any business that collects from many people and pays many people at the same time.
First: when collection and payment share a calendar, you have to design the margin between them, not assume they will line up on their own. Closing the collection cycle before the payout date kept a tuition delay from turning into a payroll delay.
Second: the legal classification of whoever receives a payment is never solved by the payment rail itself. A similar case of mass disbursement to people across countries, this time from an agency's side, appears in an agency pays its freelancers in USDC, where the same contractor-versus-employee question comes up again.
Third: automating the recurring billing step and the reconciliation is work the company itself has to build, not something the payment platform solves alone. The case of a SaaS startup collecting USDC from clients in 12 countries shows the same pattern on the collection-only side, without the mass disbursement-to-people component that Vireo Learning also had to solve.
Frequently asked questions
Is this case based on a real Soulbit client?
No. This is an illustrative, synthetic case built to explain a recurring problem for education platforms with students and tutors spread across several countries. The company, names, and figures are invented, though consistent with typical costs and timelines for cross-border collection and payment.
Can an edtech charge tuition automatically every month with a recurring debit?
Not in the V1. There is no automatic direct debit or recurring charge: each billing cycle requires generating and sending a new payment link or showing the QR code again. An edtech with monthly tuition has to automate that step from its own academic management system, since the platform will not trigger it on its own.
Do all freelance tutors get paid the same way regardless of their country?
No. The disbursement runs through a single payment file, but each tutor receives funds according to what they can operate in their own country: some keep the balance in stablecoins, others convert it through their own bank. Only Colombia has a local banking rail inside the platform; everywhere else, converting to local currency happens outside it.
Does paying a tutor in stablecoin change whether they are a contractor or an employee?
No. The payment method never defines the labor relationship. If a tutor works fixed hours under exclusivity and subordination, the law of the country where the service is performed can classify them as an employee regardless of whether they are paid in local currency or in USDC. The company in this case reviewed that classification with legal counsel before switching payment rails.
Does the platform integrate with an edtech's academic management software?
There is no API or SDK for automatically connecting to enrollment systems or academic CRMs in the V1. Reconciling a received or sent payment against the company's internal records is done by matching each operation's identifier manually or with a custom script.
Want your company to add stablecoins to its operations?
Join the Soulbit waitlist and start paying payroll, collecting and managing treasury without SWIFT.
Join the waitlist