HELIOS — Production and Projects on One Ledger

HELIOS runs a large share of Czech and Slovak mid-market manufacturers, distributors and service businesses, and it has earned that position. It reaches materially further than the accounting-led systems in these markets: production planning, capacity, project and service costing are in the product rather than bolted on. Doing that while tracking two tax codes and two payroll regimes is a substantial ongoing commitment, and Asseco Solutions has met it.

At a glance

What HELIOS is

HELIOS is an integrated enterprise information system that runs the financial, commercial and operational books of a company from a single Microsoft SQL Server database. Asseco Solutions calls it a podnikový informační systém, and unlike the accounting-led products in these markets it is genuinely built outward from operations as well as from the ledger.

The practical difference shows up in what the modules cover. Alongside accounting, VAT, banking, receivables, fixed assets and stock, HELIOS iNuvio carries technical production preparation — bills of material, operations, workplaces, tooling and production documentation — with costings, material requirements, planning calendars and capacity planning built on top. Shop-floor confirmations come back from production terminals and, where configured, from the machines. Service, transport, quality management, document management and workflow are modules of the same system rather than separate products, posting to the same ledger.

Localisation is the other half of the achievement, and it is harder than it looks. The Czech build handles Czech VAT, the VAT control statement (kontrolní hlášení) populated directly from the accounting journal, and electronic filing through EPO or a data box. The Slovak build handles Slovak DPH, the VAT control statement (kontrolný výkaz DPH) including its supplementary form, and eKasa for cash takings. Payroll is maintained separately for each jurisdiction. Asseco even maintains two documentation sets, Czech and Slovak, for the same product. Keeping two tax codes, two payroll regimes and a production planning engine correct at the same time is a serious ongoing commitment.

For a company that manufactures or assembles something, runs jobs or projects, employs enough people that payroll matters, and has to be exactly right with two tax authorities — HELIOS is a well-judged product. It competes with Business Central rather than with the small-business accounting systems, and it is priced and implemented accordingly.

The product lines

Most buyers choose a line on company size and process complexity — Asseco is explicit that the decision follows process complexity rather than headcount. It is worth understanding what else the choice determines.

Two points of history matter, because the names changed and the old ones are still in circulation. HELIOS Orange became the iNuvio edition and is now sold as HELIOS iNuvio; the Orange documentation wiki has been closed and redirects to the iNuvio one. HELIOS Green has been succeeded by HELIOS Nephrite, a new platform rather than a new version, with migration run as a multi-year programme that preserves customer customisations. If your internal documentation still says Orange or Green, the system underneath is almost certainly on a current line — and if it is not, the migration path is the vendor’s own and well travelled.

For reporting purposes the line barely matters. Every current HELIOS line puts its data in Microsoft SQL Server, so the extraction story is the same from Easy through to Nephrite.

Who HELIOS fits

Discrete manufacturers and assemblers. Bills of material, routings, work centres, capacity, shop-floor confirmation and production costing, all posting into the same ledger that produces the VAT return. This is the profile HELIOS was built for and it is the reason a company chooses it over an accounting-led system.

Project and contract businesses. Construction, engineering, installation, systems integration — anywhere revenue and cost attach to a job (zakázka) rather than to a month. HELIOS carries the job as a first-class dimension through purchasing, stock, production, payroll and the ledger, which is exactly what makes job-level profitability analysis possible.

Distributors and wholesalers with real stock complexity. Multiple warehouses, pricing structures, barcodes, automatic replenishment orders, e-commerce feeds. The stock module is deep and joined to purchasing and sales rather than sitting beside them.

Service and field-service organisations. The service module, the vehicle dimension and the transport module together cover a fleet-and-technician business more completely than most systems at this price point do.

Groups that grew sideways. A Czech manufacturing company on HELIOS iNuvio, a Slovak sales entity on something else, a Hungarian or Polish subsidiary on a third system. Each entity chose sensibly for its own jurisdiction. What nobody owns is the view across them, and this is the context in which HELIOS most often reaches us.

What HELIOS holds — and why it is good material

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

HELIOS data is disciplined data. Statutory obligation enforces a rigour that voluntary data entry never does: the VAT return has to reconcile, the control statement has to tie back to documents at line level, the ledger has to balance. A HELIOS database kept properly by a competent accounting team is complete to document-line level and stable across years, which is the precondition for everything else. That is the data quality baseline.

What makes HELIOS unusually good material is the layer above that baseline. Transactions carry four accounting dimensions — cost centre (středisko), job (zakázka), cost category (nákladový okruh) and vehicle (vozidlo) — and those dimensions run through purchasing, stock, sales, payroll and the ledger rather than stopping at the journal. Payroll cost can be split across all four. Production adds a second dimension set on top: bills of material, operations, planned and actual costings, capacity, and confirmations that tell you what was actually consumed against what was planned.

Very few mid-market systems in these markets hold that much structured operational detail next to a statutory-grade ledger, which means the raw material for real margin analysis is already in the database. The constraint is rarely that HELIOS holds too little. It is that the dimensions were filled in inconsistently over the years, or that the operational detail and the financial result have never been put on the same axis.

What sits outside HELIOS’s scope

HELIOS is scoped to one accounting entity per database, and that scope is a design decision rather than an omission. For its core user — one company, one jurisdiction, one integrated set of operations — it is the right boundary, and it is the reason the system performs the way it does.

Three things sit outside it.

The view across entities. One database per accounting entity means a group of five companies is five HELIOS databases, each with its own chart of accounts , its own dimension code lists and its own numbering. Asseco does ship a Konsolidace module, and it is a real one — it holds its own separate consolidation database, imports accounting data from the subsidiaries and performs eliminations of intercompany balances and financial investments, consolidation differences and their amortisation. That is statutory consolidation done properly, on a periodic import cycle, for entities that are themselves on HELIOS. A daily management group view across mixed systems is a different job, and currency translation across a group sits outside the module’s remit.

The view across systems. HELIOS has no opinion about whether revenue in your e-commerce platform matches revenue in the ledger, or whether the hours in your time-tracking tool match the hours costed to the job. This is worth saying plainly: no ERP does this. Not HELIOS, 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 .

A single governed place where definitions live. This is the subtle one, and it follows from how capable HELIOS is rather than from any shortfall. Users can build their own browse views, add external attributes, write SQL views, define contingency tables and build OLAP cubes on a separate Analysis Services database. Finance teams do all of it, and they are right to. The effect over a few years is that the definition of gross margin, or of an active customer, ends up encoded in a dozen report objects maintained by different people, with no single version a dashboard or an AI assistant can be pointed at. That is a data governance question, not a software one.

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

How we elevate it

We have connected HELIOS in both its Czech and Slovak builds, in single entities and in groups running HELIOS alongside other systems.

Getting the data out is the routine part. Our default is a direct read-only SQL connection to the Microsoft SQL Server database, read incrementally, on a login that has select rights and nothing else. Where a client prefers to keep the database closed, HELIOS iNuvio exposes a documented SQL API of stored procedures and views, and a REST interface through the eServer module, which keeps an external system off the database entirely. Nephrite adds its own service layer over the same engine. On ERPORT or partner hosting, the route is agreed with whoever operates the environment. Read-only throughout. Nothing is ever written back to HELIOS, and users notice no difference in how the system performs.

What happens next is the HELIOS-specific work.

The four accounting dimensions, audited and put to work

Středisko, zakázka, nákladový okruh and vozidlo are where management analysis lives in HELIOS, and they are only as good as the discipline behind them. We audit how consistently each has been used across history — by module, by document type, by year — and produce a plain map of where the coverage is solid and where it is thin. Then we agree rules for filling them going forward, encode those rules as validation in the governed layer, and report the exceptions daily so the discipline holds instead of decaying. Where a client has used the dimensions well, this step is quick and the payoff is immediate. Where the code lists have drifted — three cost centres for one department, jobs left open for years — the repair happens in the layer, so nobody touches history in HELIOS.

Production and project cost, joined to the financial result

This is the work that distinguishes a HELIOS engagement from an accounting-led one. HELIOS holds planned costings, material and capacity requirements, confirmations and actual consumption in the production and job modules, and it holds the financial outcome in the ledger. The two are related but not identical, and the difference between them is where the margin conversation actually happens: planned against actual on a job while it is still running, work in progress, absorbed against incurred overhead, scrap and rework, the labour cost payroll booked against the labour cost the routing assumed. We build the data model that puts operational and financial cost on the same axis, with a documented reconciliation back to the ledger — so a gross margin figure by product, job or customer survives being challenged in a board meeting.

One model across every HELIOS database and every other system

Each HELIOS database becomes one entity in a common model, sitting alongside Business Central, POHODA, 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 HELIOS document that produced it. Where the Konsolidace module already does the statutory job, the governed layer does not replace it: it runs the management view daily beside it, on a group budget and one set of definitions, and the two should agree.

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 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 HELIOS client can ask afterwards.

• What did that job cost against what we quoted, while it is still running — labour, material, subcontract and overhead, in one number?
• Which products actually make money once real production cost, scrap and rework are loaded, not just standard cost?
• Where is capacity going, and what is the financial cost of the work centres that are idle?
• What is group EBITDA in EUR, when the Czech and Slovak entities sit on different charts of accounts?
• Which customers are profitable after delivery, service and warranty cost?
• How much cash flow is tied up in work in progress and in stock that has not moved in six months?

Every one of these is answered from data HELIOS 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 HELIOS client, 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: HELIOS 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.

When HELIOS is eventually replaced

Some HELIOS clients change system at some point, usually because a group has decided to standardise rather than because anything went wrong — typically onto Business Central or a larger platform. Others move within the family, from Easy up to iNuvio or from iNuvio to Nephrite. It is the same question in a smaller form.

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.

HELIOS in the regional context

HELIOS 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 HELIOS to get proper management reporting? No, and we would usually advise against it. Keep HELIOS for what it does well — statutory correctness, VAT, local compliance, production and job control, 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, and it is a question worth answering carefully .

Is Onetribe a replacement for HELIOS? No. HELIOS 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 HELIOS an ERP, and is iNuvio the same thing as HELIOS Orange? HELIOS is an ERP in the full sense — production planning, capacity, project and service costing alongside the ledger, which is more than the accounting-led systems in these markets attempt. And yes: HELIOS Orange became the iNuvio edition and is now sold as HELIOS iNuvio, while HELIOS Green has been succeeded by HELIOS Nephrite on a new platform. The older names are still in circulation in internal and partner documentation. If yours says Orange or Green, the current equivalent is iNuvio or Nephrite.

What database does HELIOS use? Microsoft SQL Server, on every current line. HELIOS iNuvio is a Windows client that reaches the database through the Microsoft SQL Native Client over ODBC, using Shared Memory, Named Pipes or TCP/IP. HELIOS Nephrite is multi-layer, with a .NET application server above the same engine. It runs on SQL Server Express at the small end, though the analytical features benefit from a full edition.

Can HELIOS connect to Power BI? Yes. The practical route is a read-only extract into a governed model, with BI reporting on the model rather than on HELIOS directly. Pointing Power BI straight at the tables works once and gets harder to maintain from there — HELIOS tables are transactional and heavily normalised by design, and the definitions need to live somewhere durable. Reading this way does not slow HELIOS down: we read incrementally, on a read-only login, and on a busy production database we schedule around the working day.

Can HELIOS consolidate several companies? Partly, and it is worth being precise. HELIOS holds one accounting entity per database, so a group is several databases. Asseco’s Konsolidace module works across them: it maintains its own consolidation database, imports the subsidiaries’ accounting data and runs eliminations of intercompany relationships, financial investments and consolidation differences. For a group whose entities are all on HELIOS and whose need is a statutory consolidated statement, that is a proper tool and you should use it. What sits outside it is the daily management view across a mixed estate — different ERPs, different currencies, one set of definitions, drill-down to source. That is the most common reason multi-entity HELIOS users come to us.

Does HELIOS have an API? Yes, and more than one route. A documented SQL API of stored procedures and views inside the HELIOS database, callable directly or through a linked server; a REST API exposed by the HELIOS iNuvio eServer module, which isolates the external system from the database; standard XML import and export; and web services on Nephrite. For analytics we normally prefer a direct read-only SQL connection, because the APIs are built for document exchange and transactional integration rather than bulk historical extraction.

HELIOS has its own Business Intelligence — why would we need anything else? Because they solve different problems, and the HELIOS one solves its problem well. The built-in Business Intelligence module gives you dashboards and widgets over your own data, inside the system your users already know, with a standard set of views prepared by the vendor. On top of that, HELIOS supports OLAP cubes defined on a separate Microsoft SQL Server Analysis Services database — a genuinely capable analytical structure, and more than most systems at this level offer. If HELIOS is your only system and one company is your whole business, start there. Where it runs out is at the edges of its scope: across entities, across systems, and in the fact that definitions end up living in individual report objects and cube definitions rather than in one governed data layer that reporting, planning and an AI assistant all read from. That last point decides whether the numbers in two different meetings agree. On AI: Asseco applies machine intelligence inside the product — telemetry-driven suggestions and process automation — but publishes no conversational assistant and no MCP endpoint for HELIOS. An AI connection is built on the SQL API or the eServer surface, and what it reaches is transactional structure; the definitions an assistant needs live in the governed layer — why that matters .

Official HELIOS resources

• HELIOS product overview — Asseco Solutions Czech Republic
• Asseco Helios iNuvio — Asseco Solutions Slovakia
• HELIOS iNuvio documentation wiki — Czech
• HELIOS iNuvio documentation wiki — Slovak
• Technical requirements for HELIOS iNuvio
• HELIOS Nephrite
• HELIOS Easy
• ERPORT — the HELIOS cloud platform
• HELIOS Business Intelligence

Onetribe is not an Asseco 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 HELIOS estate — free assessment