Government Budgeting Software: Why Position Based Personnel Costs Break Every Spreadsheet You Build

Why budget season breaks in personnel, not in the numbers

It is a Thursday in March. The budget director has a proposed general fund book that balances, and the manager has just asked what happens if the police contract settles at three percent instead of two, if two vacant positions are held open for six months, and if the health plan renewal comes in higher than assumed. Three questions. Each one touches every position in the roster, which touches pension contribution rates, which touches the employer share of every fund that position is charged to. The analyst says he can have it Monday. He means Sunday night.

That is the real budgeting problem in the public sector, and it is not solved by better spreadsheets. The largest share of any city or county general fund is people, and the cost of a person is not a number. It is a calculation: a class and step on a schedule adopted by resolution, a longevity increment at defined years of service, an education incentive, a shift differential, employer pension contribution at whatever rate the state system certified this year, health insurance at the tier that employee elected, and an allocation across funds and grants. Change one input and several thousand derived numbers move.

Meanwhile the departments submitted their requests in the workbook finance emailed out in January, and eleven of them changed the tabs.

Problem 1: personnel cost is a model, and most tools treat it as a line

Ask a corporate planning tool to budget headcount and it will give you a cost center, a number of full time equivalents and an average salary. That is fine for a company. It is useless for a government where the budget document authorizes specific positions, where a vacant position still exists as an authorized slot, and where filling it in October rather than July changes the cost by a quarter.

Workday Adaptive Planning is a serious financial planning product built for corporate finance, and that is the problem: step and longevity schedules, reclassifications mid year, and position allocation across grant funded and general funded splits are not what it was shaped for. Euna Solutions Questica does position budgeting properly and is the strongest of the packaged options here, but the configuration lift is real and getting a new calculation added is a vendor conversation rather than an afternoon. ClearGov and OpenGov are good at presentation and transparency, and shallower once your personnel math involves several bargaining units with different effective dates.

What a custom build does: hold the position as the unit of budgeting. Each position carries its class, step, schedule, FTE, funding string allocation, and its incumbent or vacancy status with an assumed fill date. Salary schedules are versioned by effective date, so a contract that settles retroactive to July is applied by replaying the schedule rather than by editing cells. Benefit rates are rules, not columns: pension at the certified rate for that plan tier, health at the elected tier with a renewal assumption you can flex, taxes and workers compensation at classification rates. Then a vacancy or attrition assumption applies as a policy, not a plug, so you can show the council exactly where the savings assumption sits.

Problem 2: department requests arrive as 40 different workbooks

Finance publishes a template with locked cells. Departments unlock them. Someone adds a row, someone else summarises three requests into one line, the fire department submits a version that references a file on a drive nobody else can reach, and the analyst spends two weeks doing reconciliation instead of analysis. Supplemental and decision package requests, which are the part elected officials actually debate, arrive as narrative in a Word document with a number that does not match the workbook.

What a custom build does: replace the workbook with a form that will not accept an unbalanced request. Base budget is prepopulated from prior year actuals and adopted amounts, so departments are only entering the delta. Each supplemental request is a structured object with a cost, a funding source, a narrative justification, a performance measure and a priority ranking from the department head. Review moves through defined stages with an audit trail: department submits, budget office recommends, manager decides, and everyone can see what changed at each stage and who changed it. That last part matters more than it sounds, because the question at a council workshop is usually not what the number is but who cut it and when.

Problem 3: every scenario means rebuilding the whole book

The budget is not one book. It is a base case plus a stack of assumptions: revenue growth, the property tax levy and any state limit on it, the labor settlement, the health renewal, the pension rate letter, transfers between funds, and a fund balance target. The governing body will change at least two of those in public, on the night of the vote.

Spreadsheets handle one scenario at a time and lose history. What a custom build does: make assumptions first class and versioned, so a scenario is a named set of assumption values rather than a copy of the file. Recalculation runs across all funds at once, including the interfund transfers and the internal service charges that most workbooks fudge. Fund balance projects forward against your adopted reserve policy, so the model tells you when a scenario drops you below the floor, and GFOA's own recommendation of no less than two months of general fund operating revenue is a sensible line to draw on that chart. Then a comparison view shows any two scenarios side by side at fund, department and account level, which is what turns a workshop from an argument into a decision.

Problem 4: the adopted budget and the ledger drift apart in week two

The budget is adopted, keyed into the financial system, and then reality starts. Amendments, transfers between line items, encumbrance carryforward, grant awards received mid year, and position reclassifications all move the number. By March the amended budget in the ledger and the book on the website disagree, and the mid year review becomes an exercise in explaining the difference rather than managing it.

What a custom build does: treat adoption as a hand off with a return path. The adopted budget loads into the ledger through an interface you control, and the ledger's amended budget and actuals load back nightly, so the budget system always shows adopted, amended, actual, encumbered and available side by side. Amendments are initiated in the budget system with the approval level your ordinance requires, which means the paper trail for a council approved transfer exists in one place. Monthly forecasting then runs off actual to date plus known commitments rather than off a straight line projection, and the year end estimate stops being a guess someone defends.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, the shape here is consistent. A first release covering the position roster with real salary and benefit calculation, department request intake and base budget assembly runs $70,000 to $150,000 and ships in 12 to 16 weeks. A full platform adding scenario modeling, the capital improvement plan with multi year funding, fund balance forecasting, ledger integration and a budget book generator runs $180,000 to $400,000 phased over 6 to 12 months.

What drives cost up in this category:

• Bargaining units. Each contract brings its own schedule structure, increment rules and effective dates, and three units is materially more work than one.
• Grant funded positions with allocation splits that change during the year, because the cost has to follow the funding string.
• A capital improvement plan with multi year, multi source funding, which is a second model rather than a tab.
• The published book itself. If the document has to meet the GFOA Distinguished Budget Presentation criteria with a specific layout, charts and statistical content, treat document generation as its own workstream.
• Utility or enterprise funds with rate models attached, where the budget drives a rate study rather than the other way around.

What keeps cost down: doing personnel first and everything else later. Personnel is most of the money and all of the pain.

Build versus buy

Buy if you are small and conventional. Under roughly 200 positions with one or two salary schedules and no grant funded allocation complexity, ClearGov or your existing financial system's budget module is adequate, and a build would be an expensive way to get the same answer.

Buy Questica if position budgeting is your only real problem, you are willing to configure to its model, and you can live with a change request queue when your council invents a new requirement in July. That is an honest recommendation and we make it regularly.

Build when the calculation is genuinely yours: several bargaining units, positions split across funds and grants, an internal service allocation your finance director designed, or a rate model that has to move with the budget. Build also when the practical risk is personnel rather than software, meaning one analyst holds the model in a workbook and the organization cannot survive that person taking a new job in April. The point of the build is not features. It is moving institutional knowledge out of a file and into a system with an audit trail.

How to choose a developer for a public budgeting system

Show a candidate your salary schedule and your pension rate letter, and ask them to explain how they would model a mid year contract settlement applied retroactively. If the answer does not involve effective dating and recalculation rather than editing values, they will build you a prettier spreadsheet.

Ask how they handle a position that is 60 percent general fund and 40 percent a federal grant that ends in March. The correct design allocates cost across funding strings with time bounds. A wrong design puts a percentage field on the position and quietly overstates your grant charges.

Ask what they will do about the budget document itself, in specifics. Generating a 300 page book with fund summaries, department pages, position schedules and charts, in a layout your finance director will not compromise on, is a real engineering task and it is where projects run late.

Ask who owns the code, the database and the hosting accounts, and require it in writing before kickoff. A budget system is where your organization's financial logic lives, and it should not be portable only with the vendor's permission. At Digital Heroes the client owns the repository from the first commit, and any firm that resists that condition is telling you what the relationship will look like in year three.