Charter School Network Software: What Breaks When You Run Six Campuses on Two SIS Platforms

Why network reporting software makes or breaks a charter network

Picture a Tuesday in late October. The board meets in nine days. The Chief of Staff needs one number: chronic absenteeism, network wide, by campus, by grade band, by subgroup, compared to the same point last year. Four campuses run PowerSchool. Two run Infinite Campus because they were acquired from a smaller CMO that never migrated. The high school uses Illuminate for assessment and the elementary campuses use NWEA MAP. Behavior sits in Kickboard at three campuses and in a Google Sheet at the others. Special education documents live in SEIS or Frontline depending on the state. The data manager pulls seven CSV exports, opens a workbook with fourteen tabs, and starts VLOOKUPing student IDs that do not match because campus 3 prefixes their local IDs with the school code and campus 6 does not.

That reconciliation takes her about three days. She does it every month, plus twice more during authorizer renewal season. Price her time honestly and the manual joins alone run five figures a year, and that is the cheap part. The expensive part is that the number she produces is a snapshot with no lineage. When a board member asks why campus 4's absenteeism jumped 3 points, nobody can answer in the room, because the workbook does not know whether the jump is real, a coding change in how one campus marks half day absences, or 41 students who transferred in October and got double counted across two SIS instances.

Networks running five to fifteen campuses live inside this gap. The SIS is excellent at running one school. It was never designed to be the reporting spine for a network with different state accountability regimes, staggered enrollment lotteries, and an authorizer that wants evidence of impact in a specific format on a specific date. So the network builds a shadow reporting layer out of Excel, Google Sheets, and one heroic data person who becomes a single point of failure. When she leaves, and she does leave, six years of tribal logic walks out with her.

Problem: the same student exists three times and nobody owns the truth

A family enrolls a fifth grader at your Eastside elementary in August. In January they move across town and enroll at Westside. Eastside marks them withdrawn on the 14th, Westside enrolls them on the 21st. For seven days the student exists twice and is chronically absent at one campus and not yet enrolled at the other. Multiply that by every family that moves between your campuses in a year, and your network mobility rate, your ADA, and your subgroup counts are all wrong in ways nobody flags.

PowerSchool cannot fix this because each campus instance treats a student as a school level record with a school specific enrollment. PowerSchool's district level rollups assume one district with one enrollment authority. A charter network with campuses in three authorizing districts is not that. Infinite Campus has the same boundary. You cannot ask either system a question that spans instances they do not know about.

What a custom build does: a network student spine. One canonical student record with a network student ID, plus a match table linking every campus's local ID, state ID, and legacy IDs to that spine. Nightly pulls via the PowerSchool SIS API and Infinite Campus's Ed-Fi or ODS interface land raw enrollment rows in a warehouse. A matching service resolves identity on state ID first, then a probabilistic match on name, DOB, and guardian phone for students who move before the state ID propagates. Every match is scored, and anything under confidence threshold drops into a review queue where a human on the network data team confirms or splits in about ten seconds. Enrollment segments are stored as intervals, so the system knows a student was at Eastside from 8/19 to 1/14 and Westside from 1/21 forward, and it can compute a true network continuous enrollment rate that no SIS export can produce. Fuzzy match scoring and guardian contact deduplication are the two places AI does real work in this build, and they cut the review queue from hundreds of rows to a dozen.

Problem: authorizer and state reporting eats your fall

Each authorizer wants something different. Your Texas campuses feed PEIMS. Your California campuses feed CALPADS. An authorizer in a third state wants a renewal narrative with five years of academic growth, a financial audit, and a board governance packet. Your Chief Academic Officer and data manager rebuild these by hand every cycle, and each cycle they rediscover the same definitional questions: does a student who enrolled on day 12 count in the accountability cohort, do we count suspensions in school days or instructional days.

Off-the-shelf state reporting modules exist inside the SIS and they are fine for one campus in one state. They break the moment your network spans state lines, and they cannot produce the authorizer's narrative artifacts at all. Tools like Schoolzilla or Edulastic dashboards give you views, not a defensible pipeline, and none of them hold your business rules.

What a custom build does: metric definitions become code, not tribal knowledge. Chronic absenteeism is a versioned SQL definition with a documented owner, an effective date, and a note explaining the exclusion rules. When a definition changes, historical numbers do not silently move, because the warehouse keeps the version that produced last year's board report. State submission files generate from the same spine, with a validation pass that catches the errors the state would reject before you upload rather than after. On the narrative side, document generation assembles the renewal packet from live data: growth tables, enrollment history, demographic tables, all rendered into the authorizer's template. AI drafts the prose sections against the actual numbers, and a human edits. That turns a six week scramble into about four days of review.

Problem: the enrollment lottery and waitlist run on faith

You run a weighted lottery: sibling preference, staff children, founder families where allowed, geographic preference, free and reduced price lunch weighting if your charter permits it. Most networks run this in a spreadsheet or in SchoolMint. Then the waitlist decays over eleven months and campuses call families off it in whatever order the campus operations manager can reconstruct. In August you discover campus 2 is 40 students under budget while 60 qualified families sat unreached on a waitlist for a campus eleven minutes away.

SchoolMint handles the lottery mechanics reasonably. What it does not do is connect the waitlist to your actual seat economics: it does not know that each unfilled seat is per-pupil revenue you have already staffed against, and it does not model cross campus offers. The gap between application and butt-in-seat is where networks lose real money, and no application system owns that gap end to end.

What a custom build does: a seat ledger. Every campus, grade, and section has a budgeted seat count, a currently enrolled count, a pending offer count with expiry, and a projected count. The lottery runs with auditable randomization, meaning a stored seed and a reproducible run log, because an authorizer or an angry parent will eventually ask you to prove the lottery was fair. Offers carry deadlines and auto-release seats back to the pool. Waitlist outreach becomes a work queue with an SMS and email sequence in the family's home language, and the after-hours piece matters here: an AI intake assistant answers the "is there still a spot for third grade" question at 9pm on a Sunday, checks live seat availability, and books a campus tour, instead of that family calling your competitor Monday morning. Forecasting on top: attrition patterns by campus and grade drive a projected October enrollment, so your CFO staffs against a defensible number rather than last year plus optimism.

Problem: special education compliance is a lawsuit waiting on a calendar

An IEP annual review is due. A triennial evaluation is due 60 days out. A service minutes log at campus 5 has not been signed in three weeks because the speech provider is a contractor who works across four campuses and submits paper. The network special education director finds out during a compliance monitoring visit.

SEIS, Frontline, and Embrace hold documents and dates well enough at the campus level. What they do not do is give a network director a single queue across campuses and vendors, and they do not connect service delivery to the contractor invoices you are paying. Networks discover they paid for 1,100 service minutes and can document 780.

What a custom build does: a compliance calendar that reads from the IEP system's API and surfaces every deadline network wide, ranked by days to breach, assigned to a named person, with escalation to the network director at 14 days. Service minute logging happens on a phone, offline capable, signed at point of delivery, with the log line tied to both the IEP goal and the contractor's invoice line. Document extraction pays for itself here: pulling goals, service minutes, and dates out of uploaded IEP PDFs from acquired campuses or transfer students is real work that AI does accurately enough to be worth it, with a human confirming the extraction. FERPA obligations mean field level access control, an audit log on every record view, and encryption at rest, which is a design decision made in week one, not a checkbox added at the end.

Problem: your CFO cannot see cost per student by campus until the audit

Per-pupil funding varies by campus, by state, by student characteristic. Your teacher salaries sit in a payroll system, your vendor spend sits in QuickBooks or Sage Intacct, your enrollment sits in six SIS instances. The board asks whether campus 6 is financially viable at current enrollment. Nobody can answer without a two week exercise, and by the time the answer arrives you are three months further into a bad staffing decision.

Intacct is a competent general ledger and its dimensions are useful. But Intacct does not know that campus 6's third grade lost 22 students in September, and it will not tell you unprompted that your revenue assumption is off by $200k. The connection between the enrollment spine and the ledger is the thing nobody sells.

What a custom build does: a per-pupil model that joins live enrollment counts to funding rates and to actual spend by campus dimension, refreshed nightly. Variance alerts fire when projected revenue drifts more than a set threshold from budget. Scenario modeling lets the CFO ask what happens to campus 6's contribution margin if October enrollment lands at 380 instead of 420, and see the staffing implication in seconds rather than in a workbook.

What this costs and what actually drives the price

These bands are Digital Heroes delivery experience across 2,000+ projects, not a market survey. A focused first release, which for a charter network almost always means the student spine plus the network dashboard plus one high pain reporting workflow, runs $60k to $130k and ships in 12 to 16 weeks. A full platform adding lottery and waitlist, special education compliance, and the financial model runs $150k to $400k phased over 6 to 12 months. Ongoing runs roughly 15 to 20 percent of build cost annually, which covers hosting, the state reporting rule changes that arrive every year, and SIS API changes.

What pushes price up in this specific category: multiple SIS platforms is the biggest single driver, and each additional platform adds meaningful integration work because the data models really do differ. Multiple states is the second, because each accountability regime has its own definitions and file formats and each one needs its own validated pipeline. Historical data migration is the third and it is the one everyone underestimates: seven years of enrollment history across acquired campuses with inconsistent IDs is archaeology, and it is where projects slip. Real time versus nightly matters less than people think, and nightly is correct for almost everything a network reports on. Push back if someone quotes you real time as a default.

Build versus buy, and where we actually land

Buy if you run four campuses or fewer on one SIS instance in one state. You do not have a network data problem, you have a data hygiene problem, and PowerSchool plus Schoolzilla plus a disciplined data manager will serve you for less than a build costs. Buy if your growth plan is flat. Buy if you cannot commit a named internal owner, because a custom platform with no owner rots faster than a spreadsheet does.

Build when three or more of these are true: you run two or more SIS platforms, you operate across state lines or across multiple authorizers, one person is the single point of failure for every number the board sees, you are acquiring campuses, or your data manager spends more than two days a month on reconciliation. The signal we trust most is the acquisition one. The moment a network commits to absorbing schools that run different systems, the spreadsheet layer stops being a nuisance and becomes an operational risk, because you are now making enrollment and staffing decisions on numbers nobody can trace. Our position: at five campuses and up, with mixed systems, building the spine is cheaper over three years than continuing to buy people's time to reconcile it by hand.

How to choose a developer for charter network software

Ask them to whiteboard the student identity model before you sign anything. If they do not immediately raise enrollment intervals, state ID versus local ID, and the mid-year transfer case, they have not built this. That question separates the people who have shipped in K-12 from the people who will learn on your budget.

Ask which SIS APIs they have integrated against by name, and what broke. The right answer includes PowerSchool's rate limits, the difference between Ed-Fi and a vendor's ODS, and at least one story about a mid-year API version change. Anyone who says integration is straightforward has not done it.

Ask how they handle FERPA in the architecture, specifically. You want to hear field level permissions, audit logging on record access, a data processing agreement, and a clear answer on where student data is hosted and who on their team can see it. If the answer is "we encrypt everything," keep asking.

Get the code ownership and the exit path in writing. You own the repository, the infrastructure accounts are in your name, and there is a documented handoff so a different team can pick it up. Charter networks change vendors, and the platform that holds your board numbers should never be hostage to one firm's retainer.