Our POHODA article makes an argument we stand behind: the system holds cleaner, better-structured data than most systems we connect, and the right move for most of its users is to keep it and build on it. This article is about the quiet condition inside that argument. POHODA data is good when POHODA is run well — and whether it is run well is decided at the moment someone enters a document, months or years before anyone asks for a report.
We see the difference constantly. Stahlmann came to us with — as their case study puts it — good basic processes in place, and the engagement was analytics from the first week: real-time profitability across 20,000+ SKUs and three sales channels. Other engagements begin with a dimension audit and a repair phase, because the same fields that could have carried the analysis were filled inconsistently for years. Same system. Different habits.
These are the habits. None needs new software, a project, or our involvement. Most are cheaper than the alternative from the first month. They are POHODA-specific cousins of the practices that hold on every ERP — here with the Slovak and Czech specifics spelled out.
Respect the účtová osnova — extend down, never sideways
The Czech and Slovak chart of accounts gives every account number a meaning before you add any of your own: the first digit places it in the statutory structure, and everyone — your accountant, your auditor, the tax authority, and any reporting tool — reads that structure without being told. In our own models, the statement classification of every POHODA account is derived computationally from that first digit. It is free metadata. The worst thing you can do to it is be creative.
The practice: keep the synthetic accounts standard and put your granularity in the analytical suffix. Revenue split by line of business belongs in analytics under the standard revenue synthetics, not in inventive top-level numbers. Cost detail belongs under the standard cost classes. Named consistently, the analytical layer becomes the first draft of your management view.
And then stop expecting the chart to do the second job. Management questions — margin by channel, cost by what you control — are answered by a mapping over the accounts, not by more accounts. The statutory chart keeps its statutory shape; the management structure is designed separately and maintained as a table. Companies that try to encode management reporting into the chart itself end up with a chart that serves neither purpose and a migration problem later.
Střediska: one list, one owner, filled at entry
Cost centres (střediska, strediská) are where profitability analysis will live when you want it. They are also the field we most often find half-filled.
Four rules, none of them expensive. One list, agreed once — departments or activities, not a mixture of both plus three abbreviations for the same warehouse. One owner — a named person who approves new codes, because cost centre lists don’t decay from malice, they decay from three people each solving today’s problem. Filled at entry — the document carries its středisko when it is created, not reconstructed at close from memory; a dimension added retroactively is an estimate wearing a code. Reviewed quarterly — retire dead codes, merge duplicates, and check coverage: what share of costs this quarter carried no středisko at all?
POHODA will not force any of this on you — no mid-market system will. Which is exactly why the habit matters: the discipline either lives in your entry routine, or it has to be rebuilt later in the layer above, against history that can no longer answer questions.
Zakázky: anything with a start and an end
Jobs (zakázky) answer a different question than cost centres: not whose cost, but which piece of work. Use them for anything with a beginning, an end and a result someone quoted — an order, a project, a contract, an event.
Two habits decide their value. Open a zakázka when the work starts and put every related document on it — the sale, the purchases, the internal costs. And close it when the work closes. Jobs left open for years are the second most common thing our audits find, and each one quietly absorbs costs that belong somewhere else. A clean zakázka register is job-level profitability waiting to be read; a dirty one is noise wearing structure.
If you use činnosti as well, give each of the three dimensions a distinct question to answer — who, which work, what kind — and write those three definitions down. One sentence each is enough. Ambiguity between dimensions, not missing data, is what usually makes them unreadable later.
Documents behind every number
POHODA’s data quality argument rests on the document chain: the VAT return ties to documents, the ledger balances, everything traces. Keep that chain intact where the system gives you room not to.
In practice: nothing booked through internal documents (interné doklady) where a source document exists — an invoice booked as an internal entry is invisible to every document-level analysis that comes later. Credit notes (dobropisy) linked to the invoices they correct, not floating free. Advance invoices (zálohové faktúry) resolved promptly into their tax documents rather than left half-settled across a period boundary — unresolved advances are the single most common source of “invoiced versus booked” confusion we untangle. Bank items matched to documents, not parked. The test is one question: can today’s revenue figure be decomposed back to documents, today, without a spreadsheet?
One database per entity — don’t fight the boundary
POHODA holds one accounting entity per database, and the temptation arrives with growth: a second brand booked as a “division” inside the same books, or a second legal entity’s transactions mixed in “so we can see them together”. Resist both. The single-entity boundary is what keeps each set of books statutorily clean, and the group view genuinely does not belong inside the system — it belongs above it , where entities on POHODA can sit next to entities on anything else. TEPEDE runs eight entities across six countries into one daily view; it works because each set of books underneath is exactly one entity, kept clean.
If a second entity is coming, give it its own database on day one and register the intercompany relationships as a habit — tag the cross-entity invoices consistently, and later elimination becomes a filter rather than a hunt.
Currency and rates, maintained in the system
If you invoice or purchase in foreign currencies, let POHODA maintain the official rate list automatically rather than typing rates by hand, and book the closing revaluations the legislation expects. The principle is the same everywhere: capture the transaction currency and rate at the transaction, and translate to your reporting currency once, consistently, in one place — not per report. Casual rate habits are invisible until the first group report, and then they are the whole meeting.
Plan on the structure you book on
When budgeting time comes, build the plan on the same accounts and the same střediska you book on — not in a spreadsheet whose rows were invented for the budget. Plan and actual in the same shape is what makes variance analysis a comparison instead of a translation exercise, and it is what lets a forward view sit in the same model as your actuals rather than becoming a separate annual project. If the plan must live in a spreadsheet, keep its mapping to the chart formal — one table, owned and versioned — rather than in the head of whoever built it.
The technical hygiene
A short list, mostly set-and-forget. If reporting matters, the line matters: the SQL and E1 lines put the data in Microsoft SQL Server, where a reporting connection is incremental, invisible to users and independent of the application — the base file line works, but analytics runs from copies and schedules. The step up usually pays for itself the first time reporting becomes daily. Read-only credentials for anything analytical — nothing that reads your books should be able to write to them. Stay current with releases — POHODA’s legislative updates are the product’s core value; running old versions forfeits it. Run the maintenance the product provides and archive closed years on the vendor’s mechanism, not by improvisation. And if you connect operational integrations through mServer’s XML interface — an e-shop, or lately an AI assistant, where some caution is warranted — give each integration its own user, so the audit trail can tell them apart.
What it looks like when it’s done
A company that runs POHODA this way is a pleasure to build on, and the difference is measured in weeks, not percentages. The connection is a read-only login; the first governed reports follow inside a week; the dimension audit comes back short; and the engagement spends its time on analysis — margin by channel, job profitability, a forward view — instead of on repair. That is the Stahlmann pattern: good basic processes first, then analytics that could trust them, then growth decisions made on evidence .
A company that hasn’t run it this way is not disqualified — the layer can repair most of it, definitions can be rebuilt, and history can be mapped. But the repair is paid for once either way, and it is cheaper to never need it. Every practice on this list is decided at a keyboard, today, by whoever enters the next document.
If you want to know which side of that line your books are on, that is exactly what a diagnostic is for .