Omega — A Database per Company, per Accounting Year

Omega runs the books of a large share of Slovak companies, and an even larger share of the practices that serve them. It has earned that. KROS has tracked one legislation closely for three decades from an office in Žilina, and the result is an application where the DPH return reconciles, the kontrolný výkaz ties to documents, and legislative changes arrive in an update before the deadline does. For the work Omega is scoped to, there is very little friction left in it.

At a glance

What Omega is

Omega is a Windows application that keeps the double-entry books of a Slovak company. Where international products localise, KROS builds native: the Slovak chart of accounts (účtový rozvrh), Slovak VAT with the kontrolný výkaz, the statutory filings exported as XML straight into eDane. Not adapted for the market, written for it, by a company that has done nothing else since 1995.

The work is organised the way a Slovak accountant organises it. Accounting documents, invoicing, bank, cash, stock, fixed assets, travel orders. Each posts to the ledger under the rules of the one jurisdiction the product serves, and the support line speaks the accountant’s language in both senses.

The scope is deliberately narrower than an ERP’s, and priced accordingly. Omega does not run manufacturing or a supply chain, and does not claim to. Where a KROS customer needs that, KROS sells ONIX, its ERP — which is worth knowing about because ONIX has no general ledger of its own and posts into Omega. The two are complementary rather than a ladder.

The editions, and the choice underneath them

Most buyers pick an edition on how many companies they keep and whether they need the double-entry ledger at all. Two other things follow from that choice, and they matter more for reporting than the price does.

The database format is the decision worth understanding. KROS is direct about it: a new company is always created in Access format, and SQL is something you convert to. The architectural difference, in KROS’s own words, is that on SQL the Omega clients send requests to a server which alone reads and writes the database, whereas on Access every running copy of the program works directly with the whole database file.

That produces limits KROS documents plainly. Access warns at around 90 MB and becomes impractical near 100 MB. Four concurrent users is the ceiling; a fifth requires SQL. Remote and wide-area users require SQL. And synchronised cloud storage — NAS, OneDrive, Dropbox, Google Drive — is not permitted for Omega databases at all, for reasons that will be obvious to anyone who has watched a file-locking system meet a sync client.

For a client where reporting matters, the SQL module is usually the cheapest useful thing they can buy. It is a licence change rather than a migration, and it makes everything downstream faster, cleaner and invisible to the people using the system.

Then there is the year. Each accounting year of each company is its own database, created at rollover. This is the single most consequential fact about working with Omega data and it is the reason for this article’s title. A practice with eighty clients and five years of history is administering something on the order of four hundred databases, each attached separately, each opened one at a time. Master data does not span them: the chart of accounts, the partner list and the SZČP codes belong to a company-year, not to a company.

Who Omega fits

Accounting and tax practices. This is Omega’s centre of gravity, more so than POHODA’s. KROS says as much in its own edition naming, and the workflows — document entry, VAT runs, closings — are tuned for exactly that repetition across many client books. Increasingly, practices are also the ones asking whether they can offer clients a management view on top of books they already keep well.

Established Slovak companies on double-entry books. Stock, invoicing, fixed assets, a stable finance routine, Omega plus OLYMP covering the statutory ground completely. There is usually no reason to change any of that.

Companies whose accountant chose it. A large share of Omega books are kept externally. The company sees invoices and a monthly PDF; the practice sees Omega. This matters for reporting more than it first appears, because the data exists, is well kept, and the company that owns it has often never looked inside.

Slovak entities inside international groups. The group runs Business Central or SAP; the Slovak subsidiary runs Omega because the local accountant does, and because the Slovak statutory obligations are met without anyone having to think about them. Every choice is locally correct. The view across them belongs to nobody, and this is the context in which Omega most often reaches us.

Groups that grew sideways. Two Slovak s.r.o. entities, a Czech sister company on something else, a trading arm added by acquisition. Each set of books is sound. What does not exist anywhere is the combined picture.

What Omega holds — and why it is good material

Before the reporting question, the asset.

Statutory obligation is a data-quality mechanism. Books that have to produce a reconciling DPH return and a kontrolný výkaz that ties to documents stay internally consistent, month after month and year after year. An Omega database kept by a competent practice is complete to document level and stable across time. Against what we more often meet — spreadsheet bookkeeping, half-configured cloud tools, a decade of manual journals — that is a strong starting point, and the data quality of any reporting layer is bounded by what feeds it.

The dimensions are better than most users exploit. Omega carries four, and KROS treats them as one unit abbreviated SZČP: cost centre (stredisko), job (zákazka), activity (činnosť) and employee (pracovník). They are hierarchical, so a code can sit under a parent and roll up. They can be defaulted per trading partner. They can be attached to a posting template (predkontácia) so that routine documents carry them without anyone remembering. And there is a setting that makes the program warn on save when they are left empty, which is the difference between a dimension scheme that survives a busy month-end and one that does not.

Where they have been filled with discipline, they carry most of what real profitability analysis needs. Where they have been filled partially, they are still the right place to start enforcing structure going forward. What Omega then does with them is narrow: two reports reach them, a simple SZČP income statement and the analytical ledger book. The data is richer than the reporting built on it.

What sits outside Omega’s scope

Omega is scoped to one company’s books for one accounting year, and for its core user that boundary is correct. Three things sit outside it.

The view across companies, and across years. Because every company-year is a separate database, there is no shared chart of accounts, no consolidation, no intercompany matching, and no report that spans two of them. This is not an inference from silence: KROS once shipped consolidated balance sheet and P&L print layouts and withdrew them for periods from 2005 onward, and nothing replaced them. Even a single company’s own three-year trend is a question Omega cannot answer from inside, because the three years are three databases. Currency translation and statutory consolidation happen somewhere else by definition.

The view across systems. Whether e-shop revenue matches the ledger, whether payroll in OLYMP matches headcount in the HR file, whether the CRM pipeline squares with invoicing. This is worth saying plainly: no ERP does this. Not Omega, 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 Slovak statutory chart answers the tax authority’s questions and answers them well. Which customers make money after the cost of serving them and what did this job cost against quote are different questions in a different structure. Omega’s reporting serves the books: statutory statements, the ledger, the analytical book, printed layouts you can edit as Excel templates. There is no dashboard, no charts, and no BI product — KROS discontinued the one it had, and the BI in its range today lives in ONIX rather than in Omega. None of that is a gap in the product. It is a data model question, and a data model is not what an accounting application is for.

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

How we elevate it

We read Omega through a read-only login against the Microsoft SQL Server database. That makes the SQL module the practical prerequisite for reporting on Omega, which is the honest version of the edition advice above: on the Access format there is no server to read from, and KROS publishes no schema, no data dictionary and no general API — its Konektor API is an e-shop integration that reaches nothing an accountant would call accounting. The SQL module is a licence change rather than a migration, and it is usually the cheapest useful thing an Omega client can buy.

One Omega-specific detail we build for from the start: the database changes at every year rollover, so the connection has to follow the year rather than break at it. That is handled in our own pipeline as a matter of course, the same way we handle POHODA’s line — it is routine work on our side and nothing your team has to think about.

Read-only throughout, incrementally, nothing written back, and no change to how the system performs for the people using it.

What happens next is the Omega-specific work.

A management chart of accounts alongside the statutory one

The účtový rozvrh keeps doing its job. We map it once into a second structure built for management questions: revenue by what the company actually sells, cost by what management actually controls, margin at the level decisions are actually made. Analytical accounts that were opened for one reporting need and never retired get folded into it rather than argued about. Mapped once, versioned, owned by a named person, reviewed at each close so it does not drift. The design problem underneath is worth reading separately: chart of accounts architecture .

SZČP, put to work

We audit how consistently strediská, zákazky, činnosti and pracovníci have actually been filled across history, company by company and year by year, and show you where the gaps are before they become an argument about a number. Then we agree the rules going forward and encode them where they will hold: default dimensions on partners, SZČP carried on the posting templates, and the warning setting switched on so an empty dimension is caught at entry rather than at close. Where a client has used them well already, this step is quick and the payoff is immediate. And because the same codes are the join key OLYMP uses when payroll posts into the ledger, getting them consistent makes people cost land next to the P&L it belongs to.

One continuous history, across every company and every system

This is the work that is specific to Omega above all others. Each company-year database becomes one input to a common model, and the years are stitched back into a continuous series — so a three-year trend, a rolling twelve months, or a like-for-like comparison against the same month last year becomes an ordinary question rather than an export-and-align exercise. Each company then sits beside the others, and beside a POHODA database, a group’s Business Central, an e-commerce platform or an OLYMP payroll export, all producing the same standardised output. Group reporting in any currency, reconciliation across systems, and drill-down from a consolidated total back to the Omega 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. 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

• 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?
• How has revenue moved over three years, without anyone exporting three databases and aligning them by hand?
• What is group EBITDA in EUR when the Slovak entity is in Omega and the parent is on something else?
• Why did overhead move this month, ranked by the cost lines that moved most, against budget and against last year?
• Which companies are carrying empty SZČP codes, on which accounts, before the close rather than after it?
• What does the practice-kept ledger say today, rather than in next month’s PDF?

Every one of these is answered from data Omega 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 Omega client the connection is agreed access and the first governed reports follow inside a week. A full build — management chart of accounts, SZČP repair, several company-years stitched together, consolidation, 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, a read-only SQL login, and a conversation about what the numbers should mean. If the books live at a practice, the practice joins that conversation. It goes better with them than around them, and in our experience they are usually glad to be asked.

What does not change: Omega stays your system of record. Your accountant, internal or external, works exactly as before. 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

LIV-EPI — engineering design, 20+ concurrent projects. One of Slovakia’s largest engineering design firms, working in energy and industrial projects, keeps its books in Omega. Its project forecasts lived in dozens of spreadsheets that had to be reconciled against the ledger by hand every week. We connected Omega directly, built P&L, balance sheet and cash flow from the accounting data, and put a structured projection model on top that stays in step with the books. The result: 20+ projects tracked with integrated profitability, and manual Excel reconciliation eliminated — management moved from reporting on what happened to planning what comes next.

Read the full case

When Omega is eventually replaced

Companies grow out of Omega’s scope the way they grow out of any accounting-led system, usually for operational reasons rather than accounting ones, and usually toward Business Central or a mid-market ERP. Worth noting that moving up inside the KROS range is not one of those exits: ONIX sits alongside Omega and posts into it rather than replacing it.

Because the governed layer sits above the system, only the connection changes when a move does happen. The data model , the reports and the consolidation logic carry through, and the migration itself gets easier, because the new system’s numbers can be proved against the old system’s from day one — and the reporting history survives the change instead of 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.

Omega in the regional context

Omega 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 becomes an entity in the same governed model, which means the accounting-software decision can be made on local 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 Omega to get proper management reporting? No, and for a Slovak-legislation book we would usually advise against it. Keep Omega for what it does exceptionally well — statutory correctness, DPH, the kontrolný výkaz, clean transaction capture — and build the reporting layer above it. Replacing a working accounting system to solve a reporting problem is an expensive way to solve the wrong problem.

Is Onetribe a replacement for Omega? No. Omega 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 accounting software later, the reporting layer stays.

What database does Omega use? Microsoft Access by default — every new company is created in that format — with Microsoft SQL Server available as a separately licensed module and the only client-server option. The practical differences are covered above: Access has a size ceiling around 100 MB, a four-user limit, and no support for remote users or synchronised cloud storage. Because we read through a read-only SQL login, the SQL module is also the practical prerequisite for reporting on Omega.

Our books are kept by an external accounting practice. Does that work? Yes, and it is one of the most common Omega setups we see. The practice keeps working in Omega exactly as before, the layer reads the books, and you get the management view. Several practices we work with have started treating it as something they can offer their own clients.

Can Omega connect to Power BI? Not directly, and KROS does not publish a connector. The practical route is a read-only extract into a governed model, with Power BI reporting on the model rather than on Omega — which is the right architecture anyway, because the definitions need to live somewhere that survives a year rollover and a version update. Reading this way does not slow Omega down: we read incrementally, and nothing is written back. KROS also lists a third-party add-on, BIPower, as supporting Omega. It is a recent addition and neither party documents how it reads the data, so we cannot tell you more than that it exists.

Can Omega consolidate several companies? No. It holds one company’s books per accounting year per database, which is the right design for its core user, and KROS withdrew the consolidated print layouts it once had. Consolidation is a layer above Omega — and because the same architecture separates the years, so is any multi-year view of a single company. Between them, those two are the most common reasons Omega users come to us.

Does Omega have an API? Not a general one. KROS publishes a Konektor API, but it is an e-shop integration that exchanges stock, services and orders, and it reaches nothing in the ledger. What is documented for accounting data is a fixed-structure text export and import, a per-screen Excel export, and XML for statutory filings. KROS’s ERP, ONIX, does have a web API; Omega has no equivalent.

What about payroll? Payroll lives in OLYMP, KROS’s separate payroll product with its own database. It reaches Omega as an export and import that posts the payroll journal, and it depends on the accounts and the SZČP codes matching on both sides — which is one more reason to get those codes consistent. The layer reads both, so people cost lands next to the P&L it belongs to.

Official Omega resources

• OMEGA — product page
• Features, including work in a network and multi-company
• Imports and exports
• Recommended configuration and system requirements
• When to move to SQL — the architecture page
• Strediská, zákazky, činnosti a pracovníci (SZČP)
• Filing the DPH return and kontrolný výkaz
• eKasa in Omega
• Príručka pre používateľov OMEGA

Onetribe is not a KROS partner or reseller. We build the governed data layer above your accounting system, whichever system that is.

Next steps

• Running POHODA well — set up for the reports you’ll want later — the entry-time habits that decide what you can report on, most of which apply to Omega too
• 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
• Do you need a new ERP, or just the data already inside it? — the decision, honestly
• Discuss your Omega setup — free assessment