Mapping the chart of accounts to JPK CIT: how to assign tags and check the data?

Mapping the chart of accounts to JPK CIT means assigning tags from the Ministry of Finance dictionary to every account with turnover or a balance. This stage determines whether the JPK_KR_PD file will show the books the way the company sees them. In this article, we show how to carry out the mapping step by step and how to check the data before the file is generated.

What is chart of accounts mapping in JPK CIT?

Chart of accounts mapping means assigning tags to accounts, which in the JPK_KR_PD file indicate the content of a given account. The tags come from the dictionaries in the annexes to the Regulation of the Minister of Finance on additional data to be added to the accounting books kept. They are assigned to accounts, not to individual entries. However, the choice of tag is determined by the content of the events recorded on the account, not by its name alone.

Mapping does not have to mean changing the chart of accounts. A company usually keeps its company chart of accounts and adds a layer of tags to it. The need for changes usually arises when one account combines events of different content, which we discuss below.

A separate situation concerns taxpayers who prepare financial statements under IFRS/IAS. Until 1 January 2028, they do not have to supplement their books with account tags. This follows from the amending regulation of 15 December 2025. The Ministry of Finance explains that, for these taxpayers, the tag fields (S_12_1, S_12_2 and S_12_3) may remain empty. However, they still file the JPK_KR_PD file.

Here, we focus on how to assign and check these tags.

Which accounts need to be mapped?

Mapping covers the accounts shown in the trial balance (ZOiS) in the JPK_KR_PD file. The trial balance includes accounts on which there was turnover in the reporting period or whose balance is other than zero. Off-balance-sheet accounts are also shown, but there is no obligation to include all of them. In practice, those most often reported are the ones that relate to values necessary for calculating CIT.

The scope of mapping depends on the type of tag:

• S_12_1: a tag must be assigned to all accounts included in the file. A missing tag in this field will block the submission.
• S_12_2: a tag is assigned only where necessary.
• S_12_3: a tag is assigned only to accounts that relate to the CIT calculation.

What level of detail to choose: synthetic or analytical account?

The level of detail of the trial balance depends on the company chart of accounts of the particular company. The structure does not impose a single analytics pattern. However, the file shows the relationships between accounts: field S_3 indicates the parent account for the account shown in field S_1.

The Ministry of Finance explains this using the example of account 403 with analytical accounts 403-1 and 403-1-1:

In practice, it is worth starting the mapping at the lowest level of analytics at which the content of the account is homogeneous. The tag of the parent account follows from the mapping of its analytical accounts:

• if all analytical accounts have the same tag, the parent account receives the same tag,
• if the analytical accounts have different tags, the parent account is assigned the “Inne” (Other) tag.

What to do with an account containing events that require different tags?

If transactions of a different tax nature are recorded on one account, e.g. tax-deductible costs (KUP) and non-deductible costs (NKUP), they may need to be separated. The Ministry of Finance takes the position that such transactions should be divided into homogeneous groups, recorded on separate analytical accounts and assigned the appropriate PD tags in JPK_KR_PD.

Depreciation is an example. According to the Ministry of Finance’s explanations, accounts on which depreciation charges constituting tax-deductible costs are recorded do not, as a rule, require a PD tag (the exception concerns the R&D relief). However, accounts used to record depreciation that is not a tax-deductible cost should be marked with the appropriate tag.

Off-balance-sheet accounts can also be used to record differences between the accounting result and the tax result. If they are used to show such differences, reporting them in JPK_KR_PD is mandatory. These accounts are marked with the appropriate PD tag with the “POZABILANSOWE” (off-balance-sheet) designation in field S_12_3 and with the “INNE” (other) tag in field S_12_1. Other off-balance-sheet accounts may be reported voluntarily.

It is worth remembering that, in exceptional situations, the JPK_KR_PD structure allows two accounting tags to be assigned to one account (fields S_12_1 and S_12_2). However, this option does not apply to the PD tax tags shown in field S_12_3.

How should historical and inactive accounts be treated?

Accounts with no turnover and no balance in the reporting period are not included in the trial balance, so they do not require mapping for that year. It is different with accounts that have had no new entries for years but still have a balance. Such an account will appear in the file and needs tags.

Before the new year, it is worth reviewing old accounts with balances. Some of them can be closed, or their balance can be transferred to an account with the correct content. This reduces the number of accounts to be mapped and the risk of errors.

How to map the chart of accounts step by step?

Mapping is best carried out as a project with clear stages and a single coordinator. The sequence below works both for the first reporting cycle and for reviewing the mapping for the following year.

1. Review of the chart of accounts and turnover. Generate a list of accounts with turnover and balances for the reporting year. This is the scope of the mapping.
2. Selection of dictionaries. Determine which dictionaries from the regulation apply to your company. Create a working table from them with the tag codes and descriptions.
3. Assignment rules. For groups of accounts (e.g. revenue, costs by nature, settlements), write down a rule for which tag they receive. The rule makes it possible to map new accounts in the same way.
4. Assignment and justification. Assign tags to the accounts. For ambiguous accounts, write down a short justification for the decision.
5. Tax review. The tax department checks the profit and loss accounts and off-balance-sheet accounts for tax tags.
6. Approval of the version. Freeze the mapping for the given year. Each new account during the year follows the same path: rule, assignment, review.

Example: a company has 2,400 accounts with turnover in the year. After grouping, it turns out that 2,100 accounts can be mapped using group rules. Approximately 300 accounts, mainly cost and off-balance-sheet accounts, require a manual decision. This is where it is worth focusing the tax department’s time.

It is worth recording each tag decision in a mapping register: the account, the assigned tag, the rule or justification, the person who approved it and the date. The register makes it possible to reconstruct why an account has a given tag, even after changes in the team. It will also be useful if the tax authority asks questions about the file. We write about how the authorities select companies for review in the article JPK CIT audit: how does the tax authority select companies for review in 2026?.

What to do if the chart of accounts cannot be changed?

If the system does not allow analytical accounts to be added, the mapping can be based on analytical dimensions and carried out outside the accounting system. Data from the system is then fed into a tool that builds an extended, so-called “virtual” chart of accounts from the accounts and dimensions. Tags are assigned on this layer.

This is how we solved the problem of one of ALTO Advisory’s clients. Its system had a completely closed chart of accounts, but rich dimensions and additional markers in the entries. On this basis, an additional analytical layer was created, which made it possible to assign accounting and tax tags without changes to the source system. You can find a description of the project in the case study ALTOOL JPK CIT – Support for reporting despite system limitations.

Such a solution requires discipline in the system itself. The dimensions on which the mapping is based must be filled in consistently for every entry. Otherwise, some entries may not correctly reflect the balance of the analytical account.

In addition, the implementation of such a solution should take into account the position of the Ministry of Finance, which favours separating analytical accounts directly in the books of account.

It also happens that some of the data needed for JPK CIT is not kept in the accounting system at all, but in additional records and statements. In another ALTO project, we imported such data from external files and combined it with the accounting data. The mapping then covered both sources, and the company did not have to rebuild its system.

How to check the data after mapping?

After completing the mapping of accounts to JPK_CIT, it is worth carrying out four checks: check that the PD tags are assigned completely and correctly, reconcile balances and turnover with the books of account, verify the consistency of the reported data with the CIT calculation, and carry out a technical validation of the JPK_KR_PD file.

It is worth remembering that a positive result of the technical validation does not yet mean that the data is correct for tax purposes. The file may comply with the JPK_CIT schema and still contain errors in the assignment of tax tags or discrepancies that require explanation.

Does every account with turnover have a tag?

This is the simplest and most important check. Compare the list of accounts with turnover or balances in the year with the list of accounts that have been assigned tags. Every difference is an account to be completed.

It is worth repeating this check every month. New accounts opened during the year are the most common source of gaps in the mapping.

Do the balances agree with the financial statements and the opening balance sheet?

For balance sheet accounts, the total of the balances of accounts with the same tag should be reconcilable with the corresponding item in the financial statements. If a difference appears, it usually indicates an account assigned to the wrong tag.

Example: in the balance sheet, trade receivables amount to PLN 4.2 million. The total of the balances of the accounts with the corresponding tag is PLN 3.9 million. The difference of PLN 300,000 leads to an account for settlements with foreign customers, which was opened during the year and was not assigned a tag.

It is different when a company reports data from the trial balance (ZOiS) after the balances of the profit and loss accounts have been transferred to the financial result account. In that case, the profit and loss accounts have no balances, so comparing balances alone will not help. The entries must first be reconciled with the tags, disregarding this closing entry. Only then are they reconciled with the financial statements and the CIT settlement.

Also check the opening balance sheet. Opening balances should agree with the closing balance sheet of the previous year, and the accounts to which they were transferred should have tags. This is particularly important after a system migration or a rebuild of the chart of accounts.

Does the data match the tax settlement?

The JPK_KR_PD file contains the RPD part, i.e. data on the differences between the accounting result and the tax result. It contains eight fields (K_1 to K_8). The RPD part cannot be calculated in full from accounts with tax tags. Fields K_7 and K_8 cover tax revenue and tax costs that are not recorded on balance sheet or profit and loss accounts. However, in its answers to questions about JPK_CIT, the Ministry of Finance indicates that these values should be shown on off-balance-sheet accounts. It is therefore worth planning such accounts when rebuilding the chart of accounts.

That is why it is worth reconciling the RPD with the tax calculation and treating the accounts with tax tags as one of the sources for this check. In practice, the tax department compares the totals of these accounts with the corresponding items of the calculation. An unexplained difference may indicate an account without a tag or with the wrong tag.

Where does mapping end and XML validation begin?

XML validation checks whether the file has the correct structure and complies with the schema published by the Ministry of Finance. The file may pass XML validation even though the mapping is wrong, because the schema does not check whether a given tag matches the content of the account. The exception is a tag intended for a different type of company. Such an error will block the submission of the file. That is why the checks described above are carried out before the technical validation.

What are the most common errors in mapping the chart of accounts for JPK CIT?

The most common mapping errors result from accounts with mixed content and from accounts opened during the year. Most of them can be detected with simple checks before the file is generated.

Who in the company is responsible for mapping the chart of accounts?

Mapping combines accounting, tax and technical knowledge, so each of these roles should have a clearly defined scope. Without this, decisions on tags are made by chance, and errors come back every year.

FAQ

Does the chart of accounts have to be changed for JPK CIT?

It all depends on how the current chart of accounts is built and whether it allows PD tax tags to be assigned correctly. The problem arises mainly when transactions of a different tax nature are recorded on one account, e.g. costs that are and are not tax-deductible (KUP and NKUP).

In such cases, the Ministry of Finance points to the need to separate appropriate analytical accounts that allow PD tags to be assigned correctly.

An alternative may be to use analytical dimensions and map the data outside the accounting system. However, such a solution requires verification for compliance with the JPK CIT requirements and the position of the Ministry of Finance.

Does a depreciation account always need a tax tag?

No. According to the Ministry of Finance’s explanations, an account for depreciation that is entirely a tax-deductible cost does not require a tax tag. If part of the depreciation is not a tax-deductible cost, that part is recorded on an account with the appropriate tax tag. That is why it is worth separating tax-deductible and non-deductible depreciation into separate analytical accounts.

Who should assign the tax tags?

PD tax tags should be assigned in cooperation between the accounting and tax departments. The accounting team knows the structure of the chart of accounts and how transactions are recorded, while tax specialists are responsible for the correct classification of revenue and costs for CIT purposes. That is why it is worth linking the mapping of accounts to JPK_CIT with the verification of the income tax calculation. ALTO’s tax advisers support companies in this process, helping them assign PD tags correctly and reconcile the data reported in JPK_KR_PD with the CIT settlement.

Does the chart of accounts mapping have to be repeated every year?

The full mapping does not have to be redone from scratch, but it is worth reviewing it before each year. The chart of accounts, the scope of activity and the regulations change. The regulation on additional data has already been amended, e.g. in December 2025. The review covers new accounts, accounts with changed content and whether the dictionaries are up to date.

Can the data be mapped without changes to the ERP system?

Not always. If the financial and accounting system allows accounting entries to be exported together with analytical dimensions, the mapping of data to JPK_KR_PD can in many cases be carried out in an external tool such as ALTOOL JPK CIT. This makes it possible to limit the scope of changes to the ERP system and to use the existing data to assign the required tags.

However, it is crucial to ensure that the reported data is consistent with the books of account and that transactions requiring different PD tax tags are correctly separated. In light of the current position of the Ministry of Finance, merely separating entries technically at the stage of generating JPK_KR_PD may be insufficient. That is why the scope of the necessary changes should be assessed individually.

How ALTO can help

We help companies map their chart of accounts to JPK CIT and check the data before it is submitted to the tax authorities. We combine accounting and tax knowledge with technology: we prepare mapping rules, review tax tags and reconcile data with the CIT calculation. When the system does not allow changes to the chart of accounts, we use our ALTOOL JPK CIT application.

Sources

• Ministry of Finance, JPK_PD questions and answers (Pytania i odpowiedzi JPK_PD), updated 17 July 2026: https://www.podatki.gov.pl/podatki-firmowe/jednolity-plik-kontrolny/jpk_pd/pytania-i-odpowiedzi-jpk_pd
• Ministry of Finance, Accounting books JPK_KR_PD. Information brochure on the JPK_KR_PD structure (Księgi rachunkowe JPK_KR_PD. Broszura informacyjna dotycząca struktury JPK_KR_PD): https://www.gov.pl/attachment/22010dbd-5e27-433b-84c5-ec99cee7487c
• Ministry of Finance, JPK structures in income taxes (Struktury JPK w podatkach dochodowych): https://www.gov.pl/web/kas/struktury-jpk-w-podatkach-dochodowych
• Corporate Income Tax Act of 15 February 1992 (Ustawa z dnia 15 lutego 1992 r. o podatku dochodowym od osób prawnych), Article 9(1) and (1c)
• Regulation of the Minister of Finance of 16 August 2024 on additional data to be added to the accounting books submitted under the Corporate Income Tax Act (Rozporządzenie Ministra Finansów z dnia 16 sierpnia 2024 r. w sprawie dodatkowych danych, o które należy uzupełnić prowadzone księgi rachunkowe podlegające przekazaniu na podstawie ustawy o podatku dochodowym od osób prawnych), Journal of Laws 2024, item 1314
• Regulation of the Minister of Finance and Economy of 15 December 2025 amending the regulation on additional data (Rozporządzenie Ministra Finansów i Gospodarki z dnia 15 grudnia 2025 r. zmieniające rozporządzenie w sprawie dodatkowych danych), Journal of Laws 2025, item 1828