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.

Think of coding AIs as brilliant new junior programmers. You can see that they have mad skills, but they wander, forget what they decided yesterday, and occasionally ignore you entirely because they think they’ve found a “better way.” In other words: smart, fast, and absolutely in need of supervision.

That’s why AI coding is absolutely pair programming. If you tell AI to write a spec, you have to read the spec and approve it before moving on. If you have AI write a technical design, same thing. And if you tell AI to write code? First, never give it carte blanche to run any script, unless you want all of your files to be deleted by accident. Review the plan, approve every step, and keep an eye on what it’s doing. Every time. All the time. You must watch the messages being presented while AI is working. Sometimes an AI will “fix” a tiny issue by restructuring your entire database or get stuck in a loop repeating the same mistake. It’s on you to catch that, redirect it, or hand-code the fix. Then, when AI is done writing code, you have to review the code and test it yourself. Even if AI said it already tested everything for you.

And, when you come to work tomorrow? AI will have forgotten everything that you decided today. So, whatever corrections you needed to make during your working session, you must immortalize them in the documents being used to instruct AI on how to build specs, plans, and code. When things go wrong, look at the descriptions in your commands, update them regularly, and ensure AI is following them. When sessions are long, AI sometimes forgets where it was, and must be reminded to follow them. For this reason, always start every new day with a new chat (and sometimes start a new chat within the same day) that clears all the old (and confusing) context. 

This is new coding. A lot of sitting and watching and reading what the AI is thinking. Slightly boring most of the time, but it is also very high-performance throughput. Then, when things go south, or AI can’t figure out how to solve a problem, or there are three ways to solve a problem, you have to step in, apply your skills, make the decisions, fix the code manually, roll back and try another approach—whatever is required. 

AI is only helping you. Your ability is what determines the final outcome. When you work together in this way, you go fast, get a lot done, and you are absolutely aware of everything that has been done, how it was done, and why it was done that way. If you don’t do it this way, the best you can hope for is code that does what you asked it to do, but that is also rigid, low-performance, hard to enhance, and that no one understands—not to mention your maintenance costs will soar (yes, despite using AI). 

AI is a tool. Nothing more, nothing less. The human in the loop is what determines the quality of the finished product. The AI just helps you get done quicker and maybe go a little farther. You bring the knowledge and experience. But you cannot move beyond the knowledge and experience that you possess. However, what you can do is apply that knowledge and experience faster and with better results. AI is a “time to market” lever. It has mad skills, but it does not possess the capabilities that are the keys to success. Only you can provide those. Anyone who lets AI do their job for them will soon be disappointed. And unemployed. 

“Show me the incentive, and I’ll show you the outcome.” – Charlie Munger

On the eve of September 11th, 2025, members of Congress called the private equity fire truck roll-up REV Group to testify about their business and its impacts on fire safety in America. I encourage anyone interested to watch the full hearing on the Senate website: Sounding the Alarm: America’s Fire Apparatus Crisis.

The Wall Street Journal’s headline sums it up well:

Basel Musharbash, a lawyer who testified in front of Congress and wrote an article just following the fires titled: “Did a Private Equity Fire Truck Roll-Up Worsen the L.A. Fires?” outlined the problem in detail. “The cost of fire trucks has skyrocketed in recent years—going from around $300-500,000 for a pumper truck and $750-900,000 for a ladder truck in the mid-2010s, to around $1 million for a pumper truck and $2 million for a ladder truck in the last couple years.”

Private equity had consolidated the Fire Truck industry in America, and began increasing prices while simultaneously decreasing product quality—a typical PE formula—creating increased profits for REV Group’s private equity owners American Industrial Partners (AIP). Even worse than the cost, wait times for new trucks more than quadrupled from under a year to over four years—creating a large backlog that the AIP-installed CEO repeatedly bragged about as “financially attractive” for its positive impact on revenue visibility in K-1s and earnings calls. In 2024, REV Group’s fire truck division grew profits an exceptional 8.9 percent while AIP simultaneously “sold nearly all of its shares, but before doing so awarded a special dividend of $180 million of which nearly $80 million went to AIP.”

While REV Group has undoubtedly been a success for AIP and made its partners much wealthier (it made at least one AIP partner a billionaire), the company highlights the seriousness and potential pitfalls of the short-term profit-above-all-else ethos (feel free to use the corresponding euphemism “fiduciary duty” if that offends your sensibilities) that is the heart of the private equity industry. But, as Arkansas fire chief Gil Carpenter put it: “When is enough enough? And at what point are you going to sacrifice public safety for profits?”

It would be a mistake to understand this as a case of capitalism gone wrong. Adam Smith, the father of modern capitalism, believed that complete separation of management and shareholders created a serious risk to society. He believed this so seriously that the final sentence of Book 1 ends with the warning that pure shareholders (à la modern private equity fund ‘investors’) are “an order of men, whose interest is never exactly the same with that of the public, who have generally an interest to deceive and even to oppress the public, and who accordingly have, upon many occasions, both deceived and oppressed it.”

In Book IV Chapter 7, Smith calls out the East India Company practice of destroying entire fields of harvestable crops to create scarcity for the sole reason “that extraordinary profit was likely to be made.” Is this any different from the REV Group’s practice of acquiring fire truck manufacturing facilities, only to close them shortly after acquisition resulting in longer repair and delivery wait times and an over-inflated order backlog, which the PE-installed CEO repeatedly referred to as financially attractive? If Adam Smith wouldn’t use the term Capitalist to describe either company’s leadership, what would he call them?

Decades ago, the fire truck industry looked very similar to the ERP industry, with many small, specialized companies manufacturing and repairing fire trucks for their local markets. Today, three companies—REV Group, Oshkosh (Pierce Manufacturing), and Rosenbauer—have nearly 80% market share. The short-term profit-maximizing incentives associated with private equity ownership creates bad behavior, which only gets worse as industries consolidate and concentrate.

At Mirador, we’re working against private equity consolidation of the ERP industry, because we’ve seen the perverse incentives and their damaging consequences. While they haven’t reached the severity of threatening human lives—it doesn’t make them any less palatable for the customers and employees who suffer as PE firms consolidate and subsequently weaken companies in the name of short-term profit.

In the words of the late Charlie Munger, “show me the incentive, and I’ll show you the outcome.”

Incentives are ultimately decided by ownership.

We are different because we believe in remaining independently-owned and owner-operated to retain our long-term focus and customer-centric strategy. We believe that you can’t know what’s best for a company if you don’t work in that company, and you can’t know what’s best for a customer or employee if all they are to you is a row on a spreadsheet.

What do you think about the impact PE consolidation is having on other markets? I’d love to discuss it, so reach out to me on LinkedIn or send us an email.

If you’re running a growing business, chances are you don’t spend a ton of time thinking about your finance organization. For many small business founders, “finance” means making sure the books are closed, taxes are filed, and bills get paid on time. Necessary? Absolutely. Strategic? Not really.

But here’s the thing: the way you view finance can shape the future of your business. Done right, it’s not just about compliance — it can actually help drive growth, improve profitability, and even increase the value of your company when the time comes to sell.

Let’s break it down.

The Traditional Role of Finance: Support Mode

In many early-stage or organically grown companies, finance tends to stay in the background. Think of it as the team that makes sure the trains run on time:

Important? Of course. But when finance is only seen as a cost center, you miss out on a huge opportunity.

The Strategic Role of Finance: Driving Value

As companies mature, finance shifts from support mode to growth mode. Instead of just keeping score, finance helps call the plays.

Here’s what that looks like:

Baby Steps: How to Get Started Today

If you’re a founder, you don’t need to turn finance into a strategic powerhouse overnight. But you can start small. Here are a few ways:

  1. Know your key numbers. Beyond revenue and profit, track customer retention, cash runway, and average deal size. These will give you real insight into business health.
  2. Automate the basics. Move off spreadsheets where you can. Even small steps — like automating invoicing or expense reporting — save time and reduce errors.
  3. Build a simple forecast. You don’t need a 50-tab Excel model. Start with a rolling 12-month forecast to get a clearer picture of cash flow and growth.
  4. Get advice. Bring in an outsourced CFO or finance advisor a few hours a month. A fresh set of eyes can often unlock opportunities you’ve been overlooking.

Thinking Ahead: The Long Game

Even if selling your business isn’t on your radar today, it’s worth planning as if you might one day. Buyers pay more for companies with strong financial discipline, reliable data, and a track record of making strategic decisions. That doesn’t mean you need to run your company like a Fortune 500 business — but it does mean putting the building blocks in place now so you’re ready when opportunity knocks.

Throughout my career, I have had the privilege of managing many types of business, ranging from high-growth start-ups to mature, private equity-backed consolidation groups. I have also had the opportunity to serve customers ranging from SOHO’s to Fortune 500 enterprises. What I’ve come to realize is that what I most enjoy is everything in between—or, in other words—the midmarket.

Over the last two decades, I’ve had the privilege of helping to acquire founder-led businesses. These entrepreneurs had the vision to see a problem and the ambition to build a business around solving it. That initial growth journey—building out a proven product for a niche market—often takes a lifetime, and it’s so incredibly inspiring.

The skillset required to get that first 10 million is often very different from the skillset required for the 10-100 million journey. There’s no insult there, because I’m no founder, and I’ve met plenty of founders with no interest in the midmarket growth journey—which is what I know how to do, and what I’ve come to realize I love to do.

By far, the most rewarding aspect of the job is witnessing the professional development of the people in these businesses. The honor of my career has been mentoring young, sometimes second-generation management teams and unlocking their big ideas.

I also really enjoy the speed of execution that comes with the midmarket growth journey. The companies are still too small for bureaucracy, and the people are deeply loyal and knowledgeable. It’s an environment where small but enlightened teams can achieve tangible results quickly, and where success is extremely personal.

I also love witnessing the impact of growth initiatives—particularly from a customer perspective. Sometimes even simple changes to their service experience or a single product release can have transformative value creation and turn happy customers into true ambassadors.

At Mirador, our strategic aim is to enable the continuous business process improvement of our customers through ERP software.

In the world of midmarket ERP, success isn’t about being the lowest-cost provider or having the flashiest features. Multiples of what’s saved on a cheap ERP implementation is lost in wasted materials or poor inventory management, faulty project or job costing, and a lack of real-time data to drive informed decisions on the shop floor and the board room — and everywhere between. Flashy features from more horizontal providers look great in demos, but end up fitting the company to the system, not the other way around. They’ll pitch this as a virtue claiming “best practice,” which really just means “industry average.” We believe in becoming a true partner to our customers, helping them navigate complexity with tailored solutions, deep expertise, and a long-term commitment to continuous improvement.

ERP systems aren’t plug-and-play. They touch every aspect of a business—from production to inventory, finance, and customer service. They are the system of record. Each company has its own workflows, challenges, and strategic goals that make up its unique competitive advantage. A generic ERP system constantly drags a company toward generic operations.

That’s where customer intimacy comes in. It’s the discipline of deeply understanding each customer’s business, industry, and evolving needs. It means investing the time to learn how they operate, collaborating on customizations and product roadmap, and staying close well after go-live to ensure continued success. This kind of relationship doesn’t scale easily. It takes patience and steady, deliberate investment.

We’ve found that the midmarket is underserved when it comes to this level of care. Many ERP providers chase scale through standardization, leaving customers to adapt themselves to rigid systems. At Mirador, we go the other direction—we adapt to our customers. Our product management process is customer-driven. A refrain in roadmap meetings is that “we have 1,000 of the best product managers in our customer base.” We foster a service culture built on listening and responsiveness.

Choosing customer intimacy also aligns with how we view the role of ERP software: not as a product, but as a strategic lever. When implemented thoughtfully, ERP can improve competitiveness, enable growth, and strengthen the customer’s position in their own market. That can’t happen without a provider that truly understands their business.

In a category increasingly dominated by short-term thinking and financial engineering, we’re committed to long-term partnerships, local presence, and building trust over time. Customer intimacy isn’t just our strategy—it’s our identity.