An online shop with no fiscal device: the article 3(17) regime

What the regime actually is

The ordinary rule is that a card payment is treated as cash-like and requires a fiscal receipt. For e-commerce, Ordinance H-18 makes an exception: for remote card payments a shop may skip the fiscal device if it instead issues a specific document for every sale and files a monthly audit file.

The trade is about transparency. A fiscal device reports to the revenue agency in real time; here the same visibility comes from numbered documents whose numbering cannot have gaps, plus a monthly file containing every order in the period. For a shop selling only online, the second is considerably cheaper and simpler than a cash register.

The conditions, all of which must hold

This is where most shops fall out, and for surprising reasons. The regime applies only if the shop accepts NO other payment that would itself require a fiscal receipt. Bank transfer is compatible. Cash on delivery via a ППП-licensed courier is too. But cash paid on collection from a physical location, or cash on delivery via a courier without a ППП licence, takes the whole shop out of the regime - not just those orders.

The remaining conditions are about the software and the document: the shop must meet the ordinance’s requirements on data integrity and authentication, and the document itself must carry a unique ten-digit ascending number, merchant identification, references to the order and the payment transaction, the item lines with their tax groups, the totals, and a QR code per Appendix 18a.

In ZweiHost this is not something you check by hand. Settings carries a page that reads your live configuration - which couriers are enabled, which payment methods they allow, whether store pickup is configured - and says plainly whether you qualify, and if not, exactly what disqualifies you and where to fix it.

The Appendix 18a document

On every confirmed payment under the regime the customer receives a sale registration document. Its numbering is separate from your order numbers and must have no gaps - which is why it runs off its own counter rather than the order number, which burns a value on a failed order.

The QR code is not decoration. Its contents are precisely specified: the shop’s number with the revenue agency, the order number, the transaction reference, the date, the time and the total. ZweiHost generates it in that format and sends the document to the customer as a PDF attached to the order email; you can also issue and download it manually from the order.

The monthly Appendix 38 file

Once a month you file a standardised audit file containing every sale for the month, not only the card ones. Each line carries a net price, a VAT rate and amount, and a gross total; shipping is its own line; and the payment method carries its own code. Refunds executed in the month go in too.

The format is strict and is validated against the revenue agency’s official schema. ZweiHost builds the file from your orders and hands it to you as a download with a month picker, telling you first how many orders and refunds it will contain and what is missing from your settings if anything blocks it. Filing goes through your own tax portal - that is the step that stays with you or your accountant.

What stays with you

First of all the Appendix 33 declaration - the e-shop information filed through the tax portal with an electronic signature or PIN before sales begin. Some of its fields are our facts, not yours: the software name and version, where the site is hosted, where the database sits. ZweiHost pre-fills them so that you or your accountant can submit them.

And the decision whether to enter the regime at all. If card payments are a small share of your turnover, the simplest route may be not to accept them: a shop taking only bank transfer and ППП cash on delivery owes a receipt on nothing and has no monthly obligation. That is a perfectly legitimate choice, not a workaround.