Fund Accounting Software for Cities and Counties: Why Encumbrances and Grants Break a Commercial Ledger

Why a city ledger is not a business ledger

It is late October. The finance director has the prior fiscal year open, a shared drive folder named ACFR_2025_WORKING, and 40 Excel schedules that convert what the accounting system produced into what the auditors will accept. The system gave her fund level trial balances. It did not give her the government wide statements, so someone is keying conversion entries for capital assets, long term debt, the net pension liability from the actuary's report and the new lease and subscription schedules by hand. The public works director calls to ask whether he can still award a paving contract. She cannot answer without opening two screens, because the ledger shows expenditures and the purchase order sits somewhere else.

This is the shape of the problem in every city, county and special district we have worked with. A commercial general ledger asks one question: did the money get spent and what did it cost. A governmental ledger has to answer a different one: was the money legally available to spend, out of which fund, against which appropriation, in which budget year, and who does it have to be reported to afterward. Tyler Munis, BS&A, Springbrook, OpenGov and Caselle all exist because that second question does not fit a commercial chart of accounts. They are real products and most of them are competent at the core ledger. The gap is not the ledger. The gap is everything the ledger hands off to a spreadsheet.

Problem 1: encumbrance control that nobody outside finance can see

Appropriation control is the whole point of public sector accounting. A department has budget authority, and a purchase order commits part of it before a single invoice arrives. Every packaged local government system does encumbrance accounting in the ledger. Almost none of them put a usable number in front of the person who is about to sign a contract. So the department head asks finance, finance runs a report, the report is a day old, and the answer arrives after the requisition was already approved.

The failure mode is predictable. Encumbrances roll at year end, and the ones that should have lapsed do not, so a department appears to have $180,000 committed against a contract that was closed out 14 months ago. Nobody cleans those up until the auditor asks. Meanwhile a real overrun sits hidden behind a stale commitment.

What a custom layer does: read the ledger, the purchase order file and the contract register, then compute available balance as appropriation minus expenditures minus open encumbrances minus pending requisitions, refreshed nightly or on demand, and present it as one number per org and object code to the person who owns that budget. Add the aging: any encumbrance with no activity for 12 months surfaces on a lapse review list before close instead of during the audit. This is not sophisticated engineering. It is a joined view that the vendor never exposed, and it is usually the feature department heads notice first.

Problem 2: grants are a second set of books nobody keeps

The single audit threshold moved to $1,000,000 in federal expenditures for fiscal years beginning on or after October 1, 2024, which pulled some agencies out of a single audit and pushed others in as pandemic era and infrastructure money worked through. Either way, the Uniform Guidance at 2 CFR 200 requires you to track federal awards by CFDA number and award, apply the correct indirect cost rate, meet period of performance limits, and produce a Schedule of Expenditures of Federal Awards that ties to the ledger.

The ledger holds a project code. It does not hold the award document, the budget period, the match requirement, the reporting calendar, the draw history or the subrecipient monitoring file. Those live in a grants coordinator's folder structure. When a state agency asks why the draw request and the SEFA disagree by $14,000, the answer takes three days and the difference is usually an indirect cost calculation that was done once in a spreadsheet and never redone after the rate changed.

What a custom build does: make the award a first class object with budget lines that map to ledger accounts, so expenditure posts to the grant and the fund in the same transaction. Indirect cost calculates from the approved rate with the correct base, versioned by rate agreement period, so a rate change in March does not silently rewrite July. Draw requests generate from actual posted expenditures with the supporting detail attached, and the SEFA assembles from the same data rather than from a parallel workbook. Period of performance and reporting deadlines throw a calendar alert to a named person, not to an inbox nobody owns.

Problem 3: the annual report is assembled by hand every year

GASB 34 requires both fund statements and government wide statements, which means every fiscal year ends with conversion entries: capital assets and depreciation, long term debt, accrued compensated absences, the pension and OPEB entries from the actuaries, and now the GASB 87 lease and GASB 96 subscription schedules that most agencies still keep in a workbook. If you submit for the GFOA Certificate of Achievement, add the statistical section and the transmittal letter.

The vendors publish financial statement modules and some are usable. What they do not solve is that your conversion worksheet encodes decisions specific to your entity: which funds are major this year under the size tests, how internal service fund activity is eliminated, how the component unit presents. That logic gets rebuilt from last year's file by whoever is still there.

What a custom build does: hold the conversion as versioned, auditable rules rather than a workbook. Capital asset and debt subledgers post their own entries. Major fund determination runs the size tests against actual balances and shows the arithmetic. Every statement line traces back to the accounts that produced it, so when the audit senior asks where a number came from, you click it instead of searching a folder. Agencies that get this right cut the close from a scramble to a review, and more usefully, the knowledge stops living with one person.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, the honest shape for local government finance work looks like this. A first release covering grant and project accounting, live encumbrance and available balance visibility, and ACFR schedule assembly runs $90,000 to $180,000 and ships in 14 to 20 weeks. A full ledger build for a special district, utility authority or small city, including purchasing, accounts payable, cash receipting and a payroll interface, runs $250,000 to $600,000 phased across 9 to 18 months.

What drives the number up in this category specifically:

• The number of funds and whether you run internal service and enterprise funds with interfund billing, because eliminations are real modeling work.
• Multi year capital projects funded from several sources, where a single invoice splits across a bond fund, a state grant and a federal award with different eligibility rules.
• Payroll, which is where labor distributes across funds, grants and projects with fringe rates. If payroll allocation is in scope, add weeks.
• State prescribed reporting formats, since several states require an annual filing in their own layout on their own calendar.
• Data conversion. Ten years of history out of a legacy system is a project of its own, and the honest answer is usually to convert balances and keep the old system readable rather than migrate every transaction.

What keeps the number down: leaving the general ledger where it is and building the layer around it.

Build versus buy, and why we usually say do not replace the ledger

Here is our position, and it costs us revenue to say it. If you already run Tyler Munis or BS&A, do not hire anyone to replace your general ledger. The ledger is the least broken part of your stack, the conversion risk is enormous, and a failed finance system replacement in a city is a public event that ends careers. What you should build is the layer the vendor priced as a module you did not buy or cannot get changed: grant accounting, project cost, department self service, and reporting that runs against your own data warehouse rather than through a report request queue.

Buy outright if you are a small entity with simple funds and no federal awards. Caselle, Springbrook and BS&A serve that market properly and cost a fraction of a build. OpenGov is a reasonable choice if reporting and transparency are your actual pain and your ledger needs are ordinary.

Build the whole ledger only in narrow cases: a special district, authority or joint powers agency whose accounting does not look like a city at all, or an entity trapped on an unsupported legacy system where the migration is happening regardless and the packaged options force a business model you do not have. In every other case, build the surround.

How to choose a developer for government finance work

Ask the candidate to explain encumbrance accounting back to you before you explain it to them. If they describe a purchase order as a document rather than as a claim against appropriation authority, they will build you a commercial ledger with fund labels on it and you will discover the difference during your first audit.

Ask how they would version an indirect cost rate. The correct answer involves effective dates and replaying a period, not a field on a grant record. This one question separates people who have done federal grant work from people who have read about it.

Ask what they will do about the audit trail. Governmental accounting records have to be defensible years later, which means append only journals, no silent edits, and the ability to reproduce a statement as it stood on the day it was issued. Any design that allows a posted entry to be quietly changed is disqualifying.

Ask who owns the code, the database and the cloud accounts, and get it in writing before kickoff. Public money should not buy a system you cannot take to another firm. At Digital Heroes the client owns the repository from the first commit, and if a vendor hedges on that question, treat it as an answer.