Fiscal receipts & the alternative regime

The Settings → Fiscal receipts screen answers two questions: who issues the fiscal receipt (касов бон) for each payment method in your shop, and whether your configuration meets the conditions of the alternative regime for online sales (Наредба Н-18, чл. 3, ал. 17) - the regime under which an online shop can operate without a fiscal device.

The page has two tabs: Fiscal receipts (the question below, who issues the бон per courier and way to pay, the check and the regime) and Приложение 33 (the declaration to НАП - see "The Приложение 33 helper").

At the top, the page asks one question - whether you issue касови бонове from your own fiscal device (see "Own fiscal device" below) - and by the answer ZweiHost offers or stops the payments that need one. The rest of the page is advisory: every option that needs a касов бон from your own device links to the setting that controls it.

Own fiscal device

At the top of Fiscal receipts you answer the question "Will you issue касови бонове from your own fiscal device for online orders?". It asks about use, not ownership: if you own a register but want the courier to issue the бон, answer "No".

• "Yes" - you issue a касов бон from your own fiscal device for every order not paid by card in the alternative regime, by bank or through a courier that issues the бон. Every payment method stays available.
• "No" - ZweiHost stops every payment that owes a касов бон from your own device:
• "I issue it myself" is cleared on every courier. Sameday, BOX NOW and Pigeon Express have no other choice, so cash on delivery through them stops. On Econt and Speedy, cash on delivery comes back once you choose "… issues it for me". A courier whose only method was cash on delivery drops out of checkout.
• Cash at store pickup stops - bank transfer and card stay at pickup.
• Card needs the alternative regime (the unique RF… number from НАП and the regime switched on below). While the shop is in the regime, card stays.
• Bank transfer, on account, and cash on delivery whose бон the courier issues do not change.

Saving "No" always shows a list first: everything that will switch off for your shop, and what is already so. It also says whether the payment methods in Приложение 33 (т. 7.1) change - then send the change to your accountant and file it with НАП within 7 days. A later "Yes" brings nothing back by itself: choose again on each courier's tab.

Until you answer, the shop works as under "No": "I issue it myself" and cash at store pickup are not offered to customers, and card without the regime cannot be set up.

Suggested "Yes". If your shop already had a payment with a касов бон from your own device when the question appeared (a courier on "I issue it myself", store pickup, or card without the regime), ZweiHost pre-selected "Yes", so nothing stopped. The answer is your declaration and is saved only once you confirm it with "Confirm "Yes"" or change it. An answer ZweiHost marked waits for your confirmation too. Under a saved answer you see who gave it and when.

So that a card payment your customers already use never stops, some saves are refused:

• "No" is not saved while you take card without the alternative regime - switch the regime on or stop card payments.
• The regime cannot be switched off while the answer is "No" (or there is no answer yet) and you take card.
• Connecting Stripe or Borica (in Settings → Billing) waits for a "Yes" or the regime.

A cash-on-delivery order placed before the "No" ships as plain cash on delivery and its бон stays yours - the order detail says so. If you choose "… issues it for me" on the courier before registration, the courier issues the бон.

In demo mode none of this stops a payment at checkout.

When a fiscal receipt is owed

The obligation depends on the payment method and on who collects the money:

• Bank transfer - no fiscal receipt is owed. The bank statement is the record.
• On account (business clients who pay once a month) - no fiscal receipt is owed: the summary invoice is paid by bank transfer. See Business clients.
• Cash on delivery collected as a postal money transfer (ППП) - none owed: the courier's receipt replaces the касов бон. No courier in ZweiHost collects cash on delivery as a ППП today - this applies only to Econt orders placed before 25 September 2026 (see Econt below).
• Cash on delivery via Sameday, BOX NOW or Pigeon Express - owed, from your own fiscal device. Their cash on delivery is not a ППП: Sameday holds a ППП licence, but our Sameday waybills request ordinary cash on delivery; BOX NOW's "cash on delivery" is a card payment link, and Pigeon's is plain contractual collection. That is why many merchants switch COD off for them (see Shipping & couriers). An 18а document issued earlier for a Sameday cash-on-delivery order stays on the order - decide what to do with it with your accountant.
• Cash on delivery via Econt - depends on your choice on the Econt tab (Settings → Couriers & shipping, the Receipt for cash on delivery field). Econt ended postal money transfers (ППП) on 25 September 2026 (parcels sent up to and including 24 September stay ППП). ZweiHost treats Econt cash-on-delivery orders placed before 25 September as ППП: they show no касов бон reminder, and the Приложение 38 audit file lists them with code 3. For orders after that: with "Econt issues it for me" every cash-on-delivery waybill carries the "Online sales without a cash register" agreement and the item list, and Econt issues the касов бон in your name - you do not owe it. You sign the agreement with Econt (it is free) and pick it on the tab. With "I issue it myself" the касов бон is owed from your own fiscal device.
• Cash on delivery via Speedy - depends on your choice on the Speedy tab (the same field). With "Speedy issues it for me" every cash-on-delivery waybill carries the order's items, and Speedy issues the касов бон in your name under its "Касов бон за наложен платеж" service - you do not owe it. The service must be in your Speedy contract: the tab checks this and says so when it is missing, and without it Speedy refuses cash-on-delivery waybills. Speedy's касов бон holds at most 20 lines, delivery included. So on a bigger order the pieces of one product share one line (for example "Чаша x5" for the five together), and an order with more than 19 different products plus delivery cannot use the service - registration stops with an explanation before anything reaches Speedy. With "I issue it myself" the касов бон is owed from your own fiscal device. Speedy holds a ППП licence, but our Speedy waybills request ordinary cash on delivery, not a ППП. An 18а issued earlier for a Speedy cash-on-delivery order stays on the order - decide with your accountant what to do about it.
• Card payment - owed by default: neither ZweiHost nor the card provider issues a Bulgarian fiscal receipt. The exception is the alternative regime below.
• Cash at store pickup - always owed: paying cash in person is the classic fiscal-receipt situation. That is why it is offered only with a "Yes" to the own-fiscal-device question.

Outside Demo mode, cash on delivery via a courier switches on only once you choose on its tab who issues the касов бон. Sameday, BOX NOW and Pigeon Express offer "I issue it myself" only, and it needs a "Yes" to the own-fiscal-device question. Until you choose, cash on delivery via that courier is not offered at checkout, and a cash-on-delivery order already placed through it cannot be registered with the courier - the order says what to choose. An order that leaves the касов бон on you carries a note in the order detail in Orders; an order whose бон the courier issues says so. For cash-on-delivery orders via a courier, ZweiHost issues no Приложение 18а document - whatever you choose, except for Econt orders placed before 25 September 2026 (see "Orders without an 18а document" below).

Should I issue a касов бон? At the top of an expanded order in Orders, a note answers this for every order. A blue note means you do not issue a касов бон, and says why: for a card payment in the alternative regime the Приложение 18а document replaces it (the note gives its number, or - if the payment is not confirmed yet - says the document will replace it); for a bank transfer or an on-account payment no бон is issued (Наредба Н-18, чл. 3, ал. 1); for cash on delivery the courier collected as a postal money transfer (Econt before 25.09.2026), the courier's receipt replaces it; and when the courier issues the бон, the note says so. A note with an amber icon means you do issue a касов бон from your own fiscal device, and says why: a card payment while the Приложение 18а documents are off, a card payment in the regime with no valid document (an order from before they were on, or with an annulled document), cash on delivery whose бон the courier does not issue, or cash at store pickup. A касов бон for a sale that already has a Приложение 18а document would record it a second time. The same card rule is under the documents switch here, in Fiscal receipts, and in the card note on every courier's tab.

The alternative regime, briefly

Наредба Н-18 lets an online shop register its remote card sales with documents instead of a fiscal device. The regime is not automatic - it is a package of three things:

• Приложение 33 - declaring the shop to НАП. Filed for every online shop, whatever payments it takes (Наредба Н-18, чл. 52м, ал. 1) - by you (with КЕП or ПИК), before sales start; changes are declared within 7 days. For the regime, НАП also assigns your shop a unique number.
• Приложение 18а - a document for every card sale. A document with a unique ascending number and a QR code, which the customer receives instead of a fiscal receipt.
• Приложение 38 - a monthly audit file. A standardized XML file with the orders delivered in the month (regardless of payment method) and the refunds made in it, which you submit to НАП by the 15th of the following month (verify the deadline with your accountant).

The compatibility check

The check on the page is computed live from your settings - the payment methods per courier, store pickup and card payments - and shows one of four results:

• No fiscal receipts owed - you take no cards, and your other payments need no бон from you: bank transfer, and COD via Econt and Speedy when the courier issues the бон in your name. You need neither a fiscal device nor the alternative regime, but the shop is still declared under Приложение 33.
• Configuration compatible with the alternative regime - you take cards, and no other enabled option needs a касов бон from your own device. Card sales can go under the regime, with no fiscal device; what remains are the documents (Приложение 33, 18а and 38) and your accountant's confirmation.
• Some payments need your own receipts - you take cards, and an enabled option (COD via a courier without ППП, or store pickup) needs a касов бон from your own device. Those options do not rule out the regime for card sales - you need a fiscal device for them, while card sales can go under the regime. Before you rely on the regime, see the чл. 3, ал. 17 question in "The Приложение 33 helper" below: without a "Да" there НАП issues the shop no number.
• Your own fiscal receipts are required - you take no cards, and an enabled option needs a касов бон from your own device.

The check also follows the own-fiscal-device answer: under "No", couriers on "I issue it myself" and cash at store pickup are stopped, so they no longer need a касов бон from you.

Under the question, the "Who issues the касов бон - by courier and way to pay" card shows, for each courier you have switched on and for store pickup, who issues the бон for cash on delivery, bank transfer and card: you (from your own device), the courier in your name, or no бон - for bank transfer, and for card in the alternative regime, where the Приложение 18а document replaces the бон. The sentence above the table says which payments you receipt yourself. Under each courier's name is who issues its бон, as set on its tab ("I issue it myself", "… issues it for me" or "not chosen"). Ways to pay that a "Не" answer switched off stay in the table, greyed, with the reason - for example "Switched off - answer «No» - needs a device of your own" for BOX NOW, or "Not offered - answer «No»" for cash at store pickup. Couriers that are switched off or not connected are left out. On a phone each courier is a card of its own.

Under the result, every option that needs a касов бон from your own device is listed with a link to the setting that controls it. COD via Econt or Speedy whose бон the courier issues in your name is listed separately, with a tick: you owe no касов бон and need no device of your own for it.

When you take cards and payments with a касов бон (yours or the courier's), the page also adds a note about Приложение 33: the чл. 3, ал. 17 question in part 7 of НАП's form is still in its pre-2021 wording. See "The Приложение 33 helper" below.

The documents ZweiHost issues

Once you enable the regime from Settings → Fiscal receipts (the "Issue Приложение 18а documents automatically" switch), the platform takes over the two recurring documents:

• Приложение 18а - automatic, at every card payment. The moment a card payment is confirmed, ZweiHost issues the document - with a unique 10-digit ascending number - and emails it to the customer as an attached PDF. You also see it on every order (the "Download sale doc (18а)" button), and account customers can download it from their profile. Only a card payment gets this document: НАП confirmed in writing on 27 October 2026 that for a bank transfer, a postal money transfer and a sale recorded with a касов бон (the courier's included) a чл. 52о document is not allowed. Every other order gets an "Електронна бележка" (see below). The document carries your shop's letterhead (logo and name at the top, contacts and the page number at the bottom), fixed at the moment of issue - the QR code and the required details stay exactly where they were.

The wording depends on the payment method. For a card payment it is a "Документ за регистриране на продажба по чл. 52о от Наредба № Н-18" (sale registration document), issued under чл. 3, ал. 17, with the Приложение 18а QR code. Every other one is an "Електронна бележка" (electronic sale note) - no reference to чл. 52о, no QR code, and a note that it is neither a cash-register receipt nor an invoice: for bank transfer and on-account payment the note adds that payment had not been received on the date of the document (on account: "Agreed payment method: credit transfer"); for cash on delivery - that payment had not been received and who issues the касов бон (for example "issued by Speedy on delivery" or "by the merchant at payment"). Documents issued before 9 October 2026 keep their QR code. No document and no email to the customer contains the word "фискален" (or "fiscal" in English): чл. 7а, ал. 3 of Наредба Н-18 bans it on customer documents other than a fiscal receipt. A document issued earlier and downloaded again comes out with the new wording - its number, lines, amounts and QR code do not change.

• Приложение 38 - monthly, from Reports → НАП audit file. Pick a month with the "‹ August 2026 ›" arrows and download the ready XML in НАП's official schema - it contains every order delivered in the month and the refunds made on them in the month (see "Which orders go into the file" and "Document numbers in the file" below). Submitting it to НАП stays with you - through your own НАП profile (КЕП/ПИК), by the 15th of the following month.

A document for every order. While the regime is on, every order not paid by card - cash on delivery, bank transfer, or cash at store pickup - gets an "Електронна бележка" by email the moment it is placed, as on other online-shop platforms. The note carries the order's number, not a number from the Приложение 18а document series, is not a касов бон and never goes into the audit file: for cash on delivery the касов бон is still required, and the note says who issues it. "A document for every order" turns on by itself, together with the Приложение 18а documents, and turns off with them. The switch in the regime card shows since when it is on; only ZweiHost can turn it off for a particular shop - write to us if you want your shop to be an exception. If it already is one, the line under the switch says it is off by ZweiHost although the regime is on. It applies only to orders placed after it is turned on: no back-dated note is ever sent. The documents non-card orders received before 27 October 2026 stay as the customer received them, with their numbers - but they never go into the file.

The screen shows four figures for the chosen month - orders in the file (the ones delivered in the month), refunds, ready for the file (how many of them need nothing from you - in practice all of them, except a card order without a document) and the filing deadline (the 15th of the following month; when that is a Saturday or Sunday, the next working day) - and the blocks:

• "Ready to submit" shows the actual values that go into the file: whether the alternative regime is on, whether "A document for every order" is on (and since when), the company number (ЕИК), the НАП e-shop number, the web address in the file, how many orders and refunds go into the file and how many card documents. At the top right (on a phone, under the heading) sits one status for the whole block: "Ready to download", "1 step left" (how many details are still missing), "1 order without a number" (a card order still missing its касов бон), "Nothing to file" or "Regime not enabled". A missing ЕИК or number reads "Not filled in" with a link to the screen where you fill it in - that way a wrong ЕИК is caught here rather than by НАП. The web address is never missing (the file always has one), but while it still uses your shop's domain instead of the declared address, it says "not yet checked against your declaration" with a link - see "The web address from your declaration" below. The Download XML button is enabled once the ЕИК, the НАП number and at least one delivered order are in place and no card order is left without both a document and an entered бон. If no order was delivered in the month, there is nothing to file for it - no empty file and no notice, even if you refunded money on an order that month (see below). If the file still cannot be created, the screen comes back and shows the reason under this block.
• "Card orders without a document" appears only when an order paid by card was delivered in the month without a valid document - paid while the regime was off, or its document was annulled. If you recorded it with a касов бон, you enter the бон's number and date and press Save - the row then shows "Saved" and can be changed. The order goes into the file as paid with a касов бон (code 6), without a document number: the бон's number stays your record, because НАП does not want a бон's number in the file. A cash-on-delivery, bank-transfer or cash order is never in this list - you enter nothing for it. A card order you never recorded at all is a question for your accountant.
• "What the file contains" splits the orders, refunds, orders with a document (card) and orders with an entered бон by courier - so you can check the figures against the Sales report. It is for checking only: the file always contains every order delivered in the month, whatever the courier. That is why there is no courier filter here either. For a month up to June 2026 inclusive, a note under the table may also list orders marked delivered before 28.06.2026: ZweiHost did not record the delivery date then, so they are in no file. If one of them was delivered in the chosen month, discuss it with your accountant.

Which orders go into the file. Наредба Н-18 (чл. 52т, ал. 2) asks for the orders whose delivery took place in that month - not the orders placed in it. An order placed on 28 August that the customer receives on 2 September goes into the September file. ZweiHost takes the delivery date from the moment the order becomes Delivered - automatically from the courier, or when you mark it delivered (for store pickup, collected). So:

• A cancelled order is in no file - it was never delivered. If you refunded money on it and it was paid by card and has an 18а document, the refund goes into the refund list of the file for the month you made it - but only if at least one order in the file was delivered in that month. НАП's format needs at least one delivered order in every file, and empty or made-up orders are never filed. So a refund in a month with no delivery at all goes into no file: for example a card order paid on 3 November, cancelled before shipping and refunded on 6 November, when nothing else was delivered in November. The screen shows it in the refunds column, but the Download XML button stays disabled. Discuss such a case with your accountant.
• An order still on its way goes into the file only for the month it is delivered in. The Sales report counts orders by order date, so the two documents can show a different number of orders for the same month.
• Order history brought in with the order import is not in the file - the import carries no delivery date, and those months were reported by your previous platform.

Confirm the approach with your accountant.

Document numbers in the file. While the shop is in the alternative regime, every delivered order goes into the file - those recorded with a касов бон (cash on delivery, cash at store pickup) and bank transfers included. Only an order paid by card carries a document number and date - its Приложение 18а document's. Every other order goes in without a document number or date: that is НАП's written instruction of 27 October 2026 for the sales no чл. 52о document is issued for ("елементите <doc_n> и <doc_date> не се подават с файла"). A касов бон's number, an electronic note's, or an older document's on a non-card order never goes into the file. Neither does an annulled document's number. The document numbers in the file are 10 digits and never repeat - within the month or against earlier months. Refunds are listed for every delivered order, and for a card order with a document also when it was not delivered. НАП's official XSD schema still describes the two elements as required, so a validator such as validator.napready.bg may flag the orders without them - that is expected. If НАП's portal refuses such a file, keep the refusal and НАП's letter and write to us.

How the money went back. For each refund the file states how the money reached the customer: a card payment goes back to the card (code 2), a bank transfer or an on-account payment goes to a bank account (code 1). A cash-on-delivery order refunded through Orders → Returns also goes to a bank account (code 1), because there the customer gives their IBAN and you transfer the amount to it (see Returns). If you refunded a cash-on-delivery order some other way, without a return in Returns, ZweiHost does not know how the money went out, and the file lists the refund as "other" (4). The "cash" code (3) is not used - the platform does not record cash refunds. Confirm the approach with your accountant.

A summary invoice replaces neither of them. If you issue a monthly summary invoice to a business client (see Business clients), the 18а documents for their card-paid orders keep being issued automatically, each at its own payment - those are the fiscal document for the payment, while the invoice is the tax document for the deliveries. Приложение 38 is unaffected too: the file describes orders, not invoices. Orders paid on account go into the file as a bank transfer (code 1), because that is what they are - a bank transfer made later. Confirm that reading with your accountant.

Free delivery. When delivery is free for the customer - with Free delivery, or above the amount of Free delivery over (see Shipping & couriers) - the 18а document, Приложение 38 and the courier's item list or касов бон carry the goods only: there is no "Delivery" line, because the customer does not pay for it. You pay the courier under your contract with them. That amount is not a sale but a cost: you see it in the order, and in Expenses when its Delivery source is on. If you issue the касов бон yourself, it covers the goods only too. Confirm the treatment with your accountant.

Delivery the customer pays the courier for. When Shipping & couriers sets The customer - to the courier for a payment method (with Econt, Speedy and Pigeon Express), the delivery is the courier's service to the customer: the customer pays the courier directly on receipt, and the courier documents it. Your sale is the goods only. So the 18а document, Приложение 38, Econt's item list under "Онлайн продажби без касов апарат" and the касов бон Speedy issues for you ("Касов бон за наложен платеж") carry the goods only, with no "Delivery" line, and still add up to the cash-on-delivery amount exactly. If you issue the касов бон yourself, it covers the goods only too, and if you are VAT-registered, the VAT base is the goods. If the customer refuses the parcel, the courier bills you for both legs - a cost, as with any returned parcel. Confirm the treatment with your accountant.

Before enabling the regime, fill in the НАП e-shop number (assigned at the Приложение 33 declaration) - documents cannot be issued without it.

The card also carries two fields for the 18а document numbering: "First document number" sets where the 10-digit ascending series starts (locked once the first document is issued) - give it a high block if you issue such documents outside the store too, exactly like invoice numbers; "Series ceiling" (optional) stops issuing at that number so the block can't overrun into another declared series - the ceiling can always be raised, never below what is already issued.

The web address from your declaration

The Приложение 38 audit file carries a <domain_name> field - your shop's web address. НАП compares it character for character with the web address you declared in Приложение 33, item 4.2: if the declaration says https://www.example.bg and the file says example.bg, the submission is rejected even though both point at the same shop.

So the Settings → Fiscal receipts card has a "Web address from your declaration (Приложение 33, item 4.2)" field. Fill it in exactly as in your declaration - the whole string, with the scheme (https://) and www if they are there. The file prints that text unchanged, rather than guessing from your live domain.

To save you retyping it, the "Fetch from the НАП register" button finds it in the public e-shop register by your company number (ЕИК):

• One shop - the address is saved automatically; the row reads "Confirmed in the НАП register on …".
• Several shops - you pick which address, with the row whose domain matches the shop's own highlighted. Saving checks your pick against the register again; if the register cannot be reached at that moment, nothing is saved and you can try again shortly.
• No record - a newly filed declaration appears in the register within a few days; until then type the address in by hand.
• Register down or no ЕИК - type the address in by hand; the field stays fully usable without the register.

The lookup runs only when you ask for it (and once automatically, the first time you save the НАП number with the address still blank). Downloading the file never waits on НАП - it reads the already-saved value. An address you edit by hand is marked "Entered by hand" and loses its confirmation date.

If you leave the field empty, the file uses your shop's domain (your own domain, otherwise the zweihost.com subdomain), and the "Web address in the file" row under "Ready to submit" says this address has not yet been checked against your declaration.

The Приложение 33 helper

The Приложение 33 declaration is filed for every online shop, before sales start, whatever payments it takes - also when it takes only bank transfer and ППП cash on delivery, and when it does not use the alternative regime (Наредба Н-18, чл. 52м, ал. 1). Each shop is declared separately.

The e-shop declaration is hard to fill accurately because its hardest fields - software name and version, hosting provider, where the database lives, the split between a bank virtual POS (7.2.1) and a payment-service operator (7.2.2) - are platform facts no merchant knows on their own.

The Приложение 33 tab of Settings → Fiscal receipts is a ready-to-copy answer sheet: every field of the НАП form, in the form's own order, on one line - number, field, the exact value to copy and a copy button. The values come from your settings (name, ЕИК, address, domain, payment methods, the IBAN from your bank-transfer text) and from the platform's facts (ZweiHost as the software, the hosting, the EU database, Stripe's identification as a payment-service operator). An empty setting is never presented as "none" - instead of a value you see a link to the place that fills it. The notes under the values are cut to about one sentence - tap a note to read it in full. The platform's ten technical fields (hosting, software, database - the same for every ZweiHost shop) are folded into one line, "Platform technical data"; open it when you copy them. "What this sheet is" at the top is folded too.

"I filed it with НАП". Once you have filed the declaration, press "I filed it with НАП" and pick the filing date (today by default; it cannot be in the future). ZweiHost keeps the sheet's content as it is at that moment and compares the sheet against it from then on. Until you mark a filing, the tab shows "Mark when you filed the declaration". A filed declaration with no changes shows "Filed on … - no changes since", and "Change the date" corrects the date.

As soon as anything in the declaration changes - wherever it came from: the domain, the payment methods (a "Не" answer on the Fiscal receipts tab included), card, the bank account, the company details or a value edited on the sheet itself - a warning appears at the top of the tab: every change must go to your accountant straight away and into НАП's register, within 7 days of the change (Наредба Н-18, чл. 52м, ал. 3). It lists exactly what changed and where it came from, and - where ZweiHost knows when (your own domain connected, the "Не" answer) - the date. Changed rows on the sheet are marked "Changed", with the old value. One sentence about the change also appears on the Fiscal receipts tab, above the question, with a link to Приложение 33. The warning cannot be hidden: it goes once you file the change and press "I filed the change with НАП" - ZweiHost then keeps the new content. The platform's technical data is not compared, so a new ZweiHost version never raises the warning.

The "Download PDF for your accountant" button downloads the whole sheet as a Bulgarian PDF with numbered pages - send it to your accountant and they type the answers into the portal without ever opening the BackOffice. The НАП portal is an interactive questionnaire - the declaration is not submitted as a file, so the ready document is the maximum possible automation; the filing itself stays with your НАП profile.

A few rules the page repeats because they matter:

• Filing stays with you - through the НАП e-portal, with a КЕП or ПИК, before the shop starts selling.
• Fill only one of 7.2.1 and 7.2.2 - with Stripe you fill 7.2.2 (payment-service operator), with Borica 7.2.1 (a virtual POS from your own bank). Never both.
• Changes are declared within 7 days - a new domain, payment method, provider or account means re-filing. If you marked your filing with "I filed it with НАП", the tab tells you when that happens.
• Enter the received RF number in Settings → Fiscal receipts - without it the Приложение 18а documents cannot be issued.

Some rows are editable right on the page - the ones whose value is a suggestion rather than a setting: the goods category and description (defaulting to your catalogue categories), the start date (defaulting to the shop's creation in ZweiHost - a migrated shop corrects it to the real one), the registered seat (when it differs from the activity address), the payout-account IBAN and the "Да"/"Не" answer to the чл. 3, ал. 17 question in part 7 (see below). An edited value is saved, flows into the PDF too, and can always be reset to the suggestion. Identity data (name, ЕИК, ДДС, contacts) is not edited here - it is filled in its real settings, which the sheet links to.

Does a new courier need declaring? The declaration describes payment methods, not couriers. Adding a courier whose cash on delivery is a ППП changes nothing declared if the „пощенски паричен превод" box is already ticked. Enabling cash on delivery via a courier without ППП (Sameday, BOX NOW, Pigeon Express, Speedy, and Econt since 25 September 2026), however, adds a payment method that requires a fiscal receipt - a change of declared circumstances (re-file within 7 days). The alternative regime for card sales stays available, but the чл. 3, ал. 17 question is affected (see below). If you add such a courier for deliveries only, with COD switched off for it, nothing declared changes. A shop that declared Econt COD as a postal money transfer is in exactly this position since 25 September 2026 if Econt COD stays on. The same goes for a shop that declared Speedy or Sameday COD as a postal money transfer, while that COD stays on. The practical rule: mark every filing with "I filed it with НАП" - the tab then compares the sheet with what you filed and says what differs; when it does, you owe a new filing.

The чл. 3, ал. 17 question in part 7. The first question of part 7 (a "Да" unlocks the чл. 52р block and gets the shop its unique number) ends with "…и не приемате други плащания, изискващи издаване на фискален бон" (and you accept no other payments that need a fiscal receipt) - wording Наредба Н-18 deleted on 26.02.2021. You pick the answer from the row's dropdown: "Да" if you issue Приложение 18а documents for card payments and file the monthly Приложение 38 XML file, both generated by ZweiHost; "Не" if you issue a fiscal receipt for card payments too. If you take only cards and bank transfer, the sheet suggests "Да" - switch it to "Не" if you fiscalise with your own device. If you take cards and payments with a fiscal receipt (cash on delivery or cash at pickup, whether you or the courier issues the receipt), the sheet deliberately suggests no answer: today that does not stop your card sales from using the regime, but read literally the answer is "Не", and without "Да" НАП issues no number, so no Приложение 18а documents can be issued. Decide the answer with your accountant and ask НАП for guidance if needed. The answer you pick goes into the PDF too. If you take no cards, the answer is "Не" and cannot be edited.

What ZweiHost does and does not do

What we do: show the fiscal-receipt warnings on every order and courier, maintain the compatibility check, prepare the ready-to-copy answers for the Приложение 33 declaration, and issue the alternative-regime documents (Приложение 18а automatically at payment; Приложение 38 as a downloadable monthly file).

What we do not do - and cannot do:

• ZweiHost is not a fiscal device and not registered fiscalisation software - it issues no касови бонове for any payment method.
• ZweiHost is not a licensed postal operator - it does not collect money as postal money transfers.
• ZweiHost files nothing with НАП on your behalf - declarations and audit files go through your own НАП profile (КЕП/ПИК), submitted by you or your accountant.
• ZweiHost gives no tax advice - your accountant has the final word.