Beyond the State API: Integrating Fiscalization into Custom Software

Integrating fiscalization into custom software is now a standard part of the job across Southeast Europe. Tax offices expect invoice data in real time. They also expect it in their own format, signed with their own keys. Because of that, a platform designed five years ago may fail an audit today.

Related guide: Also read our fiscalization API guide for what such an interface does, plus the rules country by country.

What the rules actually require

Fiscalization means every sale travels to a state platform as it happens. Albania, Kosovo, North Macedonia, Serbia, Croatia, and Montenegro all run such a scheme. Each tax office picked a different design. Some require a signature on the invoice before the customer pays. Others let the till work offline, then sync later that day.

Off-the-shelf products rarely cover more than one of these designs. Custom software has to cover them all, which is where the real work begins. In fact, most engineers find the rules easier than the plumbing around them.

Why a government API is never enough

Government APIs do a single job: they accept a valid invoice and return a code. They arrive with thin docs and limited developer support. Since the rules keep changing, the endpoint you integrated last spring may move this autumn. Teams then lose days to guesswork rather than to product work.

A raw API request also carries no memory. It cannot queue a failed sale, retry it, or warn you that nothing has travelled since lunch. Your own app has to deliver all of that. Thus integrating fiscalization into custom software means building a layer, not merely a connection.

The details that defeat teams

Invoice numbers must follow strict national rules. A gap or a reset in the wrong place can void an entire day of revenue. Certificates also expire, and one stale key disables every till at once.

Speed matters just as much. A shop at peak hour cannot wait four seconds for a receipt. Because of that, the request belongs away from the checkout path, with a queue behind it. Then the sale completes fast and the government call catches up later.

Next comes the dull element that protects you: audit logging. Tax staff can request a complete transaction trail many months later. In short, if you cannot show what you submitted and when, you have a real problem.

Every industry has a different profile

Shops push huge volume in very short bursts, therefore speed wins. Hotels divide bills, hold deposits, and adjust rates after arrival. Clinics invoice both the patient and the insurer for a single visit. Transport firms issue invoices in several markets and several currencies.

A single template will not satisfy all four. Instead, the mapping from your data model to the state format has to mirror how the industry works. That mapping is the genuine product, and it absorbs most of the thinking.

Certificates, access, and privacy

Fiscal traffic carries personal names, sums, and tax codes. Thus it deserves the same care as payment card data. Keep certificates inside a vault, never inside a repo. Rotate them on a schedule, and raise alerts well before they expire.

Only a small number of staff should reach the fiscalization settings. Companies trading inside the European Union must also satisfy the GDPR rules on how long they hold this data. A yearly review of who can read what costs very little and prevents costly surprises.

Put one integration layer in the middle

The cleaner design is a compact service sitting between your apps and the state. Every app talks to that single service. Then the service talks to each country in its own dialect.

This setup buys you a lot. First, you write the state logic exactly once. Second, you can test it apart from the till. Third, you can add another app next year without touching any compliance code. Such a layer also gives you one place to watch queue depth, retry counts, and rejected sends.

Prepare for the difficult day

Real-time rules turn uptime into a sales issue rather than a technical one. If the link drops, the shop must still accept payment. Hence the queue, the local store, and a clear sync path when the connection returns.

Two machines beat one machine. Likewise, a nightly export of the queue into cold storage costs almost nothing. Test the failover before the launch, never after it.

Growth across borders adds work

Many firms here operate in three or four markets at once. Each tax office keeps its own id, its own layout, and its own signing scheme. Rather than fork the codebase per country, keep one service with an adapter per market.

That way a rule change in Skopje never delays a release in Tirana. It also reduces the cost of the next border you cross. Since an adapter is fairly small, a new market becomes weeks of effort instead of months.

Delegate the checking to automation

Most rejected sends originate in small formatting errors. An outbound checker catches those before the government platform ever observes them. As a result, reject rates fall and staff stop re-typing the same bill.

Alerts matter equally. A message when the queue exceeds fifty items beats a nasty discovery at month end. Finance staff then devote their time to analysis rather than to chasing documents.

How Square Software approaches the problem

Square Software develops custom software and integrates it with third-party and government systems. We work on a time and materials basis at 35-55 EUR/hour. You can review the kind of work we deliver on our products page. Or read how we staff a team on our outsourcing page.

If you want a rough figure first, our project estimator produces one within a few clicks. If you would rather discuss it directly, the contact page remains the shortest route.

Mistakes we see again and again

First, teams scope the job as one API call and skip the queue. Second, they test only the happy path, so the first reject on a Friday evening escapes notice. Third, nobody owns the signing keys, and a single lapse takes the whole shop down.

Here is another one. Picking a rigid product that cannot adapt when rules move looks cheap in year one. It then demands a complete rebuild in year three.

Where this is heading

State tax platforms keep growing across Europe. The European Union set a common electronic invoice format for public bodies under Directive 2014/55/EU. National schemes keep moving the same way. Albania puts its own rules and guidance on the site of the tax agency.

Expect tighter links between fiscal platforms, banking systems, and accounting software. Expect more validation before a sale completes, rather than after it. In short, integrating fiscalization into custom software will resemble basic plumbing you design from day one.

In short

Fiscal rules are not going away, and they are not becoming simpler. A thin wrapper around a state API will survive a demo and collapse on a busy Saturday.

Build the queue, the validation, the alerts, and the key schedule in advance. Keep the government logic in a single place, so another rule or another border stays a modest job. Do that, and integrating fiscalization into custom software stops being a risk. It becomes a feature you can sell.

More on the API side sits in our guide to fiscalization APIs.