For most of my career the technology line was the softest number in the district budget. Facilities could point at a boiler. Transportation could point at a bus. Technology pointed at a spreadsheet of purchase orders and a guess about how long Chromebooks last. That guess is what gets cut first, because nobody can defend it.

A refresh budget you can defend has three properties. It comes from the actual inventory, device by device. It shows its assumptions as knobs anyone can turn. And it separates what is already overdue from what is coming. This guide is how to build one, on a spreadsheet or in software, and how to present it so it survives the meeting.

Start with the inventory, not the ratio

The common shortcut is a replacement ratio: "we replace 20% of the fleet a year, so a five-year cycle." It works right up until it doesn't, and it stops working the year a large purchase cohort all ages out together. Districts that bought their 1:1 fleet in one year during the pandemic are living this now: a wall of devices reaching Auto Update Expiration in the same school year, and a ratio that told them everything was fine.

The plan has to come from the devices. For each one you need: purchase date, unit cost, model, and the end-of-support date (the Google AUE for Chromebooks, an estimate for Apple and Windows devices). That is four fields, and every one of them is either in your purchase orders or in the Google Admin console export.

If you do not have purchase dates for older devices, use the warranty start date, or the enrollment date from Google as a floor. Never use the model's release date as the purchase date: a model released in 2021 that you bought in 2024 is three years newer than its release date suggests, and writing one into the other ages the fleet and asks for money early.

The five-year table

The output is one table: school years across the top (July to June), and for each year the devices due for replacement, their replacement cost, expected repair spend, loss and growth allowance, and license renewals, with a total. Five years is the right horizon: long enough to show the wave coming, short enough that the assumptions still mean something.

Replacement. For each device, the replacement year is the earlier of its AUE year (for Chromebooks) and its purchase year plus the lifecycle you choose. Group by school year, multiply by the replacement cost per device. Apply an inflation rate to future years; three percent is a defensible default.

Repairs. Use last year's actual parts and labor spend as the baseline, not a percentage of device cost. If you track parts per ticket, this is a sum; if you do not, it is the parts budget line from last year. It should shrink as old cohorts are replaced and grow as new ones age; a flat number is fine for a first draft.

Loss and growth. A small allowance for devices that leave (lost, stolen, unrepairable) and for enrollment growth. One to three percent of the fleet per year is typical; use your own history if you have it.

Software. License renewals by fiscal year: filtering, classroom management, assessment, the office suite if it is paid. They are real money that lands in the same year and the plan is incomplete without them.

The knobs

The reason a plan survives a meeting is that the assumptions are visible and adjustable, so the argument is about the assumptions, not about your competence.

  • Device lifecycle (four, five, or six years). Turning this knob shows the board what stretching the fleet a year saves, and what it costs in repairs and out-of-support devices.
  • Cost inflation per year.
  • Replacement cost per student device and per staff device. Use what you actually paid last time, including the license and a case if you buy them together.
  • Enrollment change per year.

If the plan is a spreadsheet, put these four in cells at the top and reference them everywhere. If it is software, they should be inputs on the page. Edventory's forecast has exactly these knobs and recalculates the table as you turn them, which is the single most useful thing to do live in front of a finance committee: "here is the plan at five years; here is what happens at six."

Show the backlog separately

Devices that are already past AUE, or already past the lifecycle you chose, are not a future-year line. They are this year's problem, and folding them into the natural schedule hides them. Put them at the top of the plan as a backlog with their own count and cost.

This is also the number that gets a plan funded. "We have 140 devices already out of support on student desks" is a sentence a board understands, and it is true or it isn't. The free AUE report gives you that count in a minute from the Google Admin export; it separates the past-AUE backlog from the by-year table for exactly this reason.

Natural schedule versus level-loaded

The natural schedule replaces each device in the year it is due. For a fleet bought in waves, that produces a table nobody funds: 1,200 devices one year and 200 the next.

A level-loaded plan smooths the line. It pulls some replacements forward (replacing devices a year before AUE) and pushes others back (running some devices a year past the chosen lifecycle, never past AUE) so that each year's number is close to the average. The trade-off is explicit: some students use older devices for a year, some newer, and the finance office gets a flat line they can plan around.

Present both. The natural schedule is the honest picture of the fleet; the level-loaded plan is the proposal. When the board can see the two side by side, the conversation is about which to choose rather than whether the numbers are real.

Presenting it

Write for a board member who has never enrolled a Chromebook. Expand every acronym once: "Auto Update Expiration (AUE), the date Google stops supporting a Chromebook." Lead with three numbers: the past-AUE backlog, next year's total, and the five-year total. Then the table. Then the knobs, with one sentence each on what happens if they change.

Include one page of evidence: a chart of devices by purchase year (the wave is visible), the repair spend by model (the argument for the model you want next), and the license renewals by month (the surprise invoices, no longer surprises).

End with what you are asking for: a specific dollar amount for next year and a commitment to the level-loaded line for the years after. A plan with no ask is a report; a plan with an ask is a budget.

Edventory produces this as a one-click board report from the live forecast, with the narrative written for a non-technical reader and every number traceable to a device record. On a spreadsheet, the same structure in a five-slide deck works fine; the discipline is the same.

Keeping it alive

A refresh plan built once and never updated is worse than none, because people believe it. Three habits keep it honest:

  • Re-run it every quarter. Purchase dates, AUE dates, and repair spend all move. If the plan comes from the inventory, re-running it is a refresh, not a rebuild.
  • Record every purchase at receiving with the cost and funding source, so next year's plan already knows about this year's devices.
  • Close the loop on retirements. When a device is replaced, mark it retired the same week. A plan that still counts retired devices asks for money twice.

If the plan lives in the same system as the inventory, the help desk, and the license list, these habits are mostly automatic: the forecast reads what the rest of the system already knows. That is the whole reason Edventory's forecast sits next to the device list rather than in a separate spreadsheet, and why it is free for up to 100 devices and 100 students to start. But the method does not depend on the tool. Start from the devices, show the knobs, separate the backlog, offer the level-loaded line, and ask for a number.