ESA software vs general school software

A microschool that takes ESA money usually ends up looking at two kinds of software, and they are not the same purchase. One kind runs the school day. The other kind runs the state money. Most operators assume a single tool does both, sign up for the one that markets itself loudest, and then discover at the end of the first quarter that the part they actually needed help with, the ESA money, is the part their tool does not touch. Here is how the two categories differ and how to tell which one, or which combination, you are actually shopping for.

The two kinds of software a microschool buys

General school-management softwareis the broad category: a student information system, a tuition or payment tool, a gradebook, a parent-communication app. These run the school. They hold your roster, take attendance, post grades, message families, and collect tuition payments from a parent’s card or bank. They are good at the day-to-day of operating a school, and most of them were built for tuition-paying private schools or daycares, long before ESAs existed.

ESA back-office software is the narrow category built around the state money flow: invoicing that splits tuition into the ESA portion and the family portion, reconciling the uneven deposits the state platform sends, tracking the per-state compliance that gates each disbursement, and producing the dated, per-student records a program reviewer asks for. It does not run the school day. It runs the money the state sends for it.

Where general tools do well

General school software earns its place. If you need a clean roster, daily attendance, a gradebook, and a way for parents to pay you directly, a general tool handles that well and you should not rebuild it yourself. The point of a comparison is not that one category is better. It is that the two solve different problems.

Where general tools stop and ESA starts

A general tuition tool can charge a parent’s card. It usually cannot model a student whose tuition is paid partly by a state scholarship and partly by the family, on two different schedules, where the state portion arrives in uneven installments months after you billed it. The questions an ESA-funded operator actually loses sleep over are the ones general software was never built to answer:

• Did the state deposit match what I invoiced for this student, or did it come in short?
• Which families are on the state calendar and which pay me directly, so I can see my real cash position?
• Is an overdue compliance task about to hold my next disbursement?
• If a program reviewer asked tomorrow, could I hand over a dated, per-student record without reconstructing it?

Those are not gradebook questions. They are money-flow and compliance questions, and they are the entire reason ESA-specific software exists. The five recurring jobs ESA money creates, and the point at which a tool starts paying for itself over a spreadsheet, are walked through in what software runs a school’s TEFA money.

What to look for in ESA-specific software

If you are evaluating a tool on the ESA side, these are the things worth checking before you commit. A tool that cannot do them is a general school tool wearing an ESA label.

• Split invoicing. Can it invoice one student with an ESA portion and an out-of-pocket portion that add up to tuition, not just charge one flat amount?
• Deposit reconciliation. Can it match an actual platform deposit against the invoice it was supposed to pay and surface the shortfall?
• Per-state compliance that ties to money. Does it know which compliance task gates which disbursement, for the states you operate in, not a generic checklist?
• A real audit packet. Can it produce the per-student, dated export a state reviewer reads, in one click? This is the piece general tools skip entirely. What one contains is in what a TEFA audit packet actually contains.
• Honest pricing. Flat by the students you enroll, not a cut of the ESA money you receive. A tool that takes a percentage of state funds has a different incentive than you do.
• It stays out of the money. ESA funds should flow from the state platform straight to your bank. Software should record the money, never hold or move it.

Do you need both?

Often, yes, and that is fine. ESA back-office software is built to sit alongside the tools you already use, not to replace your gradebook or your accounting. If a general school tool is doing a good job on attendance and grades, keep it. What it cannot do is the ESA money and the state-reviewer record, and that is the gap ESA-specific software fills. The mistake is not using two tools. The mistake is assuming the general one already covers the money, finding out in a quarter-end scramble that it does not.

CohortLedger is the ESA back-office side of that pair. It does the quarterly ESA invoicing, the deposit reconciliation, the per-state compliance, and the one-click audit packet, and it never touches your funds. You can see all of it on real numbers in the live demo with no signup, or read the full feature walkthrough.