Government Fund Accounting Software Problems: The 7 That Become Audit Findings, and How to Avoid Them

Why does the scope failure of replacing the general ledger happen so often?

Because the pain is felt at the edges and blamed on the centre. The department head cannot see his available balance, the grants coordinator keeps a parallel workbook, the annual report is assembled by hand every autumn, and somebody concludes that the accounting system is the problem. It usually is not. In most agencies running Tyler Munis or BS and A, the ledger is the least broken component in the stack. What is broken is everything the ledger hands off to a spreadsheet.

Replacing the ledger to fix that is an expensive way to solve the wrong problem, and it carries risks the surrounding work does not: chart of accounts conversion, historical balances, purchasing and payroll interfaces, cash receipting, bank reconciliation, and a go live that must land at a fiscal year boundary. Any one of those slipping delays your annual report, and a delayed report is a public event.

The discipline that keeps this project honest is to write down the ten things people actually complain about and mark which of them require a new ledger. In practice, almost none do. Available balance visibility, grant and project accounting, encumbrance ageing, capital project cost across funding sources and annual report assembly can all be built as a layer that reads your existing ledger and writes back where necessary. Full ledger replacement belongs to narrow cases: a special district or authority whose accounting does not resemble a city at all, or an entity stranded on an unsupported legacy system where migration is happening regardless.

What goes wrong with converting a decade of legacy fund accounting data?

Conversion is where the schedule dies, and the reason is that governmental history is not clean history. Fund structures changed when a new enterprise fund was created and the old activity was never restated. Object codes were reused for different purposes across years. Multi year capital projects carry balances that were reconstructed once, by someone who has retired, and nobody can now explain the entry. Grants that closed years ago still hold residual encumbrances that were never lapsed.

The mistake is treating conversion as a data exercise. It is an accounting exercise with a data component, and every unexplained balance requires a decision by someone qualified to make it. Delegate that to the developer and you will inherit whatever reasonable guess they made.

The pattern that works is to convert balances rather than transactions. Bring across the current chart of accounts, opening fund balances by fund, open encumbrances that survive a lapse review, open grant awards with their expenditure to date, and the capital asset and debt subledgers. Keep the legacy system readable for history and agree, in writing, how long it stays available and who pays for it. Then plan the lapse review as its own workstream ahead of conversion, because the alternative is migrating stale commitments into a new system and discovering them in your first audit under it.

Why do the ledger, purchasing and payroll integrations break after launch?

Because the layer around the ledger is only useful if it is current, and currency depends on interfaces nobody owns after the project team disbands. The failures are consistent. A purchase order is amended in the purchasing module and the available balance view keeps the original commitment. A new fund or object code is created and the mapping table is not updated, so expenditure lands in an unmapped bucket that appears nowhere. Payroll posts a distribution across funds and grants that the layer cannot reproduce because fringe allocation is computed inside the payroll system.

Payroll is the one to watch. It is where labour distributes across funds, grants and projects with fringe rates, and it is the interface most likely to be scoped as a line item and discovered to be a project. If grant reporting depends on labour cost, the payroll interface is not optional and it is not small.

Design for drift rather than assuming it away. Run a nightly reconciliation that compares your layer to the ledger by fund and by account and reports differences with an owner attached. Report unmapped codes as an exception rather than absorbing them. And write down what the available balance view does when the interface has not run, because a stale number presented as current is worse than no number: department heads will make a commitment decision on it and be right to blame the system afterwards.

What happens when grant tracking and indirect cost rate versioning are not covered?

You get the finding. The Uniform Guidance at 2 CFR 200 requires you to track federal awards by award and identifying number, apply the correct indirect cost rate, respect period of performance limits, and produce a Schedule of Expenditures of Federal Awards that ties to the ledger. The single audit threshold moved to one million dollars in federal expenditures for fiscal years beginning on or after October 1, 2024, so agencies near that line should confirm their status with their auditor rather than assuming last year's answer still holds.

What the ledger holds is a project code. What it does not hold is the award document, the budget period, the match requirement, the reporting calendar, the draw history or the subrecipient monitoring file. Those sit in a grants coordinator's folder structure, which is why a state agency question about a fourteen thousand dollar difference between a draw request and the schedule takes three days to answer.

Covering it means the award is a first class object with budget lines mapped to ledger accounts, so expenditure posts to the grant and the fund in one transaction. Indirect cost calculates from the approved rate with the correct base, versioned by rate agreement period with effective dates, so a rate change in March does not silently rewrite July. Draw requests generate from posted expenditure with supporting detail attached, and the schedule assembles from the same records rather than a parallel workbook. Rate versioning is the piece most often skipped and the one auditors test, because a single rate field on a grant record cannot reproduce what was correct at the time.

Should you build custom or configure what you already own?

Configure, and in one case buy outright. If you are a small entity with a handful of funds, no federal awards and a finance office of three or four people, Caselle, Springbrook or BS and A serve that market properly and cost a fraction of a build. Spend the difference on staff. OpenGov is a reasonable choice when reporting and public transparency are your actual pain and your ledger requirements are ordinary.

If you already run Tyler Munis or BS and A, audit what you have licensed before commissioning anything, because agencies regularly build reports and workflows that exist in modules they already pay for and never configured. That audit is a week of somebody's time and it occasionally removes the project entirely.

Where configuration genuinely stops is specific and worth naming. Vendors expose the data they chose to expose, through the reports they chose to build, on the release cycle they control. When your requirement is a joined view across ledger, purchase orders, contracts and grants presented to a non finance user, or a conversion worksheet that encodes decisions particular to your entity, no amount of configuration produces it. That is the layer worth building, and it is buildable without touching the ledger underneath.

How do hidden costs get into the quote?

Fund count is the obvious driver and it is not the interesting one. The interesting one is interfund activity: internal service funds, enterprise funds with interfund billing, and the eliminations that follow are genuine modelling work, and a quote that treats them as configuration has not looked at your structure.

Then 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 and different reporting cycles. Then payroll allocation, discussed above. Then state prescribed reporting, since several states require an annual filing in their own layout on their own calendar, and each format is its own deliverable.

Two costs are almost never quoted. Conversion decisions, because unexplained legacy balances need finance staff time rather than developer time, and that time is not free just because it is internal. And parallel running, because you should run at least one full month end close and one grant draw cycle in parallel before you rely on the new layer, and parallel running means doing the work twice with the same people.

Finally, go live timing. Cutting over mid year is how agencies create a year with two sets of conventions in it. Go live at the start of a fiscal year, and price the wait as part of the plan rather than compressing scope to hit an arbitrary date.

What separates a fund accounting build that works from one that fails?

Ask the developer 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 a commercial ledger with fund labels on it and you will find out during your first audit under it.

Ask how they would version an indirect cost rate. The correct answer involves effective dates and the ability to replay a period, not a field on a grant record. That single 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 records must be defensible years later, which means append only journals, no silent edits, corrections recorded as new entries referencing the original, 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, whatever else it does well.

Ask how the available balance number is kept current and what the screen shows when the interface has not run. And ask who owns the code, the database and the cloud accounts, in writing, before kickoff. At Digital Heroes the client owns the repository from the first commit. Public money should not buy a system the public entity cannot take to another firm, and a vendor who hedges on that question has answered it.