Tuition.software
Book a conversation

Tuition.software · The money engine for school stores and fundraisers · Early access · 2026

The cost floor, the honest split, the add-only ledger — the money engine behind every school store and fundraiser

Tuition.software is the money layer behind school stores, fundraisers, and picture-day commerce — not a tuition-billing product. The name is the brand; the platform is the money rails: a code-enforced cost floor that nothing sells below, a no-skim split engine that runs fee-off-gross-first with exact-cent reconciliation, and an add-only ledger where every transaction is a new, dated entry and every cent is traceable. The platform does the math and keeps the record; the school and its programs keep the proceeds. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works
Cost floorcode-enforced at the data layer — nothing sells below cost, ever
No skimfee off gross first — school and program keep the full net
Exact centslargest-remainder reconciliation — zero residual platform rounding
Add-onlyevery transaction is an add-only ledger entry — reversals are records, not deletions

The money layer behind school commerce — built for the business office, the treasurer, and the store operator

Three problems every school business office knows — and one engine that fixes all three

A school store runs a spirit-wear sale. Someone prices a hoodie below cost because they forgot the imprint fee. The store sells two hundred of them. The school has just subsidised two hundred hoodies out of its own fund, and nobody finds out until a business-office audit three months later. The cost floor is the fix: a hard rule enforced at the data layer, not a policy reminder in a handbook, that refuses any sale configured below the item’s cost before the first record is written.

A booster treasurer runs a fundraiser. At the end, the split between the program’s fund, the school’s activity fund, and the processing fee is done in a spreadsheet someone built three years ago. Nobody is sure whether the fee is taken off the gross or the net. Nobody can explain where a twelve-cent discrepancy in last year’s reconciliation came from. The no-skim split engine is the fix: fee off gross first, splits on the net remainder, largest-remainder reconciliation that assigns every residual penny to the party with the largest fractional remainder — so the total always equals exactly what came in minus the stated fee, and there is no twelve-cent mystery.

At year-end, a business office pulls together records from five different places: the store system, the fundraiser spreadsheets, the picture-day order forms, the booster treasurer’s separate accounting export. None of them reconcile cleanly. The add-only ledger is the fix: every transaction recorded as a new ledger entry from the first sale, every reversal a new entry that references the original, so the full year-end picture is always one report away — not a month of manual reconciliation.

The cost floor, the split engine, and the add-only ledger are built and production-ready. The payment rail that moves money is honest-off — not enabled for live transactions today. A conversation shows the current state honestly and what the timeline looks like.

Book a conversation Full platform

How it works

The money layer across the school year in four stages

Tuition.software runs on the school year: configure the money layer in the fall, run stores and picture days through the year, run fundraisers mid-year, reconcile and export at year-end. Every stage is described as it is built today.

Step 1 · School year setup — cost floors, split configurations, and ledger accounts

Before the first store or fundraiser opens, the business office or platform administrator configures the money layer for the year: cost floors for each product category, split configurations for each fundraiser or store type, and ledger accounts for each program or fund. The add-only ledger is initialised with carry-forwards from the prior year. Consent for student and family financial data is configured at this stage — no transaction data flows for a student or family who has not opted in.

Step 2 · Picture day and store runs — cost floor and split engine behind every order

When a school store or picture-day commerce flow opens, the cost floor and split engine run behind every order. A price entered below the configured floor is rejected at the data layer before a record is written. Each order is recorded as an add-only entry: item, price, cost, split, and timestamp. The store operator sees a running total that tracks gross, cost, and net for each item type — reconciliation is not a post-season task; the ledger does it continuously.

Step 3 · Fundraiser run — no-skim split, transparent totals, projected distribution

A fundraiser configured in the split engine runs with full transparency: fee off gross first, splits to the net remainder, running totals visible to the business office before settlement. The treasurer sees the projected distribution — school fund, program, and any other party — before the charge rail runs. The add-only ledger records every contribution and every projected split entry as the fundraiser runs. There is no skim: nothing is inserted between what a supporter contributes and what the program receives beyond the stated fee.

Step 4 · Year-end — reconciliation, exact-cent settlement, ledger export

The year-end settlement runs on the exact-cent ledger: every store, every fundraiser, every order, every reversal — all accounted for per fund and per program. The reconciliation report shows gross, fee, net, and split for every transaction in the year. The business office sees the exact carry-forward for each account. One-click export delivers the full ledger in a portable format — the school owns its financial records and can take them anywhere, whether it stays on the platform or not.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. In development means the surface, wire-up, or integration is in active build. We do not claim otherwise.

Code-enforced cost floor — nothing sells below cost at the data layer

The cost floor is a hard rule enforced at the data layer: no item in a school store or commerce flow can be configured to sell below cost — no price may be set below its configured cost floor. The store or platform administrator sets the cost for each item at configuration time. If a price is ever entered below that floor — by accident, by data-entry error, or by misconfiguration — the engine refuses the sale at the data layer, not by disabling a form element that could be re-enabled, but by refusing the transaction at the engine. This protects a school from unknowingly subsidising a sale out of its own fund. The cost floor applies to yearbook orders, spirit gear, fundraiser items, and photography packages — anything priced through the commerce layer. The floor is set by the school or the studio, not by the platform, and the platform inserts no margin of its own. The code-enforced cost floor is built and production-ready.

Built · production-ready

No-skim split engine — fee off gross first, exact-cent, largest-remainder reconciliation

The split engine divides gross proceeds with exact-cent precision, applying three rules in strict order. First: the fee comes off gross first — it is deducted from gross proceeds before any split is calculated. A fee computed after the split is applied to gross would hide extra platform revenue inside the math — this engine does not do that. Second: all party splits are calculated on the net remainder after the fee. Third: a largest-remainder reconciliation pass handles any residual penny after integer rounding, assigning it to the party with the largest fractional remainder so the total disbursed equals the total net to the cent. The result is a distribution that sums exactly to what came in minus the stated fee, with nothing coerced into a platform margin. The split engine runs fundraisers, store payouts, and program distributions. The split engine is built and production-ready. The charge rail that moves money is honest-off — the math runs and the ledger records every distribution, but the payment rail that triggers real money movement is not enabled for live transactions today.

Split engine built · charge rail honest-off

Add-only ledger — every transaction recorded, reversals are entries not deletions

Every transaction in the platform — a sale, a refund, a split disbursement, a cost-floor enforcement, a fundraiser entry, a reversal — is recorded as an add-only entry in the ledger, add-only by construction. There are no edits and no deletions: a correction is a new entry alongside the original, and a reversal is a reversal entry that references the original, not a removal of it. A school business office can always reconstruct the full history of any account, order, or fund from the ledger, forward and backward, without worrying that a record has been silently modified. An auditor following a discrepancy can trace every entry to its source transaction. The add-only ledger is not an audit feature toggled on after a problem — it is the default state of every record from the first transaction. The add-only ledger is built and production-ready.

Built · production-ready

Exact-cent payouts and reconciliation — the ledger closes to the cent, every time

The reconciliation layer computes settlement payouts to the cent using the same largest-remainder math as the split engine. When a settlement runs, every party’s share is computed from the ledger, rounded to the cent, with any residual penny assigned by largest remainder. Total payouts equal total net proceeds in the ledger to the cent, every time. There is no platform rounding that captures residual fractions silently. The reconciliation math and ledger computation are built and production-ready. The payment rail that actually moves funds from the ledger to a recipient account is honest-off — it exists in the platform, not enabled for live transactions today. There is no live payout, no subscription billing, and no live money movement until the payment rail is enabled.

Reconciliation built · payment rail honest-off

Four-way portrait split — studio, school, photographer, and lab, per order

Photography orders can involve multiple parties: the studio that runs the picture day, the school or program that hosts it, the individual photographer on the day, and the lab that fulfils the print order. The four-way portrait split engine configures a per-party share for each transaction type — digital delivery, print package, retouching — and applies the same no-skim, exact-cent math: fee off gross first, splits on the net remainder, largest-remainder reconciliation to the cent. Each party’s projected share is visible in the ledger before the charge rail runs. The four-way portrait split is in early access — the engine is in active development and not yet enabled for live use.

Early access · in active development

Who uses it

The business office, the treasurer, the store operator — three views of the same engine

School business office

The business office sees the ledger view: running totals per account or fund, gross collected, fee deducted, net, and split per program. The year-end settlement report shows every transaction in the year, with gross, fee, net, and split — no manual reconciliation, because the add-only ledger has been keeping the record continuously. One-click export delivers the full ledger in a portable format. The school owns its financial records and can take them anywhere.

PTO/PTA treasurer and booster treasurer

The treasurer sees the fundraiser split before it runs: fee off gross, projected net, and the exact cent going to each party. The no-skim split engine puts the calculation on screen before the charge rail runs, so the treasurer is never surprised by the final payout. The split is the same every time — not a spreadsheet that changes depending on who built it. Year-end: one reconciliation report, every fundraiser and split in the year.

Store operator and yearbook adviser

The store operator configures a product with its cost, its price, and its split. The cost floor enforces the margin at the data layer — no accidental below-cost sale gets through. A yearbook adviser running a picture-day order form sees the same cost-floor guarantee on every print package. The portrait-split engine (in early access) extends this to the four parties in a photography order: studio, school, photographer, and lab.

What tuition.software is not — plainly stated

Not a tuition-billing product. Not an autopay scheduler. The name is the brand.

The domain says “tuition” and school finance staff hear “tuition billing.” That is not this platform. Tuition.software does not issue tuition invoices to families. It does not manage tuition payment plans. It does not configure recurring autopay for monthly tuition. No family receives a tuition statement from this platform. If that is what you need, this is not the right product and we say so directly, because your time matters more than a misleading first impression.

What the platform does: it runs the money rails behind school stores, fundraisers, and picture-day orders. A spirit store. A yearbook pre-order form. A booster fundraiser. A picture-day package sale. Those transactions run through the cost floor, the split engine, and the ledger. That is the product. The name “Tuition.software” is the brand name of this engine — not a description of what it invoices.

Student and family financial data — consent-gated, owned by the school

Your school’s financial records. Your data. Consent-gated, never sold.

Student and family financial data is owned by the school, not by the platform. No financial record is sold to or shared with outside companies or advertisers. Family payment data is consent-gated: a family must opt in before their contact or payment record is associated with a school account. Consent is not assumed. It is collected. Consent can be withdrawn at any time.

Minor student data runs on our own systems and is never shared with advertisers. It is never visible to other families. The one-click export is available in writing — if the school ever leaves the platform, every ledger record leaves with it: transaction history, split records, reconciliation reports, and consent status. This guarantee is part of the onboarding agreement, not a footnote.

What is built and what is coming — plainly stated

The engines are built. The payment rail is not live yet.

Built and production-ready today: the code-enforced cost floor (refusal at the data layer, not a policy reminder); the no-skim split engine (exact-cent, fee-off-gross-first, largest-remainder reconciliation, program-level treasury distribution); the add-only ledger (append-by-convention entries, reversals-as-records, full year-end reconciliation); and the reconciliation math for exact-cent payout computation.

Not yet enabled for live use: the payment rail (the part that moves money), live checkout on any store, live fundraiser disbursements, live payouts to program accounts, and the four-way portrait split for photography orders. These are honest-off — present in the platform, not enabled for live transactions. There is no live checkout here. No billing. No subscription. We say so directly because a school business office deserves to know what is production-ready and what is still being wired.

Connected to the school commerce layer

The money engine runs behind School Fundraiser Network, School Booster Network, and the school commerce layer

Tuition.software is the money rails. The storefronts and fundraiser products that run on top of it are built separately. School Fundraiser Network is the no-skim fundraiser storefront: school-set pricing, transparent totals, and the same cost floor and split engine running behind every campaign. School Booster Network is the operating platform for athletics, band, and theatre booster clubs: gate-scan ticketing, concessions POS, and per-program treasury records — the split engine handles every fundraiser and programme split. School Spirit Network is the spirit store and event commerce layer: branded per-school stores, event photo coverage, and per-school revenue share, with the cost floor enforced on every item. The school publishing platform at homeroom.software ties them all together: yearbooks, newspapers, and the picture-day order form where the portrait split and cost floor run on every package.

schoolfundraiser.network schoolbooster.network schoolspirit.network homeroom.software

Early access · School business offices, treasurers, advisers, studio owners

Book a conversation to see the current state honestly

Tuition.software is in active development. We do conversations that show the current state honestly: how the cost floor is configured and enforced on a store item, how the split engine models a fundraiser distribution to the cent before the charge rail runs, how the add-only ledger records every transaction and reversal, and what the reconciliation report looks like at year-end. None of that involves live payments today. There is no pricing commitment and no signup. If it looks right for your school or programme, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What does “the money engine” mean? What does tuition.software actually do?

Tuition.software is the money layer behind school stores, fundraisers, and picture-day commerce: the code that enforces cost floors, runs no-skim split math, and keeps the add-only ledger. It runs behind a school’s spirit store, its yearbook order form, its picture-day package sales, and its booster fundraisers. The business office sees the ledger; the treasurer sees running totals; the store operator sees cost floors enforced. This is not a tuition-billing, tuition-invoicing, or autopay product. The name is the brand; the platform is the money rails.

Is this a tuition-billing product? Can I use it to invoice families for tuition or set up autopay?

No. Tuition.software is not a tuition-billing system, a tuition-invoicing engine, or an autopay scheduler. Families cannot receive a tuition statement from this platform. There is no recurring payment configuration for tuition. The word “tuition” in the name is the brand, not a product description. If your school needs a system to invoice families for tuition or manage a tuition payment plan, this is not that product — and we say so plainly rather than let the domain name mislead you.

What is the code-enforced cost floor, exactly?

The cost floor is a hard rule enforced at the data layer: no item can be sold at a price below its configured cost. The store or platform administrator sets the cost for each item at configuration time. If a price entry falls below the floor — by accident, by data-entry error, or by misconfiguration — the engine refuses the sale at the data layer. Not by disabling a form field that could be bypassed; by refusing the transaction at the engine. This means a school cannot unknowingly subsidise a sale out of its own fund. The cost floor is set by the school or the studio, not by the platform, and the platform inserts no margin of its own.

How does the no-skim split work? What is the exact math?

Three rules apply in strict order. First: the fee is deducted from the gross amount collected before the split is calculated. A fee computed after a gross-split would inflate the platform’s apparent cut — this engine avoids that by taking the fee off gross first. Second: all party splits are calculated on the net remainder after the fee. Third: a largest-remainder reconciliation pass handles any residual penny after integer rounding — it assigns the residual to the party with the largest fractional remainder, so the total disbursed equals the total net exactly, to the cent. There is no platform margin inserted beyond the stated fee.

What is an add-only ledger, and why does it matter for a school business office?

An add-only ledger records every transaction as an entry that is add-only by construction — no edits, no deletions. A correction is a new entry (a credit or a reversal entry that references the original), and the original remains visible alongside it. A business office can always reconstruct the full history of any account from the ledger without relying on anyone’s memory of what was changed and when. An auditor following a discrepancy traces every entry to its source. The audit trail is not toggled on after a problem; it is the default state of every record from the first transaction.

Is money actually moving through the platform right now?

No. The cost floor, split engine, and add-only ledger are built and production-ready — the math runs, records are written, distributions are computed. But the payment rail — the part that triggers real money movement — is honest-off: it exists in the platform, not enabled for live transactions today. There is no live checkout, no live payout, no subscription billing. This is described plainly because a school business office deserves to know what state the system is in before evaluating it. When the payment rail is enabled (a founder-gated decision), we will say so clearly.

What is the four-way portrait split?

Photography orders can involve multiple parties: the studio that runs the picture day, the school or program that hosts it, the individual photographer, and the lab that prints the order. The four-way portrait split engine configures a per-party share for each transaction type — digital delivery, print package, retouching. The same no-skim math applies: fee off gross first, splits on the net, largest-remainder reconciliation to the cent. The four-way portrait split is in early access — the engine is in active development and not yet enabled for live use.

How does the school business office see the money layer in practice?

The business office has a ledger view that shows running totals per account or fund: gross collected, fee, net, and split per program or party. The view reads directly from the add-only ledger, so it reflects the exact current state without manual reconciliation. A treasurer can see the projected year-end carry-forward for each program at any point in the year. The year-end settlement report shows gross, fee, net, and split for every transaction in the year. One-click export delivers the full ledger in a portable format the school owns.

Is student and family financial data secure? Who owns it?

Student and family financial data is owned by the school, not by the platform. No financial record is sold to or shared with outside companies or advertisers. Family payment data is consent-gated: a family must opt in before their contact or payment record is associated with a school account. Consent can be withdrawn at any time. Minor student data is never visible to other families. One-click export is available in writing — if the school ever leaves the platform, every ledger record leaves with it.

When is the payment rail live? What does early access look like?

The payment rail is honest-off — the decision to enable live money movement has not been made yet. In a conversation we walk through the current state honestly: how the cost floor is configured and enforced on a store, how the split engine models a fundraiser distribution to the cent, how the add-only ledger records every transaction and reversal. None of that involves live payments today. A conversation is the honest next step — we show what is built, what the payment-rail timeline looks like, and what early access means for a business office.