Krogis advises municipal companies (district heating, water utilities, public transport and ports) on the changes that IT projects bring: the invoice workflow for KSeF, integration with the finance and accounting system, e-files, electronic signatures, ERP replacement. I help put them in a single order, prepare managers and staff in the office and in the field, independently assess offers before the supervisory board (what will integrate with the finance and accounting system, what it really costs over five years, how to compare two offers against the same criteria) and check after the rollout whether people really are working differently. For district heating companies, water utilities, public transport operators and port companies.
In a municipal company, change affects the office and the field staff at the same time, and responsibility is shared between the management board, the supervisory board and the owner.
What changes for people: invoices arrive electronically, and they are coded and approved in the system rather than on paper passed between departments.
Typical difficulty: some of the people who approve invoices are rarely at a desk, so the new path has to fit their working day.
What I focus on: an approval path that fits field work, cover for absences, department heads as the first recipients and a check after go-live on where invoices get stuck.
What changes for people: documents and personnel files live in the system, and signing and archiving no longer need binders.
Typical difficulty: being used to paper and the fear that “it will get lost in the system”.
What I focus on: what we simply scan and what we actually change in the process, which departments go first and who in the company keeps things in order after the rollout.
What changes for people: almost everyone’s work changes: accounting, the warehouse, billing and customer service.
Typical difficulty: the comfort of the old system and people’s own spreadsheets, which the new system loses to unless someone has planned for it.
What I focus on: preparing department heads, training on the company’s own data and a review after 3–6 months of whether people really are working in the new system.
What changes for people: letters and proceedings with statutory deadlines move entirely to electronic channels.
Typical difficulty: with statutory deadlines at stake, people prefer the tried-and-tested way and are afraid of making a mistake.
What I focus on: a clear procedure, cover for absences and a simple cheat sheet for people who do this rarely.
KSC and NIS 2. District heating companies, water utilities and public transport operators are typical entities covered by KSC. The obligations fall on the company’s board; I help break them down, keep vendors on track and prepare the company for the audit. KSC from the board’s side
I put them to presidents and board members of municipal companies before they sign a contract. If the answer to any of them is “we don’t know”, that is exactly where I can help.
The cost of a mistake. A low starting price is often smaller than the cost of annexes, of integrations added after signing and of maintenance over the following years. An advisor usually costs less than a single badly chosen technology, a single wrong vendor or a single trap in a contract.
A municipal or port company usually has its own IT department and a capital budget — yet decisions on the direction of digitalisation are taken on the strength of a single recommendation, with no external check on risk, cost or alternatives.
You are not a public administration body. A commercial company works on a different logic from a public office: a different decision horizon, a different way of justifying decisions, different pressure to deliver results. We work in your language — risk, cost, operational continuity — not the language of administration.
Mandatory structured e-invoicing through KSeF (the national e-invoicing system) requires integration with your existing finance and accounting systems, not just the purchase of a new module.
From the inventory: a finance-system integration matrix and a list of the systems that must exchange data with it.
Integrating a new system with the existing finance system is the most common flashpoint — the question is “can we make it connect?”, not “should we replace everything?”.
From the inventory: the integration requirement written into the specification from day one, not tacked on as an amendment after signing.
Each new module either plugs into what you already have or becomes yet another application silo that the company pays for twice.
From the inventory: A/B/C/D categories and the order of rollouts.
Many public utility companies, particularly in district heating, water supply and transport, fall within the scope of the amended National Cybersecurity System (KSC) Act, even though they operate as commercial companies.
From the inventory: a systems register and a risk register.
A large, integrated ERP sounds safe, but it can turn into one big dependency on a single vendor, with no agility and no room for newer technology. There is no single right answer: it depends on the company’s business model and size.
From the inventory: what stays in the ERP and what is better carved out as a separate, well-integrated system.
The head of IT identifies the need but has no authority over other department heads to secure their cooperation — what is missing is leverage, not knowledge.
From the inventory: a mandate from the board for an external advisor to gather what the IT department needs.
Without a common comparison matrix, you end up comparing like with unlike, and the winner is the better presentation rather than the better offer.
From the inventory: comparison criteria agreed before the vendor meetings, not during them.
Before the company buys another module, I ask why, and what will count as success. It often turns out that behind the request for a single system lies a process that needs sorting out first, with the tool coming only as the second step.
The request“We need an invoice-workflow system for KSeF.”
It happens that the supervisory board asks about cost and risk, while the management board has a single recommendation, from its own IT. Integration with the finance and accounting system often only comes to light after the contract is signed. KSeF, e-Doręczenia and document-flow projects are frequently run by different vendors.
Annexes and running costs often keep growing, because the starting price does not show the five-year cost. Replacing the ERP or the invoice workflow can slip when the vendor wrote the requirements. The board then decides without a second, independent opinion.
Usually the president of the board or the board member responsible for finance, working with the head of IT.
I don’t replace the IT department or step into its remit, and I don’t sell systems. The decision stays with the board and the supervisory board.
The smallest safe first step: a 30-minute call at no charge, then an inventory (2–6 weeks, below the public-procurement threshold). Until then you commit to nothing.
KSeF, integration with the finance and accounting system, an ERP replacement and further modules are run by different people and different vendors. The IT department can be small, and coordination gets whatever time is left after keeping the systems running.
I bring together in one place what is scattered today: projects, deadlines, dependencies, decisions and vendor commitments. On the company’s side, and without stepping on the IT department’s responsibilities.
One page for the CEO and the chief accountant, a presentation for the board meeting and a full set of documents for talks with vendors.
Outline draft. A 60–90-minute session is included in the price.
| Your plan | What the board gets | Risk it addresses |
|---|---|---|
| Invoice workflow under KSeF | A finance-system integration matrix, requirements for the specification, an integration option and a new-system option with the 5-year cost. | Yet another application silo next to the finance system, amendments to pay for integration, double data entry. |
| Integration with the finance system and ERP | The integration requirement written into the specification from day one, questions for vendors. | Discovering after signing that “it can’t be connected”, and having to replace a system nobody wanted to replace. |
| Digital personnel files and further modules | A/B/C/D categories, a rollout order, a change-management plan. | Resistance from staff at the outset, and modules that don’t talk to each other. |
| Supervisory board and owner | A one-page recommendation, offers compared against standardised criteria, the total cost over 5 years. | A decision taken “on the strength of the presentation”, and questions about its basis after the event. |
Depending on the number of systems and departments. I confirm the exact price after a 30-minute call about the size of your company.
Decides on IT projects on the basis of their own IT department’s recommendation — and needs a second, independent opinion before signing, not after the event.
Receives: a one-page recommendation and two decision options with their 5-year cost, ready to present to the supervisory board.
Outcome: a decision they can defend before the supervisory board.
Responsible for integrating new systems with the existing finance and accounting system — usually the first and toughest point of contention in any project.
Receives: a finance-system integration matrix and requirements that can be written into the vendor contract and enforced.
Outcome: predictable costs and integration without contract amendments.
An ally when an independent review backs their recommendation with figures and board-level arguments — not a competitor taking over their role.
Receives: a systems register, a repeatable methodology and board-level arguments for their own recommendation.
Outcome: independent confirmation of their own recommendation.
The same way of working proved itself in the digitalisation of a container terminal: an external, independent voice at the board table, alongside the expertise of the company’s own IT department, not in place of it.
A register of systems, integrations and dependencies, with particular focus on the finance and accounting system and its links. A/B/C/D categorisation and a risk map. A one-page summary for the board.
Before the board approves the IT department’s recommendation: a second opinion on risk, total cost and alternatives. Pointing out where other companies in a similar position overpaid because they did not anticipate integration, data migration or resistance from staff. When the CEO has an idea but no time to write it up, a 15–20-minute conversation is enough for me to come back in about 2 days with a finished concept for review.
A comparison matrix for two (or more) offers against common criteria, questions to put to vendors, and attending meetings as the board’s representative — so that the decision put to the CEO rests on comparable data, not on how persuasive a presentation was.
Attending vendor meetings, giving an opinion on further projects in parallel with your IT department’s recommendation, and an up-to-date view of where similar companies have overpaid for decisions on cloud, APIs or automation.
The legal department at the same organisation now has a digital archive of procurement proceedings, invoice workflow with OCR, KSeF integration and a legal-support module, delivered as successive projects, each building on the last, using the same mechanism: the board sets out its intent, Krogis turns it into action.
“The same way of working as in the digitalisation of the container terminal — an independent voice for the board alongside the expertise of the company’s own IT department, not instead of it.”
A CRM system for the customer-service and sales teams, built on a process platform: contacts, website enquiries, offer calculation and preparation, complaints, still in use today. Identifying objectives, analysing requirements and developing the concept for a stakeholder relationship management system. Experience of digitalising a large infrastructure operator.
Design, implementation and launch of a collaboration and business process management platform covering, among other things, a digital archive of procurement proceedings, a digital cost-invoice workflow, digital personnel files, correspondence management and legal support.
Recurring, anonymised themes from conversations about digitalisation — not quotes from any particular company.
“Before we go any further, I need to know whether this will connect to our finance system at all — everything else is secondary.”
“We always put two offers side by side in front of the board — we need someone to help us compare them fairly, not just pick the more polished presentation.”
“Even when a process is automated, I want a real option to make the decision manually when I think it’s necessary.”
“We don’t want to be treated like a public body — we’re a company, and we weigh risk and results differently from a public office.”
In most cases it can be done through an API or a dedicated integration, as long as the integration requirement is written into the specification from day one rather than tacked on through an amendment after the contract is signed. It’s one of the most common sticking points in IT projects at municipal companies — and one of the easiest to address in advance.
Yes. Under the amendment in force since 3 April 2026, a company performing public-utility tasks is covered by the Act at least as an important entity, regardless of its size. District heating, water supply or transport may additionally qualify it as a key entity in its sector — that is worth checking case by case. Operating as a commercial company does not exempt it from the obligations.
You need a common criteria matrix — functionality, architecture and openness, security and compliance, technology and vendor, total cost — agreed before the vendor meetings, not during them. Without it, you often end up comparing like with unlike, and the winner is the better presentation rather than the better offer.
Yes. The logic of the Commercial Companies Code differs from that of public administration: the decision horizon is different, so is the pressure on financial results, and some obligations (public procurement, for example) may not apply to a company to the same extent as to a public office. That is why communication with, and advice to, municipal companies should be in business language — risk, cost, continuity — not administrative language.
You need to calculate the total cost of ownership over several years — licence, implementation, maintenance, training, integration — and compare it with the actual cost of your current, fragmented systems, not with the list price they had years ago. A general claim that one platform will save money usually falls apart once the numbers are done.
First, list what the new system has to work with: the finance and accounting system, the KSeF invoice workflow, technical systems and customer service. Decide who in the company makes decisions about processes, and write down the requirements, including integrations, before you start talking to vendors. Compare offers in a single matrix and on total cost, and base acceptance on agreed test scenarios.
