JPK CIT audit: how does the tax authority select companies for review in 2026?

JPK CIT: your books under the tax authority’s scrutiny

JPK CIT is the informal name for the new obligations to report books and records in income taxes. For CIT taxpayers, the most important element is the JPK_KR_PD structure, i.e. the electronic form of the accounting books supplemented with tax data.

JPK CIT reporting covers two structures: JPK_KR_PD, relating to the accounting books, and JPK_ST_KR, covering the register of fixed assets and intangible assets. From the perspective of analysing tax settlements and reporting deadlines, JPK_KR_PD is of particular importance. It contains, among other things, data on accounts and accounting entries, counterparties, and differences between the financial result and the tax result. This gives the tax authorities broader opportunities to verify the consistency of settlements and to identify areas requiring clarification.

JPK_KR_PD is not an ordinary data export from an accounting system. It is a file prepared in such a way that the tax administration can process and analyse it automatically. This follows from Art. 193a § 2 of the Tax Ordinance Act, under which the logical structure of electronic tax books and accounting documents must allow for automatic data analysis. In other words, the legislator already provided in the law that JPK is to serve automatic data analysis, not merely act as a digital version of a paper ledger.

The legal basis for the obligation of CIT taxpayers is Art. 9(1c) of the CIT Act. This provision requires taxpayers to keep accounting books using computer software and, after the end of the tax year, to submit them to the competent head of the tax office in a structure compliant with Art. 193a § 2 of the Tax Ordinance Act. For companies without legal personality, the relevant rules follow from Art. 9(1e) of the CIT Act, and for tax capital groups, from Art. 9(1g) of the CIT Act.

The JPK_KR_PD obligation is being introduced in stages. In 2026, JPK_KR_PD was submitted by the largest CIT taxpayers and tax capital groups. The full schedule, thresholds and deadlines are described in our article JPK_CIT in 2026: deadlines, JPK_KR_PD structure and new obligations. In this context, the key point is that the tax authority is starting to receive accounting data in a format suitable for automatic processing and comparison.

The scope of data in JPK_KR_PD is broader than the accounting entry itself. The Regulation of the Minister of Finance of 16 August 2024 requires the books to be supplemented with, among other things, counterparty data, account tags based on the dictionaries of the Ministry of Finance (MF), and the data needed to reconcile the accounting result with the tax base. The structure also includes field D_12, i.e. the number identifying an invoice or corrective invoice in KSeF. However, it does not apply to every invoice. Field D_12 is required for transactions documented with an invoice or corrective invoice issued via KSeF by the entity submitting the JPK.

In practice, this means that JPK_KR_PD makes it possible to look beyond the bookkeeping entries themselves. It also allows analysis of how the taxpayer classifies revenue, costs, and the differences between the accounting result and the tax result.

What does the Ministry of Finance do with JPK CIT files? Automated audits

There is no official description of an algorithm showing how MF or the National Revenue Administration (KAS) analyses JPK_KR_PD and selects companies for audit on that basis. There are, however, official communications confirming that the tax administration uses risk analysis, analytical tools, Big Data and statistical models, particularly in VAT.

This is an important distinction. It is fair to say that JPK_KR_PD gives the tax authority material for analysis. However, it cannot be claimed that we know a specific JPK CIT audit algorithm, because no such mechanism has been publicly described.

The safest way to look at this topic is in three steps.

• First, the law expressly assumes automatic analysis of JPK data (Art. 193a § 2 of the Tax Ordinance Act). Moreover, the explanatory memorandum to the introduction of JPK CIT reporting expressly states that the aim of the changes was “to enable the tax administration to verify the correctness of settlements and detect abuse remotely, without the need to carry out on-site activities, and to increase their effectiveness.”
• Second, KAS publicly states that it uses analytics, Big Data and risk analysis to direct verification activities. The KAS Analysis Department is responsible, among other things, for risk analysis in the tax administration’s area of activity.
• Third, a practical conclusion can be drawn from these two facts: data from JPK_KR_PD may be used to select taxpayers for verification activities or audits. This still does not mean, however, that MF has disclosed a specific list of rules, alerts or risk scoring for JPK CIT.

Most of the official information available today concerns not JPK CIT but earlier experience with JPK_VAT and STIR. MF reported using JPK_VAT for automated verification activities, and KAS described the so-called Analytics Engine (Silnik Analiz), which in the VAT area used statistical and econometric modelling and machine learning. This is a good point of reference, but not proof that the same mechanism is already in place for JPK CIT.

Cross-checking data: JPK CIT vs JPK_VAT

There is no public confirmation that MF applies a specific, named mechanism for cross-checking JPK_KR_PD against JPK_VAT. Such data comparison is, however, technically possible, because both data sets reach the tax administration and concern, among other things, transactions, counterparties, documents and settlement periods.

In VAT, the use of JPK for analysis is already described in public materials from the Supreme Audit Office (NIK) and MF. NIK pointed out that JPK enabled broad analysis of data on counterparties and transactions, and that the administration developed reports comparing the JPK_VAT of a taxpayer with that of its counterparties. MF also stressed that JPK_VAT contains the data needed to analyse the correctness of VAT settlements, and that VAT settlements are automatically verified for the correctness of output and input tax.

For JPK CIT, however, caution is needed. It is true that the tax authority, thanks in part to tools such as ARANEA, most likely has the technical capability to compare data from different structures. Nevertheless, at least for now, there is no publicly known algorithm that automatically matches specific JPK_KR_PD fields with specific JPK_VAT fields.

It is also necessary to distinguish between markings specific to different structures. The MPP or TP markings are elements of JPK_VAT/JPK_V7 and relate to procedures or transaction types. In JPK_KR_PD, other elements are relevant: the Kontrahent (counterparty) node, the chart of accounts, the Dziennik (journal of entries) and account tags, including S_12_1, S_12_2 and S_12_3 in the ZOiS node, i.e. the trial balance.

It is worth noting that parliamentary question no. 9710 of 2025 concerned automatic analysis and algorithms in JPK_VAT. This shows that the automation of JPK is also present in public debate. It is not, however, a source confirming a specific mechanism for selecting JPK CIT audits.

Deviations in financial ratios and warning algorithms

MF has not published a list of warning indicators for JPK CIT. Therefore, any examples of such indicators must be described as possible areas of risk analysis, not as known rules of how the system works.

In practice, such areas may include, among others, consistency of the accounting result with the tax base, the level of costs permanently not constituting tax-deductible costs, exempt and non-taxable revenue in the current year, balances of settlements with related parties, recurring losses despite high revenue, or unusual relationships between the books and the CIT-8 return.

These are areas that naturally follow from the content of JPK_KR_PD and the logic of risk analysis. They should not, however, be presented as an official MF checklist. The safe thesis is simpler: the more structured data reaches the tax authority, the easier it is to spot unusual relationships, discrepancies and points requiring clarification.

Which account tagging errors might the MF system respond to?

The key is to distinguish between technical and substantive errors. Technical errors may be detected as early as file validation. Substantive errors may create an analytical risk, but assessing them requires examining the accounting entries, the accounting policy and the actual nature of the transactions.

It would be overly optimistic to claim that “an automated system will never detect a substantive error”. Analytical tools can point to inconsistencies, deviations or unusual data. An automated system does not, however, decide on its own whether a given account has been correctly assigned to a tax tag. That requires an assessment of documents, accounting principles and the way the company operates.

The JPK_KR_PD structure includes, among others, the Naglowek, Podmiot1, Kontrahent, ZOiS, Dziennik, Ctrl and RPD nodes. The header contains the CelZlozenia field, where the value “1” means the first submission and “2” a correction. In 2026, reference should be made to the JPK_KR_PD(1) structure and the current v1-1 schema published by MF. The update to version v1-1 resulted from aligning the dictionaries with the Regulation of the Minister of Finance of 16 August 2024.

Technical errors include, for example, non-compliance with the XSD schema, a missing required field, an incorrect data type, an incorrect date format, an invalid dictionary value, exceeding the character limit or inconsistent control data. Such an error may result in the file being rejected, no UPO (official confirmation of receipt) being issued, or the need for a technical correction.

Substantive errors are more difficult. A file may be technically correct but still contain an incorrect tax classification. For example, an account may be assigned to the wrong tag, a cost may be incorrectly treated as tax-deductible, and the difference between the accounting and tax results may be recognised incorrectly. In the JPK_KR_PD FAQ, MF indicates that, given the different accounting policies and different methods of record-keeping, it is not possible to create a single universal instruction for completing fields S_12_1 to S_12_3. The taxpayer must therefore independently analyse the accounting entries and the actual nature of the business events.

The “optional” status of fields is also important. The fact that a field may be technically optional does not mean it is left to discretion. MF indicates that fields S_12_1, S_12_2 and S_12_3 may remain empty only in specific cases, e.g. under special exemptions for entities applying IFRS. As a rule, the taxpayer should apply the appropriate tag if this follows from the content of the books and the nature of the account.

The safe conclusion is as follows: the system may stop the file or flag technical problems, and data from a correctly submitted JPK_KR_PD may later be subject to risk analysis. An error in the file does not in itself mean an automatic penalty, however. A sanction requires a separate legal basis, the appropriate procedure and a determination of who is responsible for the infringement.

From prevention to targeted audits: how to prepare your team for questions from the tax office

Data from JPK_KR_PD may lead to various responses from the authority: from verification activities, through a tax audit, to a customs and tax audit in more serious cases. Which procedure is chosen depends on the type of irregularity and the authority’s risk assessment.

Verification activities are the least formalised. As part of them, the authority may check, among other things, whether returns have been filed and tax paid on time, the formal correctness of documents, and whether the data is consistent with the documents submitted.

In practice, this may mean a request for explanations, a request for a correction, or an attempt to reconcile the data with the CIT-8 return.

A tax audit is a formal procedure provided for in the Tax Ordinance Act. Its purpose is to check whether the taxpayer is fulfilling its tax obligations. As a rule, the authority gives prior notice of its intention to initiate an audit, but the law provides for exceptions to this rule. JPK_KR_PD may shorten the audit preparation stage, because some of the data the authority used to obtain only in the course of proceedings is now received after the end of the year.

A customs and tax audit is a separate procedure governed by the KAS Act. It covers, among other things, checking compliance with tax law. KAS states publicly that audit activities are directed where risk analysis shows a higher probability of irregularities.

It is too early to assess the effects of using JPK_KR_PD in tax audits. The first reporting cycle ended on 31 July 2026, and publicly available KAS data do not make it possible to isolate audits in which this file was used. Experience with JPK_VAT may show the analytical potential of reporting, but it does not yet prove the effectiveness of JPK CIT.

Before submission, it is worth checking the consistency of the data in JPK_KR_PD with the tax calculation and the CIT-8 return, explaining any discrepancies and verifying the substantive correctness of the file. It is also worth organising the documentation that makes it possible to reconstruct how aggregated amounts were determined. As a result, if the tax office asks about specific items, it will be easier to quickly prepare consistent and well-documented explanations.

Check your JPK CIT before the tax office does

Before JPK_KR_PD reaches the tax office, it is worth reviewing it the way a tax department would during an internal audit: technically, from a tax perspective and in terms of process.

ALTO supports clients with the ALTOOL JPK CIT tool, available in SaaS and on-premise versions. The application helps automate key stages of reporting: from data retrieval, through validation, to generating reports that comply with current requirements. It also enables mapping of financial data, adding data from outside the accounting system, and separately adding accounting and tax tags to accounts. This is particularly important for companies working on complex or inflexible ERP systems.

ALTO also offers comprehensive implementation support, including analysis of CIT settlement processes, analysis of data completeness and identification of areas requiring adjustment in order to assign the appropriate tags.

FAQ: Frequently asked questions about JPK CIT audits

Does the tax authority automatically detect errors in JPK CIT?

At the submission and validation stage, mainly technical errors are detected, e.g. non-compliance with the XML schema or missing required data. Substantive errors may attract the attention of analytical systems, but assessing them requires an analysis of the taxpayer’s books, documents and accounting principles.

Is JPK CIT cross-checked against JPK_VAT?

There is no official confirmation of a specific mechanism for cross-checking JPK_KR_PD against JPK_VAT. Such a comparison is technically possible, but it should not be presented as a disclosed MF algorithm.

Is there a public list of indicators that MF checks in JPK CIT?

No. MF has not published a list of alerts for JPK CIT. Areas relevant to risk analysis can be identified, but not as an official tax authority checklist.

What are the consequences of an error in a JPK CIT file?

Sanctions under the Fiscal Penal Code depend on the type of error, its tax consequences and to whom liability can be attributed.

Sources

1. Art. 193a § 2 of the Tax Ordinance Act.
2. Art. 9(1c), (1e) and (1g) of the CIT Act.
3. Regulation of the Minister of Finance of 16 August 2024 on additional data to be added to accounting books subject to submission under the Corporate Income Tax Act, Journal of Laws 2024, item 1314.
4. MF/KAS web pages “JPK_PD” and “JPK structures in income taxes”.
5. JPK_KR_PD(1) information brochure, JPK_KR_PD(1) v1-1 schema and MF FAQ on JPK_PD.
6. KAS communications on risk analysis, Big Data, JPK_VAT, STIR and the Analytics Engine.
7. Parliamentary question no. 9710/2025 on JPK_VAT verification procedures.
8. ALTO materials on ALTOOL JPK CIT and comprehensive preparation for JPK CIT.

Article updated: September 2026.