JPK_PKPiR for 2026 in an accounting office: a file you've been writing since January and will send in April 2027

You're Not Preparing This File. You've Been Writing It Since January

Clients on the revenue and expense ledger (KPiR) who file monthly JPK_V7M send their first annual JPK_PKPiR for 2026 by 30 April 2027, the deadline for the annual PIT return. Everybody else on KPiR follows a year later. That's the short version, and it's why most offices have mentally filed it under "spring".

Wrong drawer. JPK_PKPiR is not a report you'll compile next April. It's an export of the ledger as it stands, and nine months of that ledger already exist. Every row entered since January, under rules that also changed in January, will land in the file exactly as it was typed. Nothing validates it until the day it's generated. If that day is 28 April 2027, every problem you find gets fixed in a hurry.

October is the cheapest moment to look. Here's what to look at.

Who Sends When

The obligation sits in art. 24a of the PIT act and was phased in by VAT filing frequency:

• Wave 1, tax year 2026. PIT taxpayers on KPiR who file JPK_V7M. Ledger kept electronically from 1 January 2026, file for the whole year sent by 30 April 2027.
• Wave 2, tax year 2027. Everyone else on KPiR: quarterly JPK_V7K filers and VAT-exempt businesses. First file for 2027, sent by the 2028 return deadline. 30 April 2028 is a Sunday and 1 May a holiday, so in practice 2 May 2028.
• Not KPiR at all. Lump-sum (ryczałt) clients send JPK_EWP. Full-books clients are in the JPK_CIT world, which I covered in the JPK_CIT post.

The fixed-asset register for KPiR clients doesn't ride inside JPK_PKPiR. It goes as a separate structure, JPK_ST.

So the first job is a list, and it takes an afternoon: every KPiR client, marked V7M or V7K/exempt. If a client changed filing frequency during 2026, put them in a third pile and check how their case is treated before you assume either wave. Don't guess on those.

What Changed Inside the Ledger in January

The file is new, but the bigger change is the ledger it exports. A new regulation on keeping the KPiR, dated 6 September 2025, has applied since 1 January 2026. Four changes matter for the export:

• A column for the invoice's KSeF number. Every invoice that exists in KSeF should carry its number in the ledger.
• A column for the contractor's tax ID. NIP is enough. A ledger row with a name and no NIP used to be harmless. Now it's an empty field in a structured file.
• No more summary entries. Daily summaries of sales invoices are no longer an accounting document. Entries go invoice by invoice. Old habits ("sales per summary, 14 invoices") survive longer than regulations, especially at clients who enter their own sales.
• Electronic only. For wave-1 clients the ledger is kept in software from 1 January. A client who kept a paper ledger until December and typed January in late will still produce a structurally valid file. Whether the content is right is another question.

On the software side, the structure is now JPK_PKPiR(3). Comarch's documentation for Optima, for example, says the date range can't cross a calendar year, files can't be merged, and the non-qualified signature option isn't available for this structure. Check how each client's file will actually be signed before April. Who signs under which authorisation is a question for October, not for the last week.

The Column That Will Hurt: KSeF Numbers

Since 1 February 2026 every business receives structured invoices through KSeF. So from February, most domestic purchase invoices exist in KSeF with a number. The question is whether the number made it into the ledger.

It often won't have, for a boring reason. The invoice reached the office as a PDF in an email, or a photo from the client, and somebody booked it from that. The KSeF copy existed the whole time and nobody linked it.

Some rows will legitimately have no KSeF number, and those need sorting out first, or you'll chase ghosts:

• invoices from foreign suppliers,
• receipts with a NIP,
• invoices from sellers who weren't yet obliged to issue in KSeF (the smallest sellers have until 1 January 2027),
• offline invoices before a number was assigned (I wrote about offline24 mode separately).

I went through that list in detail in the post on documents outside KSeF. What's left after removing them is the real gap: ledger rows for invoices that exist in KSeF but carry no number. Each one is a small thing. Across a year and a portfolio, it's the difference between a file that matches the tax office's own data and one that doesn't.

The mirror image matters too: invoices that sit in KSeF and never reached the ledger. Some are private purchases with the business NIP, correctly left out. Some are costs the client never forwarded. The tax office sees all of them in KSeF. The ledger is where the office gets to explain which is which, and it's much easier to explain in October than after a question arrives.

A Trial Export, January to September

The cheapest diagnostic is to produce the file early. For each wave-1 client, generate JPK_PKPiR(3) for 1 January to 30 September. Don't send it. Open it and count four things:

1. Cost rows dated February or later with an empty KSeF number, minus the legitimate exceptions above. This is the KSeF-number gap.
2. KSeF purchase invoices for the period with no matching ledger row. Match on NIP, invoice number and gross amount.
3. Rows without a contractor tax ID where one obviously exists.
4. Summary entries. Search the description field for "zestawienie", "wg zestawienia", "sprzedaż dzienna" and similar.

Then the same for JPK_ST: assets depreciated in the ledger that aren't in the register, and the other way round.

The output isn't a pass or a fail. It's a per-client list ranked by size, and that ranking tells you where November goes.

What It Costs Across a Portfolio

Rough arithmetic. Say an office has 60 KPiR clients, 25 of them on V7M. Say an average client books 60 cost documents a month. Nine months is 540 rows per client, about 13,500 across wave 1.

Nobody checks 13,500 rows against KSeF by hand. In practice offices sample, find a handful of problems at the clients they already worry about, and miss the rest. The check itself is mechanical: two lists of invoices and a match on three fields. It's exactly the kind of work that shouldn't need an accountant, and exactly the kind that gets skipped because in practice it still lands on an accountant's desk.

What an Agent Does, and What Stays With the Accountant

An agent here runs read-only. It never posts anything to the ledger.

• Generates or reads the trial export per client, on a schedule. Monthly from now on, not once in April.
• Matches ledger rows with KSeF downloads that the office already pulls (see automating KSeF downloads). Output: rows missing a number that should have one, with the number it should be, and KSeF invoices with no ledger row.
• Flags structural leftovers: summary entries, missing tax IDs, rows outside the period.
• Reconciles the asset register with depreciation in the ledger.

What it doesn't do: decide that an unbooked KSeF invoice is a private purchase, move a cost to another month, or change a row. Those are judgments, and they stay with the person who signs. I wrote about where that line runs in AI agents and liability. It's the same split as everywhere in accounting work: the agent prepares the list, a person decides.

A Calendar

• October: split the portfolio into wave 1, wave 2 and "check first". Run the trial export for wave 1.
• November: fix the KSeF-number gap and the unbooked KSeF invoices, biggest clients first. Settle how each file will be signed.
• December: run the export again for January to November. The list should be short. Do it before the year-end close takes every free hour.
• January–April 2027: monthly re-runs, then the real file with the annual return. Wave 2 starts its own year on 1 January, so the same check runs for them from month one.

One Number to Start With

Take your three largest V7M clients on KPiR. For each, count the purchase invoices in KSeF for September and the September ledger rows that carry a KSeF number. If the two numbers match, the 2026 file is in better shape than most. If one is half the other, you know what April would have looked like.

If you'd like a second pair of eyes on that count, or want to see an agent run it for the whole portfolio, write to me.