Statutory invoicing and fiscalization, wired into what you already run.
Every cash invoice reported to FURS the moment it is issued, every invoice to the public sector filed in the format it expects, built into the system that already issues your invoices rather than living beside it.
What this is
Fiscalization and e-invoicing get talked about as one requirement. They are two, running on different rails, and a business usually needs a different mix of each than it assumes. Fiscalization is the Slovenian requirement that cash transactions, anything paid in cash or by card at the point of sale, get reported to FURS in real time: the invoice is signed, sent, and a unique identifier (an EOR) comes back before the receipt can be handed over, alongside a protection mark (a ZOI) the issuer generates itself. Straight business-to-business invoicing on payment terms is not fiscalized at all. Selling to the public sector is a third regime again, structured e-invoicing in e-SLOG format, submitted through UJP. Knowing which of the three actually applies to a given invoice is usually the first useful thing we tell a client.
The technical work is signing and reporting every applicable invoice against FURS's live service, using a qualified certificate the business holds and renews, and it has to survive the day the connection does not. FURS has a documented offline procedure: an invoice can still be issued without a live connection, marked accordingly, and reported afterward inside the window the regulation sets. Most fiscalization problems we get called about are not the everyday path, which is well documented and mostly works. They are the offline case, built once, never tested, and then found to be broken on the one day the connection actually drops.
For public-sector customers the format is e-SLOG, an XML standard submitted through UJP, mandatory for business-to-government invoicing in Slovenia for years. Wider Europe is moving toward the same idea by different roads: Italy's SDI, Poland's KSeF, and more joining on their own timelines, each with its own format and its own endpoint, plus PEPPOL as the network several of them plug into for cross-border structured invoices. A system built with the reporting layer separate from the invoicing logic survives the next country's mandate arriving. One built with FURS's rules hardcoded into the invoice screen does not.
This wires into whatever already issues invoices, custom software, a point of sale, or an ERP, ours or somebody else's. It is deliberately a narrower piece of work than an ERP implementation. If there is no invoicing system yet and the actual decision is what to run the business on, that choice belongs with ERP implementation, where fiscalization is one module inside a bigger build rather than the whole engagement.
What you get
FURS fiscalization wired into the point of issue
Every cash invoice signed, reported and returned an EOR before the receipt goes to the customer, with the ZOI generated and printed alongside it.
Qualified certificate installed and managed
The signing certificate set up correctly, with renewal documented instead of left to expire quietly.
Offline handling, built and tested
What the system does the moment FURS is unreachable, and the back-reporting once the connection returns, tested deliberately rather than assumed.
B2G e-invoicing in e-SLOG
Structured invoices submitted through UJP for anything sold to the public sector.
PEPPOL or another structured format, where required
Wired in for customers or jurisdictions that need it, without hardcoding one country's rules into the invoice logic.
Reconciliation report
Fiscalized invoices checked against what FURS actually recorded, so a mismatch surfaces before an audit finds it.
Audit trail and archive
Records kept in a form that holds up if FURS or an accountant asks for them years later.
Documentation for finance
What the system does automatically, and what still needs a person to look at it.
When this fits, and when it does not
A good fit
- You issue invoices for cash or card transactions and need FURS fiscalization done correctly, not assembled from a forum thread and left untested.
- You sell to the public sector and need e-SLOG e-invoicing through UJP, and your current system cannot produce it.
- Your invoicing already runs somewhere, custom software, a point of sale, an ERP we did not build, and it works. It just needs this one piece wired in properly.
- You are expanding into another EU country and its own structured e-invoicing mandate is arriving on a schedule you do not control.
- An accountant or an audit has already found a gap between what got issued and what got reported.
Not a good fit
- There is no invoicing system yet and the real decision is what to run the business on. That is ERP implementation; fiscalization is one module inside it, not a starting point.
- You want general bookkeeping or accounting advice. We wire the statutory reporting plumbing. We are not accountants and will not pretend to be.
- The building's systems need to feed data into a business system. That is Building management system integration, different protocols and a different kind of connecting work entirely.
- You need this handled somewhere neither Slovenia nor the wider EU rules we know cover. Tell us the country and we will say honestly whether we know that regime well enough to be useful.
- You issue a handful of invoices a month and want a one-off manual fix. Your accountant's existing tool is the right size for that, not an integration project.
How it runs
- 01
Read the setup
What issues invoices today, what is already fiscalized, what public-sector invoicing exists if any, and where the actual gap is.
- 02
Wire fiscalization in
Certificate, signing, the live FURS calls, and the offline path built and tested rather than hoped never to be needed.
- 03
Wire e-invoicing in
e-SLOG through UJP for public-sector customers, PEPPOL or another structured format for anywhere else it is required.
- 04
Reconcile
Fiscalized invoices checked against FURS's own record until they match, not assumed to.
- 05
Hand over
Documentation for finance, and support through the first real outage rather than only through the demo.
Questions we get
Do we need this if we only invoice other businesses on payment terms, not consumers?
Fiscalization in Slovenia applies to cash transactions, invoices paid in cash or by card at the point of sale. Straight business-to-business invoicing on terms is a different regime entirely, and e-invoicing to the public sector is a third one again. Which of these actually applies to you is usually the first thing worth establishing before anything gets built.
What happens if FURS is unreachable when we need to issue an invoice?
There is a documented offline procedure: the invoice still gets issued, marked as issued without a live connection, and reported back once the connection returns, inside the window the regulation sets. We build to that path deliberately and test it, rather than assuming the connection never drops.
We operate in more than one EU country. Can one system handle all of it?
If it is built with the reporting layer separated from the invoicing logic from the start, yes. Italy's SDI, Poland's KSeF, Slovenia's FURS: the same underlying problem with a different format and a different endpoint each time. We have built directly to Slovenia's rules; extending the same architecture to another country's mandate is a smaller job than building it twice from scratch, and we will say so honestly if a particular country is outside what we know.
Does this replace our invoicing or accounting software?
No. It wires into whatever you already use to issue invoices. If there is no invoicing system yet, that is a different conversation, and it starts with ERP implementation rather than here.
More digitalization
Need fiscalization or e-invoicing done properly?
Tell us what issues your invoices today and who you sell to. An engineer reads it and tells you exactly which regime applies before anything gets quoted.