Mission Agency Support and Remittance Software: Paying Workers Abroad From 400 Donors Who Never Coordinate

A gift with a name on it that legally is not theirs

A donor in Ohio gives $150 a month and writes a worker's name on the memo line. In the donor's mind that money belongs to that family. Legally it does not. For the gift to be deductible the agency has to retain control and discretion over its use, which means the worker's name is a preference the agency considers rather than an instruction it must follow. Every mission agency finance director knows this. Almost no donor does. And the software has to hold both truths at once: an internal ledger that reflects real charitable control, and a worker facing view that lets a family in Nairobi see who is supporting them and what their account looks like this month.

That tension shapes everything downstream. Support levels move constantly as donors start, stop, lapse and increase. A worker whose account is running below budget has to know early enough to do something about it, not discover it when the remittance is short. And the agency has to move money to a country where the banking works differently, in a currency that moved four percent this quarter, on a date the family has already budgeted around.

Most agencies run this on an accounting package with hundreds of designated funds or classes, a spreadsheet the finance team maintains for support levels, TntConnect on the worker side for donor relationships, and a monthly remittance built by hand. It holds to about 25 workers. Past that, the manual joins between those four things become the job.

Where the usual tools stop

TntConnect is a genuinely useful tool and workers like it, because it was built for the person doing ministry partner development rather than for the finance office. It manages the worker's own donor relationships, appeals and thank yous. What it does not do is agency side fund accounting, remittance, or the authoritative record of what a worker's account actually holds. It is a worker's tool, and it should stay that way.

Donor CRMs handle gifts, receipting and appeals. They do not model a support account with a budget, a variable monthly disbursement, an agency assessment and a balance that has to survive the worker moving to a different field. Accounting packages handle designated funds and produce statements your auditor will accept. They cannot give 200 workers across 40 countries safe self service access, and you should not try to make them.

The gap is the same one every multi party charity operation has: an operational layer that speaks to workers and donors in their language, sitting on accounting the auditor recognises, with the rules of designated fund control enforced in between.

Problem one: support level is a forecast, not a balance

A worker's account balance tells you the past. What the family needs to know is whether their committed monthly support covers their approved budget, and whether that is trending down. The inputs are messy: recurring gifts that will probably continue, recurring gifts whose card is about to expire, annual gifts that arrive every December from a church that has not decided yet, one time gifts that should not be counted as ongoing, and pledges that were verbal.

A build should compute committed support from actual recurring instruments with a confidence view rather than treating all giving as equal, and show the worker three numbers: what is committed, what is trending, and what the budget requires. Lapse detection is the highest value feature in the whole system. A monthly donor whose payment failed silently and who has not given for 70 days should generate an alert to the worker while the relationship is still warm, because a lapsed donor recovered in week ten is far more likely to return than one noticed in month six. That is not a technical claim, it is what every development team in this sector will tell you.

Problem two: remittance across borders is the part that breaks

Once a month you move money to workers in a dozen countries. Some have a local bank account. Some are paid into a home country account and draw on it. Some receive part in local currency for living costs and part at home for insurance and retirement. The exchange rate applied has to be defensible and consistent, because two families in the same country comparing their statements will notice a difference and they will ask.

The design decisions worth making early: hold worker accounts in a single functional currency and convert at remittance with a documented rate source and timestamp, rather than trying to maintain multi currency balances per worker, which multiplies complexity for no benefit most agencies can use. Record the rate on the transaction so a statement reproduces exactly. Decide how FX gain and loss is borne, by the agency or by the worker account, and apply it consistently, because inconsistency here is the single most common source of worker complaints about finance.

Then there is compliance. Sanctions screening on payments to certain regions, correspondent banking that quietly rejects transfers to a handful of countries, tax and social contribution obligations that vary by where the worker is resident and what nationality they hold, and in some jurisdictions rules about foreign funding of local organisations. None of this is software you build. It is policy the software has to apply consistently and evidence afterwards, and it belongs to your counsel and your auditor.

Problem three: the worker portal is a pastoral tool, not a report

What a worker needs is simple and specific: my current balance, my committed monthly support against budget, who gave this month, who has lapsed, what my next remittance will be, and how to submit a field expense. What they must not see is anything about another worker's account or the agency's internal notes.

Two details matter more than they sound. First, this has to work on a phone over a poor connection, because the person using it is in a place where bandwidth is expensive. Second, donor contact information visibility is a policy decision, not a default. Some agencies show workers full donor details because the relationship is theirs. Some restrict it. The system needs to support whichever you choose and to log access either way, since these are the records that surface awkwardly when a worker leaves the agency.

Problem four: designated fund discipline that survives an audit

Your auditor will test whether preferenced gifts were treated as agency funds under agency control, whether the agency assessment was applied consistently per policy, whether funds for departed workers were redirected according to your written policy rather than ad hoc, and whether the subledger ties to the general ledger.

That means the system needs an explicit policy for the awkward cases and enforces it: a worker leaves with a positive balance, a worker never reaches their support level and does not deploy, a donor asks for a refund, a project fund closes with money left. Each of those needs a documented disposition with an approval, not an email. Get those four cases decided before a build starts, because they are policy questions the software will otherwise ask you at an inconvenient moment.

Cost, timeline and what drives it

In Digital Heroes delivery experience a first release covering gift intake with designated fund handling, worker support account ledgers, support level tracking and a monthly remittance run costs $70,000 to $145,000 and ships in 12 to 18 weeks. The full platform adding multi currency payment execution, worker and donor portals, field expense claims, multi jurisdiction receipting and accounting integration runs $170,000 to $380,000 across 8 to 14 months.

What raises the price: the number of currencies and payment corridors, since each has its own operational quirks. Receipting in more than one country, because donor tax rules differ and a receipt is a legal document. Field expense claims with documents captured offline, which is a real mobile engineering problem rather than a form. Integration with your accounting package, which is essential and should be scoped as its own workstream. And migration, because agencies typically carry decades of worker and donor history that people are emotionally as well as legally attached to.

What keeps it down: doing the ledger, support tracking and remittance first, running one remittance cycle in parallel with your existing process, and delaying portals until the numbers are trusted.

When you should not build

Do not build if you support under about 25 workers in one or two currencies. A properly configured accounting package with designated funds, plus TntConnect for the workers, plus a disciplined monthly process, will serve you and cost a fraction of a build. Do not build if you cannot commit an internal owner from finance for a day a week, because the rules here are yours and no developer can invent them.

Build when you support 60 or more workers, when remittance spans several currencies and corridors, when workers cannot see their own position without emailing finance, when the finance team is spending more than a week a month on the remittance cycle, or when your auditor has raised questions about designated fund handling. The trigger is the same one that shows up across sponsor and intermediary organisations: the moment the coordination between donors, funds and beneficiaries becomes the actual operation, it needs to be a system.

How to choose a developer

Ask them to explain, in their own words, why a gift with a worker's name on it is not that worker's money. If they cannot, they will build you a wallet application and your auditor will find it.

Ask how they would handle a corrected exchange rate or a failed international transfer after statements have gone out. The answer should involve reversal as a recorded event and a reissued statement, never a quiet edit.

Ask what they will do about a worker on a slow connection in a rural area, and listen for whether they have thought about payload size and offline capture at all.

Ask how the subledger posts to your accounting package and whether they have worked with your specific one. Then settle ownership in writing before kickoff. The repository, the cloud accounts and the right to hire another firm should be yours. At Digital Heroes the client owns the code from the first commit, which matters for an agency whose worker and donor records need to outlive every vendor relationship it will ever have.