enova365 — Payroll and Ledger in One System

enova365 sits in the middle of the Polish mid-market, and it has earned that position. It is properly localised, maintained against a tax and labour code that moves every year, and modular enough that a company can buy what it needs and add the rest later. It also holds something most systems in this series do not: the full payroll record, in the same place as the ledger.

At a glance

What enova365 is

enova365 is a business management system that runs the financial, commercial and personnel records of a Polish company. Soneta describes it as an ERP, and the label fits: ledger, tax book, trade and stock, fixed assets, CRM, production, project budgeting and payroll are all first-class modules of the same application, sharing one data model and one database.

The architecture is three-tier — database, business logic, user interface — with Microsoft SQL Server underneath and .NET above it. The same installation is reachable through a Windows client, a browser and a mobile interface, and Soneta has kept the platform current: .NET 8, Windows or Linux hosting, container images, OpenTelemetry. That matters practically as well as technically. The data sits in a mainstream database engine any reporting tool can read.

The other half of the achievement is legislative. enova365 files JPK_V7 and JPK_KR, handles the KSeF e-invoicing obligation that phased in through 2026 including the offline fallback when the tax authority’s API is unavailable, produces the full ZUS declaration set and the PIT-4R, PIT-11 and IFT series, and calculates PPK contributions. Polish payroll is among the most complex in the region — parallel contract regimes, contribution ceilings, a tax scale rewritten more than once in a decade, a mandatory pension scheme added on top — and keeping a payroll engine correct against it, inside a general ERP rather than as a standalone product, is a substantial ongoing commitment. Soneta has met it, year after year, and that is the clearest reason the product is chosen.

For a Polish company that needs to be right with the tax office and with ZUS, wants payroll and the ledger in one place, and prefers to add modules rather than replace systems as it grows, enova365 is a well-judged product. A lot of businesses should stay on it for a long time.

The three licence tiers

Most buyers choose a tier on headcount and budget . It is worth understanding what else the choice determines, because the tier — not the module list — decides how much of the data is usable for management analysis.

Two things follow from the tier map Soneta and its partners publish. The gold tier is where reporting gets easier, because cechy — user-defined attributes attachable to almost any object — are what let a business tag its own dimensions onto transactions the statutory chart of accounts was never going to describe. And moving up a tier is a licence change, not a migration project: nothing is re-implemented and nobody is retrained.

Modules sit across the tiers, and the self-service portals (pulpity) push a slice of the system out to employees and managers — which matters for reporting, because HR data is then captured at source rather than typed in later.

Who enova365 fits

Polish SMEs with real payroll complexity. Fifty to five hundred people, mixed contract types, shift patterns, absence rules, PPK. This is the profile enova365 serves best. What these companies want next is usually not a different ERP — it is a management view of the data enova365 already holds correctly.

Companies that grew module by module. A business that started with Kadry Płace, added Księga Handlowa two years later, then Handel, then CRM. The system accumulates a broad record without anyone having planned it as a reporting asset. It usually is one.

Accounting and payroll practices. A practice may hold several hundred client databases in one installation and administer them centrally. Efficiency at that scale is a genuine strength, and practices are among enova365’s most concentrated users. Increasingly they are also the ones asking whether they can offer clients reporting on top of books they already keep well.

Manufacturers and project businesses. Produkcja, Projekty i budżetowanie and the analytical description together give a costing spine reaching from a purchase invoice to a production order. Where that is configured properly, the profitability analysis material is already there.

Groups that grew sideways. A Polish operating company, a second entity for a new business line, a small subsidiary abroad — enova365 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 enova365 most often reaches us.

What enova365 holds — and why it is good material

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

enova365 data is clean, and for the reason it is clean in every properly kept ledger: statutory obligation enforces a discipline that voluntary data entry never does. JPK_V7 has to reconcile. The KSeF number has to be on the invoice. The ZUS declaration has to tie to the payroll run. A database kept by a competent accountant is complete to document-line level and stable across years, and that data quality is the ceiling on everything built above it.

Three things make enova365 richer than the statutory minimum.

The analytical description (opis analityczny) is a controlling layer that attaches to documents anywhere in the system, at line level on trade documents, and can express an amount, a quantity, a duration, a date or free text. It is how a cost is assigned to a cost centre (miejsce powstawania kosztów, MPK), a project or another defined dimension. Used consistently, it carries most of what profitability analysis needs.

Attributes (cechy) extend almost any object with user-defined fields, and the BI module reads them at any level of a data model. Where a business has thought about its own dimensions, they are in here.

And then payroll, at the level of the individual pay component — contracts of employment and civil-law contracts, absences, working time, PPK contributions, employer cost by employee by month, in the same database as the ledger those costs post into. Very few systems in this series hold that combination.

What sits outside enova365’s scope

enova365 is scoped to the operational and statutory record of a company, or of a group of companies on one installation. That scope is a design decision, and for its core user it is drawn in the right place. Three things sit outside it.

The view across databases and entities. A single company is one database. From the gold tier a group can keep several companies in one database — genuinely useful, with shared master data and one place for the books of every entity. But group reporting is not the same job as multi-company bookkeeping. A common management chart of accounts , intercompany matching, currency translation and elimination logic belong above the transaction system. Where entities sit in separate databases that is obvious; where they share one, it is easy to mistake proximity for consolidation.

The view across systems. enova365 has no opinion about whether revenue in your e-commerce platform matches revenue in the ledger, or whether the headcount your operations team plans against matches the payroll run. This is worth saying plainly: no ERP does this. Not enova365, 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 (plan kont) is built to satisfy the tax office, and it does that job well. It is not built to answer which customers make money or what did that contract cost us in people. enova365’s own BI module does capable work here — pivot reports, KPI, BI panels, multi-database analysis, export to Power BI and Excel. What it is not is a semantic model a dashboard or an AI assistant can query across a group and across systems, with definitions that survive the person who wrote them.

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

How we elevate it

Getting the data out is the routine part. Four routes — direct read-only SQL against the Microsoft SQL Server database, our default; WebAPI, a REST interface with JWT tokens, Swagger documentation and native multi-database support; Integrator, which exchanges XML or JSON over SOAP or REST against schemas you define; and scheduled export as a fallback. Read-only throughout. Nothing is ever written back to enova365, and users notice no difference in how the system performs.

What happens next is the enova365-specific work.

People cost, against the P&L it belongs to

This is where enova365 pays off differently from every other system in this series. Payroll and the ledger are in one place, so employer cost can be joined to the revenue it produced without a monthly export, a spreadsheet and an argument about which headcount number is right.

What we build from it: cost per full-time equivalent by team and by month, on the same calendar as the P&L. Salary cost as a share of revenue, by cost centre and by entity. Absence and turnover read next to output rather than in an HR report nobody reconciles. Contract-mix cost — what the same work costs under an employment contract against a civil-law contract. Overtime attributed to the projects that caused it. Where Projekty i budżetowanie is in use, planned against actual people cost while a contract is still running.

Two disciplines make this safe. Payroll is read at the level the analysis needs and no lower, with access rules mirroring the ones already inside enova365. And the join between the payroll record and the ledger is reconciled every day, so a difference between what payroll calculated and what the ledger holds is a flagged exception rather than a discovery at year end — reconciliation doing its ordinary job on an unusually valuable join.

The analytical description and the attributes, put to work

Opis analityczny and cechy are where the management dimensions live. We audit how consistently they have been used across history — which documents carry an MPK, which projects were tagged, where a field was populated for eighteen months and then quietly abandoned. We surface the gaps, agree rules for filling them with the person who will own each one, and encode those rules as validation so the discipline holds rather than depending on memory.

Alongside that, a management chart of accounts is mapped against the statutory one. The statutory chart keeps doing its job; the second structure answers management questions — revenue by what you actually sell, cost by what you actually control, gross 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.

One view across every database, and every other system

Each enova365 database becomes one entity in a common data model — and where several companies share a database, each company becomes its own entity within it rather than being read as a total. That distinction is the difference between a group view and one large set of books. Those entities then sit alongside Business Central, an e-commerce platform, a payroll system in another country or a spreadsheet, all producing the same standardised output: group reporting in any currency, with drill-down from a consolidated total back to the enova365 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 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 an enova365 client can ask afterwards.

• What does each team cost us per head per month, and what did it produce?
• Which customers are actually profitable, after the people cost of serving them?
• What does the same role cost under an employment contract against a civil-law contract, across the group?
• What did that project cost against what we quoted, while it is still running?
• Why did overhead move this month, ranked by the cost lines that moved most?
• What is group EBITDA in EUR, when the Polish entities and the foreign one sit on different charts of accounts?
• Where does the reported number differ from the booked number, and why?

Every one of these is answered from data enova365 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 enova365 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: enova365 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

The pattern enova365 arrives in is almost always the same: the books are correct, payroll is correct, and nobody can put the two next to a group P&L without a week of spreadsheet work. One published engagement shows the shape of the answer, though it does not involve enova365.

TEPEDE — eight entities, six countries, six ERPs A CEE large-format printing group. 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 , and consolidation went from a 20-day monthly exercise to real-time. TEPEDE does not run enova365; it is cited as evidence of the mixed-system pattern.

When enova365 is eventually replaced

Some enova365 clients change system at some point, usually because a group has standardised across borders rather than because anything went wrong.

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: they can prove the new system’s numbers against the old system’s 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.

enova365 in the regional context

enova365 is one of several capable systems serving the Polish market. 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 is on the series hub .

Frequently asked questions

Do we need to replace enova365 to get proper management reporting? No, and we would usually advise against it. Keep enova365 for what it does well — statutory correctness, VAT and JPK, payroll, 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. Where a new system genuinely is the right call, we say so .

Is Onetribe a replacement for enova365? No. enova365 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 enova365 an ERP, or a payroll system with accounting attached? It is an ERP, and the payroll reputation is earned rather than misleading. Kadry Płace is what most buyers come for, but Księga Handlowa, Handel, Produkcja and Projekty i budżetowanie are full modules on the same platform and database, not satellites. The honest positioning is a modular mid-market ERP whose strongest module is the one most vendors sell separately.

What database does enova365 use? Microsoft SQL Server, across every tier and every deployment model — supported versions 2016, 2017, 2019, 2022 and 2025, Standard or Express. The architecture is three-tier: SQL Server, a .NET business-logic layer, and Windows, browser or mobile clients above it, with the server side running on Windows or Linux.

Can enova365 connect to Power BI, and does it have an API? Yes to both. enova365 ships WebAPI — a REST interface with JWT application and session tokens, Swagger documentation, dynamic controllers and native support for several databases at once — plus Integrator, which exchanges XML or JSON over SOAP or REST against schemas you define. The BI module exports models to Power BI and Excel directly. For reporting, the practical route is a read-only extract into a governed model, with BI reporting on the model rather than on enova365 directly — pointing Power BI straight at the tables works once and gets harder to maintain from there, because the tables are transactional by design and the definitions need to live somewhere. Reading this way does not slow enova365 down: we read incrementally on a read-only login, outside working hours where volumes warrant it.

Can enova365 consolidate several companies? Partly, and the distinction matters. From the gold tier it supports multi-company operation (wielofirmowość) — several companies in one database, with shared master data and central administration — and the BI module analyses across several databases at once. What it does not do is group consolidation in the accounting sense: a common management chart of accounts, currency translation, intercompany elimination, and the same definitions applied to systems that are not enova365. That is a layer above, and the most common reason multi-entity enova365 users come to us.

Payroll data is sensitive. How do you handle it? Read-only, at the level of aggregation the analysis needs, under the access discipline the source system already applies. enova365’s payroll module has a strict permission model over pay data and the reporting layer inherits that thinking rather than working around it — individual pay detail stays with the people already entitled to see it, and most reporting sits at team, cost centre and contract-type level. The layer is EU-hosted, aligned with ISO 27001 and GDPR, and data governance is written down rather than assumed. Nothing is written back at any point.

Is the enova365 BI module enough? For a single company, or a group whose entities all sit on enova365, with finance users comfortable building their own pivot reports — it does real work and is worth using. Configurable KPI, BI panels, multi-database analysis, employer-cost and turnover analysis, Du Pont, ABC/XYZ and export to Power BI and Excel is a broad range for a module inside an ERP. Where it runs out is where every vendor BI tool runs out: across systems that are not enova365, on group definitions that must hold when someone leaves, and on a model an AI assistant can query reliably. If enova365 is your only system, start there. On AI: Soneta applies AI inside the product — invoice OCR and categorisation, document-flow automation — and maintains developer tooling for AI-assisted extension work, but publishes no conversational assistant and no MCP endpoint. An AI connection is built on WebAPI or the SQL data; what it needs on top is exactly what the governed layer holds — why AI fails on raw ERP data .

Official enova365 resources

• enova365 — product site, Soneta
• enova365 documentation
• Technology and system requirements
• Offer and licensing model
• Modules and integrations
• Business Intelligence module
• WebAPI
• KSeF information centre

Onetribe is not a Soneta 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 enova365 estate — free assessment