JPK_PKPIR in Poland: deadlines and preparing tax records with AI

JPK_PKPIR applies from 2026 to the first group of businesses keeping a Polish KPiR tax ledger: taxpayers required to submit JPK_V7M. Their file for 2026 is submitted after the year ends, normally by 30 April 2027. AI can help prepare and review the ledger data, but creating a file does not submit it.

If you are asking how AI prepares taxes in Poland, this requirement illustrates a specific part of the process. Before preparing an annual return, you need organised revenue, expenses and supporting documents. JPK_PKPIR communicates those records in a prescribed format. It is neither another name for a PIT advance nor a VAT return. This guide concerns a Polish sole proprietorship, or JDG, keeping a tax revenue and expense ledger. The rules were checked on 4 November 2026.

What is JPK_PKPIR?

JPK_PKPIR is an electronic representation of the Polish tax revenue and expense ledger, known as KPiR, following a Ministry of Finance structure. The XML file contains organised information about the taxpayer, reporting period and ledger entries. Version JPK_PKPIR(3) also includes information used to determine income and control totals. An ordinary PDF summarising expenses is not this file.

KPiR is used by businesses including sole proprietors taxed under the progressive PIT scale or flat-rate income tax, known as podatek liniowy. A business using ryczałt, the lump-sum tax on revenue, keeps a revenue register and uses JPK_EWP. A sp. z o.o. keeping full accounting books has a different reporting scope. Start with the type of records your business keeps, rather than selecting a file simply because its name contains “JPK”.

“JPK PIT” is an umbrella term for reporting books and registers related to personal income tax. It does not identify one universal form for every business. Here we focus on KPiR and the data required for JPK_PKPIR, rather than full accounting or fixed-asset reporting.

When must businesses start keeping electronic records?

The National Revenue Administration timetable distinguishes the start of electronic record-keeping from the later submission of a file. An obligation covering a particular year means preparing records throughout that year, not starting on the submission deadline.

The VAT reporting obligation on the date the books are opened matters when determining the applicable group. The Ministry of Finance explains this in answer 134 of its income-tax JPK questions and answers. If your VAT reporting arrangements changed during the year, do not determine the starting date solely from your software’s current settings.

The table presents the general timetable. Check the current rules for your circumstances if a specific exemption or change of status applies. A proposed postponement discussed in an article is not, by itself, an exemption in force. Recheck Ministry of Finance guidance before closing the year.

When is the first file due, and does 31 July apply?

For KPiR, the statutory deadline is linked to the annual PIT return deadline. This follows from Article 24a(1e) of the PIT Act, as amended by the Act of 15 May 2026. The ordinary annual PIT deadline is 30 April of the following year. For the first group keeping records for 2026, this means 30 April 2027.

The 31 July deadline for full accounting books is not the JPK_PKPIR deadline. This distinction matters when searching under the broad heading of income-tax JPK. Changes applying to full accounting do not automatically apply to a sole proprietor’s KPiR.

Submitting the annual ledger does not replace PIT-36 or PIT-36L, and it does not pay your tax. Keep separate tasks for preparing the ledger, submitting it, filing the annual return and settling any amount due. Completing one does not confirm the others.

How can AI help prepare tax-ledger data?

The useful work starts before an XML file is created. An assistant with access to the relevant documents can help read their details, suggest categories and identify entries that need an explanation. Its capabilities depend on the tool and the information supplied. A chatbot that knows tax rules does not automatically know your ledger.

Divide preparation into five steps:

1. Define the scope. Identify the business, year, tax regime and type of records. If you changed accounting software, include the earlier months.
2. Link entries to evidence. Keep the source document, date and description for each entry. A bank payment alone may not establish how an expense should be treated.
3. Review AI suggestions. Check the business purpose, category, period and amount. A convincing explanation is not sufficient reason to approve an unclear entry.
4. Resolve discrepancies. Look for missing documents, potential duplicates and differences between reports. Record which items still need a decision.
5. Reconcile before exporting. Check totals, annual completeness and the information needed to determine income, including inventory where applicable. Then create the file in software that supports it.

A useful instruction could be: “Help review my KPiR records for 2026. Identify entries without supporting documents, unclear categories and possible duplicates. Do not change entries without my approval.” This defines a review task; it is not a promise that every product supports every step. Uncertain tax treatment still needs a decision based on the documents and applicable rules.

Example: how can valid XML contain an incorrect expense?

Suppose an illustrative service-business ledger records the same expense twice: once from its supporting document and again when describing the bank payment. Assume the correct deductible expense is PLN 1,000. The duplicate overstates expenses by PLN 1,000, even if both entries contain correctly formatted dates and amounts.

XML validation may not detect this underlying accounting error. An assistant can help compare descriptions, amounts and documents, but similarity alone does not prove duplication. Two payments for the same amount can relate to different services. Reviewing the evidence establishes whether an entry needs correction.

After resolving the issue, check its effect on the ledger and tax calculations. Do not simply subtract PLN 1,000 from the tax: that is the expense amount in this example, not the liability. The example illustrates data review, rather than calculating tax for a particular business.

What should you check before generating JPK_PKPIR?

Confirm support for the correct structure version and submission purpose. The Ministry of Finance JPK_PKPIR(3) brochure distinguishes a file provided on request, an initial mandatory submission and a correction. An “export JPK” button does not establish that the program supports all three cases.

Check the taxpayer identifier, reporting period, counterparty details and control totals. AI should not guess a missing tax number. Resolve unclear document details at their source. Also retain a record of which ledger version produced the file, so it can later be compared with any correction.

In Norman, a useful starting point is reviewing the records described in the KPiR and exchange differences guide. Public documentation of ledger preparation does not confirm support for the new mandatory annual JPK_PKPIR(3). Before planning submission, check the available format and feature scope. Do not assume that AI submits it automatically.

When is preparation complete?

Distinguish three outcomes: reviewed accounting records, a correctly prepared file and successful delivery to the tax authority. Each needs different evidence. A saved XML confirms file creation. After electronic submission, check the processing result and retain the official receipt, UPO. Starting an upload is not enough.

For the wider process, see how AI prepares taxes for a Polish business and how to check JPK submission status and UPO. The first explains the broader tax workflow; the second explains receipt evidence. For JPK_PKPIR, the essential combination is an accurate ledger, the right reporting obligation and a deliberately completed submission.