Fundraising Software · the school-fundraising platform built on a floor, not a skim
Fundraisers that fund real purchases — and a floor that keeps the school whole.
The standard fundraising model in this category takes a large cut of what a supporter gives — often 20% or more — before the school sees a dollar. Fundraising Software is built differently. The FLOOR PRINCIPLE is the foundation: the donor-side processing fee covers the card cost, so the school’s fundraising total is never reduced by processing. If a donor fee ever under-covers the actual card cost, the platform eats the shortfall — the school net is never touched. Every fee is disclosed to the donor before they give, in plain language, before the charge is submitted. And the proceeds of a fundraiser are aimed at a real catalog payment rather than a separate deposit the school eventually applies somewhere: a fundraiser’s gross is meant to go STRAIGHT toward the school’s catalog payment — yearbooks, modules, publications, any catalog line — via direct settlement rather than passing through an extra hand on the way. That settlement leg is founder-gated and not yet live, so every dollar currently settles 100% to the school.
This is the fundraising product home — deep on the FLOOR economics and the cross-catalog funding model. The campaign-store sibling for PTOs and booster clubs is at schoolfundraiser.network. The booster-club and PTA operations home is at boosterclub.software. The family and donor surface is at parentsoftware.app. The full platform story is at homeroom.software.
The category problem: a large cut taken before the school sees a dollar
School fundraising has a structural problem that predates the software platforms that run it. A supporter gives $50 to a school. A model that takes 20% or more of what a supporter contributes keeps $10 or more before the school receives anything. The school runs a campaign, does the work of reaching every family, and receives 80 cents on the dollar — or less. On a $10,000 campaign that is $2,000 or more that never reaches the school.
The problem is compounded by opacity: the supporter rarely knows how much of their gift reaches the school. The fee is embedded in the price of the item, or taken from proceeds at settlement, or described in terms that make the real cut difficult to compute before giving. The school often does not know the exact settlement amount until the check arrives.
Fundraising Software is designed around the opposite premise. The FLOOR PRINCIPLE means the school’s fundraising total is never reduced by card processing — that cost is covered by a disclosed donor-side fee, not taken from what the school receives. Every fee is shown to the donor before the charge is submitted, in plain numbers, not embedded in a price. And the model is built so a fundraiser’s proceeds fund a real purchase directly, not a separate deposit the school reconciles later.
The FLOOR PRINCIPLE: the school’s total is never reduced by processing
THE FLOOR is the foundational rule of this engine. One sentence: the donor-side processing fee covers the card cost, so the school’s fundraising total is never reduced by processing. If the collected donor fee ever under-covers the actual card cost, the shortfall comes out of the platform’s share — the platform share may go negative — never out of the school’s net.
The exact gross-up (the default donor fee mode)
The default donor fee mode is the exact gross-up. The math: a charge C = gift D + fee F; the processor takes its percentage of C plus its flat fee; the school still receives the full gift D. The fee is the ceiling of a ratio so the donor covers enough — never a cent short. The gross-up is the ONLY donor-fee mode that always fully covers the processor’s published card schedule for every donation amount, regardless of how small the gift is. The engine proves this property on every compute path, not by convention.
Every fee is disclosed before the donor gives
The disclosure is computed server-side off the gift amount — the donor never names the fee, so the disclosed amount cannot be gamed. The donor sees the gift amount, the processing fee, and the total charge in plain dollar figures before the charge is submitted: “Your $25 gift + $1.21 processing = $26.21 total. 100% of your $25 reaches Lincoln Elementary.” The “100% reaches the school” claim is gated: the engine surfaces it only when the donor fee fully covers the card cost. When the donor chooses not to cover the fee, the disclosure collapses to the no-fee form and the platform handles the card cost.
The platform eats the shortfall, never the school
If a donor fee falls short of the actual card cost — possible if a donor opts out of the cover-fee, or if the flat mode is used below its coverage breakeven — the shortfall is charged to the platform’s share, which may go negative. The school net is a FLOOR by construction: the engine computes schoolNet = donation - take and then resolves the platform share as the remainder. A processor cost that the donor fee did not cover lands in the remainder, not in the school’s number. The engine asserts this on every compute path and throws before returning a result that would violate it.
Conservation: no cent is lost or created
Every split is exact-integer-cents. The four-way split — school net, platform, studio (for a studio-run school), processor — sums exactly to the gross on every computation. There is no rounding residual that disappears silently. The conservation invariant is asserted by the engine before every result is returned; a cent unaccounted for throws, not drifts. The math is exact integer arithmetic, not floating-point, so there is no accumulation error across a campaign with thousands of transactions.
How the donor cover-fee flow works
The donor flow has a clear decomposition. The donor names a GIFT — the amount they intend the school to receive. The platform computes the processing fee server-side off that gift; the donor never names the fee. The donor is then asked whether they want to cover the processing fee so 100% of their gift reaches the school.
- Donor covers the fee: the charge = gift + covered fee. The school receives the full gift. The donor has transparently paid the card cost on top. The disclosure string shows all three figures before the charge is submitted.
- Donor does not cover: covered fee = 0, charge = gift. The school receives the gift minus whatever card cost the platform absorbs — the FLOOR ensures the school net is never reduced below the gift minus the disclosed take. The platform may absorb the card cost from its share.
The exact-sum invariant holds in both cases: charge = gift + covered fee, always, to the cent. The route asserts this before submitting any charge; an inequality throws rather than proceeding with a mismatched amount. The beneficiary on a donation nets the full intended gift in the cover-fee case; the school’s net is protected by the floor in the non-cover case.
Beneficiaries are typed: a donation can name a school, an organization, a club, a program, or a campaign as the beneficiary. Each resolves at settlement to the correct Connect destination. The donation lane is excluded from the product revenue-share by construction — there is no four-way product split on a donation, only the exact-sum decomposition into gift, covered fee, and the platform’s processing cost.
Fundraisers that fund real catalog purchases
The cross-catalog funding model is the structural difference from a fundraiser that produces a general deposit. When a school runs a fundraiser on this platform, the proceeds are aimed at a real catalog purchase — yearbooks, modules, digital publications, or any other catalog line. The fundraiser goal maps to a specific amount the school owes for a defined order. The proceeds settle directly toward that payment rather than sitting as an undifferentiated deposit the school applies later.
Yearbook for every child
The most common application: a school runs a fundraiser specifically to cover the cost of yearbooks for students whose families cannot pay for one. The fundraiser’s goal is the number of sponsored yearbooks times the per-book amount. As the fundraiser collects, the proceeds build toward that specific catalog line. The school does not need to write a separate check — the settlement goes directly to the yearbook order. A student who would not have received a yearbook receives one because the community funded the purchase through the platform directly.
Modules and publications
Any catalog line can be the target. A school that wants to fund digital publications for every student runs a fundraiser toward that purchase. A school that wants to add a module — a library catalog, a scheduling upgrade, a student-activities platform — runs a fundraiser toward that catalog cost. The settlement is direct: the fundraiser’s gross goes toward the school’s catalog payment, not to a general fund the school reconciles separately. The connection between what a supporter gives and what a student receives is traceable.
Honest-off today: the settlement leg is founder-gated
The cross-catalog funding model is built as a substrate. The settlement leg that routes fundraiser proceeds directly to a catalog payment does not yet exist as a live path. Every dollar currently settles 100% to the school. We name this plainly rather than presenting the settlement model as live today. The model is the right one and the substrate is the foundation; the live settlement leg is the founder-gated step. When it opens, the school’s fundraiser proceeds will route directly to catalog payment without an intermediate step. Honest-off — settlement leg founder-gated
The four fundraising surfaces: what is built and what is honest-off
The fundraising platform has four distinct surfaces. Each is marked honestly below — built means the engine is built and the compute substrate is production-ready; honest-off means the live money movement (the charge rail) is founder-gated and not active today.
Donation flows with donor cover-fee
The core donation flow is built: the donor names a gift, the server computes the processing fee, the donor is shown the disclosure (gift + fee = total) and asked whether to cover it, and the charge is assembled as an exact sum. The exact-sum invariant is asserted before any charge is submitted. The beneficiary types (school, org, club, program, campaign) are all supported, each resolving to the correct settlement destination. The donation lane is excluded from the product revenue-share by construction. Built. The charge rail that moves money is honest-off. Engine built
p2p fundraiser pages (consent-gated)
Peer-to-peer fundraiser pages let individual students, parents, or supporters run their own fundraising page on behalf of the school or campaign. p2p pages are consent-gated: a minor’s p2p page requires the appropriate consent record before the page can be created or published. The consent gate is at the data layer, not an application-layer check. The p2p page model is built (migration 0320_p2p_fundraiser_pages). The fundraising substrate and goal tracking run on the same engine as the core donation flow. Built. Live p2p checkout is honest-off. Engine built
Ticketing purchase flow (box-office)
The ticketing surface is the box-office: a school event, a concert, a play, or a game. The service-fee model has clear honest rules: a comp ticket (price $0) carries $0 fee; a cash or free event carries $0 fee; the donation line within a ticket order carries $0 fee and $0 take. A paid ticket carries the box-office service fee, which is modelled separately from the donation floor engine. No-oversell is enforced: the capacity gate is fail-closed. The gate-scan for entry is built. Built. Live ticket checkout is honest-off. Engine built
Campaign management and transparent totals
A fundraising campaign has a goal, a timeline, an item catalog (for a campaign store) or a donation target, and a transparent-totals dashboard: gross contributions, the processing fees, and the school’s net, live and updated with every transaction. The add-only ledger records every transaction as a new, dated entry — a correction is a new entry, not an edit. A school officer or treasurer can see the exact projected payout at any point, not just at close. Built. Communications delivery (email/SMS fan-out) is honest-off without configured provider keys. Engine built
How a fundraiser moves from launch to settled proceeds
The fundraising flow has a clear sequence. Each step builds on the previous; nothing is assembled at the output stage that was not entered or computed at an earlier one.
- The school configures the campaign. A campaign coordinator sets the goal — a dollar target, a number of yearbooks to fund, or a specific catalog line to purchase. The campaign has a name, an open date, a close date, and a payout configuration. The payout configuration states the fee structure before the campaign opens: there is no hidden margin revealed at settlement. The FLOOR rules are in effect from the first transaction.
- A supporter gives. The donor visits the fundraiser page — or the school’s p2p page operated by a student or family member — and names a gift amount. The platform computes the processing fee server-side. The donor sees the exact disclosure: gift, fee (if they choose to cover it), and total, in plain dollar figures. The donor submits the charge with full knowledge of where each dollar goes.
- The charge decomposes exactly. The charge = gift + covered fee. The exact-sum invariant is asserted at the route before the charge is submitted. The beneficiary receives the full gift. The covered fee absorbs the card cost. The platform share is the remainder; a processor shortfall that the covered fee did not offset lands in that remainder, never in the school’s net. No cent is unaccounted for.
- The ledger records the transaction. The add-only ledger writes a new, dated entry: the gift amount, the covered fee, the total charge, the beneficiary, and the timestamp. A correction is always a new entry, never an edit. The transparent-totals dashboard updates: the school’s running net is visible immediately, not at month-end. The goal-progress indicator reflects the new total against the campaign target.
- At close, the settlement routes to the catalog payment. When the campaign closes, the payout engine runs the exact-cent distribution. The settlement routes directly toward the school’s catalog payment — yearbooks, the catalog line the campaign was aimed at. There is no intermediate deposit the school reconciles. The connection between the donor’s gift and the student’s yearbook is direct. This settlement leg is honest-off today (founder-gated); every dollar currently settles 100% to the school while the live routing is prepared.
The operator consoles: who runs a fundraiser
A fundraiser on this platform is run by the school, a booster/PTA organization, or a studio operating on behalf of the school — each with their own console surface. The booster_pta role is a first-class role in the platform: a booster club or PTA officer has their own console for managing campaigns, viewing transparent totals, and tracking the campaign ledger. The booster/PTA console is distinct from the school administrator console and the studio console; a booster officer accesses only the campaigns their organization runs, not the school’s full financial picture.
Consent is at the center: a booster/PTA officer does not have access to student PII. The role is explicitly not a finance viewer on the school’s internal fund-accounting surface. The campaign ledger a booster treasurer sees is the ledger of the fundraiser they operate — not the school’s general fund. The separation is enforced at the data layer. The booster_pta console is built and landed (commit f75e8a89). The booster-club and PTA operations home is at boosterclub.software.
A studio operating on behalf of a school can run fundraisers in a studio-run configuration. In a studio-run fundraiser, the studio share is a fraction of the disclosed take — not an additional charge to the school. The FLOOR applies to studio-run schools exactly as it does to directly-run schools: the school net is the donation minus the disclosed take, and neither card costs nor the studio’s share reduce it below that figure.
Minor consent and data posture
A fundraiser involves minor students in several ways: a student is the beneficiary of a sponsored yearbook; a minor may operate a p2p fundraiser page; a minor’s identity may appear in campaign communications. The platform’s consent substrate governs each of these cases distinctly.
p2p pages are consent-gated for minors
A minor student’s p2p fundraiser page cannot be created or published without the appropriate consent record in the platform. The gate is at the data layer, enforced at the point of page creation, not as an application-level check a route could omit. A p2p page that lacks the required consent record for a minor operator is rejected before it is created. The consent record required is specific to the fundraising p2p-page purpose; a general consent record for a different purpose does not satisfy the gate.
Donor and supporter data: school-owned, never sold
A donor who gives to a school fundraiser is giving to the school, not to the platform. The donor’s contact information, giving history, and relationship to the school are owned by the school and the organization running the campaign. The platform does not sell, share, or use donor data for advertising or outside purposes. Consent for outreach (email or SMS reminders about an open campaign) is collected before the first message; a donor who has not opted in does not receive outbound communications from the campaign.
The beneficiary’s identity is not the donation’s identity
A donation that names a specific student as the beneficiary (a sponsored yearbook for a named child) does not expose the student’s identity to the donor or to the campaign store. The beneficiary reference in the platform is an opaque identifier — the student’s name does not appear on the donor-facing surface. The school’s administrator can see which students have been sponsored; the donor sees a confirmation that a student has been funded, not the student’s name or record.
Common questions
What is the FLOOR PRINCIPLE?
The FLOOR is the foundational rule of the fundraising engine: the donor-side processing fee covers the card cost, so the school’s fundraising total is never reduced by processing. Formally: schoolNet is always at least the donation minus the disclosed take. If the collected donor fee under-covers the actual card cost — which can happen if a donor declines to cover the fee — the shortfall comes out of the platform’s share, which may go negative. It never comes out of the school’s net. The school is protected by construction, not by policy.
What is the exact gross-up donor fee?
The exact gross-up is the default donor fee mode. The math: a charge C = gift D + fee F; after the processor takes its cut of C (the percentage plus the flat), the school still receives the full D. The fee is the ceiling of (rate * D + flat) / (1 - rate). It is the ONLY mode that always fully covers the processor’s published card cost for every gift amount, regardless of size. The disclosure is shown to the donor before the charge: gift amount, fee, and total in plain dollar figures.
How does the donor cover-fee flow work?
The donor names a gift — the amount they intend the school to receive. The platform computes the processing fee server-side. The donor is asked whether to cover the fee. If yes: charge = gift + covered fee; the school receives the full gift; the exact-sum invariant (charge = gift + covered fee) is asserted at the route before the charge is submitted. If no: covered fee = 0; charge = gift; the platform absorbs the card cost from its share via the floor. In both cases the exact-sum holds and the school’s net is protected.
What does 'fundraisers fund real catalog purchases' mean?
A fundraiser’s goal maps to a specific catalog line: yearbooks, modules, digital publications. When the fundraiser settles, the proceeds route directly toward the school’s catalog payment rather than depositing to a general account the school reconciles later. The settlement leg that routes proceeds directly to catalog payment is honest-off today — every dollar currently settles 100% to the school. The model is built; the live catalog-settlement routing is founder-gated.
What is the difference between fundraising.software and schoolfundraiser.network?
schoolfundraiser.network is the campaign-store sibling in the fleet — the product site for PTOs, booster clubs, and school offices running honest-math campaigns with a school-set item catalog. fundraising.software is the product home for the whole fundraising platform: the place that goes deep on the FLOOR economics, the donor cover-fee flow, the cross-catalog funding model, and the donation substrate. The two are siblings, not duplicates. schoolfundraiser.network is the operational campaign surface; fundraising.software is the platform home.
Are p2p fundraiser pages available?
The p2p fundraiser page model is built (migration 0320_p2p_fundraiser_pages). The consent gate for minor-operated pages is enforced at the data layer. The fundraising substrate and goal tracking on a p2p page run on the same engine as the core donation flow. Live p2p checkout — the charge that moves money — is honest-off (founder-gated). The engine is built and production-ready; the live charge rail is the honest-off step.
How does the ticketing flow work?
The ticketing purchase flow uses a box-office service-fee model. A comp ticket (price $0) carries $0 fee; a cash or free event carries $0 fee; the donation line within a ticket order carries $0 fee and $0 take. A paid ticket carries the box-office service fee, modelled separately from the donation floor engine. No-oversell is enforced: the capacity gate is fail-closed (a ticket to a full event cannot be sold). The gate-scan for event entry is built. Live ticket checkout is honest-off.
Is the booster/PTA console part of this platform?
Yes. The booster_pta role is a first-class role in the platform, with its own console for managing campaigns, viewing transparent totals, and tracking the campaign ledger. The booster/PTA console is built and landed. A booster or PTA officer does not access the school’s full financial picture, and the role does not have access to student PII. The booster-club and PTA operations home is at boosterclub.software; the fundraising platform home (this page) covers the fundraising engine itself.
Is live checkout available today?
The compute and prove substrate is built: the exact-integer-cents fee engine, the floor engine, the donor-cover-fee decomposition, the exact-sum invariant, the ledger, the p2p page model, the ticketing model, and the transparent-totals dashboard are all built and production-ready. The live checkout — the charge rail that moves money — is honest-off (founder-gated). We name this plainly. No pricing commitment, no live checkout, no live catalog-settlement routing today.
How does the school receive its proceeds?
The payout engine runs at campaign close. The exact-cent distribution uses a largest-remainder reconciliation pass so the total distributed always equals the gross minus the fee, to the cent, with no rounding in the platform’s favour. Payouts queue automatically to the school’s configured Connect account; there is no manual reconciliation step. When the catalog-settlement routing is live, proceeds will route directly toward the school’s catalog payment. Until then, every dollar settles 100% to the school.
Related surfaces
The fundraising platform connects to the rest of the school through the shared donor surface, the booster/PTA console, and the catalog. These destinations cover the adjacent surfaces.
boosterclub.software
The booster-club and PTA operations home: the surface for the officers who run these fundraisers, manage the treasury, and coordinate volunteers. The booster_pta console lives here.
parentsoftware.app
The family and donor surface. Parents and guardians live here: the fundraiser page a family visits, the p2p pages their students operate, and the donation flow with the donor cover-fee disclosure.
schoolfundraiser.network
The campaign-store sibling in the fleet: the product site for PTOs, booster clubs, and school offices running honest-math campaigns with school-set item catalogs. A sibling surface, not a duplicate of this page.
homeroom.software
The flagship platform brand home: the full product story, the persuasion case, and the complete picture of the fundraising substrate and every other module on the platform.
What is built and what is honest-off
The FLOOR engine — exact_gross_up donor fee, floor-is-law, platform-eats-shortfall, conservation of every cent — is built and production-ready today. The donor cover-fee decomposition — charge = gift + coveredFee, beneficiary nets the full gift, exact-sum asserted at the route, fee disclosed server-side before the charge — is built today. The p2p fundraiser page model (migration 0320_p2p_fundraiser_pages), consent-gated for minors, is built today. The ticketing purchase flow — box-office service-fee model, $0 fee on comp/cash/free events, $0 fee and $0 take on the donation line, fail-closed no-oversell, gate-scan built — is built today. The transparent-totals dashboard, the add-only ledger, and the booster/PTA console (f75e8a89) are built today. The live checkout charge rail is honest-off (founder-gated): the compute/prove substrate is built; live money movement is not active today. The catalog-settlement routing — the leg that routes fundraiser proceeds directly toward a catalog payment — is honest-off: the model is built; the live settlement path is founder-gated. Every dollar currently settles 100% to the school. No competitor brand names appear here. Money, pricing, and checkout are not on this page. No cookies.