How to justify the IT budget to the Council: obligation, investment and the cost of inaction

This post is for treasurers and secretaries who submit the draft budget each autumn and need to explain to councillors why IT costs more than it did last year.

Calendar: what the law says about deadlines

Under Article 238 of the Public Finance Act, the executive body of a local government unit (JST) – the head of the municipality/mayor (wójt, burmistrz or prezydent miasta) or the district board (zarząd powiatu) – prepares the draft budget resolution and submits it to the decision-making body, i.e. the Council, and to the regional audit chamber (regionalna izba obrachunkowa) for an opinion. The deadline is 15 November of the year preceding the budget year. In 2026, 15 November falls on a Sunday, so it is safer to plan to submit the draft earlier.

Together with the draft, the executive body submits a justification and supporting materials, the scope of which is set out in the Council's resolution on the procedure for budget work (art. 234). This resolution also contains internal deadlines for departments, usually earlier than the statutory one. It is worth checking by when the department responsible for IT must submit its proposals.

Together with the draft budget, the executive body also presents a draft resolution on the multiannual financial forecast or its amendment (art. 230). The forecast covers the budget year and at least the following three years (art. 227). The Council adopts the budget resolution before the start of the year, or, in particularly justified cases, by 31 January at the latest (art. 239).

Three buckets instead of one line item

A single figure labelled "IT" tells councillors nothing. The same spending broken down into three buckets shows what the Council is actually deciding on.

Obligation. Spending the authority cannot avoid because it follows from legislation or a signed contract. Examples: adapting invoice processing to the National e-Invoicing System (KSeF), handling e-Delivery (e-Doręczenia), preparing to work in an EZD-class system (electronic document and case management system), commitments under service contracts signed in previous years. Each item should state its basis: a provision of law or a contract number.
Maintenance. The cost of keeping current systems running for another year: service support, licences, updates, connectivity, replacing worn-out hardware. This spending recurs every year and usually grows with each new system. More on this mechanism in the post on total cost of ownership (TCO).
Investment. Spending the authority chooses because it is meant to improve something: shorten case-handling time, replace manual data entry, reduce the number of systems. This is where the Council has a genuine choice, and where a justification of the benefits and of the maintenance cost in subsequent years is needed.

The line can be blurred. Replacing a server for which the manufacturer is ending support is maintenance. A new module purchased "while we're at it" alongside an obligation is an investment and should be described as such.

For financial oversight

The three buckets do not replace budget classification. The Act divides spending into current and capital expenditure (art. 236), and an obligation can fall into either group: service support is current spending, while purchasing a new system is usually capital spending. The buckets are an additional column in the justification. They show the reason for the spending, while the classification shows its type.

Multiannual spending and the financial forecast

Implementing a larger system rarely fits into a single year, and annual fees follow afterwards. The Act provides that multiannual programmes, projects and tasks are included as "undertakings" in an annex to the multiannual financial forecast, with a name and purpose, the responsible unit, the implementation period, total outlays, annual spending limits and a commitment limit (art. 226).

For the treasurer, this translates into a simple question for every IT investment: how much will it cost in the year of purchase, and how much in each of the following three years. If the department cannot provide that second figure, the request is not ready.

The cost of inaction, without scaremongering

The cost of inaction answers the councillor's question: "and what if we don't do this?" Described well, it is calm and specific. Described badly, it sounds like a threat, and councillors stop listening.

A few rules that help:

Describe the effect on the authority's work, not a catastrophe. Instead of "we face paralysis", it is better to say: "after the support end-date, the vendor no longer fixes bugs, and resolving a failure depends on the vendor's goodwill".
Give dates and documents. The end of the contract, the end of support, the statutory deadline. A date from a contract is more convincing than an adjective.
Show the cost of delay if it can be calculated. For example: today two people manually re-enter data from invoices, and that will continue for another year. If it cannot be calculated, do not insert an estimate pulled out of thin air.
Separate the certain from the possible. A fee increase set out in a contract is certain. A failure of an old server is possible. Councillors should see that difference.
Do not rely on penalties as the main argument. It is enough to indicate that the obligation follows from legislation, and from when.

Analogy for the Council

The IT budget resembles the budget for the authority's own building. Chimney and installation inspections are an obligation. Heating and cleaning are maintenance. Thermal modernisation is an investment meant to cut bills. Nobody asks whether to pay for heating, but everyone wants to know whether insulation will pay for itself. The conversation about systems is worth structuring the same way.

How to present this to councillors

Councillors do not assess systems. They assess whether spending is necessary, purposeful and economical, because that is what the Act requires of public spending (art. 44). This is why, in the justification and at committee meetings, a single page works better than a technical presentation.

That page should contain: the three buckets with amounts compared to the current year, one sentence of "why" and one of "what if not" for each major item, and the costs for subsequent years for each investment. System names are replaced with a description of what they do: "correspondence workflow system", "tax assessment programme". Abbreviations are spelled out on first use or omitted.

It is also worth pre-empting the question about growth. If the budget is increasing, the page should show which part of the increase stems from obligations, which from price rises in existing contracts, and which from the authority's own decisions.

The documents behind it

The split into buckets is credible only if it can be verified. The treasurer can ask for three things:

A register of systems. For each one: what it is used for, which department uses it, who the vendor is, the contract number and term, the annual cost, and the manufacturer's support end-date. I write about how such a register differs from a mere list of programs in the post on system inventory.
A summary of contracts with costs for coming years. Which fees are fixed, which are rising and on what basis, and when the notice period expires.
A list of obligations with their legal basis and deadline. Short, naming the provision and specifying exactly what it covers in the authority.

If these documents do not exist, the first budget built this way will be approximate. That is still better than a single line item, provided the justification states plainly which figures are estimates.

Sources

Legal status as of 4 October 2026.