Migration to SAP S/4HANA in the middle of a year and JPK CIT. How to submit a JPK_KR_PD report without errors?

Migration to SAP S/4HANA in the middle of a tax year is one of the most challenging projects for finance and accounting departments. The JPK_KR_PD file contains accounting records and data required for preparing the CIT return. The JPK_KR_PD report must be submitted by most taxpayers by 31 July 2027.

In the face of the new reporting obligations, the change of the system is not merely an IT project but also has a direct impact on the continuity of the accounting records, the consistency of data, and the accuracy of the the generated JPK file.

Key takeaways:
– Migration between different SAP versions in the middle of a year has an impact on JPK CIT reporting.
– The safest option is to generate a single JPK_KR_PD file containing complete records for the entire tax year.
– In practice, it is often necessary to prepare two partial files.
– It is crucial to maintain continuity and consistency in the accounting records and the chart of accounts.
– Problems arise mainly when balances are transferred.
– Correct mapping of the chart of accounts is crucial for accurate JPK_KR_PD reporting.
– It is a good practice to start preparing for JPK_KR_PD reporting well ahead, particularly with a view to a planned change of the financial and accounting system.

1. A challenge for businesses

Due to frequent amendments to the legislation and reporting obligations which are difficult to follow, companies are often required to change their financial and accounting systems. The goal is to obtain a tool that allows businesses to fulfil their statutory accounting and fiscal obligations while also facilitating effective management, liquidity control, budget planning, comprehensive reporting, and integration with other processes. Changing the financial and accounting system may be also dictated by the group to conform to its software and reporting structure.

In changing the financial and accounting software in the middle of a year, the closest attention must be paid to data migration as well as configuration and parameterisation of the new system. To check that the migration has been completed without errors, process tests are carried out in the new environment.

The most optimal solution is to change the software at the beginning of the tax and fiscal year. In practice, for various reasons, the change often takes place in the middle of the year.

Pre-migration checklist

✅ Review the chart of accounts and the structure of the books.
✅ Check if the option of traceability of the accounting records is available.
✅ Identify the method of JPK_KR_PD reporting in the new accounting system.
✅ Determine if the new software has the option to generate a JPK_KR_PD file for the entire tax year.
✅ Generate test JPK_KR_PD files from the previous and present systems, i.e. pre- and post-migration.
✅ Verify the completeness, compatibility, and consistency of the data in JPK_KR_PD partial files.
✅ Verify the completeness and consistency of historical data.
✅ Document the migration process.

2. S/4 specifics
The issue in question generally applies to users of older versions of SAP software. As SAP will discontinue the support for SAP ECC, which has been the main pillar of the ERP suite, the users will have to migrate to the latest release – S/4HANA. Failure to migrate to the new system by 31 December 2027 will result in the users not receiving any updates or security patches, incurring higher maintenance costs, and losing access to the new features of the SAP software.

SAP S/4HANA is modern ERP software designed to support enterprises in managing business processes in key operating areas, such as finance, manufacturing, supply chain, sales and procurement, and resource management. In simple terms, it can be described as the technological ‘successor’ to SAP R/3 and SAP ERP, which, by utilising built-in artificial intelligence and process automation, enables better operational efficiency.

In what way will CIT payers who use SAP software be affected? They will have to find a way to generate the JPK_KR_PD file when changing the software – for example, from R/3 to S/4HANA – and transfer their data, which might frequently take place in the middle of a tax year. In practice, it often leads to accumulation of implementation projects in the company and the need to engage IT specialists as well as accounting and tax teams to a significant extent.

3. Key accounting aspects of successful data migration

When changing the system in the middle of a year, the most important aspect is to avoid any errors in the accounting records or in the structure of the financial statements. Before obligatory JPK CIT reporting was introduced, only the snapshot of the company’s financial position as at the balance sheet date was important. Now, however, each individual posting matters more than the year-end accounting. Hence the importance of correct data migration and of the adequate planning of the process as well as carrying it out within appropriate timeframes. 

Other relevant ‘accounting’ aspects of data migration include:

1. Ensuring the continuity of the accounting records – the new system may use a different numbering convention for documents and records (e.g. journals, entries, the chart of accounts, vendor and supplier numbering) to previous systems. Therefore, it is crucial to ensure adequate mapping of numbers to maintain data continuity.
2. Ensuring data consistency throughout the fiscal year – mapping of the accounts to maintain consistency of the accounting records.
3. Consistency of balances, entries, and document history – data transferred from the previous system must be complete in order to prevent gaps in data which would subsequently lead to discrepancies in registers or errors in tax filings (including retracing of unsettled items in accounts payable and accounts receivable, verification of the consistency of closing and opening balances).
4. Access to historical data – following the change of the system, the entity must still have full access to historical data for inspection, audit, and reporting purposes.
5. Documenting the migration – for the purpose of recording the migration date, the range of the migrated data, the method used to ensure the continuity of numbering and record-keeping, the mapping of accounts and of vendors and suppliers, and control procedures.

4. JPK_KR_PD after changing the accounting system in the middle of a tax year

Taxpayers generally have two options: to submit two separate JPK_KR_PD files – one generated from SAP R3 and the other from SAP S/4HANA – or to submit one file which contains all the postings from the new system.

Filing a single report is most certainly the safest option. It would be possible if the new system was able to retrace all the postings from the first day of the tax year. However, it would only be possible if all data (record by record) has first been accurately and completely migrated from SAP r4 to SAP S/4HANA.      

In practice, due to the volume of the data, migration is not performed in full; instead, all debit and credit entries recorded in an SAP R3 account to date are transferred to the corresponding account in SAP S/4HANA by way of a single record. 

In such a situation, taxpayers have the option to generate and submit two JPK_KR_PD files:

• one covering the period from the beginning of the tax year to the migration date (SAP R/3),
• the other one covering the period from the migration date to the end of the tax year (SAP S/4HANA).

This possibility is allowed by the Ministry of Finance, as referred to in the Q&A section available on the Ministry’s website (answer to question No. 140). As stipulated, if taxpayers have several accounting systems, they are required to consolidate the data for the reporting period into a single complete JPK_KR_PD file covering the entire tax year/fiscal year and to retrace:

• all accounts which show debit and credit entries and/or balances for the reporting period
• all primary accounts whose subsidiary accounts show debit and credit entries and/or balances for the reporting period

As pointed out by the Ministry, the JPK_KR_PD logical structure has a feature that allows taxpayers to split the generated JPK_KR_PD file into any periods, provided they are not shorter than one day. It should be noted, however, that the JPK_KR_PD files generated for any given periods must maintain the continuity of their records so that, after being consolidated into a single file, the consolidated file fully reflects the entity’s books of account without any gaps or duplicates in any of the nodes.

5. How to generate partial JPK_KR_PD files?

According to the guidelines of the Ministry of Finance referred to in the Q&A section (for example, question No. 150), “JPK_KR_PD files generated for any given periods must maintain the continuity of their records so that, after consolidation of the data, the consolidated file fully reflects the entity’s books of account without any gaps or duplicates in any of the nodes”.

In addition, partial periods must be reported successively and cover the entire reporting period of the tax year (or fiscal year) without any gaps or duplicates. If submitted in that manner, the partial JPK_KR_PD files will ensure the continuity of reporting.

To ensure the consistency and continuity of the data in partial files for any given period, for each account, the values in the “ZOiS” node must be shown in line with the following scheme:

• in the S_4 field – the opening balance of the account (Debit) as at the beginning of the tax year/fiscal year
• in the S_5 field – the opening balance of the account (Credit) as at the beginning of the tax year/fiscal year
• in the S_6 field – total entries on the account (Debit) for the partial period
• in the S_7 field – total entries on the account (Credit) for the partial period
• in the S_8 field – total entries on the account (Debit) for the period from the first day of the tax year/fiscal year to the last day of the partial period
• in the S_9 field – total entries on the account (Credit) for the period from the first day of the tax year/fiscal year to the last day of the partial period
• in the S_10 field – balances of the account (Debit) as at the end of the partial period
• in the S_11 field – balances of the account (Credit) as at the end of the partial period

Case study 1

A company whose tax year coincides with the calendar year changed its financial and accounting system with effect from 1 October 2026. Taking into consideration the above guidelines, the balances and entries in the partial files should be shown as per the following table:

To meet the above requirements, it is necessary to determine if the chart of accounts also changed as a result of changing the accounting system.

Case study 2 

The company changed its accounting system with effect from 1 October 2026. The chart of accounts in the new system will be the same as the one in the current system, and the numbering of the records will be continued. The company is planning to submit two JPK_KR_PD files: one covering the period from January to September 2026 from SAP R/3 and the other covering the period from October to December 2026 from SAP S4/HANA. The company is not planning to transfer individual business transactions and records from SAP R/3 to SAP S4/HANA. 

The company entered into SAP S4/HANA the total of the opening balance as at the beginning of the fiscal year and all debit and credit entries recorded on a given account to date as the opening balance of that account (data from SAP R/3), recognising them on the last day of the month prior to the go-live of SAP S4/HANA, i.e. 30 September 2026. For the profit and loss accounts, only the debit and credit entries for the period from January to September were transferred in this manner.

Using this approach, it will be problematic to generate a JPK_KR_PD file from SAP S4/HANA, since – as indicated in the table above – each partial file must show the opening balance, and it cannot be generated directly from the new system. In addition, the company will be unable to generate the incremental amounts of the entries accurately, as the total entries for the period from January to September 2026 are recorded in SAP S4/HANA together with the opening balance (for the balance sheet accounts). 

In view of the above, when migrating balances from SAP R/3 to SAP S4/HANA, one needs to take into consideration the JPK CIT reporting obligations.

6. Bottom line

Adequate preparations for migration involve close collaboration between finance, tax, and IT teams already at the stage of planning the new SAP environment. In principle, the JPK_KR_PD report should contain continuous and consistent data that align with the financial statements. Consequently, it must include complete books and postings as well as enable traceability of all the accounts which show debit and credit entries and balances for the reported period.

In practice, S/4 rarely allows for complete traceability of the accounts if migration takes place in the middle of a year. In such a situation, the solution is to generate and submit two JPK CIT files:

• JPK 1 – from the beginning of the year to the migration date (SAP R3)
• JPK 2 – from the migration date to the end of the year (e.g. SAP S/4)

An important aspect is to maintain the continuity and consistency of the data as well as to ensure full compatibility of the balances.

Are you planning to migrate to SAP S/4HANA? It is worth considering JPK CIT requirements already at the planning stage. Experts of RSM Poland support enterprises both in analysing the tax implications of migration to the newer SAP version and in preparing JPK CIT reports in accordance with the requirements of the Ministry of Finance.