Sales invoices in KSeF from the accounting office's side: you build the register from the client's list, the tax office holds the original

The Half of KSeF Most Offices Don't Download

Ask an accounting office what it automated for KSeF this year and you'll hear about purchases. The client's cost invoices now land in KSeF, so the office pulls them, matches them and books them. That's where the effort went, because that's where the pain was: costs arrive from other people, in every format, late.

Sales get much less attention. The client issues their own sales invoices, so the office assumes it knows about them. In practice, sales reach the register the old way: a monthly list exported from the client's invoicing software, a folder of PDFs, sometimes a spreadsheet. The office books what the client sends.

But since KSeF became mandatory, every one of those invoices has been issued through KSeF. The tax office has the complete list before the client's version even reaches you. The client's list is a copy. KSeF holds the original — and that's what your JPK_V7 gets compared against.

So the question isn't whether to pull the purchase side. You already do that. The question is whether you pull the sales side too, and check it against the register before the file goes out on the 25th.

Why the Client's List and KSeF Disagree

The client isn't hiding anything. The list and KSeF drift apart for perfectly ordinary reasons.

More than one invoicing tool. The main program, the bank's built-in invoicing, an app on the owner's phone, an online shop that issues invoices on its own. Each one sends to KSeF. Only one of them produces the list that reaches the office.

More than one person issuing. An employee with KSeF permissions issues an invoice from the client's account and never tells the owner, who then never tells you. I wrote about keeping track of who holds which KSeF permissions separately. It matters on this side too.

Corrections. The client issues a correction in KSeF to fix a price or a quantity, and the list for that month doesn't include it because "it's just a correction". The KSeF corrections post covers the booking side.

None of that is new. What's new is that the tax office now sees all of it, row by row.

Two Rules That Change What "Issued" Means

Two rules from the VAT act and the Ministry of Finance explanations decide whether a row in the register is right. Both are easy to miss when you're working from the client's list.

A structured invoice is issued on the day it's sent to KSeF (art. 106na(1) of the VAT act). The date the client typed into their software, field P_1, is the date the seller declares. If the file goes to KSeF a day later, the send date is the one in the UPO and in the KSeF number. An invoice prepared on 31 October and sent on 1 November was issued in November.

For most sales the VAT tax point is the delivery date, not the issue date, so the month doesn't move. For supplies where the tax point is tied to issuing the invoice, such as rent or re-invoiced utilities, it can. Add overnight batch sending or a KSeF outage at month-end, and that becomes a real difference.

A rejected invoice was never issued. KSeF can reject a file, for example because of a structural error or a sender without permissions. The Ministry's position is that a rejected invoice isn't treated as issued. It gets no KSeF number. It can't be corrected or cancelled. The seller fixes it and sends it again, and the new send date is the issue date.

Here's the catch. Plenty of invoicing programs keep the rejected invoice on the list, with its number and amount, next to a status column nobody reads. It goes into the export, the export goes to the office, and the register now holds a sale that legally doesn't exist. If the client later re-sends a fixed version, you can end up with both.

Rows That Are Allowed to Have No KSeF Number

Not every sales row without a KSeF number is a mistake. On the sales side, the legitimate ones in 2026 are:

• invoices issued before the client's KSeF obligation started (1 February 2026 for the largest businesses, 1 April 2026 for the rest),
• invoices from the smallest sellers, who could stay outside KSeF until the end of 2026 while their monthly invoiced sales stayed under 10,000 zł,
• offline24 invoices that got their KSeF number later, and need it filled in once they do,
• cash register sales to private customers, booked from the daily report,
• documents that were never invoices in the KSeF sense.

Each of those needs the right marker in JPK_V7. The post on OFF, BFK and DI goes through them, including the BFK row sitting next to a buyer's NIP, which is the classic sign of a sale that should have been in KSeF.

The Comparison, Before the 25th

The check is simple to describe. For each VAT client, before the JPK_V7 for the month is sent:

1. Pull every invoice the client issued in KSeF for the month. Most offices already have the client's invoice access because they download purchases, so what's usually missing is the query, not the permission. If your downloading tool only looks at the client as a buyer, that's the first thing to fix (see automating KSeF downloads).
2. Match them with the sales register on KSeF number, then on invoice number, buyer NIP and gross amount for rows without one.
3. Count five things:
   • KSeF invoices with no row. Sales the tax office sees and the register doesn't.
   • Rows with no KSeF number after the client's start date, minus the legitimate exceptions above.
   • Rows that match nothing in KSeF at all. Candidates for a rejected invoice that never got issued.
   • Send dates in a different month than the date in the register, for clients whose tax point can follow the issue date.
   • Corrections in KSeF that aren't in the register.

The first two are mechanical. The third is the interesting one, because the fix isn't "add the KSeF number". It's "find out whether this sale exists".

What It Costs Across a Portfolio

Rough, hypothetical numbers. An office with 120 VAT clients, each issuing on average 60 sales invoices a month, has about 7,200 sales rows a month. If 1% of them disagree with KSeF in some way, that's 72 rows a month that someone has to look at. That's not the scary part. The scary part is that nobody is looking at them now, because nobody is comparing.

By hand, the comparison takes long enough that it never makes it into the pre-25th routine. Run by software, it's a list waiting for you on the morning of the 20th.

What an Agent Does, and What Stays With the Accountant

The agent runs read-only. It doesn't add, change or delete anything in the register or in KSeF.

• Pulls issued invoices from KSeF for every VAT client, every month, alongside the purchase side.
• Matches them with the sales register and lists the gaps both ways, with the KSeF number that should be in each row.
• Flags rows with no KSeF counterpart as "possibly rejected or never sent", not as errors to fix.
• Compares the send date with the register date and lists invoices that crossed a month boundary.
• Finds corrections issued in KSeF with no row in the register, and links each one to the original invoice.
• Suggests markers (OFF, BFK) for rows that legitimately have no KSeF number.

What it doesn't do: decide the tax point for a supply, decide the VAT rate, or decide whether a document should be booked at all. Those are judgment calls, and they stay with the person who signs the file. I wrote about where that line runs in AI agents and liability.

For ryczałt clients, the same comparison feeds the revenue record — the JPK_EWP post covers the receipt-invoice trap on that side.

One Number to Start With

Take your five largest VAT clients. For September, count the invoices each one issued in KSeF and the sales rows in the register that carry a KSeF number. For a client fully in KSeF, those two numbers should be equal. If they're not, the difference is either a sale you never heard about or a sale that never happened. Either way, you want to know before the tax office asks.

If you'd like to see that comparison run across your whole portfolio, write to me.