Fiscal Sponsorship Software: Giving 80 Projects Their Own Balance Without Losing Control of One Charity

One legal entity, eighty separate operations, and one very exposed operations lead

Fiscal sponsorship is a strange business to run. Legally you are one charity. Practically you are a bank, a payroll department, a compliance function and a customer support desk for dozens of independent projects who think of the money as theirs. The donations belong to you. The liability belongs to you. The tax return is yours. But the project leader who raised $40,000 for a river cleanup expects to see her balance, approve her own expenses and know what she can spend, and she expects it today rather than at month end.

The typical stack is an accounting package with classes or departments, a spreadsheet per project maintained by the operations lead, a donation platform that has no idea projects exist, and email. It works to about 15 projects. Somewhere between 20 and 40 it stops, and the failure is always the same shape: a project leader commits money that has already been spent or is restricted to something else, and nobody notices until the reconciliation. Now you are having a conversation about a deficit with someone who does not accept that the money was ever yours to control.

The second failure is slower and more expensive. Every project asks the same three questions, and the operations lead answers them individually, all week. What is my balance. Did that grant arrive. Can I pay this contractor. At 80 projects that is a full time job doing nothing but reading a ledger aloud.

Why accounting software and Open Collective each solve half of this

Open Collective is a real product and a good one for what it does. It gives projects a transparent public ledger, a donation page and expense submission, and for open source communities and grassroots groups it is often exactly right. Where it stops for a serious sponsor is the sponsor side: the fee schedule complexity, the restriction logic inside a project, the payroll relationship with employees of the sponsor working on a project, the grant reporting obligations you inherited when a foundation funded a specific project through you, and the consolidated audit and 990 that has to reconcile across everything.

Accounting packages solve the other half. QuickBooks classes and Sage Intacct dimensions will track project balances accurately, and your auditor will be happy. What they will not do is let a project leader touch anything. There is no safe way to give 80 non employees limited self service access to your general ledger, and you should not try. So the sponsor ends up as a permanent translation layer between the ledger and the people who need to read it.

The gap between those two is the product nobody sells: a project facing operational layer with real restriction enforcement, sitting on top of accounting the auditor recognises.

Problem one: restrictions inside restrictions

Every dollar in a sponsored project already carries one restriction, which is the project itself. Then a foundation grants $75,000 to that project for a specific program with a specific period and a specific budget. Now you have a restriction inside a restriction, and the project leader's spendable balance is not her total balance. It is total minus the grant funds that can only be used on the grant program, minus commitments already approved but not yet paid, minus the administrative fee that will be assessed on money that has arrived but has not yet had the fee applied.

Nothing packaged models that cleanly. A custom build treats a project as a container of funds, each with its own restriction, period and reporting obligation, and computes available balance per fund rather than per project. The number the leader sees on her dashboard is the number she can actually spend today, which is the single change that removes most of the friction in this business. Commitments matter here: an approved but unpaid contractor invoice has to reduce available balance immediately, otherwise the balance is a historical statement rather than a control.

Problem two: the fee schedule is never one number

Sponsors rarely charge a flat rate. There is usually a base percentage that varies by sponsorship agreement, a different rate on grant income versus individual donations, sometimes a reduced rate above a revenue threshold, sometimes a floor so tiny projects still cover their cost of administration, and payment processing costs that either pass through or do not depending on what you promised in 2019. Some projects were grandfathered onto old terms nobody has revisited.

When that is calculated by hand it is wrong somewhere, and the errors are asymmetric: you undercharge more often than you overcharge, because nobody complains about being undercharged. A build makes the fee a rule attached to the sponsorship agreement, applied automatically at the moment income posts, with the calculation visible on the project ledger so the leader can see it rather than discover it. Visible fees generate fewer disputes than invisible ones, even when the amount is identical. That is not a technical observation but it holds every time.

Problem three: paying people through someone else's entity

The project wants to pay a contractor, reimburse a volunteer, or in Model A sponsorship employ staff who are legally your employees working on their program. Every one of those is your legal exposure. Contractor classification, tax reporting, insurance, and the fact that a project leader who is not your employee is effectively directing work.

What the build has to do is route the request rather than execute it blindly. A payment request carries the project, the fund, the payee, the classification, the supporting document and the approval chain, then flows into whatever actually pays: the accounting package, a payroll provider, or a payment rail. Available balance is checked before approval, not after. Tax documentation is collected before the first payment rather than chased in January. And the project leader sees status without seeing anything about other projects, which sounds obvious and is where most homegrown solutions leak.

Problem four: one audit, one return, many stories

At year end you produce one set of financial statements and one Form 990 covering everything. Your auditor will test whether restricted funds were used as restricted, whether the fee methodology was applied consistently, and whether project level records tie to the general ledger. If your project ledgers live in spreadsheets, that testing is a manual sample and it takes weeks.

A build should post to the general ledger continuously with a documented mapping, keep an immutable transaction log so nobody can edit history, and produce a per project statement that reconciles to the ledger without adjustment. Release from restriction should be an explicit event with the evidence attached, not an assumption. Getting this right is what turns your audit from an excavation into a review.

Cost, timeline and what moves the price

In Digital Heroes delivery experience a first release covering project fund ledgers with restriction logic, donation intake and receipting, expense approval and automated fee assessment runs $65,000 to $140,000 in 12 to 16 weeks. The full platform with project leader portals, per project public donation pages, grant tracking and reporting, payment routing and accounting sync runs $160,000 to $350,000 over 7 to 12 months.

What pushes it up: whether you operate Model A comprehensive sponsorship with employees, since payroll allocation across projects is materially harder than contractor payment. The number of legacy fee arrangements you have to honour. International projects and payments, which bring currency, sanctions screening and local receipting into scope. Donor receipting rules if you sponsor across multiple jurisdictions. And a public donation page per project, which is really a small fundraising product with its own design and performance requirements.

What keeps it down: launching with your 20 largest projects, keeping the leader portal read heavy at first with expense submission as the only write action, and leaving public donation pages on your existing platform for phase one.

When you should not build

Do not build if you host fewer than about 15 projects and your fee schedule is uniform. Classes in QuickBooks plus a monthly statement PDF plus Open Collective for anything public facing will serve you, and the operations lead can hold it. Do not build if you are still deciding what your sponsorship model is, because the software encodes policy and encoding policy you have not settled costs more than waiting.

Build when project leaders asking for their balance has become a full time job, when a project has overspent and you found out late, when your fee schedule has more than three variants in the wild, when foundations are granting into specific projects and you owe them reports, or when you are past roughly 30 projects and month end reconciliation is eating the first week of every month. The trigger is control. Sponsorship is a business where the sponsor carries the liability and the project holds the initiative, and software is the only thing that lets you say yes quickly without losing the ability to say no.

How to choose a developer

Ask them to model available balance on a whiteboard for a project that has a general fund, a restricted foundation grant, two approved but unpaid invoices and an unassessed fee on last week's donations. If they produce one number, they have not understood the business. If they produce a number per fund with commitments deducted, keep talking.

Ask how they will keep project leaders inside a hard boundary. Multi tenant isolation is the security requirement here, and the failure mode is one project leader seeing another project's donors. That is a relationship ending bug and it should be tested, not assumed.

Ask what they have integrated on the accounting side and get the specific package by name. Ask how release from restriction is recorded and whether an auditor could follow it without your help.

Then settle ownership in writing before kickoff. You should hold the repository, the cloud accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit, which matters here because your projects will outlive any vendor and the records belong to a charity, not to a supplier.