POHODA — What It Is, Who It Fits, and How to Build On It

POHODA runs a large share of Czech and Slovak SMEs, and it has earned that position. It is properly localised, well maintained, and correctly scoped for the businesses it serves. It also holds cleaner, better-structured data than most systems we connect — which makes it good raw material for management reporting.

At a glance

What POHODA is

POHODA is a Windows application that runs the financial and operational books of an accounting entity. STORMWARE calls it an economic and information system rather than an ERP, and that is the more honest description — it is built outward from the ledger rather than from manufacturing or supply chain, and it does not pretend otherwise.

The work is organised into agendy — screens that map closely to the statutory books. Issued invoices. Received invoices. Bank. Cash. Internal documents. Stock. Fixed assets. Payroll. Each posts into the ledger under the accounting rules of the jurisdiction the build is localised for.

That localisation is the product’s real achievement, and it is harder than it looks. The Slovak build handles DPH, the kontrolný výkaz DPH with statutory section coding applied at document and line level, and eKasa for cash takings. The Czech build handles Czech VAT and its own filing obligations. Both file electronically from inside the application, and both track legislative change closely enough that users rarely have to think about it. Keeping pace with two tax codes across three decades is a substantial ongoing commitment, and STORMWARE has met it.

For a company that needs to be correct with the tax authority, wants stock and payroll in the same place, and does not need manufacturing depth — POHODA is a well-judged product at a reasonable price. A lot of businesses should stay on it for a long time.

The three product lines

Most buyers choose a line on user count and budget. It is worth understanding what else the choice determines.

The move from the base line to POHODA SQL is worth knowing about. On SQL or E1 the data sits in Microsoft SQL Server, which makes reporting work simpler, faster and entirely invisible to the people using the system. It is a licence change rather than a migration project, and for a client where reporting matters it usually pays for itself inside a quarter.

Variants sit across the lines. Jazz, Standard, Profi, Premium and Komplet control which modules are switched on — double-entry versus single-entry bookkeeping, stock, payroll, job costing. POHODA Start is a record-capped free version for testing. POHODA Look is a read-only variant given to clients of accounting practices so they can inspect books kept externally. mPOHODA covers invoicing from a phone.

Who POHODA fits

Sole traders and micro companies. Single-entry bookkeeping, invoicing, a VAT return. POHODA in a low variant is the correct tool and there is nothing here to improve.

Established SMEs. Ten to two hundred people, one or two legal entities, double-entry bookkeeping, stock, payroll. This is the core of the market, and POHODA serves it well. What these companies typically want next is not a different ERP — it is a management view of the data POHODA is already holding correctly.

Accounting and tax practices. A practice may hold several hundred client databases in one installation; STORMWARE’s own sizing guidance discusses four users working across four hundred accounting entities. POHODA’s efficiency at this scale is a genuine strength, and practices are its most concentrated and most loyal user group. Increasingly they are also the ones asking whether they can offer clients reporting on top of books they already keep well.

Retail and hospitality with cash takings. The Kasa agenda plus eKasa integration handles over-the-counter sale directly against stock. That combination is why POHODA appears in shops, cafés and small chains that outgrew a standalone till — and it scales further than many people assume. One of our retail clients runs more than 15 brands and over 20,000 SKUs across an e-shop, physical stores and B2B distribution, with POHODA as the ERP throughout.

Groups that grew sideways. A Slovak trading company, a Czech subsidiary, a UK sales office. Each entity chose the right local system for its own jurisdiction — POHODA in one, something else in another. Every individual choice was sound. What nobody owns is the view across them, and this is the context in which POHODA most often reaches us.

What POHODA holds — and why it is good material

Before the reporting question, it is worth being clear about the asset.

POHODA data is clean. Statutory obligation enforces a discipline that voluntary data entry never does: the VAT return has to reconcile, the kontrolný výkaz has to tie to documents, the ledger has to balance. A POHODA database that has been kept properly by a competent accountant is complete to document-line level, internally consistent, and stable across years.

It is also richer than most users exploit. POHODA carries analytical fields — cost centre (stredisko), activity (činnosť) and job (zákazka) — that allow transactions to be tagged for management analysis. Where they have been used consistently, they carry most of what is needed for real profitability analysis. Where they have been used partially, they are still a foundation worth building on.

Compared with the systems we more often meet — spreadsheet-based bookkeeping, half-configured cloud tools, a decade of accumulated manual journals — POHODA is a good starting point. That matters, because the quality of a management reporting layer is bounded by the quality of what feeds it.

What sits outside POHODA’s scope

POHODA is scoped to one accounting entity, and that scope is a design decision rather than an omission. For its core user — one company, one jurisdiction, one set of books — it is exactly the right boundary.

Three things sit outside it.

The view across entities. One database per accounting entity means a group of five companies is five POHODA databases. There is no shared chart of accounts and no consolidation, so intercompany matching and currency translation happen outside the system.

The view across systems. POHODA has no opinion about whether revenue in your e-commerce platform matches revenue in the ledger, or whether headcount in your HR system matches the payroll run. This is worth saying plainly: no ERP does this. Not POHODA, not Business Central, not SAP. Cross-system truth is a layer above every transaction system, which is the point we make at more length here .

The management view. The statutory chart of accounts is built to satisfy the tax authority, and it does that job well. It is not built to answer which customers make money or what did that project cost against quote. POHODA’s reporting is print layouts against the current book, plus POHODA BI — an OLAP cube consumed through Excel, which does capable work within one entity. Neither is a semantic model that a dashboard or an AI assistant can query across a group.

None of this is a reason to change system. It is a reason to add a layer.

How we elevate it

We have connected POHODA in both its Czech and Slovak builds, across all three product lines, in single entities and in groups running POHODA alongside other systems.

Getting the data out is the routine part. There are four routes — direct read-only SQL on POHODA SQL and E1, which is our default; POHODA’s own XML API through mServer; file-level read on the base line, always against a controlled copy; and scheduled export as a fallback. Read-only throughout. Nothing is ever written back to POHODA, and users notice no difference in how the system performs.

What happens next is the POHODA-specific work.

A management chart of accounts alongside the statutory one

The statutory chart keeps doing its job. We map it to a second structure built to answer management questions — revenue by what you actually sell, cost by what you actually control, margin at the level you actually make decisions. Mapped once, versioned, owned by a named person, reviewed at each close so it does not drift.

The analytical dimensions, put to work

Stredisko, činnosť and zákazka are where the profitability analysis lives. We audit how consistently they have been used across history, surface where they are thin, agree rules for filling them going forward, and encode those rules as validation so the discipline holds. Where a client has used them well, this step is quick and the payoff is immediate.

One view across every entity and every system

Each POHODA database becomes one entity in a common model, sitting alongside Business Central, Helios, SAP B1, an e-commerce platform, a payroll system or a spreadsheet — all producing the same standardised output. Group reporting in any currency, with drill-down from a consolidated total back to the POHODA document that produced it.

This is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. One CEE group runs 8 entities across 6 countries on 6 different ERPs, POHODA among them, in a single daily-refreshed group view. See Group Reporting & Consolidation .

On the governed layer, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a semantic model that Power BI and AI can both query reliably , and your business context accumulating so answers get sharper the longer it runs.

What becomes answerable

The clearest way to describe the difference is to list what a POHODA client can ask afterwards.

• Which customers are actually profitable, after delivery and service cost — not just gross margin on the invoice?
• What did that job cost against what we quoted, while it is still running?
• What is group EBITDA in EUR, when the Slovak and Czech entities sit on different charts of accounts?
• Which product lines earned their shelf space this year?
• Why did overhead move this month, ranked by the cost lines that moved most?
• How much cash is tied up in stock that has not moved in six months?
• Where does the reported number differ from the booked number, and why?

Every one of these is answered from data POHODA is already holding. The information was there. What was missing was the structure to ask.

What it takes, and what does not change

Connection in days. First reports in the first week. For a single-entity POHODA client on the SQL or E1 line, the connection is a read-only login and the first governed reports follow inside a week. A full build — management chart of accounts, dimension repair, consolidation across several entities, the reporting suite — runs in phases over the following months. The distinction matters, and we would rather be precise about it than promise a finished model in a fortnight.

What we need from you: an NDA, read-only credentials, and a conversation about what the numbers should mean.

What does not change: POHODA stays your system of record. Your accountant keeps working the way they work. No migration, no data cleanse project, no retraining, nothing written back.

Read-only access throughout. Your data stays in an EU-hosted Azure environment, aligned with ISO 27001 and GDPR, governed by you.

In practice

POHODA appears across our client base, on its own and alongside other systems. Three published engagements show the range.

Stahlmann — multi-channel retail on POHODA A Slovak tool and hardware retailer running an e-shop, physical stores and B2B distribution, with POHODA as the ERP and good basic processes already in place. The complexity was in the portfolio — more than 15 brands and over 20,000 SKUs — and in a Czech-market expansion that happened during the engagement. We integrated directly with POHODA on automated extraction, then built trend and profitability analysis across online, retail and B2B in one view. Worth noting for anyone doubting POHODA’s capacity: 20,000 SKUs is not a small book, and POHODA carried it.

TEPEDE — POHODA as one of six ERPs A CEE large-format printing group: 8 entities, 6 countries, 6 different ERP and accounting systems, POHODA among them. Each entity had chosen sensibly for its own jurisdiction, and none of those choices had to be revisited. Chart of accounts mapping, currency normalisation, intercompany elimination and daily automated extraction produced a single group P&L, balance sheet and cash flow. Consolidation went from a 20-day monthly exercise to real-time, with roughly a 90% reduction in effort.

Knifestock — POHODA stock data driving replenishment Thousands of SKUs across 4 sales channels in 8 countries, where replenishment decisions had been made on intuition and historical pattern. The stock and sales data needed already existed in POHODA. What was missing was the layer that turned it into a per-SKU view of cover, demand and run-out risk.

When POHODA is eventually replaced

Many POHODA clients change system at some point, usually because they have outgrown the scope rather than because anything went wrong — typically to Business Central, Helios or ABRA.

Because the governed layer sits above the ERP, only the connection changes. The data model, the reports, the dashboards and the consolidation logic stay as they are. Clients who built the layer first find the migration measurably easier, because they can prove the new system’s numbers against the old system’s numbers from day one — and they keep their reporting history through the change rather than starting again.

This is not a theoretical claim. When JING Tea replaced its operational stack, the reporting layer carried through the change unaltered — the systems underneath moved, the numbers and the reports did not.

POHODA in the regional context

POHODA is one of several capable systems serving these markets. Each gets its own article in the series .

From a data-layer perspective the choice matters less than it appears. Each of these becomes an entity in the same governed model, which means the ERP decision can be made on operational fit rather than on reporting fear. The full matrix — including the Polish stack — is on the series hub .

Frequently asked questions

Do we need to replace POHODA to get proper management reporting? No, and we would usually advise against it. Keep POHODA for what it does well — statutory correctness, VAT, local compliance, clean transaction capture — and build the reporting layer above it. Replacing a working ERP to solve a reporting problem is an expensive way to solve the wrong problem.

Is Onetribe a replacement for POHODA? No. POHODA remains your system of record and your team keeps using it exactly as they do now. We read from it, never write to it. If you change ERP later, the reporting layer stays.

Is POHODA an ERP or accounting software? Both descriptions are defensible. POHODA covers ledger, invoicing, stock, fixed assets, payroll and cash sale, which is ERP scope for a small business. It does not carry the manufacturing and project depth of a system like Helios or Business Central, and it is not priced as though it does. STORMWARE’s own term — economic and information system — is the most accurate.

What database does POHODA use? It depends on the product line. The base POHODA line uses a file-server architecture on the MS Jet engine, storing data in .mdb files. POHODA SQL and POHODA E1 are client-server and store data in Microsoft SQL Server.

Can POHODA connect to Power BI? Yes. On POHODA SQL or E1 the practical route is a read-only extract into a governed model, with Power BI reporting on the model rather than on POHODA directly. Pointing Power BI straight at the tables works once and gets harder to maintain from there — the tables are transactional by design, and the definitions need to live somewhere. Reading this way does not slow POHODA down: we read incrementally on a read-only login, and on the base file-server line only ever from a controlled copy.

Can POHODA consolidate several companies? No — it holds one accounting entity per database, which is the right design for its core user. Consolidation is a layer above POHODA, and it is the most common reason multi-entity POHODA users come to us.

Does POHODA have an API? Yes — an XML API, exchanged over HTTP through POHODA mServer, built into the application. It is designed for local-network use, so remote integration needs a secured route in. It is a document-exchange interface rather than a bulk analytics one.

Is POHODA BI enough? For a single entity, with finance users comfortable in Excel, POHODA BI does real work and is worth using. Where it runs out is across entities and across systems — group definitions, cross-system reconciliation, and a model an AI assistant can query reliably. If POHODA is your only system and one company is your whole business, start there.

Official POHODA resources

• POHODA product overview — STORMWARE Czech Republic
• POHODA product overview — STORMWARE Slovakia
• pohoda.sk — Slovak product site
• POHODA XML API developer documentation
• System requirements, including SQL Server sizing
• eKasa in POHODA — Slovakia
• Kontrolný výkaz DPH in POHODA

Onetribe is not a STORMWARE partner or reseller. We build the governed data layer above your ERP, whichever ERP that is.

Next steps

• Every source system we connect — the series hub, with the full matrix
• How we consolidate any combination of ERPs — group reporting
• Why your ERP doesn’t govern your data — the cross-system layer, in detail
• Discuss your POHODA estate — free assessment