Superfaktúra — Invoicing Done Properly, and Nothing Else

Superfaktúra does one job and does it properly. It issues documents quickly, matches incoming payments without anyone typing, chases what is owed, and hands the result to whoever keeps the books. The scope is narrow on purpose, the price is stated plainly, and the API is real rather than nominal — a combination rarer than it sounds.

At a glance

What Superfaktúra is

Superfaktúra is a cloud invoicing and receivables platform for Slovak and Czech small businesses, used in a browser and on mobile, with a documented REST API.

It covers the commercial document chain end to end — quote, order, proforma, tax document for a payment received, delivery note, final invoice — and each document can be raised from the one before it, in fourteen languages and 155 currencies, with or without VAT.

Where the product earns its reputation is after the invoice is sent. Bank notification emails are read and matched to open documents automatically, across most Slovak and Czech banks. Reminders go out before and after the due date, by email or SMS, on rules the user sets once. An online payment button sits on the invoice itself. That is order-to-cash for a small business, in one place.

The localisation is separate rather than translated. The Czech product runs on its own domain, with its own price list in CZK, its own sandbox and its own accounting export targets. The Slovak product tracks Slovak VAT rules closely, and is preparing for mandatory e-invoicing from 1 January 2027 by acting as the user’s structured-invoice mailbox and Peppol gateway. Carrying two tax codes and a national e-invoicing transition is a substantial commitment for a company this size, and the vendor has met it.

The vendor calls it an invoicing system. That is the accurate description, and this article respects it.

The three plans

Most buyers choose a plan on features and budget . The choice also determines whether the data can be read programmatically at all.

Prices are per month on annual billing, excluding VAT, as displayed in July 2026. Monthly billing costs a little more, and the Czech product has its own price list in CZK.

The line worth noticing is that the API sits in the top plan, which makes the plan choice a data decision as much as a feature one — and at these prices, not a difficult one. Separate number series matter for the same reason: a company running two e-shops through one account can keep them distinguishable at source rather than reconstructing the split afterwards.

Who Superfaktúra fits

Sole traders and micro companies. A price list, a handful of recurring clients, a VAT return prepared by someone else. Superfaktúra on the base plan is the correct tool and there is nothing here to improve.

Small companies with an external accountant. The core of the market. The company invoices, the platform matches payments and chases debtors, and the accountant gets a login or a monthly export in the format their own system reads — POHODA, Omega, Money, MRP, Proluc, Oberon, Profit365, Tangram or the universal ISDOC. The division of labour is clean, and it works.

E-shops. Modules exist for WooCommerce, PrestaShop, Shoptet, OpenCart, Shopify and a dozen more, so orders become invoices without anyone opening the platform. For an e-shop doing volume, this is the whole reason Superfaktúra is in the stack.

Service businesses on recurring fees. Recurring invoicing, automatic matching and scheduled reminders turn collection into an exception list.

Groups that grew sideways. A Slovak company invoicing through Superfaktúra, a Czech subsidiary on something else, an e-shop added two years ago, an accountant keeping the ledger in a desktop system. Every one of those choices was right on its own terms. What nobody owns is the view across them, and this is the context in which Superfaktúra most often reaches us.

What Superfaktúra holds — and why it is good material

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

Superfaktúra holds the invoice — header and lines. Client, item, quantity, unit price, discount, VAT rate, currency and rate, issue date, delivery date, due date, and the payments against it with their dates and amounts. It also holds the client master, expenses with categories and attached documents, stock items with movements, the cash record, and — on the Prémiový plan — tags applied to invoices, expenses and clients.

The data quality is high, for a structural reason. An invoice is a legal document that goes to a customer who reads it, and a payment either matches it or does not. Errors are found by the counterparty rather than at year-end, and continuously rather than at close.

It is also well structured on the way out. The API returns typed JSON rather than a rendering of a PDF, so line-level analysis needs no parsing. Where the invoice line carries the thing being sold, and the item catalogue or the tags carry how the business thinks about its sales, real profitability analysis is reachable from what the platform already holds. Our published work with a Slovak publisher recovered sales by distributor, genre, author and title from exactly this material.

One honest note on dimensions. Superfaktúra’s tags are labels rather than a hierarchy, so they are not the equivalent of the cost centre (stredisko) structures a desktop accounting system carries. Used consistently they are still a foundation, and the structure they lack can be supplied above the platform.

What sits outside Superfaktúra’s scope

Superfaktúra is scoped to invoicing and the cash that follows it — a boundary the vendor drew deliberately, and drew in the right place. Three things sit outside it, and this is the cleanest scope section in the series precisely because none of them is contentious.

The ledger. Superfaktúra holds what was invoiced. It does not hold what was booked. Accruals, deferrals, depreciation, provisions, the accountant’s corrections, the trial balance, the VAT return and the VAT control statement (kontrolný výkaz DPH) live in the accounting system, which is why the export routes into POHODA, Omega, Money and the rest exist at all. Payroll is not in the product in any form, and neither is the fiscal cash register (eKasa) — the pokladnica module is a cash book rather than a certified eKasa client. The vendor is candid about all of this, publishing which figures in its own overviews are indicative rather than final.

Sales that never passed through it. A marketplace channel, a point-of-sale till, a subsidiary invoicing from its own system, a distributor reporting sell-through. Superfaktúra has no view of any of them, and no reason to.

The view across systems. Whether invoiced revenue agrees with booked revenue, whether the e-commerce platform’s order total agrees with either, whether the cash the bank shows reconciles to both. This is worth saying plainly: no source system does this. Not Superfaktúra, not POHODA, 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 .

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, and on Superfaktúra it is the least troublesome extraction in this series. We create a dedicated API user, as the vendor recommends, and read incrementally through the REST endpoints — invoices and invoice items, clients, payments, expenses, stock movements and tags — authenticating with the SFAPI header and passing company_id where a login carries more than one company. The documented rate-limit headers are respected, so a scheduled pull never crowds out the e-shop module writing invoices in the other direction. We call read endpoints only, and nothing changes for the people issuing invoices.

What happens next is the Superfaktúra-specific work.

Reconciling invoiced revenue to the booked ledger

This is the first thing a Superfaktúra client needs, and the thing no single system can give them. Invoiced revenue and booked revenue are different numbers, legitimately: timing differs, credit notes land in different periods, the accountant posts corrections, some revenue never touches the platform. We build the reconciliation as a standing daily control rather than a month-end investigation — invoice totals from Superfaktúra against the revenue accounts in the accounting system, matched at document level where document numbers carry through the export and at period level where they do not. Differences are classified rather than chased: timing, credit note, manual journal, out-of-scope channel. The client gets a management P&L whose revenue line ties to the statutory books, with the bridge between them visible and explained. That bridge is also the chart of accounts conversation, because what a business sells in and what it books to are rarely the same categories.

Receivables and collection, on live invoice data

Superfaktúra already knows who owes what and since when. What it does not do is turn that into a managed process across the whole business. We build the receivables view on live invoice data — ageing by customer and by channel, days sales outstanding as a trend rather than a single number, the cash flow picture that follows, and a ranked list of who to call this week, weighted by amount and by how that customer has actually behaved. Because the platform records the payment as well as the invoice, collection effectiveness is measurable rather than anecdotal. And because the same layer holds the accounting system, the receivables position reported to a bank or a board agrees with the balance sheet.

Combining an invoicing platform with an accounting system, an e-shop and whatever else the business runs is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .

Beyond that, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a data model that Power BI and AI can both query reliably , and your business context accumulating so answers sharpen the longer it runs. A dashboard is the visible part; the governed data layer underneath, held to standing data governance , is what makes the number defensible.

What becomes answerable

The clearest way to describe the difference is to list what a Superfaktúra client can ask afterwards.

• Which customers and which products actually make money, at gross margin and after the cost of serving them?
• Does invoiced revenue agree with booked revenue this month, and where exactly does it not?
• Which invoices are at risk, who should be called first, and what is that worth in cash this week?
• What is total revenue across the invoicing platform, the e-shop and the entity that invoices from somewhere else — counted once?
• How is days sales outstanding moving, and which customers are moving it?
• What is the cash position three months out, given what is invoiced, recurring and committed?

Every one of these is answered from data the business already has. 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 Superfaktúra 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 — an API key on a dedicated user, plus equivalent access to whichever system keeps your ledger — and a conversation about what the numbers should mean.

What does not change: Superfaktúra stays your system of record for invoicing. 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

TATRAN — live sales analytics and title profitability for a book publisher

TATRAN is a Slovak book publishing house with a growing title portfolio and, at the start of the engagement, no structured reporting infrastructure. Sales were aggregated manually in spreadsheets at month-end, accounting served VAT compliance rather than management decision-making, inventory levels were not regularly monitored, and the profitability of individual titles was unknown — reprint and pricing decisions were made on intuition.

We integrated with Superfaktúra via its API and built automated real-time sales extraction with breakdowns by distributor, genre, author and individual title. Sales data was linked to inventory levels so that reprint needs surfaced proactively as stock declined, and sales reporting from Superfaktúra was combined with manual cost calculations to create a methodology for measuring title-level profitability across author, genre and distribution channel. As one of the first pilot clients for the Onetribe AI layer, TATRAN also gained market insight on Slovak book-market sales trends, validated by experienced financial professionals. The engagement ran in phases across four to five months: discovery, live sales, inventory, profitability, then the AI layer.

The result was a move from monthly manual aggregation to a daily live view of current sales, a systematic data-driven approach to reprint decisions in place of estimates, and clear profitability visibility supporting pricing on evidence. Reporting infrastructure went from nothing to live, built so that adding a distribution channel does not require rebuilding it.

That case is the argument of this article. Superfaktúra was the sales source, not the only source — costs came from elsewhere and inventory had to be brought alongside. The value came from the layer that held them together.

When Superfaktúra sits beside, or is eventually replaced by, something larger

Some Superfaktúra clients move on at some point, usually because they have grown into needing stock, production or multi-entity accounting in one system rather than because anything went wrong. Others never move, and simply add systems around it. Both cases are handled the same way.

Because the governed layer sits above the source systems, only the connection changes — the data model, the reports and the consolidation logic stay as they are. Clients who built the layer first find any 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.

Superfaktúra in the regional context

Superfaktúra rarely stands alone. It is normally paired with an accounting system, and that pairing is the thing to understand. Each system below gets its own article in the series .

From a data-layer perspective the choice matters less than it appears. Each becomes a source in the same governed model, which means the 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 Superfaktúra to get proper management reporting? No, and we would usually advise against it. Keep Superfaktúra for what it does well — fast document issue, automatic payment matching, collection chasing, clean capture of what was sold — and build the reporting layer above it. Replacing a working system to solve a reporting problem is an expensive way to solve the wrong problem.

Is Onetribe a replacement for Superfaktúra? No. Superfaktúra remains where your invoices are issued and your team keeps using it exactly as they do now. We read from it, never write to it. If you change system later, the reporting layer stays.

Is Superfaktúra an ERP or an invoicing system? An invoicing system, and the vendor says so. It covers the commercial document chain, receivables, expenses and a price list with basic stock — but not the general ledger, not payroll, not production, not multi-entity accounting. Calling it an ERP would flatter it in a way that eventually disappoints someone.

What database does Superfaktúra use? There is no customer database, which is the honest answer and an important one. Superfaktúra is a multi-tenant cloud service: the vendor operates the data store and does not expose it. Access is through the REST API, authenticated per company with an email address and API key, returning JSON. In practice this is simpler than a desktop system rather than harder — no server access, no file copies, no version differences.

Can Superfaktúra connect to Power BI? Yes, through the API and into a governed model rather than by pointing Power BI at the API directly. Direct connection works once and gets harder to maintain from there — the API is paginated and rate-limited by design, and the definition of what counts as revenue needs to live somewhere other than inside a report. We pull incrementally on a schedule, which respects the published limits and means BI reporting runs against the model rather than the platform. Nothing we do affects the platform’s speed for your users.

Can Superfaktúra consolidate several companies? Not in the accounting sense, and it does not claim to. One login can hold several companies and the API accepts a company_id, so several entities read cleanly through one integration — but each company is a separate subscription, with no shared chart of accounts, no intercompany elimination and no currency translation . Statutory consolidation is a layer above the source systems, and we do it across any combination of them .

Does Superfaktúra have an API? Yes, and a good one. It is a language-agnostic REST API documented publicly on GitHub, covering invoices, expenses, clients, contact persons, bank accounts, the cash register, stock, tags and value lists. Authentication is a header carrying the account email, an API key and a module identifier, and rate limits are reported back in response headers so an integration can pace itself. There is an official PHP client, community connectors in .NET, C++ and Python, and Slovak and Czech sandboxes. API access sits in the Prémiový plan.

Are Superfaktúra’s own overviews enough? For a sole trader or a small company with one revenue stream, they do real work, and the vendor is unusually straight about which of its figures are indicative and which are exact. Where they run out is anywhere the answer needs a second system: revenue that ties to the ledger, margin after costs Superfaktúra never sees, a group view, or a model an AI assistant can query reliably. On AI: the vendor ships no assistant and no MCP endpoint, and the REST API makes wiring one straightforward. But an assistant reading Superfaktúra alone sees invoices, not the ledger — the join to the books is what makes its answers mean something, and that join is the layer’s job — why AI fails on raw source data .

Official Superfaktúra resources

• Superfaktúra — Slovak product site
• Superfaktura.cz — Czech product site
• Plans and pricing
• Integrations — e-commerce, banks, couriers, accounting systems
• REST API documentation
• Official PHP API client
• Developer sandbox
• eFaktúra — the vendor’s e-invoicing preparation
• Help centre (pomoc)

Onetribe is not a SuperFaktura partner or reseller. We build the governed data layer above your ERP and your source systems, whichever they are.

Next steps

• Every source system we connect — the series hub, with the full matrix
• Do you need a new ERP, or just the data already inside it? — worth reading before any system decision
• How we consolidate any combination of systems — group reporting
• Discuss your Superfaktúra estate — free assessment