When the tax portal is slow, does your shop stop selling?

In some countries an invoice is not an invoice until the tax authority’s system has stamped it, in real time, with a returned number printed on the document. Not reported in a monthly return afterwards. Stamped first. Until that happens, the piece of paper is not an invoice.

Now picture a shop with several tills, and the authority’s system having a bad afternoon. If the software was built the obvious way, every till stops. Customers stand at the counter holding goods, and staff can neither sell nor explain why. The cost is sales lost and a queue that builds, caused by somebody else’s slowness, and the tills simply freeze with nothing to show why.

The first design for this did exactly that. It put the call to the authority inside the step that records the sale: create the sale, submit it, write the stamp on, finish. It reads cleanly and it is wrong in a way that only shows up in a shop.

What was actually going on

While a sale is being recorded, the stock it is about to reduce is locked so two tills cannot sell the same item. Adding a call to a third party means those locks are held for as long as their system takes to answer, which can be tens of seconds. One slow reply and every other till selling the same product waits behind it.

Worse, the usual safety net does not help with the real problem. If the call times out, undoing the sale on your side does not undo the submission. You do not know whether the authority received it, and that is the whole difficulty.

There is also a question of what state a document can be in. A simple yes or no does not survive contact with the problem, because there are five. Not yet sent. Sent, awaiting a reply. Accepted, which is the only state in which the document may be handed to a customer. Rejected, with a reason. And unknown, where the request timed out or the connection dropped after sending. Unknown is the one people forget and the only dangerous one, because the natural response, trying again, can create a second stamped document for one sale.

What we changed

The design that replaced it records the sale first and finishes it, releases the stock locks, and treats the submission as a separate step with its own status. The document sits locally as unstamped until the authority answers.

For the unknown state the rule is to ask before trying again. So the integration needs to do three things, not one: submit, ask the authority about a document already sent, and cancel one that was accepted. That only works if the document number is created locally before the first attempt and never changes, because a fresh number on a retry makes a second, genuinely new tax document that then has to be formally cancelled.

A rejection is treated as an operational problem, not an error message. The business chooses, per its regime and appetite for risk, whether to block the sale, complete it and mark it pending for resubmission, or print a provisional document with the pending status visible. What must not happen is for the choice to be an accident of how a fault was caught. The same goes for being offline: a queue with a stated limit and a stated behaviour when it fills, because a queue with no ceiling turns a two-hour outage into a three-day backlog nobody noticed growing.

The time on the document is taken from the server at the moment of submission, and the till’s clock is for display only. Shop tablets drift, were set by whoever unboxed them, and have been set wrong on purpose to fix something else, and the authority rejects documents dated in the future. Every request and reply is also stored in full, with both timestamps, because when someone disputes whether something was sent, only the exact payload counts.

What it did not fix

None of this lets the shop sell when the authority is down. It makes the shop’s records true about what happened while it was down, which is the part you control. Someone still has to decide, in advance, what a cashier does with the customer in front of them.

The pattern, for anyone running tills under real-time tax rules

Ask your software supplier what happens at the till when the portal is slow, when it says no, and when the connection drops midway. Ask whether a timed-out submission can produce two tax documents. Ask who chose what a cashier does after a rejection, and whether that choice is written down. And ask where the time on the invoice comes from.

Where this ends up

The submission queue, the frozen document number and the state that means not known yet sit outside the sale itself in Sazinga Factory, where the same till also has to reduce stock while the authority is still thinking about it.