JPK_EWP for 2026 in an accounting office: lump-sum clients send only their sales, and KSeF already knows every invoice

The Simplest JPK File, and the Easiest One to Check

Lump-sum (ryczałt) clients who file monthly JPK_V7M send their first annual JPK_EWP for 2026 by 30 April 2027. Everyone else on ryczałt follows a year later. That's the same calendar as JPK_PKPiR, and most offices will treat the two as one spring job.

They're not the same job. A KPiR ledger is mostly costs, and costs arrive from other people: PDFs, photos, foreign suppliers, invoices the client forgot to forward. A ryczałt revenue record is the opposite. There are no costs in it at all. It's the client's own sales, and since KSeF became mandatory the client has been issuing those invoices through KSeF. The tax office doesn't need JPK_EWP to know what your ryczałt client invoiced in June. It already has the invoices.

So JPK_EWP isn't really new information for the tax office. It's a test of whether the office's record agrees with data the tax office already holds. That makes it the easiest JPK file to check in advance, and the most awkward one to get wrong.

Who Sends When

The obligation comes from the lump-sum tax act (art. 15 of the act of 20 November 1998) and is phased in the same way as JPK_PKPiR:

• Wave 1, tax year 2026. Ryczałt taxpayers who file JPK_V7M. Revenue record kept electronically from 1 January 2026, file for the whole year sent by 30 April 2027.
• Wave 2, tax year 2027. Everyone else on ryczałt: quarterly JPK_V7K filers and VAT-exempt businesses. First file for 2027, sent in 2028.
• Separately: JPK_ST. The register of fixed assets and intangibles travels as its own structure. It also gained fields in 2026, including the KSeF number of the purchase invoice and the asset's production date.

The first job is the same as for KPiR, and it takes an afternoon: list every ryczałt client and mark each one V7M or V7K/exempt. Clients who changed VAT status or filing frequency during 2026 go into a "check first" pile. Many ryczałt clients are small and VAT-exempt, so wave 1 may be a shorter list than you expect.

What a Row Looks Like Now

The file structure is JPK_EWP(4). Each revenue row carries:

• the entry date and the date the revenue was earned,
• the document number,
• the KSeF number of the invoice,
• the contractor's country code and tax ID,
• the revenue amount,
• the lump-sum tax rate for that revenue,
• an optional note.

Three of those matter more than the rest.

The KSeF number and the tax ID are optional in the schema. That's not an invitation to leave them empty. They're optional because a cash register sale to a private customer has neither. An invoice to a company that exists in KSeF and sits in the record without its number is a row the tax office can match and you can't, which is the wrong way round.

The rate is per row. A client whose main service is taxed at 12% and who now and then sells something under another rate has two kinds of rows, and the file shows which revenue went where. Before, a wrong rate on one service was buried in a monthly total. Now it's a column, sitting next to the contractor's tax ID.

No more summary entries. From 2026 a daily summary of invoices is no longer an accounting document. Invoiced sales go invoice by invoice. Cash register sales to private customers still go in from the daily fiscal report. The law also dropped the requirement to show deductions from revenue in the record when calculating the monthly tax, so the record is now a cleaner list of sales.

Where Ryczałt Records Go Wrong

KSeF makes the main check almost trivial: the list of invoices the client issued against the list of rows in the record. The interesting part is the list of reasons the two won't match, and which of those reasons are fine.

Legitimate rows without a KSeF number:

• cash register sales from the daily report,
• invoices issued before the client's KSeF obligation started (1 April 2026 for most businesses),
• invoices from the smallest sellers, who could keep issuing outside KSeF until the end of 2026 while their monthly invoiced sales stayed under 10,000 zł. Plenty of ryczałt clients fall exactly here,
• offline invoices before the number was assigned (I wrote about offline24 mode separately),
• invoices to foreign customers issued outside KSeF where that was allowed.

The actual problems:

1. A KSeF invoice with no row. The client issued it in their own invoicing app and never told the office. This is the most common one, and it's revenue the tax office can see and the record can't.
2. A row with no KSeF number for an invoice that has one. Usually entered from a PDF or a monthly sales list the client sent over.
3. The invoice issued for a receipt. A customer buys on the cash register, then asks for an invoice with their NIP. The receipt is already in the daily report. If the invoice also goes into the record as a sale, the same revenue is counted twice. It's an old trap with a new twist: in 2026 that invoice also exists in KSeF. A matching check that doesn't look for the receipt reference will happily "find" it and flag it as missing.
4. A rate that drifted. The same client, the same kind of service, 12% for eight months and 15% in one. Sometimes it's correct. Often it's a default in the invoicing software.
5. Leftover summaries. "Sales per list, May" as one row. Old habits.

The double-counted receipt is the one worth explaining to staff before anyone runs the check, because the naive version of the check pushes people the wrong way: it says "this KSeF invoice has no row, add it", when the right answer is "this revenue is already in the record through the daily report".

A Trial Export, January to September

For each wave-1 client, generate JPK_EWP(4) for 1 January to 30 September. Don't send it. Then pull the client's issued invoices from KSeF for the same period. If you already download KSeF invoices automatically, you probably only pull purchases, so add the sales side (see automating KSeF downloads).

Count five things:

1. KSeF invoices with no matching row (match on invoice number, buyer tax ID and amount).
2. Rows dated after the client's KSeF start with no KSeF number, minus the legitimate exceptions above.
3. KSeF invoices that carry a receipt reference, and whether the matching revenue is already in a daily report.
4. Rows whose rate differs from the client's dominant rate for that kind of revenue.
5. Rows that look like summaries.

Then JPK_ST: assets on the register without the new fields, and purchases from 2026 that look like assets but never reached the register. The JPK_ST_KR post covers the full-books version of that problem, and most of it carries over.

What It Costs Across a Portfolio

Rough, hypothetical arithmetic. An office has 40 ryczałt clients, 15 of them on V7M. An average wave-1 client issues 35 invoices a month. Nine months is 315 rows per client, about 4,700 across wave 1.

That's a smaller pile than the KPiR side, and it's tempting to say someone can check it by hand in a week. Someone could, once. The problem is that it isn't a one-off. A client who forgot to tell you about three invoices in June will forget again in November, and the April file contains both months. This is a monthly comparison of two lists, and it should run monthly.

What an Agent Does, and What Stays With the Accountant

The agent runs read-only. It doesn't add, change or delete rows.

• Pulls issued invoices from KSeF for each ryczałt client and matches them against the record, monthly.
• Lists the gaps both ways: KSeF invoices with no row, rows with a missing KSeF number, together with the number it should be.
• Spots invoices for receipts by the receipt reference and checks whether the revenue is already in the daily report, so the list says "possible double count", not "missing".
• Flags rate outliers per client and kind of revenue.
• Checks JPK_ST for missing fields and likely missing assets.

What it doesn't do: decide which rate applies to a service, decide that a sale is private rather than business, or fix a row. Rate classification under the lump-sum act is a judgment with consequences, and it stays with the person who signs. I wrote about where that line runs in AI agents and liability. The agent's job is the list; the accountant's job is deciding what each line means.

A Calendar

• October: split ryczałt clients into wave 1, wave 2 and "check first". Trial export for wave 1, with the sales side pulled from KSeF.
• November: close the gaps, biggest clients first. Settle the receipt-invoice cases with each client's cash register practice in mind. Agree who signs each file.
• December: run January–November again before the year-end close eats the month.
• January–April 2027: monthly re-runs, then the real file. Wave 2 starts its year on 1 January, so for them the check runs from month one.

One Number to Start With

Take your three largest ryczałt clients on V7M. For each, count the invoices they issued in KSeF in September and the September rows in their revenue record that carry a KSeF number. For ryczałt, those two numbers should be close to equal: every invoiced sale is the client's own, and the only reason for a difference is a sale the office never heard about or a receipt that already counted. If they're far apart, you've found your November.

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