6 Feb 2026

Poland update: JPK-V7(3) (Schema version 3) becomes mandatory from 1 Feb 2026 - what D365 Finance teams need to do now

Author: Roman Abilkhatov, D365 Finance Solution Architect

If you run Polish VAT reporting out of Dynamics 365 Finance, this is one of those “quiet” changes that becomes very loud right before the deadline.

Poland’s JPK-V7 is the VAT reporting format (SAF-T regime) that combines the VAT return with detailed sales and purchase ledger data. The next iteration, JPK-V7(3) (Schema version 3), becomes mandatory from 1 February 2026.

The driver is practical: the schema is being updated to align with Poland’s national e-invoicing system KSeF, and new fields/tags are being introduced (including items linked to the deposit-refund system, “system kaucyjny”).

Below is a straightforward, project-friendly breakdown of what changes and the required actions in D365 Finance.

What’s changing in JPK-V7(3) and why it matters

According to the issue note, JPK-V7(3) introduces:

1. an updated schema to align data flow between KSeF e-invoices and VAT reporting
2. additional fields and XML tags in the schema (including deposit-refund related fields)

For Finance leadership, the risk isn’t “can D365 output an XML file”. The risk is:

1. generating the file with the wrong schema version
2. missing mandatory tags (especially those referencing KSeF context)
3. getting validation failures and rework during close when you have the least capacity

Required actions in Dynamics 365 Finance (from the hotfix guidance)

1) Upgrade your D365 Finance application to a supported build

The guidance is explicit: you must be on a supported application build that includes the fixes and changes required for JPK-V7 Schema version 3. The minimum build numbers listed are:

1. Application 10.0.44 -> Finance build 10.0.2263.197
2. Application 10.0.45 -> Finance build 10.0.2345.141
3. Application 10.0.46 -> Finance build 10.0.2428.78
4. Application 10.0.47 -> Finance build 10.0.2513.0

Practical note: don’t leave this to the last minute. Localisation updates can be blocked by environment freezes, UAT cycles, or release scheduling.

2) Import updated Electronic Reporting (ER) configurations

You’ll need the latest ER configurations required for Schema version 3. At a minimum, the issue note calls out these versions:

1. Standard Audit File (SAF-T) - version 208
2. Standard Audit File model mapping - version 208.338
3. JPK-V7 XML format (PL) - version 208.237
4. JPK-V7 Excel format (PL) - version 208.237.89

This is a common failure point in real projects: code gets updated, but ER configs don’t get promoted consistently across DEV/UAT/PROD. Treat ER versions like deployment artefacts, not “someone imported it once”.

3) Update Electronic Messages (EM) configuration

Electronic Messages processing must be aligned with the new schema. The guidance offers two approaches:

Option A - Import updated EM package Import the latest EM setup package that includes Schema version 3 support: “PL JPK-V7 EM setup v.9 ID1074347.zip”

Option B - Manual configuration If you don’t import the updated package, you must manually add schema version “3” to the relevant additional field (Wersja schematu) in your existing JPK-V7 EM processing configuration and set it as default for JPK-V7 processing.

New XML tags introduced (the bits auditors and validators will care about)

As part of Schema version 3, the issue note lists the following XML tags being introduced:

1. <NrKSeF> - identifier number of the invoice in the National e-Invoice System (KSeF)
2. <OFF> - marker for an invoice referenced in Article 106nf of the Act, which does not have a KSeF identifier and has not been sent to KSeF
3. <BFK> - marker of an electronic invoice or an invoice in paper form
4. <Dl> - marker of another document (not an invoice) issued via the National e-Invoice System :contentReference[oaicite:11]{index=11}

If you’re thinking “that’s just a few tags”, remember: these flags typically depend on upstream process discipline (how invoices are issued, whether they are sent to KSeF, what exception paths exist). The technical change is often easier than the business alignment.

A low-drama rollout approach

If you want this to land cleanly before Feb 2026, here’s the pattern that works:

1. Confirm current app/build in all environments (DEV/UAT/PROD)
2. Upgrade DEV first to a supported build
3. Import ER configs in DEV (and document versions)
4. Update EM config (package import preferred to reduce manual drift)
5. Generate sample JPK-V7 output and run validation checks early
6. Repeat in UAT with the same ER/EM versions
7. Lock down ownership: who maintains schema version settings, and who validates KSeF-related flags?

CFO-friendly takeaway

This change is compliance-led and date-driven (mandatory from 1 Feb 2026). The cost of doing it early is a controlled upgrade and a couple of UAT cycles. The cost of doing it late is unplanned rework, delayed filings, and avoidable risk during close.