Polish JPK CIT account tags: can the export tool do all the work?

For many businesses, a Polish JPK CIT project starts with a question for the software provider: can the system produce a file containing the required account tags? That needs to be established, but the harder issue arises earlier. A single ledger account may contain deductible expenditure, permanently non-deductible expenditure and amounts that become deductible only in a later period. If these categories are separated only during export, a technically valid file may show a distinction that does not exist in the accounting records. Recent Polish tax rulings place considerable weight on precisely this difference.

Law and source review: 10 November 2026.

Tax Legal Partner team

Why a valid file does not settle the accounting issue

A recurring implementation difficulty is the gap between the annual tax calculation and the way the books are maintained throughout the year. The accounting team posts invoices to expense accounts, while the person preparing the Polish CIT-8 return keeps a separate spreadsheet of tax adjustments. That spreadsheet may explain the tax calculation. It does not, by itself, establish that the information required for JPK is properly reflected in the books. Export then exposes an issue in the organisation of the underlying data, as well as any limitations of the software.

Three matters require separate consideration: the tax treatment of an expense, its recording in the books and the validity of the file submitted to the authorities. XML validation checks the data structure, permitted fields and formats. It does not determine whether a payment is actually deductible, whether an account tag reflects the transaction or whether the same amount has been excluded from deductions twice. Acceptance of the file by the submission system does not replace those checks.

The relevant framework is Article 9 of the Polish Corporate Income Tax Act and § 2(1)(3) and § 2(3) of the Minister of Finance's Regulation of 16 August 2024 on additional accounting data. Tags relate to ledger accounts and the classification of the transactions recorded in them. They are not simply descriptions chosen for a report. Where an account contains transactions requiring different tags, the business needs to establish how those groups are distinguished in its records and how the reported amounts can be substantiated.

This does not mean that every business must replace its financial accounting system. Mapping software can translate an existing accounting classification into JPK fields. The difficulty arises where the export process creates a new distinction that substitutes for the required organisation of the books. For the finance director, the essential question is therefore whether each reported item can be explained through accounting entries and supporting documents, alongside whether the file can be generated.

Tags created during export: the practical example of loan interest

In the individual ruling of 12 August 2026, reference 0111-KDIB1-3.4010.260.2026.2.AN, a company proposed a seemingly practical solution. It recorded paid interest and accrued but unpaid interest on the same account. When generating JPK, the software would add an internal designation to individual entries. The trial balance in the file would then contain separate reporting items resembling analytical subaccounts, although the company's chart of accounts would remain unchanged.

The application described PLN 1,000 of accrued but unpaid interest and PLN 500 of paid interest. The company intended to separate these amounts on export and maintain consistent identifiers between the trial balance and the detailed account entries. Its proposal was therefore more developed than an unexplained adjustment to a file: it was a deliberate technical mechanism designed to preserve the existing accounting arrangements.

The Director of National Tax Information, referred to as KIS, rejected the company's position. The authority referred to dividing transactions into homogeneous groups, creating separate analytical accounts and recording transactions on those accounts with the appropriate tags. The critical point was that the split made in the exported file would replace the corresponding separation in the accounting records. Technical consistency between the different parts of the file was insufficient.

For businesses, the lesson is not that every reporting module is prohibited. Before accepting a proposed solution, the company should establish whether it reads properly organised ledger data or creates reporting items that merely resemble accounts at the point of export. Those are different arrangements. Off-balance-sheet or combined methods also require real, identifiable entries. Another taxpayer's ruling helps identify the risk in a particular design; it does not confer protection on a different implementation.

How should accounts be prepared for Polish JPK CIT tags?

The starting point should be the company's actual transactions, rather than a list of account numbers copied from another business. An account called ‘other services’ might contain advice connected with taxable revenue, expenditure attributable to exempt activities and payments requiring a separate assessment. The account name does not decide the tax treatment. For each material group, the company needs to identify the substance of the entries, the tax treatment and the required tag, then check whether the existing analytical structure distinguishes those groups.

The review must also cover items whose treatment changes over time. Accrued interest may be excluded in one period and become deductible in another, subject to payment and the other statutory conditions. The company needs a method for reversing the difference, as well as an account on which to identify it initially. Otherwise, the first year's exclusion may be reported correctly while the system cannot identify which items are deductible later. Corrections, transfers between accounts and entries made after a monthly close deserve the same attention.

The account hierarchy requires a separate check. In the ruling of 24 September 2026, reference 0111-KDIB1-3.4010.438.2026.1.ZK, an independent public healthcare institution tagged its lowest-level analytical accounts but omitted general ledger accounts and intermediate levels on which no entries were made directly. It considered complete tagging of the final posting accounts sufficient. KIS disagreed and required tags at the higher levels as well.

A tag used for analytical accounts can be repeated at a higher level if it accurately describes the content of that account. Where a general ledger account aggregates different categories and the same tag cannot be used appropriately, the ruling referred to the INNE, or ‘OTHER’, tag. This is not permission to label every difficult account INNE. In other situations it remains a solution for content that cannot be assigned to another suitable tag in the prescribed dictionary. An aggregation issue at a higher level must be distinguished from a failure to analyse the underlying entries.

The practical deliverable should be an approved mapping table with reasons for the classifications, a list of accounts requiring further analytical detail and a process for new transaction types. Responsibility also needs to be clear: who makes the tax decision and who implements it in the system? A software provider can configure a rule, but should not independently decide whether a particular payment qualifies as a deductible expense under Polish law.

How should deductible and non-deductible costs be separated for JPK CIT?

Consider an illustrative example: a services account contains PLN 100,000, of which the company has separately assessed PLN 15,000 as permanently non-deductible. For accounting purposes, the whole amount remains an expense under the applicable accounting policies. For CIT, PLN 85,000 is deductible, assuming the remaining conditions are met. The JPK issue is how to present this distinction through the records while retaining a clear connection between the PLN 15,000 and the relevant documents.

A suitable arrangement may use analytical accounts within the financial ledger, off-balance-sheet records or both. The choice depends on how the books are organised and the nature of the differences. If the original expense remains on its existing account while its non-deductible portion is identified off balance sheet, the company must maintain consistency and avoid excluding the same amount twice. An annual aggregate entry reading ‘non-deductible costs — PLN 15,000’ does not explain which transactions it covers or why they were excluded.

Permanent and temporary differences also need to be distinguished. Expenditure that is definitively excluded from deduction is different from accrued interest whose deductibility depends on payment and other limitations. A temporary difference requires continuity between periods: identification of the original expense, the reason for deferral and the later event allowing deduction. The broad label NKUP, used in Poland for non-deductible costs, is insufficient to handle both categories properly.

The fields in the structure serve different purposes. Balance sheet and profit-and-loss tags in S_12_1 and S_12_2 do not replace the PD tax tag in S_12_3. The possibility, in particular circumstances, of using two tags describing balance sheet or profit-and-loss items does not allow unrestricted mixing of tax categories on one account. Confusing those rules can produce a technically accepted file that does not reflect the substance of the books.

Acceptance testing should therefore trace a document through its accounting entry, account and tag, and then work backwards from the amount reported in JPK to the source documents. Where a step depends on a manual decision made only during export, the company should determine whether that decision should already have been reflected in the records. This identifies the actual missing element and gives the software provider and accounting team a concrete issue to resolve.

Shared costs: why an allocation spreadsheet may be insufficient

A different problem arises where a business carries on activities with different tax treatments. The ruling of 19 October 2026, reference 0111-KDIB1-1.4010.454.2026.2.SG, concerned a cooperative with agricultural activities alongside taxable trading and services. It incurred shared administration, IT and legal costs. It wanted to allocate those costs outside the books using a ratio based on operating revenue, excluding certain non-operating items.

The dispute involved two separate matters: whether the allocation methodology was correct and whether JPK, as a reporting obligation, could ever require changes to the records. KIS rejected the cooperative's position. On the JPK issue, it explained that substantive tax deduction rules remain unchanged, but the books must contain the data needed to prepare the structure. If the existing records cannot provide it, they require adjustment, potentially through analytical accounts, off-balance-sheet accounts or a combined arrangement.

A business therefore needs to check two questions independently. First, can the expense be allocated directly, and does the proposed ratio comply with the law and the circumstances? Only then should the company design how the allocation is recorded and reported in JPK. Correctly programming an incorrect allocation key does not repair the tax calculation. Conversely, a sound allocation methodology does not remove the need for the required accounting records.

The outcome should not be extended automatically to every business that allocates shared expenditure. The ruling concerned a particular combination of activities and a particular method. Its wider practical value lies in the distinction it makes: the assumption that an annual tax spreadsheet will always suffice needs to be tested against the JPK data requirements and the company's actual accounting arrangements.

Polish Estonian CIT: reporting scope and tax tags are separate questions

A company using Poland's Estonian CIT regime does not calculate its current tax base as the difference between taxable revenue and deductible costs under ordinary CIT rules. This does not put it entirely outside the obligation to submit accounting books. The two questions must be considered separately because they lead to different implementation decisions.

In its final judgment of 15 May 2025, case I SA/Wr 875/24, the Regional Administrative Court in Wrocław examined a car and parts dealer that also provided vehicle servicing. The company argued that, because it did not recognise taxable revenue in the ordinary CIT sense, exceeding EUR 50 million of accounting revenue should not bring it into the first reporting stage. The court dismissed the complaint. Among other points, it noted that Article 9(1c) also covers companies filing CIT-8E and that the meaning of revenue must account for the particular features of the lump-sum regime.

By contrast, the ruling of 23 April 2026, reference 0111-KDIB2-1.4010.86.2026.1.AJ, confirmed that the PD tax tags were not required in the Estonian CIT circumstances described. KIS explained that these tags classify revenue and costs under ordinary taxation, whereas the lump-sum regime taxes different categories of income. The ruling does not remove the obligation to maintain and submit the books or dispense with all other tags.

An implementation cannot therefore rely on a single ‘CIT: yes/no’ setting. It needs to establish the tax regime, period, reporting scope and relevant tags. Copying an ordinary CIT mapping into an Estonian CIT company can be as misleading as assuming that the latter is exempt from all JPK requirements. The judgment and the ruling answered different questions and should not be presented as conflicting decisions on the same point.

What does a court's annulment of a tax ruling actually establish?

The reason for a court's decision also matters to an implementation project. In its final judgment of 15 April 2026, case I SA/Op 873/25, the Regional Administrative Court in Opole annulled a ruling concerning separately maintained books of a Polish company's foreign branches. The company pointed out that the branches kept their accounts under the laws of their respective countries. The authority had not adequately explained why the obligation should nevertheless extend to those books, taking account of the company's arguments and the relevant accounting provisions.

The court found material procedural defects in the reasoning and did not decide the remaining substantive tax arguments. This was not a judgment approving the addition of tags during export. Nor does the operative part alone establish a general JPK exemption. Before relying on a favourable judgment, a business needs to identify the actual dispute, the reason the taxpayer succeeded and the questions left unresolved.

Individual rulings on account tags likewise show the authority's view of a specified accounting model. They help assess risk and compare designs, but protective effect depends on the statutory conditions and the correspondence of the taxpayer's own facts. The project documentation should explain those differences instead of treating another taxpayer's favourable or adverse outcome as sufficient in itself.

How should the implementation be checked before submission?

Acceptance should include data that captures the business's real difficulties: a deductible expense, a permanent exclusion, a temporary difference and its later reversal. Mixed activities call for a shared cost example; a complex chart of accounts also calls for checks of general ledger and intermediate accounts. The purpose is to test different mechanisms, rather than select an arbitrary sample of invoices.

For each item, establish the source document, posting, account, tax analysis, tag and JPK presentation. Reconcile turnover and balances, and explain differences between the accounting result and the CIT calculation. Not every amount in the entire JPK file must match a single CIT-8 field. The business should nevertheless be able to explain the path between the data sets, allowing for their different reporting scopes.

The test should also reproduce a later change: payment of previously accrued interest, an invoice correction or a revised tax classification. This shows whether the change reaches all connected entries and whether a fresh export produces a different result for an identifiable reason. Mapping rules should have an identifiable version, an effective date and a person responsible for approving changes.

The result should be a specific discrepancy list: accounts requiring separation, missing tags, unreconciled differences and recommendations for the accounting team and system provider. Management can then assess the work and responsibility for completing it. A report stating only ‘file valid’ cannot provide that information. Our separate article discusses the wider scope of the files and the temporary JPK_ST_KR exemption.

Further reading on this area: JPK CIT and JPK_ST_KR in Poland: the scope of the temporary exemption and preparing data.