JPK_V7M(3) Validator Poland
Vérifiez un fichier JPK_V7M(3) avec le XSD officiel du ministère des Finances, et découvrez si vos registres contredisent votre déclaration — dans le navigateur, sans upload.
Qu’est-ce que le JPK_V7M, et en quoi diffère-t-il de KSeF ?
Le JPK_V7M est le fichier de contrôle TVA mensuel polonais : un seul document XML qui réunit la déclaration (la partie <Deklaracja>, les cases P_*) et les registres de ventes et d’achats (la partie <Ewidencja>, les colonnes K_*). Ce n’est pas une facture — les factures vivent dans KSeF. La variante (3) est en vigueur depuis le 1er février 2026, et le schéma porte lui-même cette date (TDataCzas minInclusive). Ce validateur gratuit contrôle le fichier contre le XSD officiel du ministère des Finances, puis effectue le contrôle qu’aucun schéma ne peut faire : les sommes des registres ont-elles réellement atteint les bonnes cases de la déclaration ? Tout se passe dans votre navigateur : le fichier ne quitte jamais votre machine.
Le schéma est une chose ; que les registres nourrissent la déclaration en est une autre
La première couche est le XSD officiel JPK_V7M(3) du ministère des Finances polonais. Structure, types, cardinalités et listes de codes fermées ne sont jamais réencodés à la main. Un piège mérite d’être nommé : les modules importés par le MF (StrukturyDanych v12, KodyKrajow v13) sont des versions DIFFÉRENTES de celles qu’utilise KSeF — autres espaces de noms, autres fichiers. Il ne faut pas les « factoriser ».
La seconde couche est ce qui fait la valeur de l’outil : aucun validateur gratuit ne vous dira que votre registre contredit votre déclaration. Nous confrontons les sommes des colonnes K_* aux cases P_*, les compteurs de contrôle (LiczbaWierszySprzedazy, LiczbaWierszyZakupow), la numérotation des lignes et la clé du NIP (mod 11). Seules les cases qui sont une SOMME PURE sont comparées — P_10 à P_36 et P_40 à P_47. Des cases comme P_37, P_38 ou P_39 sont des calculs de la déclaration elle-même, pas l’agrégation d’une colonne : les traiter comme des sommes produirait des alertes fausses.
Pourquoi des avertissements plutôt que des erreurs ? Pour deux raisons indépendantes, toutes deux vérifiées. D’abord, les deux fichiers d’exemple du ministère déclarent eux-mêmes LiczbaWierszySprzedazy = 0 alors qu’ils portent une ligne de vente, et leur NIP (1010000000) échoue au mod 11 — c’est un placeholder. Un contrôle bloquant rejetterait les propres exemples du MF. Ensuite, le ministère ne publie aucune liste de codes de rejet numérotés (contrairement à la NAV hongroise ou au SdI italien) : nous ne pouvons donc pas affirmer que la bramka rejetterait ce fichier. Affirmer un rejet qu’on ne peut pas sourcer serait mentir.
À retenir
- Le JPK_V7M n’est pas une facture : c’est le fichier de contrôle TVA mensuel — déclaration (P_*) et registres (K_*) dans un seul XML. Les factures, c’est KSeF.
- La variante (3) s’applique depuis le 1er février 2026 — le schéma porte lui-même cette date.
- Le contrôle registres → déclaration est la raison d’être de cet outil : il vérifie que les sommes des K_* ont atteint les cases P_*.
- Des avertissements, jamais de blocage : les propres exemples du ministère y échoueraient, et le ministère ne publie aucun code de rejet numéroté.
- Seules les cases qui sont une somme pure sont contrôlées (P_10-P_36, P_40-P_47) — P_37/P_38/P_39 sont des calculs, pas des sommes de colonne.
Questions fréquentes
Quelle différence entre le JPK_V7M et KSeF ?
Ce sont deux obligations distinctes. KSeF porte sur la facture structurée individuelle (le schéma FA(3)) et fonctionne en temps réel. Le JPK_V7M se dépose chaque mois et porte la déclaration de TVA ainsi que les registres de ventes et d’achats. L’un dit « voici une facture » ; l’autre dit « voici ce que j’ai déclaré ce mois-ci, et voici de quoi c’est fait ».
Pourquoi un écart entre registres et déclaration n’est-il qu’un avertissement ?
Pour deux raisons, toutes deux vérifiées. Les deux fichiers d’exemple du ministère déclarent LiczbaWierszySprzedazy = 0 alors qu’ils portent une ligne de vente, et leur NIP (1010000000) échoue au mod 11 : c’est un placeholder. Un contrôle bloquant rejetterait les propres exemples du MF. À cela s’ajoute que le ministère ne publie aucune liste de codes de rejet numérotés : rien ne permet de prouver que la bramka rejetterait le fichier. Nous signalons l’écart et vous laissons la décision.
Quelles cases de la déclaration sont comparées aux registres ?
Uniquement celles qui sont une somme pure de colonne : P_10 à P_36 et P_40 à P_47. Des cases comme P_37, P_38 ou P_39 résultent de calculs internes à la déclaration et non de la somme d’une colonne de registre — les comparer à un total de K_* déclencherait des alertes fausses.
Mon fichier est-il envoyé à un serveur ?
Non. Le moteur XSD et tous les contrôles tournent dans votre navigateur, en WebAssembly. Un fichier JPK_V7M contient un mois entier de ventes et d’achats : il ne quitte jamais votre machine.
Que cet outil ne peut-il pas vérifier ?
Tout ce qui exige la base de l’administration : si un partenaire est assujetti actif à la TVA, si un fichier a déjà été déposé pour la période, si le déclarant dispose du bon mandat, et comment la bramka réagira réellement. L’outil l’affiche à l’écran plutôt que de le cacher derrière un badge vert.
ValidateFin est un outil indépendant, ni certifié ni approuvé par le ministère des Finances polonais. « Officiel » qualifie le schéma utilisé — le XSD JPK_V7M(3) publié par le ministère des Finances — et non une quelconque accréditation de cet outil. Valider un fichier ici ne le dépose pas.