Fiscalizing a web shop: what gets fiscalized and exactly when

A web shop has no counter, no cashier and no printer, but it does have customers who are private individuals. That is enough: an online sale to a natural person is a retail sale and is fiscalized like any other.

As we understand article 3 paragraph 4 of the Law, the seat of a business selling at retail over the internet counts as a retail facility, so sales through the web shop to companies and sole traders are fiscalized too, with their tax number on the receipt.

What really differs is three things: when the receipt is issued, how it reaches the buyer and who presses the button. None of them is a question of whether a receipt exists.

When an order is fiscalized

The rule is the same as at a counter: the receipt is issued at the moment of sale, and money received before that is an advance, fiscalized when it is received (article 6 paragraph 1 of the Law). The rules say nothing specific about distance selling, so this is our understanding, worth checking with your accountant. Three scenarios are worth keeping apart, because shops mix them up constantly.

The third row is the one worth thinking about. A payment made up front for goods still to be sent is, as we understand the Law, an advance: the advance receipt is issued at the latest on the next working day after the payment arrives (article 11 of the Rulebook), and the final receipt at the sale. The Tax Administration has also said, in its answers to frequent questions, that when a natural person pays the full amount of a proforma, a final receipt may be issued at the moment of sale; if you work that way, confirm it with your accountant.

How the receipt reaches the buyer

If you sell exclusively over the internet, the fiscal receipt is issued in electronic form (article 13 paragraph 3 of the Rulebook on types of fiscal receipts). If you also have a shop with premises, the receipt is, as we understand the Rulebook, issued in printed form (for example in the parcel), and it may also be delivered electronically only with the buyer's consent, alongside the printed one, not instead of it (article 13 paragraphs 1 and 2).

The rule that applies then is that a receipt issued in electronic form carries the verification address as a hyperlink instead of a QR code. It is also practical: nobody can scan a QR code inside an email when the phone is already in their hand, while a link opens with a tap.

As we understand it, that means the verification address in the email should be a real link that opens with a tap, not text in which the address sits as a plain string of characters. It is a small thing, easy to skip and easy to check: open the email on a phone and try to tap it.

How a shop connects to an ESIR

A web shop is not an ESIR. It is a system that knows what was sold and to whom, and it leaves issuing the receipt to an ESIR through an interface. In practice there are two ways.

A ready made plugin

For WooCommerce and similar platforms there is a plugin that talks to the register itself. A typical setup asks for four things:

• the ESIR address,
• an API key,
• the order status that triggers issuing the receipt,
• a mapping from the shop's payment methods onto the seven fiscal payment methods.

The third item is the one to think about before pressing save. If fiscalization is triggered by the "processing" status, and a cash on delivery order gets that status the moment it is placed, you have issued a receipt before you saw the money. For cash on delivery, as we understand it, the right status is a later one, set at dispatch or at delivery; which of the two moments applies, confirm with your accountant. For card payments it is the status set on successful capture, with an advance receipt if the goods have not been delivered yet.

The REST API

If the shop is not on a ready made platform, the same thing is done directly over the API. The request carries items, quantities, prices, tax labels and the payment method, and the response carries the PFR number, the counter, the journal and the verification link.

POST /api/v1/invoices
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{"invoiceType":"NORMAL","transactionType":"SALE",
 "items":[{"name":"Мајица","labels":["Ђ"],"quantity":1,"unitPrice":2490.00}],
 "payments":[{"paymentType":"CARD","amount":2490.00}]}

Tax labels per product

This is the most common cause of wrong receipts out of a web shop. A shop generally knows the price but not the tax label, because it never needed one.

The fix is to make the label a product attribute, exactly like the price. In WooCommerce that is done through a meta field, and in a custom system through a column on the product table. If the label is missing, the register either rejects the receipt or assumes something, and an assumption here is always wrong for at least part of the range.

What happens when something goes wrong

This is the part that usually does not get designed, so it gets solved live. Three situations are worth covering in advance:

• The processor is unreachable. The API has to return a clear error and the receipt is then not issued. The shop must not assume success. The order stays marked as not fiscalized and the attempt is repeated.
• The response is lost after success. The request went through, the network broke on the way back, the shop thinks it failed and sends again. Without protection that means two fiscal receipts for one order. The protection is called idempotency: the request carries a key, and the register answers the same key with the same receipt instead of issuing a new one.
• The customer cancels the order. An issued receipt is not deleted but corrected with a refund, which carries the original's referent number and a buyer ID.

How this works in Otkucaj

Otkucaj has a REST API v1 with Bearer keys and a ready WooCommerce plugin. The plugin writes the PFR number and the verification link into every order, and the per product tax label is set through the meta field otkucaj_label.

The API accepts an idempotency key, so a lost response cannot produce a second receipt. Errors are predictable and always the same shape, and a 502 means the processor did not answer and the receipt was not issued.

The details are in the API documentation.

Otkucaj is an ESIR approved by the Serbian Tax Administration, record number 1667, classification 3. A new account starts in the test environment, where receipts are not fiscal; production requires your own security element and PAC.