ABRA Flexi and Gen — The API-First Czech Family

ABRA Software has been building business systems in the Czech market for three decades, and the decision to run two distinct products rather than stretch one across every buyer is well judged. A sole trader and a two-hundred-person manufacturer do not want the same software, and ABRA does not pretend they do. What both products share is a serious attitude to integration — the most consequential thing a vendor can get right.

At a glance

What ABRA Flexi and ABRA Gen are

ABRA Flexi is a cloud-first accounting and business system for small and mid-sized companies, run from a browser or from a desktop client on Windows, Linux or macOS against the same data. ABRA Gen is a modular ERP for medium and larger companies, assembled from more than thirty modules spanning CRM, trade, warehousing, production, finance and after-sales service.

They are genuinely different products, and it is worth being clear about why. Flexi grew up as FlexiBee, an internet-native accounting application, and joined the ABRA group in 2014 before taking the ABRA Flexi name in 2020. Its architecture reflects that origin: PostgreSQL underneath, a web interface first, and an integration surface built to be used by other software rather than only by people. Gen was formed in 2016 when ABRA merged its G3 and G4 lines, and it has the characteristics of a configurable ERP — a rich module matrix, a choice of database engine, deep parameterisation, and implementation by a partner or by ABRA’s own consultants.

The rename is complete in the product and on the main site, but FlexiBee has not disappeared and you should not be surprised to meet it. The support portal is at podpora.flexibee.eu, the developer documentation at flexibee.eu and demo.flexibee.eu, and the API’s own XML and JSON envelope element is still called winstrom — after WinStrom, the product FlexiBee grew out of. That is what backwards compatibility looks like when a vendor takes it seriously: every integration written against the old name still works.

Both products carry the Czech and Slovak statutory obligations properly. The Czech builds handle Czech VAT and the VAT control statement (kontrolní hlášení); the Slovak builds handle Slovak VAT, the VAT control statement (kontrolný výkaz DPH) and the recapitulative statement (súhrnný výkaz), with ABRA Gen supporting eKasa for registered cash takings. One Stop Shop, Intrastat and ISDOC electronic invoicing are in scope too. Keeping two tax codes current across two product lines is a substantial standing commitment, and ABRA has met it.

The two product lines

Most buyers arrive at one product or the other through company size and process complexity. It is worth understanding what else the choice determines, because the two have different data stories.

ABRA Flexi comes in three variants. Basic covers double-entry and single-entry bookkeeping, invoicing, bank, cash, fixed assets, stock and cost centres (střediska). Business adds payroll and HR, orders and jobs, user-defined reports, Excel import, batch tracking and point-of-sale. Premium adds advanced stock with bills of materials, EDI, recurring invoicing, Intrastat, cost-centre pricing and the configurable report editor. Every variant includes unlimited companies, unlimited documents and unlimited read-only users — a materially different licensing philosophy from most of the market, and one that matters more than it first appears. There is also a dedicated tariff for accounting practices.

API access is a licensed line on the Flexi price list, with a daily request quota that rises by variant and can be increased for a fee. A fair way to price the surface, with one design consequence we return to below: a reporting integration should read incrementally rather than re-read everything each night.

ABRA Gen is assembled rather than chosen. More than thirty modules run from address book, VAT, bank and cash through purchasing, sales, warehousing, production planning, service and payroll. The database engine is an installation decision — Firebird ships with the product, while Oracle and Microsoft SQL Server are options for double-entry installations. A multi-company installation runs each company in its own database, capped by licence. Ready2go is a preconfigured deployment for companies that want the standard configuration quickly rather than a bespoke one slowly.

Who ABRA fits

E-commerce and integration-led businesses. This is where ABRA Flexi is at its strongest. A shop, a payment gateway, a shipping broker, a warehouse and the ledger all need to agree with one another, and Flexi’s API makes that a configuration exercise rather than a development project.

Established SMEs on Flexi. Ten to a hundred people, one or two legal entities, double-entry bookkeeping, stock, payroll. What these companies want next is not a different system — it is a management view of data Flexi is already holding correctly.

Accounting and tax practices. Unlimited companies on a single licence, a shared-data tariff, and read-only access at no cost for clients — a sensible commercial design for practice work, and practices are a concentrated part of the Flexi base. Increasingly they are also the ones asking whether they can offer clients reporting on top of books they already keep well.

Manufacturing, distribution and service companies on Gen. Production planning, bills of materials, operational scheduling, subcontracting, service contracts and after-sales — ERP scope in the full sense, and the reason a company chooses Gen over Flexi. These businesses hold the richest operational data of any ABRA user, and have the least time to analyse it.

Groups that grew sideways. A Czech trading company on Gen, a Slovak subsidiary on Flexi, an e-commerce entity on something else again. Each chose the right local system for its own jurisdiction and operating model, and every individual choice was sound. What nobody owns is the view across them, and this is the context in which ABRA most often reaches us.

What ABRA holds — and why it is good material

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

ABRA data is clean, and for the same reason POHODA data is clean: statutory obligation enforces a discipline that voluntary data entry never does. The VAT return has to reconcile, the control statement has to tie back to documents, the ledger has to balance. A set of books kept properly in either product is complete to document-line level, internally consistent and stable across years. That matters, because the quality of a reporting layer is bounded by the data quality beneath it.

It is also richer than most users exploit. Both products carry analytical dimensions — cost centre (středisko), job (zakázka) and activity (činnost) — that tag transactions for management analysis alongside their statutory posting. Where those fields 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. ABRA Gen adds production, project and service data that most accounting systems in these markets do not hold at all.

And then there is the thing that sets ABRA Flexi apart from every sibling in this series. The data is not merely well kept — it is reachable. Not through an export routine or a document exchange format, but through a proper read interface: every record type at a predictable URL, filterable server-side, projectable to the fields you want, with field metadata published per record type and a change feed telling you what moved since you last looked. Many vendors treat data access as an afterthought. ABRA treated it as a product decision, and it was the right one.

What sits outside ABRA’s scope

Each ABRA product is scoped to one accounting entity, and that scope is a design decision rather than an omission. For the core user — one company, one jurisdiction, one set of books — it is 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 databases, whether those sit under one Flexi licence or one Gen multi-company installation. There is no shared chart of accounts across them and no consolidation, so intercompany matching and currency translation happen outside the system. Flexi makes access to those five databases uniform, which is more than most systems manage. It does not make them one book.

The view across systems. ABRA 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 ABRA, 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 job cost against quote. ABRA’s own reporting does capable work inside those boundaries — user-defined reports and the configurable report editor in Flexi, ABRA BI alongside Gen. Neither is a semantic model a dashboard or an AI assistant can query across a group, and neither is meant to be 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 ABRA Flexi in both its Czech and Slovak builds, in single entities and in groups running it alongside other systems, and we read ABRA Gen installations on each of the database engines it supports.

Getting the data out is the routine part, and with ABRA it is more routine than most. On Flexi the default route is the REST API over HTTPS, authenticated with a read-only account, requesting exactly the fields we need in CSV or JSON, filtered server-side by accounting period and change date. Where a client hosts Flexi themselves, a direct read-only PostgreSQL connection is available instead; on the vendor cloud the API is the supported route. On Gen we read through the REST Web API or directly against the database engine, depending on how the installation is hosted. Read-only throughout. Nothing is ever written back to ABRA, and users notice no difference in how the system performs.

What happens next is the ABRA-specific work.

Reading Flexi properly, and within the quota

An easy API invites a careless integration, and a careless integration against a metered API is what causes trouble later. We design the Flexi connection the way the API asks to be used: field-level projection, so we request the columns the data model needs rather than whole records; server-side conditions rather than filtering after the fact; explicit paging; and incremental reads driven by the record’s own change timestamp and the change feed, so a normal day’s refresh costs a fraction of a full reload. Codebook references arrive as coded pointers, so we resolve them once into managed dimension tables instead of on every pass. The result runs comfortably inside the daily request allowance of the client’s licence variant, and stays inside it as volumes grow.

A management chart of accounts, and the dimensions that feed it

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, 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. Alongside it, the analytical dimensions: we audit how consistently středisko, zakázka and činnost have been used across history, agree rules for filling them going forward, and encode those rules as validation so the discipline holds. On ABRA Gen the same treatment extends to production orders and service contracts, where the interesting margin questions live.

One view across every entity and every system

Each Flexi company and each Gen database becomes one entity in a common model, sitting alongside another ERP, 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 ABRA document that produced it. Routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .

Here is the honest consequence of all of it. When access is easy, the missing piece is never access. It is structure, definitions, and the view across systems — the cleaner version of the argument this whole series makes. 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 ABRA client can ask afterwards.

• Which customers are actually profitable, after delivery and service cost — not just 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 Czech and Slovak entities sit on different charts of accounts?
• Which product lines earned their shelf space this year, across the e-shop and the trade channel together?
• Why did overhead move this month, ranked by the cost lines that moved most against budget ?
• How much cash is tied up in stock that has not moved in six months?

Every one of these is answered from data ABRA 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 ABRA Flexi 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: ABRA 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 ABRA is eventually replaced

Some ABRA clients change system at some point, usually because they have outgrown the scope rather than because anything went wrong — sometimes from Flexi up to Gen, sometimes out to an international platform when a group standardises.

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 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.

ABRA in the regional context

ABRA is one of several capable system families 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 ABRA to get proper management reporting? No, and we would usually advise against it. Keep ABRA 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 ABRA? No. ABRA 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.

What is the difference between ABRA Flexi and ABRA Gen? Different products for different buyers. Flexi is a cloud-first accounting and business system, licensed per named user per month, with unlimited companies and an integration surface designed to be consumed by other software. Gen is a modular ERP with production, service and project depth, licensed by module and priced on application. Both are properly localised for the Czech and Slovak markets, and both come from the same vendor.

What database does ABRA use? It depends on the product. ABRA Flexi stores data in PostgreSQL. ABRA Gen runs on Firebird, which ships with the product, or on Oracle or Microsoft SQL Server for double-entry installations. In both, each accounting entity has its own database. On the Flexi cloud service a direct database connection is not offered — the REST API and in-product user queries are the supported routes, and in practice that is a cleaner, more stable interface than a raw connection.

Can ABRA connect to Power BI? Yes, and ABRA publishes its own guide to doing it — the Flexi REST API returns CSV straight to a Power BI web query under Basic auth. That is a good way to prove a number quickly. For anything ongoing, the practical route is a read-only extract into a governed model, with BI reporting on the model rather than on ABRA directly. Pointing Power BI at the endpoints works once and gets harder to maintain from there — the records are transactional by design, codebook references need resolving, the definitions need to live somewhere, and each refresh spends against your daily API allowance. Reading our way does not slow ABRA down: incrementally, on a read-only login, only the fields the model uses.

Can ABRA consolidate several companies? Not as a group book. Both products hold one accounting entity per database — a Flexi licence can carry unlimited companies, a Gen multi-company installation several — but each remains a separate set of books with its own chart of accounts. Consolidation is a layer above ABRA, and the most common reason multi-entity ABRA users come to us. Flexi does make the mechanics easier than most: every company on the licence is reachable through the same endpoint with the same credentials.

Does ABRA have an API? Yes, and this is the product family’s real technical distinction. ABRA Flexi exposes a full REST API over HTTPS in which every record type — invoices, ledger movements, address book, price list, stock movements, cost centres, jobs — sits at a uniform URL, readable and writable in XML, JSON, CSV, XLS or ISDOC. It supports server-side filtering, sorting, paging, aggregation, field-level projection, per-record-type field metadata, external identifiers for idempotent syncs, a dry-run mode, a change feed and webhooks, authenticated by HTTP Basic or a session token. ABRA Gen has its own REST Web API over business objects, licensed by user count. Independent client libraries exist for both — the clearest evidence that the interface is usable in earnest.

Is ABRA BI enough? ABRA BI does real work — precomputed tables for volume, sources beyond the ERP, dashboards in a browser. For a single entity with a clear question set, it is worth using. Where it runs out is where every ERP-adjacent BI tool runs out: group definitions owned outside the ERP, cross-system reconciliation , a documented governed data layer with data governance around it, and a semantic model an AI assistant can query reliably. On AI: unsurprisingly for the best-documented API in this series, community MCP servers for ABRA Flexi already exist — an assistant can be reading Flexi in an afternoon, though ABRA itself publishes no assistant and no official MCP endpoint. Easy connectivity sharpens the real point: access was never the constraint here, definitions were — why AI fails on raw ERP data .

Official ABRA resources

• ABRA Flexi — product overview · pricing and variant comparison
• ABRA Gen — product overview
• ABRA Flexi REST API — overview and developer licence
• ABRA Flexi REST API documentation
• ABRA Flexi — system requirements
• ABRA Flexi and Power BI — the vendor’s own guide
• ABRA Gen Web API — developer documentation
• ABRA Gen — supported database servers
• ABRA Software Slovakia

Onetribe is not an ABRA Software 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
• Do you need a new ERP, or just the data already inside it? — the question behind most system projects
• Discuss your ABRA estate — free assessment