Integrations and government systems
E-invoicing service
A Go service that opens the door from the till software to the national e-invoicing system, electronic delivery notes and email. Everything leaving the shop goes through it.
Problem
Serbian law introduced e-invoices, electronic delivery notes and VAT records — all through a government system, over HTTP calls carrying UBL XML, API keys and TLS. The till software was written to talk to a local database and a fiscal printer, not to web services whose specification keeps changing. Rewriting it was never an option: it runs in shops, people know it by heart, and every change means a new installation at every site.
Solution
Everything that leaves the building was moved into a separate Go service — a single executable, no installer and no dependencies. The till software calls a local address and gets an answer back; it knows nothing about XML, keys or certificates. When the government changes the specification, only that one file changes and the till software is left alone.
What was built
- Sending outgoing invoices to the national system, with registration in the central invoice registry
- Sending and retrieving electronic delivery notes, inbound and outbound
- Downloading documents as both XML and PDF
- Checking the status of a submitted invoice
- Accepting and rejecting inbound invoices
- Individual VAT records
- XML validation before sending, so an error is caught before it leaves
- Listing companies registered on the system
- A second intermediary as an alternative route, with the same flows
- Daily fiscal report from the till — reading it and preparing it for submission
- base64 both ways, PDF to text and back
- Sending mail with an attachment through Gmail, Outlook or Yahoo
- Pushing the fiscal receipt into the web shop
- Sending daily turnover reports to large suppliers
This is the only project here with no screen at all. The service has no interface — another program calls it, and a person only notices it when it stops working.
What makes it interesting is where it sits. The till software is legacy: it has run for years, people know it by touch, and it should not be disturbed without cause. The government system is the opposite — it changes, it asks for new formats, and it does not wait for anyone to be ready. Something has to absorb that difference between the two.
So the line was drawn in one place: the till software knows nothing about the outside world. It calls a local address and gets an answer. It does not know what UBL is, it holds no keys, it deals with no certificates. When the specification changes, the customer gets one file — not a new version of the program, and not a visit to every shop.
The service dates from 2023, the first year e-invoicing became mandatory, and it has grown with the legislation ever since — electronic delivery notes, VAT records and the second intermediary all came later, each time as an addition to the same file rather than as a new program.
It now has close to fifty routes, and nearly every one has a demo twin pointing at the test environment. That is not duplicated work for its own sake: an invoice submitted to the government system has been submitted. There is no undo. Being able to rehearse the whole flow — assembling, validating, sending, checking status — is the difference between rolling out a new version on a Tuesday morning and rolling it out on a Friday night with your fingers crossed.
Go was chosen for one property: it compiles to a single executable with no dependencies. On a machine in a shop there is no runtime to install and no version that fails to match. The file is copied across and run.
Result
The till software meets a legal obligation without having been rewritten. When the government system's specification changes, the customer receives one file instead of a new version of the program. The same service also carries mail, supplier reports and receipts into the web shop.