We would like to clarify that this case should be treated not as a generic product defect, but as a Polish localization and legal compliance issue.

The current system behavior results in a situation where a final invoice that fully settles an advance invoice (1:1), applies a 0% VAT rate, generates no additional VAT amount, and does not change the taxable base is nevertheless reported in JPK_V7M with “0” values. This occurs solely due to tax transaction splitting triggered by exchange rate differences between ledger and bank postings. While the tax transaction split may be technically correct from a core Finance perspective, the resulting JPK_V7M output is not compliant with Polish VAT reporting requirements.

Pursuant to Article 109(3) of the Polish VAT Act and the Regulation of the Minister of Finance of 15 October 2019 on the scope of data included in VAT records (JPK_V7), VAT records — and consequently JPK_V7 — must include only documents that affect VAT settlement. Only transactions generating a tax obligation, changing the taxable base, or impacting VAT amounts should be reported. A final invoice that fully offsets an advance invoice (1:1), does not create a new tax obligation, does not increase VAT payable, and does not change the taxable base, therefore must not be reported as a separate entry in JPK_V7. This approach is further confirmed by official explanations of the Polish Ministry of Finance, which state that invoices that do not affect VAT settlement — including final invoices fully settling advances — should not appear as separate entries in JPK_V7. Reporting such documents with zero values solely due to technical transaction splitting caused by exchange rate differences leads to non-compliant VAT reporting under Polish regulations.

This situation cannot be resolved through standard configuration and forces customers to implement custom reporting logic. As a result, customers are exposed to audit risk and potential penalties, as tax authorities may interpret the inclusion of such zero-value entries as incorrect or misleading VAT reporting, given that they do not reflect actual VAT-relevant events.

We therefore kindly ask you to reclassify this case as a Localization / Legal compliance gap for Poland and to consider implementing one of the following solutions: suppressing final invoices (1:1 advance settlement, VAT 0%) from JPK_V7M regardless of bank exchange rate differences, or providing a dedicated configuration option or localization flag within the Polish localization to control this behavior.