allclouds.pl

Accelerating local government finance analysis: can a city treasurer trust AI when working with a city budget?

A treasurer analyzing Bydgoszcz financial data with an auditable AI system

A city treasurer needs answers faster than manual review of reports allows. At the same time, they cannot accept a result that cannot be reproduced, verified, and traced back to a specific source. That is why, in public-finance analysis, a language model should not *calculate* the budget. It should understand the question, trigger the right computations, and explain the result.

![City treasurer analysing Bydgoszcz financial data using an auditable AI system](image:cover)

Why now

Local-government finance in Poland is undergoing its biggest redesign in two decades. Since 2025, a reform has been in force in which the main source of funding for local governments (JST) is residents’ PIT, not subsidies; in the first year, local governments received a total of PLN 53.3bn more than under the old rules — yet the Ministry of Finance itself admits the system needs fixes and announces changes for 2027. Revenues for 2026 are calculated based on tax data for 2024, and their growth is no longer guaranteed. PAP

For a treasurer, this creates two new working conditions. First: the unit’s position against a peer group has stopped being a mere reporting curiosity — in a system with wealth-dependent adjustments, benchmarking against other cities becomes a variable that can materially affect revenues. Second: uncertainty in the rules rewards the ability to recompute scenarios quickly — not once a year during budget drafting, but continuously, with every announced correction to the system.

There is also real pressure on the expenditure side. Local budgets for 2026 are record-high, but the planned sub-sector deficit may reach PLN 47bn; chronic underfunding of education quickly absorbs revenue-side increases and forces very cautious spending decisions. Questions about the operating balance, debt service capacity, and the impact of cost increases are no longer academic in local government. They are the substance of discussions with the council, the regional audit chamber, and banks. Gov.pl

The problem is that the tools treasurers are expected to use to answer these questions have not kept up with the scale and pace of change.

The problem does not start with a lack of data

Local governments have a lot of financial data. The Ministry of Finance publishes reports on revenues, expenditures, budget results, receivables, liabilities, budgetary establishments, and earmarked accounts of education units.

The issue is that these data are produced in many separate structures, and analysing them requires knowledge of the budget classification, the meaning of individual fields, and dependencies between the reports.

An additional barrier is the format. Large Ministry of Finance datasets are published, among other things, as DBF files. To run an analysis in a typical tool, an employee has to download them, unpack them, convert them to CSV or Excel, join them with the local-government dictionary, filter the right unit type, and then build aggregations.

Only then can they begin to answer the actual questions:

These are not questions about a single document. Each one requires combining data, performing computations, and applying the right comparative method.

The AI paradox in public finance

A language model understands questions asked in natural language very well. It can explain concepts, structure arguments, and present a complex result in a way a human can follow.

However, it should not independently sum hundreds of thousands of records, derive medians from documents retrieved via RAG (Retrieval-Augmented Generation), or read numbers from multi-page PDF tables and treat them as reliable numeric data.

In such a working model it becomes hard to answer basic control questions:

In public finance, a fluent answer is not yet a credible answer. Credibility begins where the language model’s freedom ends.

Architecture instead of trusting the model

In a prototype built for a city-treasurer scenario, we used a hybrid architecture. It separates language understanding from computations — the same principle we described for procurement processes: the language model should not do everything.

The user works in one environment, TWIN:DESK, and asks a question the way they would ask an analyst:

> Show the departments where Bydgoszcz has low plan execution but high commitments, and compare them with the median of other cities with county rights.

The language model recognises intent, selects the right tool, and passes controlled parameters. From that point, computations are performed by deterministic code, not by the AI model.

The flow looks like this:

AI does not replace the analytical engine. It is a communication and orchestration layer over an engine that can be tested.

What exactly AI does

In this approach, AI is used for four distinct tasks:

This separation is critical. RAG answers “what does this field mean?”, code answers “what is the value of the indicator?”, and the language model explains “what follows from it and what cannot be concluded yet.”

Data remain data, not the model’s context

The prototype analyses about 1.85 million reporting records. Trying to place such a dataset directly in a model context would be inefficient and would not produce trustworthy aggregations.

That is why raw data are not indexed as ordinary RAG documents. The tool:

The model is not given the ability to run arbitrary code, execute SQL, or fetch any URL. It can only use pre-defined analytical functions and their parameters.

One conversation, many sources

The current-situation analysis uses Ministry of Finance reports for the first quarter of 2026. An extended layer combines them with:

Thanks to this, the conversation does not end with a simple “plan execution” view. The system can compare operating balance and capital spending over time, present values per capita, analyse the relation of spending to population or service users, and indicate the safety buffer implied by the WPF.

However, the data scope is always explicit. If a comparable metric does not exist for a given year, the system returns a “no data” status. It does not interpolate it and does not ask the model to “reasonably estimate” a missing value.

A scenario is not a forecast

One function of the prototype is cost-pressure analysis. A treasurer can check what would happen to the budget if, for example:

The engine first identifies the calculation base using the budget classification. It then separately calculates the impact of current and capital costs on the operating balance, the budget result, and additional financing needs.

The language model is not allowed to present such output as a forecast. This is sensitivity analysis: an answer to what happens to specific items if chosen parameters change, while other assumptions remain unchanged.

This distinction matters. A forecast would require a model of revenue changes, inflation, debt, repayment schedules, and many other factors. Sensitivity analysis shows the consequence of one assumption and helps prepare for a risk conversation — including the one that will be triggered by the announced 2027 correction to the financing system.

Auditability built into the answer

Every result returned by the tool includes the metadata needed to assess it:

For example, “plan execution” is not described as a general statement by the model. It is calculated as the ratio of execution to plan. “Commitments” use a separate field, and overdue liabilities are derived from the indicated items in the Rb-Z report.

Similarly, analysing whether spending aligns with strategy does not claim that higher spending means a goal has been achieved. It uses an explicit, versioned mapping that assigns departments, chapters, and tasks to strategic goals. Each assignment receives a confidence level, and amounts without unambiguous mapping remain marked as unassigned.

The system must not only provide an answer. It must also provide instructions for challenging it.

What the prototype validated

The solution includes 18 analytical functions and a set of ready-made conversation scenarios. It supports, among other things:

The data layer covered eight historical annual periods, a 20-year WPF horizon, and the full set of 66 cities with county rights. Mechanisms were covered by tests controlling, among other things, formulas, completeness of peer groups, avoidance of double counting, source integrity, and presence of source and limitations in the results.

This is still an analytical prototype, not a system that makes budget decisions. Its job is to shorten the path from a question to a verifiable analysis — not to replace the treasurer’s responsibility.

A treasurer does not need a model that “knows the answer”

They need an environment that understands their question, can trigger the right procedure, and does not hide how it arrives at the result.

In this arrangement, AI delivers real value to public administration: it removes the technical barrier between a question and an analysis. The treasurer does not have to convert DBF, build spreadsheet formulas, or remember the structure of each report — yet they still see sources, periods, formulas, and limitations.

The safest use of AI in public finance is not handing numbers to the model. It is giving a human the ability to talk to a deterministic analytical system in natural language.

---

We are entering the season of building 2027 budgets and updating the WPF — and with it, questions about the consequences of the announced changes to the financing system. The prototype described in this article works and can be demonstrated on live reporting data.

If you want to see what such an analysis would look like for your city — on your reports, your WPF, and your strategy — contact us. We prepare demonstrations using public data from the Ministry of Finance.