Lack of VAT registration in the timeframe expected by the Polish VAT rules generates quite wide range of practical doubts how to suit documentation and settlements to the new reality.

Although, based on EU VAT approach, it is not necessary to formally get registered in order to be considered a VAT taxpayer, in practice, if the company is not registered for VAT, it cannot benefit e.g. from VAT deduction or VAT refund (see: CJEU in case C-101/16, SC Paper Consult).

There is also quite a lot of issues that should be checked or planned before VAT registration will be done retroactively. Below we present key aspects discussed with our Clients and tax authorities while performing retroactive VAT registrations (on invoicing, financial effect of the process, formal difficulties).

Can purchase invoices received before the VAT registration date be settled?

If a taxpayer received purchase invoices, he has no right to deduct input VAT before he is formally registered. After registration – the deduction is possible.

Invoices issued before VAT registration usually does not have a Polish VAT number of the purchaser. The chance to correct them is small - suppliers argue that at the time of the transaction the taxpayer was not registered for VAT, and therefore they are not willing to add / change the VAT number on the issued invoices, as well as in the submitted SAF-T files and recapitulative statements. This creates inconsistencies and lead to checking activities.

Nevertheless, based on our practice, despite the discrepancies in the submitted VAT reports, in the end tax offices grant taxpayers the right to deduct input VAT from purchase invoices received before the date of formal registration for VAT.

Can sales invoices be issued before VAT registration in Poland?

It is highly unrecommended to issue sales invoices with Polish VAT without VAT registration.  Such proceeding exposes the seller to VAT sanctions and fiscal code penalties. Moreover, due to way of VAT reporting in Poland, issued invoice may be swiftly included by the customer in Polish VAT return and thus, tax authorities may start control activities to check why the seller is not VAT registered (what may bring business discussions with the client).

Therefore, if invoice needs to be issued, the recommended way is to submit VAT registration documents as soon as possible, and then – proceed with the invoicing process.

It may happen however, that before VAT registration in Poland, a foreign taxpayer issue invoices to the Polish customer under reverse charge mechanism (without Polish VAT; with own, foreign VAT number). The necessity of retroactive registration may force both parties to correct past settlements (usually a lengthy process, generating a lot of practical doubts and documentation difficulties e.g. on how to issue correction document, or on exchange rates applied for calculation of VAT amount).

VAT due or VAT to be refunded

Sometimes it is not possible to assess in advance what will be the final financial outcome and cashflow issues of retrospective VAT settlement.

There is no annual VAT report in Poland, VAT is settled either on monthly or quarterly basis, interest, if any, is calculated from the date when VAT was due to the tax office (as a rule 25th of the month following the reporting period).

Therefore, to properly calculate amounts to be paid, incl. penalty interest, or input VAT to be refunded, all transactions to be reported needs to be firstly allocated to the proper VAT returns.

Nil VAT returns

If no documents are to be reported in a given period, a taxpayer is obliged to submit a nil return. So, even only few transactions needs to be reported in the past, SAF-T files for each month starting from the date of past registration date needs to be prepared and submitted.

Is supplier authorized to apply 0% VAT rate on EU-supplies performed before registration?

Taking into account literal wording of VAT provisions, applying 0% VAT rate for intra-community supplies made before getting Polish VAT number may bring risk for the supplier. At the moment of the supply, the supplier should possess active VAT number for IC-supplies granted by the country of dispatch. Moreover, in EC Sales and Purchase List such supply should be properly reported to guarantee 0% VAT rate. Recently, negative tax rulings are issued by tax authorities on that matter.

Despite it, in practice, taxpayer are sometimes allowed to use 0% VAT rate for the past supplies – that requires however to explain deeply and clearly the reasons of delayed registration and reporting (not only through showing that mistake has been done, but also by showing how the process of structuring past transactions and making decisions was performed taking into account the unproper results of actions taken).

Mandatory split payment mechanism

If transactions performed should have been settled under mandatory split payment mechanism (‘MPP’), retroactive registration may result in obligation of issuing invoices with MPP annotation and executing payment of VAT amount into supplier’s Polish VAT account (details in our article – Split payment mechanism). Verification of this aspect is essential to properly structure the process of adjustment the past settlements properly.


Although the process of submitting delayed VAT reports as well issuing and settling of invoices may generate some discussions with tax authorities, at the end – our Clients are able to fix initial fault and gain VAT position in accordance with VAT rules (e.g. by deducting VAT from purchases connected with Polish registration). In disputes with tax authorities following individual tax rulings may be signaled: 0113-KDIPT1-3.4012.493.2022.2.OS dated November 21, 2022, 0112-KDIL1-3.4012.670.2021.2.MR dated February 28, 2022 (as they confirm e.g. right to deduct VAT from invoices issued before VAT registration).


Retroactive VAT registration requires assistance of experienced experts who will spot any aspect and risk related to performed transitions and their delayed VAT settlement in order to reduce administrative, fiscal and financial burdens for the taxpayer.