An independent review of the project before you sign: what will integrate with the finance and accounting system, what it really costs over five years, and how to compare two offers against standardised criteria. For district heating companies, water utilities, public transport operators and port companies.
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 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 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.”
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 | What risk it closes |
|---|---|---|
| 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 case 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 multilingual counterparty management system on a process platform: registration, enquiries, offers and 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.
Many public utility companies, particularly in district heating, water supply and transport, fall within the scope of the amended KSC Act (NIS 2), even though they operate as commercial companies rather than public administration bodies. It is worth checking case by case, as coverage depends on the scale and type of activity.
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.
