Private School Software: Fixing the Admissions, Billing and Parent Comms Gap

Why enrollment and billing software makes or breaks a private school network

A four-campus independent school network with 1,600 students runs six systems that each claim to hold the student record. Blackbaud Enrollment Management for admissions. Blackbaud Tuition Management or FACTS for billing. Veracross or Rediker for the SIS. ParentSquare or Remind for comms. A Google Sheet the Director of Admissions actually trusts. And Mailchimp, because the CRM (Customer Relationship Management)'s email builder is unusable and nobody wants to file a ticket to change a subject line.

Every March the same failure repeats. A family accepts a spot at the Lower School campus, then in July asks to move their second child from Campus B to Campus C because they are relocating across town. The registrar updates the SIS. Billing does not know, because the FACTS agreement is keyed to Campus B's tuition schedule and the sibling discount was manually applied. The family gets an invoice with the wrong tuition, plus a late fee, plus a comms blast about Campus B's orientation. The Director of Enrollment finds out when the parent emails the Head of School. Three staff spend a combined nine hours untangling one transfer, and the family's trust in the institution takes a hit that shows up in re-enrollment 14 months later.

Multiply that. A network doing 400 new applications and 1,200 re-enrollments a year, with sibling discounts, staff-child remission, financial aid awards, payment plans, and mid-year withdrawals, throws off a couple of hundred of these reconciliation events per cycle in the networks we have worked with. At three to nine hours each, that is one full-time salary burned on copy-paste. And that ignores the revenue leak: in those same networks, the business office typically finds $40k to $120k a year in tuition that was billed wrong, discounted twice, or never invoiced after a mid-year add, discovered months late in the June audit.

Problem: the family is not a record in any of your systems

Every off-the-shelf tool in this category models a student. Admissions models an applicant. Billing models a payer. The SIS models an enrollment. Nobody models the family, which is the actual unit your operation revolves around: two guardians who may be divorced with a split-billing arrangement, three children across two campuses, one on 40 percent aid, one on staff remission, one full-pay, plus a grandparent who pays the after-school fee.

Blackbaud and Veracross both let you link siblings. Neither lets you compute "what does this household owe, net of all awards, across all campuses, as of today" without an export. That is why your Business Manager has a spreadsheet called Household Reconciliation FY26 v7 FINAL.

What a custom build does: a household aggregate as the top-level entity, with students, guardians, billing contacts and payment responsibility as relationships underneath it, each with an effective date. Split billing becomes a percentage or line-item allocation on the household ledger, not a note in a comment field. Aid awards, sibling tiers and remission are rules attached to the household and evaluated at invoice generation, so a transfer or a withdrawal recalculates automatically and produces an adjustment entry rather than a phone call. One screen answers what the family owes and why, with every rule that fired shown as a line.

Problem: tuition changes mid-year and your billing system cannot do proration honestly

A student withdraws on November 12. Your enrollment contract has a refund schedule. There is tuition insurance. There is a deposit that is non-refundable. There may be an aid award that gets clawed back proportionally, or may not, depending on how the award letter was worded. FACTS and Blackbaud Tuition Management handle payment plans well. They handle mid-year contract mutation badly, because they were built as payment processors that assume the amount owed is settled upstream.

So your Business Manager calculates it by hand, in a spreadsheet, against a PDF of the enrollment contract, and hopes. When the family disputes it in February, nobody can reconstruct the math.

What a custom build does: the enrollment contract becomes executable, not a PDF. Refund schedule, deposit terms and insurance interaction are encoded as a versioned policy object tied to the contract the family actually signed that year. Withdrawal on a date triggers a deterministic recalculation that writes an auditable adjustment to the household ledger with a plain-English explanation of every step. Two years later you can pull up exactly why that family was charged $8,412 and show them the same explanation they saw the day it happened. The billing processor stays: keep FACTS or Stripe for the rails, own the ledger and the rules yourself. That distinction matters, and most vendors will not make it for you.

Problem: admissions is a funnel with no forecast

Your Director of Enrollment is asked in December what next year's enrollment will be. She has inquiries, tours booked, applications started, applications complete, and last year's yield. Blackbaud Enrollment Management gives her counts at each stage. It does not tell her whether Campus C converts weekday morning tours better than weekend tours, or at what point a stalled transcript request stops converting at all. She has counts, not causes.

You do not get to fix what you cannot see, and you are making a staffing and budget commitment on a number that is essentially a vibe.

What a custom build does: every funnel event is timestamped and attributed, so stage-to-stage conversion is computed by campus, by grade band, by source, by tour type, and by days spent stalled at each step. A weekly forecast projects enrollment with a range, not a point, and updates as the funnel moves. AI does two specific jobs here. It reads the inbound inquiry, whether that is an email, a form, or a voicemail transcript, and extracts the child's grade, target start year, sibling status and stated interest into structured fields, so the tour scheduler is pre-filled instead of an admissions associate retyping. And it answers after-hours inquiries in 90 seconds with three actual open tour slots pulled from the campus calendar, not a "we will be in touch." In the networks running this, the inquiry-to-tour rate moves, because most of the loss was sitting in the 14-hour gap between a parent's 9pm form fill and an 11am reply.

Problem: financial aid applications are a document-shuffling operation

Every February, 300 families upload W-2s, 1040s, Schedule Cs, divorce decrees and letters of hardship. Your aid committee, three people, reads them. Someone types the numbers into a spreadsheet to compute a family contribution. Clarity or FACTS Grant and Aid gives you a recommended number, which your committee then overrides half the time because the methodology does not know that this family's business income was a one-time asset sale.

The off-the-shelf tools cannot fix this because the override reasoning lives in the committee's heads and in an email thread, and next year's committee starts from zero.

What a custom build does: document extraction pulls line items off the 1040 and W-2 into structured fields with a confidence score and the source page highlighted, so the committee verifies rather than transcribes. In our builds that is 20 to 40 minutes per file down to about five. The award decision, including the override and the written reason, is stored against the household and versioned, so year two opens with last year's rationale visible. Award letters generate from the decision, which means the letter and the ledger cannot disagree. Keep Clarity's methodology if you like it: call it, store the answer, own the decision record.

Problem: parent communication is a compliance and trust surface, not a newsletter

ParentSquare and Remind are fine at broadcast. They are poor at "message only the guardians with financial responsibility for a student enrolled at Campus B in grades 6 through 8 whose re-enrollment contract is unsigned as of today." So your staff builds the list by hand in a spreadsheet, and the list is wrong, and a family that already signed gets a nag, and a divorced parent who should not receive billing communications does.

That last one is not an annoyance. Custody and communication preferences are a real liability, and a wrong send is the kind of thing that ends up in a lawyer's letter.

What a custom build does: audiences are queries against the live household and enrollment model, not static lists. Communication preference and custody restrictions are attributes on the guardian relationship that every send path respects by construction, so it is not possible to build a segment that violates them. Every message is logged against the household record, so when a parent says "nobody told us," the registrar can see what was sent, to whom, when, and whether it opened. Re-enrollment nudges fire off contract state automatically, and AI drafts the follow-up in the school's actual voice using the family's history, which the Director reviews and sends. Twelve manual chase emails a week become two minutes of approval.

What this costs and how long it takes

Across 2,000-plus projects, Digital Heroes sees this category land in two bands. A focused first release runs $60k to $130k and ships in 12 to 16 weeks. For a school network that almost always means the household model plus the unified ledger plus the admissions funnel, with your existing billing processor and SIS still in place, connected. That is the release that stops the bleeding. A full platform, where you are replacing the SIS layer and running scheduling, gradebook, attendance and the parent portal yourself, runs $150k to $400k phased over 6 to 12 months.

What drives price up in this category specifically. First, the number of distinct tuition and fee schedules: a network with one schedule per campus is cheap, a network with 14 schedules because two campuses were acquisitions with grandfathered contracts is not. Second, historical data migration: ten years of Rediker or a legacy Blackbaud instance with inconsistent household linkage is typically $15k to $35k of the budget on its own, and it is the line item every vendor lowballs. Third, integrations: FACTS, Clarity, your accounting system, Google Workspace or Microsoft 365 for rostering, and a payment processor each add real weeks. Fourth, if you take federal or state voucher or ESA funds, the reporting obligations attached to those are not optional and not small. Fifth, and this is the one that actually blows schedules: whether your registrars can give the team six focused hours a week. Every project that slipped, slipped there.

Build or buy: where the line actually is

Buy if you run one or two campuses under about 800 students with a single tuition schedule and under 15 percent of families on aid. Veracross at that size does the job, and the workarounds cost you less than the build. Buy if your pain is a process problem wearing a software costume: if three people define "enrolled" differently, custom software will encode the disagreement at higher speed.

Build when these show up together. Your business office spends 40-plus hours a month reconciling tuition to enrollment. You have more than one billing entity or campus with different schedules. Your annual audit surfaces five figures of billing errors. Your Director of Enrollment cannot answer a forecast question without a two-day export. And you have someone internally, usually a COO or Director of Operations, who can own the product decisions.

The position: at a 3-plus campus network with 1,200-plus students, the off-the-shelf stack is not saving you money, it is moving the cost from a software line item to a payroll line item where nobody looks at it. The right move is rarely a full rip-out. It is owning the household model and the ledger, and letting the vendors keep doing the parts they are genuinely good at, payment rails and aid methodology.

How to choose a developer for private school network software

Ask them to model a household on a whiteboard, in the room, before any contract. Divorced guardians, split billing 60/40, three kids on two campuses, one on aid, one on staff remission, one withdrawing in November. If they draw students with a nullable parent_id, end the meeting. This is a five-minute test and it eliminates most of the field.

Ask what happens to the ledger when a student transfers campuses mid-year. The right answer involves effective-dated enrollment records and a recalculation that writes an adjustment. The wrong answer is "we would update the record." A firm that has shipped this knows tuition is a time-series problem, not a field.

Ask them to name the integrations they have shipped and what broke. FACTS, Blackbaud, Veracross, Clarity, Rediker: someone who has done this will have opinions about which APIs paginate badly and which require a nightly file drop. Vagueness here predicts a discovery phase where you pay them to learn.

Ask how they handle FERPA and student PII in practice, not in policy. What is logged, who can see a household's aid file, how is access revoked when a registrar leaves, what happens in a data request. If you take voucher or ESA money, ask what reporting they have built against it. A firm that answers with a certification logo instead of a design decision has not done this work.

Last, get code ownership and a data escrow in writing before the SOW is signed, not at handover. Your student record is the institution's asset. Any developer who hesitates on that has told you what the relationship is going to be.