Fiscalisation is the legal obligation to record turnover through a fiscal device, and with an online store the question becomes how an online order turns into a fiscal receipt. In practice there are 2 approaches: issuing receipts manually per order, or connecting the store to the fiscal system automatically.
An online store does not issue a fiscal receipt by itself. It records the order, the payment and the address, but fiscal recording is a separate system with its own rules.
At low volume this is handled manually - the order arrives, a receipt is issued, the goods are shipped. Simple, but every receipt takes someone’s time.
As order numbers grow the manual route becomes a bottleneck and a source of errors, and the question of connecting arises.
Manual. The order from the store is retyped into the receipt-issuing program. No development cost, but a cost in time and a risk of error during retyping.
Automatic. The store connects to the fiscal solution over an API, so the receipt issues itself. It requires development and maintenance but removes both the time and the errors.
The decision follows volume. With a few orders a day manual is reasonable. With dozens, automation pays for itself quickly.
Check with your accountant what your specific activity and payment methods require. Rules differ and change, so that conversation comes before development, not after.
Check whether your fiscal solution has any connection route at all. Some older programs have none, and then automation is not a budget question but a feasibility one.
Align the data. Items in the store and items in the fiscal system must match by name, tax rate and unit of measure, or the connection cannot be reliable.
Decide what happens with cancellations and refunds. That is the part most often forgotten until it happens for the first time.
The payment method changes the procedure. Card payment, cash on delivery and bank transfer are not treated identically, so one flow does not cover every case.
Selling abroad adds its own rules, both on tax and on receipts.
Reporting. When data lives in two separate systems that disagree, every monthly reconciliation becomes manual work.
That is why on a serious online store the fiscal side is planned together with the store itself, not added as an afterthought.
The payment method comes first. A card is treated differently from cash on delivery, and a bank transfer differently from both - so a single flow rarely covers every online sale channel.
The second is catalogue alignment. Every item in the store needs a counterpart in the fiscal system, with the same tax rate and unit of measure. A misaligned catalogue is the most common reason an integration does not work reliably.
The third is exception handling. Cancelling an order, a partial refund, replacing an item - each of those needs its own procedure, and they are usually not planned in advance.
The fourth is reporting. If data lives in two systems that do not agree, monthly reconciliation becomes manual work that cancels part of the saving the integration was built for.
One further note on tax: if you sell items with different tax treatment, make sure every rate has a counterpart in both systems before the store goes live. Correcting receipts already issued is work nobody wants.
Last updated: 17 August 2026
Send the address and we will tell you where you stand - no obligation.
Send an enquiry
