JPK_V7M(3) Validator Poland
Verifique um ficheiro JPK_V7M(3) com o XSD oficial do Ministério das Finanças polaco e veja se os seus registos contradizem a sua declaração — no navegador, sem envio.
What is JPK_V7M, and how does it differ from KSeF?
JPK_V7M is Poland’s monthly VAT control file: a single XML document that combines the VAT declaration (the <Deklaracja> part, the P_* boxes) with the sales and purchase registers (the <Ewidencja> part, the K_* columns). It is not an invoice — invoices live in KSeF. Variant (3) has been in force since 1 February 2026, and the schema itself carries that date (TDataCzas minInclusive). This free validator checks the file against the official Ministry of Finance XSD, then runs the check no schema can perform: whether the sums in the registers actually reached the right boxes of the declaration. Everything happens in your browser — the file never leaves your machine.
The schema is one thing; registers agreeing with the declaration is another
The first layer is the official JPK_V7M(3) XSD from the Polish Ministry of Finance. Structure, types, cardinalities and closed code lists are never re-encoded by hand. One trap worth naming: the imported MF modules (StrukturyDanych v12, KodyKrajow v13) are DIFFERENT versions from the ones KSeF uses — different namespaces, different files. They must not be “factored together”.
The second layer is where the value is: no free validator will tell you that your register contradicts your declaration. We check the K_* column sums against the P_* boxes, the control counters (LiczbaWierszySprzedazy, LiczbaWierszyZakupow), the row numbering, and the NIP check digit (mod 11). Only boxes that are a PURE SUM are compared — P_10 to P_36 and P_40 to P_47. Boxes such as P_37, P_38 or P_39 are computations of the declaration itself rather than the aggregation of a column; treating them as sums would produce false alarms.
Why warnings rather than errors? Two independent reasons, both verified. First, the ministry’s own two sample files declare LiczbaWierszySprzedazy = 0 while carrying a sales row, and their NIP (1010000000) fails the mod-11 check — it is a placeholder. A blocking check would reject the ministry’s own examples. Second, the ministry publishes no list of numbered rejection codes (unlike the Hungarian NAV or the Italian SdI), so we cannot claim that the gateway would reject this file. Asserting a rejection we cannot source would be a lie.
Key takeaways
- JPK_V7M is not an invoice: it is the monthly VAT control file — declaration (P_*) plus registers (K_*) in one XML. Invoices are KSeF.
- Variant (3) has applied since 1 February 2026 — the schema carries that date itself.
- The registers-versus-declaration check is the point of this tool: it verifies that the K_* sums reached the P_* boxes.
- Warnings, never blocking: the ministry’s own samples would fail them, and the ministry publishes no numbered rejection codes.
- Only pure-sum boxes are checked (P_10-P_36, P_40-P_47) — P_37/P_38/P_39 are computations, not column sums.
Frequently asked questions
How is JPK_V7M different from KSeF?
They are two different obligations. KSeF concerns the individual structured invoice (the FA(3) schema) and operates in real time. JPK_V7M is filed monthly and carries the VAT declaration together with the sales and purchase registers. One says “here is an invoice”; the other says “here is what I declared this month, and here is what it is made of”.
Why is a mismatch between registers and declaration only a warning?
For two reasons, both verified. The ministry’s own two sample files declare LiczbaWierszySprzedazy = 0 despite carrying a sales row, and their NIP (1010000000) fails the mod-11 check — it is a placeholder. A blocking check would reject the ministry’s own examples. On top of that, the ministry publishes no list of numbered rejection codes, so there is no way to prove the gateway would reject the file. We report the discrepancy and leave the decision to you.
Which declaration boxes are compared with the registers?
Only those that are a pure column sum: P_10 to P_36 and P_40 to P_47. Boxes like P_37, P_38 or P_39 are the result of computations inside the declaration rather than the sum of a register column — comparing them to a K_* total would raise false alarms.
Is my file uploaded to a server?
No. The XSD engine and every check run in your browser, in WebAssembly. A JPK_V7M file contains a full month of sales and purchase records — it never leaves your machine.
What can this tool not check?
Anything that needs the administration’s database: whether a counterparty is an active VAT taxpayer, whether a file for the period has already been filed, whether the filer holds the right authorisation, and how the gateway will actually respond. The tool lists this on screen rather than hiding it behind a green badge.
ValidateFin is an independent tool, not certified or endorsed by the Polish Ministry of Finance. “Official” refers to the schema used — the JPK_V7M(3) XSD published by the Ministry of Finance — not to any accreditation of this tool. Validating a file here does not file it.