KSeF and JPK: how the invoice system works with the JPK family of structures

JPK is a family of XML structures comprising three groups: recurring JPK_VAT with the VAT return, mandatory annual JPK_PD income-tax files, and seven structures supplied on request. JPK_PD is being introduced in stages and does not cover every taxpayer in the same year.

KSeF does not replace JPK_VAT. KSeF stores and handles individual structured invoices, whereas JPK_V7 reports sales and purchase records and the VAT settlement for a given period, including on the basis of evidence originating outside KSeF.

JPK_V7M(3) and JPK_V7K(3) apply from the February 2026 settlement. If an invoice has a KSeF number, it is entered in the NrKSeF field. If there is no number, the appropriate OFF, BFK or DI marker is used instead.

A business may see 120 documents for May in KSeF but a different number of entries in its JPK records for May. The difference alone does not prove that there is an error. Some invoices may belong to another VAT period, some purchase VAT may not yet have been deducted, and some JPK entries may arise from aggregate evidence, internal documents or invoices issued outside KSeF.

The key is to distinguish four levels: the FA(3) invoice file, the event and number in KSeF, the VAT ledger entry, and the periodic JPK file. The data may be linked, but the levels are not identical and do not arise at the same time.

This guide presents the legal and technical position as at June 6, 2026. It does not describe a field-by-field mapping from FA(3) to JPK because there is no simple one-to-one mapping between these structures.

1. JPK is a family of structures, not a single file

2. What JPK_VAT with the VAT return is

3. What KSeF stores and what JPK reports

4. GTU in FA(3) and JPK_V7 does not map one-to-one

5. Where KSeF and JPK data come from

6. The issue and receipt dates do not always determine the JPK month

7. The supplier's invoice number and the KSeF number are two different identifiers

8. How to report an invoice in JPK_V7 from February 2026

9. Offline modes, system failure and total failure

10. Invoices outside KSeF and aggregate evidence

11. Correcting invoices and JPK corrections

12. JPK_FA and other structures supplied on request

13. Transitional periods in 2026

14. KSeF-to-JPK reconciliation matrix

15. Month-end procedure

16. Frequently asked questions

The table below summarises the most important distinctions needed when reconciling KSeF with the VAT settlement.

The Polish Standard Audit File for Tax, known as JPK, is a data set generated by direct export from a taxpayer's IT systems in a prescribed XML layout. The abbreviation JPK does not denote a single form. It covers structures intended for different books, records and document types.

The full picture comprises three groups. The first is recurring JPK_VAT with the VAT return. The second consists of the annual JPK_PD structures: JPK_KR_PD, JPK_ST_KR, JPK_PKPIR, JPK_EWP and JPK_ST, whose application depends on the implementation stage and the type of records maintained. The third group consists of seven structures supplied on request: JPK_KR, JPK_WB, JPK_MAG, JPK_FA, JPK_FA_RR, JPK_PKPIR and JPK_EWP.

The JPK_PD obligation is phased. The first JPK_KR_PD files are submitted in 2026 for a year beginning after December 31, 2024 by the largest CIT taxpayers and tax capital groups, with JPK_ST_KR optional for that group for its first reported year. For years beginning after December 31, 2025, the obligation also covers the remaining CIT taxpayers and PIT taxpayers filing JPK_V7M. For years beginning after December 31, 2026, it extends to the remaining taxpayers, including those filing JPK_V7K. The specific obligations must therefore be checked by reference to the type of records, tax and tax year.

The detailed scope and timetable are published by the Ministry of Finance on the JPK for income taxes page. The authority may obtain structures supplied on request during verification activities, tax proceedings, a tax audit or a customs and tax audit. The deadline specified in the request may not be shorter than three days.

In practice, asking whether a business should use KSeF or JPK sets up a false choice. KSeF is an invoice circulation system, while the individual JPK structures are used to report tax data or provide books and records on request.

JPK_VAT with the VAT return is a single electronic document consisting of two parts. The records section contains the data needed to calculate output and input VAT correctly. The declaration section contains the items needed to calculate VAT payable, an excess or a refund.

Since October 1, 2020, active VAT taxpayers have not filed a separate VAT-7 or VAT-7K return and the former JPK_VAT file. These data have been combined in the JPK_V7M and JPK_V7K structures.

JPK_V7M is used by a taxpayer settling VAT monthly. JPK_V7K applies to a taxpayer settling VAT quarterly, but its records section is still submitted for each month. The declaration section for the entire quarter is included in the file for the third month of the quarter.

Versions JPK_V7M(3) and JPK_V7K(3) apply from the February 2026 settlement. They were designed to report either the number in the NrKSeF field or an alternative marker for a document without that number. Details are provided in the JPK_VAT with the VAT return guide applicable from February 1, 2026.

KSeF is primarily responsible for issuing, receiving and storing structured invoices. JPK_VAT with the VAT return is responsible for periodic VAT records and settlement. These are two separate obligations, even if invoice data from KSeF feeds the accounting system.

KSeF does not know all of the taxpayer's accounting decisions. It does not automatically determine the period in which a particular purchase should be deducted, how internal evidence should be recorded, how imports, intra-Community acquisitions or cash-register sales should be settled, or whether a particular correction changes an already submitted JPK.

The KSeF number makes it easier to link a ledger entry to an invoice. This does not mean, however, that the National Revenue Administration performs a publicly documented, complete and automatic reconciliation of every JPK record with every KSeF invoice.

FA(3) is the structure of an individual structured invoice. It contains the parties' data, line items, amounts, rates, payment information and other details that are mandatory or voluntarily provided by the supplier. Once the document is accepted, KSeF assigns a number to it and stores it in the system.

JPK_V7 describes sales and purchase ledger entries for a period and the declaration section. JPK_FA, by contrast, is an invoice structure supplied on request for documents covered by that request.

The comparison is based on the official description of the structured invoice and FA(3) and the JPK_VAT with the VAT return guide. A shared XML format does not mean a shared schema. FA(3), JPK_V7 and JPK_FA have different purposes, nodes and scopes. It should not be assumed that every FA(3) field has an exact JPK equivalent or that every JPK row is created from a single invoice field. For a broader discussion of the invoice structure, see XML and the FA(3) format in KSeF.

GTU designations illustrate why the technical mapping of FA(3) to JPK_V7 is not a simple matter of copying fields. The official FA(3) structure guide describes GTU designations in the FaWiersz element as optional fields relating to a specific invoice line.

In JPK_V7, a GTU designation applies to the record or document in the sales ledger. If even one invoice line falls within a particular GTU, the accounting system must determine the correct designation for the entire record. A single XML node therefore cannot simply be copied without an aggregation rule.

FA(3) may contain GTU information as an aid, but the optional nature of that field does not release the taxpayer from correctly designating JPK_V7 if the record-keeping rules require a GTU. Conversely, the absence of GTU in FA(3) does not determine that the JPK entry should have no designation.

KSeF receives an invoice file conforming to the FA(3) structure. JPK is generated from VAT records and data held in the financial and accounting system. Invoices downloaded from KSeF may reduce manual data entry, but they do not independently create a complete JPK file.

JPK requires additional tax context: the correct tax-point period, the date on which the invoice was received, the right to deduct, document designations, corrections, aggregate evidence, internal documents and events such as imports of services, intra-Community acquisitions or other transactions settled without a KSeF invoice.

The KSeFGPT invoice analytics view can help organise incoming and outgoing data before it is passed to accounting. The screenshot below shows invoice-data analytics, not a module for creating or submitting JPK.

The scope of the records and declaration data is described on the official JPK_VAT with the VAT return page.

In standard online mode, a structured invoice is generally regarded as issued on the date it is sent to KSeF, provided that the transmission date is consistent with the date entered in field P_1. For a domestic buyer with a NIP, the date of receipt of an online or offline24 invoice, or an invoice issued during unavailability, is generally the date on which the KSeF number is assigned. The precise receipt process is described in How to receive an invoice from KSeF step by step.

In the system-failure mode, the invoice is supplied to the buyer outside KSeF. The receipt date is the earlier of actual receipt and assignment of the KSeF number. For buyers referred to in Article 106gb(4), the date of actual receipt continues to apply. During a total failure, invoices are not subsequently sent to the system, so actual receipt is decisive.

These dates do not replace VAT rules. Sales are recorded according to the applicable tax point. Purchase VAT may be deducted no earlier than when the right to deduct has arisen and the invoice has been received, with the possibility of exercising that right in the subsequent periods permitted by law.

Sales example: a service was performed on May 29 and the invoice was sent to KSeF on June 2. If the tax point for the service arose in May, the sales record may belong to May despite the June invoice issue date.

Purchase example: KSeF assigned a number to an invoice on May 31, but the taxpayer did not deduct VAT in May and exercised the right in one of the subsequent periods permitted by law. The invoice has been in KSeF since May, but the deduction record may appear later.

The dates for the individual modes are compared in the official Ministry of Finance comparison table.

The supplier assigns the invoice's own number. In the FA(3) structure, it appears in field P_2 and identifies the document within the taxpayer's numbering system.

KSeF assigns its number only after accepting the invoice. It is not a number entered by the supplier in field P_2 of the invoice being issued. The KSeF number is returned in the system confirmation, including the UPO.

In JPK_V7(3), the KSeF number has a different role: it links the ledger entry to the document accepted by KSeF. Accounting data should therefore retain both identifiers rather than replacing one with the other.

This distinction is confirmed by the official description of the KSeF number and aggregate identifier.

The starting point is the document's status on the date the records are submitted. If the invoice already has a KSeF number, that number is entered in the NrKSeF field for sales or purchases. If there is no number, NrKSeF is left blank and the appropriate alternative marker must be used.

OFF, BFK and DI are not values of the NrKSeF field or three names for the same absence of a number. OFF applies to an invoice issued in the system-failure mode specified in Article 106nf(1). BFK applies to an electronic or paper invoice issued outside KSeF. DI covers evidence other than an invoice and, in specified cases, an offline24 invoice or an invoice issued during unavailability that does not yet have a KSeF number.

The rules in the table follow the official JPK_VAT marker matrix. A JPK file marked OFF is not corrected solely because a number is assigned later. For sales, a DI record concerning an offline24 invoice or an invoice issued during unavailability must be corrected after the number is obtained by completing NrKSeF. The purchase section of the Ministry of Finance matrix does not impose an equivalent correction solely because of the later number.

The informal term offline invoice may refer to several distinct legal procedures. Offline24 is chosen by the taxpayer. Unavailability and system failure concern events announced for the system, while total failure has separate consequences.

The differences cover the document format, submission deadline, method of determining the issue and receipt dates, and the JPK marker. OFF therefore cannot be used as a universal marker for every invoice issued without a current connection to KSeF.

The table is based on the official comparison of invoice issue modes. For a domestic buyer with a NIP, online, offline24 and unavailability generally result in receipt when the KSeF number is assigned. During a system failure, the earlier of actual receipt and the KSeF number applies, while during a total failure only actual receipt applies.

JPK_V7 is not limited to structured invoices. The records may still include consumer invoices, documents covered by a statutory exclusion, invoices from transitional periods and other documents issued outside KSeF.

Mandatory issuing in KSeF began on February 1, 2026 for the largest taxpayers and on April 1, 2026 for the remaining taxpayers. Only invoices that would be subject to mandatory KSeF without the preference count towards the PLN 10,000 gross threshold. The threshold excludes, among other things, B2C invoices, sales recorded on a cash register, receipts with a NIP up to PLN 450 and invoices covered by another exclusion.

If the total of the relevant invoices exceeds the threshold, the invoice that crosses the threshold and all subsequent invoices must be issued in KSeF. Once the threshold has been exceeded, the taxpayer cannot return to the preference in subsequent months. The Ministry of Finance publishes rules and examples on the Below PLN 10,000 page. For broader context on the exceptions, see Who must use KSeF in 2026 and who is exempt?.

An invoice issued outside KSeF in breach of the obligation does not disappear from business circulation or the records. The Ministry of Finance states that, in principle, it may support the buyer's deduction if the conditions under Article 86 of the VAT Act are met. The authority may, however, examine due diligence in the particular circumstances.

JPK_V7 is not merely a list of invoices. It also includes specified aggregate evidence and internal documents. RO identifies aggregate evidence of sales from cash registers, WEW identifies internal evidence, and FP identifies invoices connected with cash-register sales to the extent required by the rules.

The official JPK_VAT questions and answers distinguish three situations. On the sales side, a receipt with a NIP up to PLN 450 treated as a simplified invoice is generally covered by the RO report and does not receive a separate FP. A separate invoice issued to a receipt or an invoice generated by a cash register is marked FP. If such an invoice remains outside KSeF, BFK is also used. On the purchase side, an invoice outside KSeF, including a simplified invoice, receives BFK.

NrKSeF links a record to a specific invoice, but it does not support the assertion that every KSeF invoice must, without exception, be a separate row in every possible case. Aggregation applies to the types of evidence specified in the rules, so the nature of the record must always be checked.

A correcting invoice changes the data of the original document. A correction to a structured invoice is generally also issued as a structured invoice and should contain the KSeF number of the corrected invoice if that number was assigned. Once accepted, the correction receives its own KSeF number. The practical process is described in Corrective invoices in KSeF.

A JPK correction means resubmitting the complete file with corrected data. Under the JPK_V7M(3) and JPK_V7K(3) guide, a file containing only the corrected items is not submitted. The mere fact that a correcting invoice has been issued does not prove that the earlier JPK was incorrect.

For VAT corrections, the supplier and buyer, the direction of the correction, its reason, the issue mode and the method of receipt must be analysed separately. The VAT Act and the amending Act of August 5, 2025 provide special rules for downward corrections submitted to KSeF after being issued in special modes.

Upward corrections also do not have a single universal date. If the reason already existed at the time of sale, the period may require a retrospective correction. If the reason arose later, settlement may fall in the current period. The date on which the correcting invoice receives its KSeF number therefore cannot be the sole criterion.

For invoices issued in KSeF, the authority has access to the data and therefore does not request it again in JPK_FA. This does not mean that JPK_FA has been abolished.

The authority may still request JPK_FA for invoices issued outside KSeF, such as documents covered by an exclusion or a transitional period. The scope of the request depends on the activities being conducted and the data that remains outside KSeF.

The remaining structures supplied on request concern accounting books, bank accounts, warehouses, the tax revenue and expense ledger or revenue records. KSeF stores invoices, so it does not replace those areas.

The scope of this exclusion is described in the official KSeF 2.0 questions and answers and the information on JPK supplied on request.

The year 2026 combines the launch of mandatory KSeF, new JPK_V7 versions and several transitional preferences. When reconciling a month, it is therefore necessary to check not only the document date but also the supplier's status and the invoice type.

A Ministry of Finance announcement dated July 4, 2024 can still be found online. It stated that the KSeF number would not have to be reported in sales records from February 1 to July 31, 2026. This is historical information based on the timetable then in force. The later regulation of December 12, 2025, the JPK_V7(3) schemas, the guide and the Ministry of Finance matrix provide for NrKSeF or an alternative marker in the structures used from the February 2026 settlement.

Accounting instructions should therefore not be based on the older announcement without checking the later legislation and technical documentation.

Reconciliation should not consist solely of comparing invoice counts and gross totals. First classify the difference as timing-related, document-related, technical or tax-related. Only then can it be assessed as correct or incorrect.

The matrix below is an original operating procedure based, among other things, on the Ministry of Finance marker matrix and the JPK_V7(3) guide. It is not a statutory catalogue or a substitute for analysing the particular case.

The following list is an original operating procedure for a business or accounting firm. It is not an exhaustive catalogue of activities required by law. Its purpose is to identify exceptions before JPK is submitted.

1. Download the list of sales and purchase invoices available in KSeF, including their own invoice numbers, KSeF numbers, dates and statuses.

2. Isolate documents without a KSeF number. Determine whether they were rejected, await submission, arose in offline24, during unavailability, system failure or total failure, or were issued outside KSeF.

3. For an invoice with a number, complete NrKSeF. For a document without a number, use OFF, BFK or DI as appropriate to the document type and mode.

4. Check the tax-point period for sales and the period in which the right to deduct is exercised for purchases. Distinguish the invoice date from the date of VAT recognition.

5. Identify correcting invoices. Check the original document number, KSeF number, reason for the correction and the correct period for the supplier or buyer.

6. Separate RO, WEW and FP from ordinary invoice records. As a rule, leave a simplified receipt in RO without FP, and mark a separate invoice to a receipt as FP.

7. Review invoices outside KSeF, including exclusions, the PLN 10,000 threshold calculated only for invoices subject to KSeF, the invoice crossing the threshold, consumer documents and cash-register invoices.

8. Compare net and VAT totals, the number of entries and the number of exceptions. Do not require the number of KSeF documents and JPK records to be identical without analysing the reasons.

9. Check DI sales records awaiting a KSeF number and rejected documents. Do not automatically correct purchase records marked DI solely because a number was assigned later.

10. Retain an explanation trail: the source document, basis for the marker, note on the VAT period, correction status and approving person.

To explore the subject further, read these four materials in detail: XML and the FA(3) format in KSeF, Corrective invoices in KSeF, How to receive an invoice from KSeF step by step, and Who must use KSeF in 2026 and who is exempt?.