1. What was released on 13 January?
The Tax Administration published a Q&A set clarifying how Fiscalization 2.0 works in practice—how FiskApplication displays statuses, how issuer/recipient pairing is read, and how the initial implementation phase will be handled so business keeps moving as systems settle.
2. How the first phase will be handled by the authorities?
The Administration stresses a partnership approach and the principle of opportunity in the opening phase. Routine mistakes at the start won’t trigger misdemeanour proceedings. Authorities will first seek clarification; only intentional misconduct risks proceedings.
3. Sanctions: approach in the opening months?
This isn’t a blanket amnesty. Early-phase handling prioritises correction over punishment. To avoid issues:
- Keep issuing and fiscalizing within legal windows (including the 5-day rule for received e-invoices).
- If you reject an e-invoice, eReport the rejection so FiskApplication reflects the correct status—no manual status edits needed.
- Keep simple evidence that your authorisations, routing, and services were in place or swiftly fixed.
4. Reading statuses inside FiskApplication
Two layers combine into one reading:
- Message status: Received (delivered), Charged (issuer reported payment), Rejected (recipient reported rejection).
- Pairing: Unpaired (only one side sent), Paired (both sides match), Deviation (both sent, data differ).
Examples: Received & Unpaired (one side sent), Received & Matched (both match), Rejected & Deviation (recipient rejected; details differ).
5. When an e-invoice shows as “non-fiscalized”
If the counterparty fiscalized but you haven’t, it appears under Non-fiscalized eInvoices. Usual checks:
- Missing authorisations in FiskApplication.
- Invoice not received—confirm with your Information Intermediary (received or rejected?).
- Service not contracted—ensure outgoing/incoming fiscalization services are active.
Note: if authorisation was misconfigured during implementation, you do not need to retro-fiscalize already issued invoices; a flexible approach applies while businesses adapt.
6. What “Deviation” signals?
Deviation flags a data mismatch (e.g., one side “0” vs the other “null”). It’s not a reason to reject, correct, or resend. The commercial liquidation step decides invoice validity and any rejection. As software aligns, Deviation should decline.
7. Who to contact when something looks wrong?
Start with your ERP provider (what exactly was sent) and your Information Intermediary (transport/validation). If the e-invoice looks correct yet still mismatches in FiskApplication, involve your internal authorised person for fiscalization. The Tax Administration steps in for clarifications or persistent anomalies.
8. Access and authorisation in FiskApplication
Access runs through ePorezna. Visibility sits with the authorised person designated by the taxpayer. The app is available to all entities covered by the law.
9. What the app shows—and its limits
FiskApplication provides:
- Views of fiscalized data from F1.0, F2.0, and eReporting (B2B and B2C).
- An informative VAT return (built from fiscalized data with maximal input-tax assumptions).
- Statuses (sent/received/paid/rejected), fiscalization errors, and entry forms for fiscalization/eReporting.
It’s informative only: the taxpayer remains responsible for the official VAT return; certain non-invoiced activities and deduction limits aren’t reflected in the app.
10. Identifiers, consent, and non-VAT taxpayers
- Identifiers (MPS → AMS) are data delivery, not user registration or extra consent. Confirming your intermediary in FiskApplication publishes your identifier in AMS.
- Not in the VAT system? If you won’t use MICROeINVOICE, you must select and authorise another Information Intermediary in FiskApplication. From 1 January 2026, even non-VAT taxpayers must receive e-invoices, fiscalize them, and eReport rejections
