A guest blog from founder of bookreport Cassie Tognoni

Every ERP vendor right now is telling you AI is going to change everything. Faster implementation. Smarter reporting. Agents that do the tedious work while you focus on what matters.

I wish that were the case. I really do. We’ve been building ERP for K-12 schools for over a decade and there is nothing I would love more than a magic button that makes this work fast and easy. There isn’t one. And understanding why not—and what actually would transform financial operations for schools—is worth a few minutes of your time before you spend the next two years waiting for a shiny new thing that probably won’t deliver what it promised.

First, what does an ERP actually need to do?

Let’s start simple. An ERP has three jobs.

One: keep a general ledger. Record every financial transaction accurately and in compliance with whatever rules govern your organization.

Two: store all the data related to that ledger—and store the right data. Every transaction has context that either gets captured or gets lost forever. Which program funded it. Which campus. Which student population. Who approved it and why. The schema is a set of bets about which questions will matter later. Get the bets wrong and no amount of reporting fixes it. Most ERPs bet wrong, because they’re built for everyone, which means they’re built for no one in particular.

Three: answer questions that guide decisions. Not just “how much did we spend?” but “are we spending in a way that reflects what we say we care about?”

Most ERPs are built almost entirely for job one. Job three is where the real value lives. Job two is what makes job three possible, and it’s where almost everyone cuts corners.

Where AI actually helps (and where it doesn’t)

I won’t be a complete wet rag. AI does help with ERP. Just not where the hype says.

It helps with UI. ERP interfaces are genuinely complex: a single data entry screen might need to handle a dozen edge cases without overwhelming the person using it. Being able to rapidly iterate on design, test ten versions of the same screen, and land on something that actually makes sense for the workflow is faster with AI than without it. And once the design is right, our dev team uses AI to implement it faster too. This is real and I’m grateful for it. But bad data structure, not bad UI is not the real reason your ERP is failing you. A beautiful interface to the wrong data architecture means you still get to the wrong answer; it just looks prettier.

It helps with categorization. LLMs are better than rules-based systems at figuring out that this purchase order probably belongs in function 11 rather than function 23. Not dramatically better, but meaningfully better. Fine.

It can help you query data in plain English—if someone has already built a schema worth querying. This is where it gets genuinely useful. A school CFO who can type “show me the trend in per-pupil spend on intervention programs by campus over three years” and get an answer in seconds instead of waiting for a report; that’s real value. But notice the conditional: if someone built the schema. AI does not build the schema. It queries whatever you’ve already built.

It can help agents do tedious work. Processing invoices, matching receipts, flagging duplicates. Real time savings. But finance and administrative operations are about 2-5% of a school’s total operating cost. The ceiling on how much money you save by making that function faster is not large. It’s not nothing, but it’s not a game changer.

Here’s where it doesn’t help.

It cannot design the data schema. This is the core of my entire argument: the data scheme is the most crucial element of the ERP and domain expertise still wins here. AI’s suggestions on data architecture routinely contradict each other under pressure. I’ve used AI to brainstorm data structures as we build payroll and while it occasionally points out something I missed, its final recommendations often don’t hold together as a system. A payroll coding structure is not a collection of individually reasonable ideas; it’s a set of constraints that have to work simultaneously, and AI doesn’t hold those constraints well enough yet. (And by yet, in humility, I mean yet, but I’m not one of the people who turns every “not yet” when it comes to AI as a “but definitely one day.” Put more bluntly, I’m skeptical this will ever happen.)

It cannot run the ledger. And here’s the reason that “AI-native ERP” is a marketing phrase, not a product category: a general ledger requires auditability. Every entry needs a deterministic, traceable chain of causation. LLMs are probabilistic; they don’t produce the same output given the same input, and their reasoning isn’t inspectable in the way an audit requires. You cannot have an AI engine at the core of a financial record. Any vendor telling you otherwise is either confused or hoping you are.

It cannot fix bad data architecture. An AI query layer on top of a poorly designed schema doesn’t give you better answers. It gives you faster wrong answers, occasionally dressed up with a confidence it hasn’t earned (and if they land it with a compliment, it’s hard to resist believing). I’ve seen AI summarize an income statement with “total expenses went up 3% because payroll increased 2% and office expenses went up 5%.” Not bad, not wrong. I’ve also seen it follow that with advice to “reduce discretionary spending to improve your operating margin.” Duh, not helpful.

The integration trap

We’ve spent years trying to solve the problem of bad school financial data by connecting systems together. A financial system here, a payroll vendor there, an HR platform somewhere else, all supposedly talking to each other through APIs and integration layers. Now AI is promising to be the connective tissue that finally makes it work.

It keeps failing. Not because the technology is bad, but because of how integration actually works in practice.

Every integration needs someone to maintain it. Not set it up, maintain it. Every time one vendor updates their API, every time a field gets renamed, every time a new campus opens or a new fund gets added to the chart of accounts, someone has to go touch the integration. That someone is usually the most technical person on a team that wasn’t hired to be technical. When they leave, the integration quietly starts drifting. Six months later nobody knows why the numbers don’t match and the person who built the connection is gone. This is why we’re building payroll inside our ERP rather than connecting to an external payroll processor. Payroll isn’t just a transaction. It’s the largest single data object in a school’s finances, and it touches fund coding, position management, grant compliance, benefits reconciliation, and labor cost analysis simultaneously. The seam between payroll and everything else is exactly where the most important insights live, and it’s exactly where integration layer approaches fall apart.

The answer isn’t a smarter layer. It’s fewer layers.

What transformational ERP for schools actually looks like

Here’s the question nobody is asking but should be: what does a school not know about itself that it could know, if the data were structured to answer it?

Marguerite Roza has spent decades doing forensic accounting on school districts and found that schools consistently spend the most money on things they say least about and least money on things they say most about. Schools in poor areas of a district often get less money than schools in wealthier areas—even as the district publicly commits to prioritizing low-income students. How does that happen? Simple ignorance, Roza says. “Education leaders simply do not know whether their investments support their stated objectives.”

I’ve been reading Roza since 2010. Not much has changed.

The questions that would change it—the ones a well-built ERP for schools should be able to answer—are questions like these:

What does it actually cost to produce one student’s reading growth of one grade level? Not per-pupil expenditure in the aggregate. The actual marginal cost of a learning result, connected to the specific intervention that produced it.

Which intervention programs have real ROI when you normalize for student demographics and prior achievement? Schools spend millions on curriculum and programs with essentially no financial accountability attached to outcomes. The purchase order exists. The outcome data exists. Nobody has connected them.

At what enrollment number does each campus cross from fixed-cost-heavy to contribution-positive? This is the breakeven question behind every expansion decision. Almost nobody can answer it cleanly.

What is the fully loaded cost of a teacher vacancy, including not just the substitute cost but the learning loss that will require remediation spend next year?

These questions are unanswerable today. Not because the data doesn’t exist, but because it lives in separate systems with no shared logic. Student outcomes are in one place. Financial transactions are in another. Staff data is in a third. Nobody defined what a “teacher” is in a way that’s consistent across all three.

The path to answering these questions isn’t connecting those systems with a smarter integration layer. It’s building a data architecture that owns the relevant student data—enrollment, program participation, assessment results tied to grant-funded interventions—as part of the financial system itself. Not the full student information system. The minimum student data schema that makes the financial data analytical.

That’s a tractable problem. It’s just not a fast or easy one.

So what should you actually expect AI to do for ERP?

Expect AI to reduce friction in data entry and categorization. It’s real and worth having. Don’t confuse it with transformation.

Expect AI to make querying your data easier—but only after someone has done the hard work of building a schema worth querying. AI is a good query layer. It is a terrible substitute for the architectural decision to own the right data in the first place.

Do not expect AI to design that schema. That still requires someone who knows the industry deeply enough to know which questions matter and what the data has to look like to answer them.

Do not expect AI to fix an ERP that was never designed to answer those questions. A faster interface to bad data architecture is still bad data architecture.

The ledger is not going away. Auditability and determinism are not legacy constraints we’re waiting to upgrade past. They are the non-negotiable foundation of financial trust.

The transformation opportunity in school finance has always been the same one Marguerite Roza identified in 2010: build accounting systems that actually inform resource allocation. AI can help you surface what those systems know. It cannot decide what those systems need to know, and it cannot build the systems themselves.

That part is still hard. It was always going to be hard. Anyone who tells you otherwise is selling something.