BFK, DI or OFF: a client's sales in JPK_V7 after KSeF, from the accounting office's side

One Column, Four Possible Values

Until January the sales side of JPK_V7 didn't care where an invoice came from. Since 1 February 2026 it does. In the JPK_V7(3) schema every sales record carries either the invoice's KSeF number or one of three markers: OFF, BFK or DI. Exactly one of the four. No exceptions.

On paper that's a small change: one extra field per line. In an accounting office it means that for every client, every month, someone has to know which of the four applies to each sales document. And most of those documents come out of the client's own invoicing tool, shop plugin or cash register. Not the office.

This week I've been writing about KSeF from the purchase side: offline24 invoices, corrections you have to wait for, and documents that never come through KSeF. This post looks at the same problem from the client's sales register. Eight months in, the mistakes repeat in clear patterns.

The Map

Here's the short version I use with offices. One sales document, one value:

Sales document	JPK_V7 value
B2B invoice issued in KSeF	KSeF number
B2C invoice issued in KSeF (voluntary)	KSeF number
B2C invoice issued on paper or as PDF	BFK
Invoice from a cash register, or from a seller under the 10,000 zł monthly limit (until 31.12.2026)	BFK
Offline24 invoice with a KSeF number known by filing day	KSeF number
Offline24 invoice with no KSeF number by filing day	DI, then correct once the number exists
Invoice issued during an officially announced KSeF failure, no number yet	OFF, no correction required
Cash-register report (RO), internal document (WEW)	DI, alongside the document type

Two definitions do most of the work. BFK is for invoices that are allowed to exist outside KSeF. DI is for documents that aren't invoices in the KSeF sense, plus the offline24 invoice that hasn't been given its number yet. Keep those two apart and most of the errors below go away.

Mistake 1: Consumer Invoices Marked DI

The error I see most often: a paper or PDF invoice for a private person goes into JPK as DI. The reasoning is "it's not in KSeF, so it must be some other document". But it's still an invoice. The correct marker is BFK.

It gets more interesting with clients who sell to consumers in volume. Issuing B2C invoices in KSeF is voluntary. Some sellers send every invoice through KSeF to keep one process, and the consumer gets access through the QR code on the PDF or printout. Others keep consumer invoices outside KSeF. Some do both, depending on which shop module produced the invoice. So the same client can legitimately have consumer invoices with a KSeF number and consumer invoices with BFK in one month. The office can't work out the marker from the buyer type. It has to check whether a KSeF number exists.

Mistake 2: BFK Next to a Buyer's NIP

This one isn't a marker error. It's a symptom of something worse.

Here's a scenario, not a case study. An online shop issues around 900 consumer invoices a month as PDFs and around 40 invoices to companies. Its shop plugin sends an invoice to KSeF only when the "NIP" field at checkout is filled in. A customer buying for their sole proprietorship types the NIP into the "company name" field instead. The plugin sees an empty NIP field, issues a PDF, and the record goes into the register as B2C with BFK.

As far as the JPK is concerned, everything adds up. Legally, though, a B2B invoice that had to go through KSeF didn't. The buyer won't see it in their KSeF and will eventually ask for it, usually after their own office has gone looking. The financial penalties for invoicing outside KSeF don't apply until 2027, but the invoice problem exists today.

The check is mechanical: every BFK line where the buyer data contains something that looks like a Polish NIP goes on a list. For clients with cash-register invoices or the 10,000 zł exemption, some of those lines are legitimate until the end of 2026. For everyone else, each one is a question for the client.

Mistake 3: DI on Offline24 Invoices, Then Nothing

An invoice issued in offline24 mode has to be sent to KSeF by the next business day. If the JPK for that month is filed before the office has the KSeF number, the line goes in with DI. Once the number exists, the sales record should be corrected to carry it. OFF works differently: invoices from an officially announced KSeF failure don't need that correction.

In practice, DI lines on invoices are exactly where corrections get forgotten. Nobody gets a reminder. The JPK was accepted, the month is closed, and the DI just sits there. I'd put one item on the office's monthly list: for the previous month, find every DI line whose document type is an invoice, and check whether it has a KSeF number by now. If it does, it needs a correction. If it doesn't after a week, the invoice probably never reached KSeF, and that's a much bigger problem than the JPK. The offline24 post covers how to spot that from the download side.

Mistake 4: Invoices to Receipts, Counted Twice

Invoices issued to receipts (FP) were a classic JPK trap long before KSeF. The sale has already been reported through the cash-register report, so the FP invoice gets a marker that stops it increasing the tax base a second time. KSeF adds another layer. An FP invoice to a company with a NIP is a normal invoice that goes through KSeF and carries its number. An FP invoice to a consumer issued outside KSeF carries BFK. The RO report it relates to carries DI.

So one sale can now appear as two lines with two different values in the KSeF column, and both are correct. The real problem is a line where the FP marker gets dropped during import from the client's system. With new KSeF integrations that happens more often than I'd like. The check: the number of FP-marked invoices for the month, compared against the number of FP invoices downloaded from the client's KSeF. A difference means the marker is getting lost somewhere.

Mistake 5: A KSeF Number That Doesn't Exist

The quietest of the five. The client's invoicing tool writes a KSeF number into the sales record. The office imports it. Nobody checks whether that number belongs to that invoice, or exists at all. Typos in hand-entered numbers, numbers copied from a rejected submission, a number belonging to the correction instead of the original invoice.

JPK validation checks the format, not the content. Only one thing confirms the number: the client's issued invoices in KSeF. If you already have automatic KSeF downloads for purchase invoices, the same connection can download what the client issued.

The Nightly Check

This is the read-only check I set up for offices on the sales side. It runs every night during the month and once more before the JPK is generated:

1. Download the client's issued invoices from KSeF for the period.
2. Match every sales record against them by KSeF number; if there's no number, by invoice number, buyer and gross amount.
3. Report five lists: KSeF numbers not found in KSeF; invoices found in KSeF but marked BFK or DI in the register; BFK lines with a buyer NIP; DI lines on invoices from the previous month that now have a KSeF number (correction needed); FP count mismatches.
4. Show the count per value (KSeF number, OFF, BFK, DI) next to last month's. A client whose BFK share jumps from 5% to 30% has changed something in their shop or invoicing tool, and nobody told the office.

The agent changes nothing in the books and doesn't file anything. It turns the KSeF column into something someone actually checked. It's the same pattern as the JPK_V7 corrections post: the agent prepares and reports, the person signs off.

Two Numbers for This Week

1. In September's sales registers, how many BFK lines have a Polish NIP in the buyer data? For clients without cash-register invoices or the 10,000 zł exemption, the right answer is zero.
2. How many DI lines on invoices from August and September are still uncorrected? If nobody in the office can answer that, it isn't on anyone's list.

Want the sales-register check running before your next JPK deadline? Write to me. If KSeF downloads already work in your office, it's a short step.