JPK_V7 corrections: what an AI agent fixes, and what it must never touch

There are two kinds of error in a JPK_V7 file, and nearly every conversation about automating them runs the two together.

The first kind is a file that disagrees with itself, or with the ledger it came out of. A sales invoice carrying goods that should have a GTU code and doesn't. A NIP with two digits swapped. A receipt-backed invoice marked FP that somebody also booked as an ordinary sale, so the same 4 000 zł sits in the file twice. A record part and a declaration part that stopped adding up because someone edited a document after the summary had already been generated. These are data problems. There is a correct answer, the data alone is enough to reach it, and software gets there faster and far more completely than a person scrolling a spreadsheet on the 24th.

The second kind is a file that is a perfectly faithful record of a wrong understanding. Everything ties. Every code validates. And a correcting invoice sits in June while the evidence that both sides agreed the discount is dated May — or a consulting engagement went in without GTU_12 because the invoice says "usługi wsparcia" and nobody asked what was actually delivered. Nothing in the data is inconsistent. The file is wrong anyway.

An agent removes most of the first kind. It cannot touch the second, and anyone implying otherwise is selling you a liability with a subscription attached.

The first kind is worth automating, for a reason that isn't the fine

The number everyone repeats is 500 zł per error. It's real. What gets dropped is how it actually arrives — and that omission is why half the offices I speak to are frightened of it and the other half have quietly decided it's a myth.

It isn't charged for every typo and it isn't automatic. It applies to errors that make it impossible to verify whether a transaction was correct, and it only goes live after the tax office sends a notice and you let fourteen days pass without either correcting the file or explaining that there's nothing to correct. The order matters: error, letter, fourteen days, then possibly money.

So the operational risk in a busy practice isn't the penalty. It's the letter. A notice arrives about a file you sent in April, it lands in a mailbox four people have access to, and the fourteen-day clock runs whether or not anyone has opened it. I watched a practice pay for exactly one error and describe the cost afterwards as "the fine plus the day and a half we spent reconstructing what we'd sent." The reconstruction was the expensive half.

Which is why you automate the mechanical checks — not to dodge 500 zł. A check that runs on the 3rd costs nothing. The same check on the 24th costs you the only week you don't have.

What actually automates

On a portfolio of 40 clients and roughly 2 400 documents a month, here's the work that can run in the background without anyone asking for it:

Code and marker consistency. Every sales line whose PKWiU or item classification implies a GTU code, checked against the code actually applied — and, more usefully, the reverse: codes applied to items that don't warrant them, which nobody ever goes looking for. Document markers on both sides too, including FP invoices inflating the totals and internal documents that should carry WEW and don't.

Duplicates, properly. This got materially easier once the KSeF mandate went live. Every structured invoice now carries a unique KSeF number — the reliable key duplicate detection never had. Before that you matched contractor plus amount plus date and swallowed the false positives. A repeated KSeF number is a fact, not a heuristic.

Cross-period placement. Documents dated in one month, booked in another, listed with the gap in days. Not to move them. To show them to someone. This overlaps with what a close actually looks like when documents arrive late — same problem, seen from the other end.

Internal arithmetic. The record part reconciled to the declaration part before submission rather than after a letter, plus the checks that only make sense across clients: a contractor filed as a supplier for one client and a customer for another, related-party flags set for one entity and missing for its sister company.

The letter clock. A notice received, logged, counted down from, visible to more than one person. Deeply unglamorous. Probably worth more than everything above it.

All of it in draft-and-alert mode, the same rule that governs every agent I build for accounting offices: the software prepares and warns, a named person decides and signs. In an enova365 or Optima setup the findings attach to the document itself as attributes and notes — not to a separate dashboard somebody has to remember to open.

The correction itself is the easy part

This surprises people who haven't filed many: the mechanics of a JPK_V7 correction are trivial. The file has a record part and a declaration part, and you correct them independently. A wrong GTU code, a mistyped NIP, a missing marker — none of it moves the tax, so you resubmit the record part and leave the declaration alone. Only corrections that change the numbers reach the declaration part.

Generating that file is a solved problem. Your ERP does it. The agent's contribution is deciding to look, not knowing how to write XML.

The hard part sits upstream: deciding that something was wrong, deciding which month it was wrong in, deciding whether the answer is a correction or an explanation. None of that is a data problem.

The five decisions that stay with a person

Which period a correcting invoice belongs to. On the sales side an in-minus correction doesn't follow the date printed on the document. It follows when the parties agreed the new terms, and whether you hold documentation proving it. That documentation is sometimes an email, sometimes a signed annex, and quite often a phone call written up three weeks later. An agent can surface every correcting invoice and flag the ones with no supporting document anywhere in the system. It cannot decide when an agreement happened.

What a service actually was. GTU_12 covers intangible services — advisory, accounting, legal, management, marketing, market research, training. The invoice in front of you says "usługi wsparcia" or "obsługa projektu". Whether that was advisory work is a question about what got delivered, not about what someone typed into the description field. A model will guess, and it will guess confidently, and it will be wrong often enough to matter.

Who is related to whom. Related-party marking depends on a relationship graph that mostly doesn't live in any system you own — family ties, overlapping boards, a shareholding held through a third entity. Once someone builds that map, an agent will hold it and apply it consistently, which is genuinely useful. It won't discover it for you.

How to answer a wezwanie. Replying to a tax office notice is a representation act. Sometimes the right answer is a correction. Sometimes it's a letter explaining that the file is right and the office is reading it wrong. That call carries professional liability, and liability doesn't delegate to software.

Whether to correct at all. Not every error you find is worth correcting, and judging materiality — including what a correction signals about the months either side of it — is exactly what you pay an accountant for.

If someone offers you an agent that "handles JPK compliance" with no person standing on those five, the offer is dishonest. Same logic as contractor verification and deciding when split payment is mandatory: registry lookups automate, judgment doesn't.

When not to build this

If JPK checks are the only thing you're automating, don't. On its own the pre-submission review runs maybe two to four hours a month across a mid-sized portfolio, once your ERP's own validation has done its work. Real hours, annoying hours, hours that always land at the worst point in the month — but not a project.

This is a module, not a product. Add it once an intake or bank reconciliation agent is already running against your data. At that point the JPK checks cost almost nothing extra, because the expensive part — a live connection to the ledger — is already paid for. The volume thresholds where any of this starts to make sense are the ones I worked through in what an accounting AI agent costs.

One number worth measuring first

Take your last six months of submitted files and count the corrections. Then split the pile in two: how many fixed something the data could have shown you before you hit send, and how many fixed something you only found out later, from a person?

Mostly the first? You have an automation problem, and it's the solvable kind. Mostly the second? No agent will help you, and the lever sits somewhere else entirely — usually in how fast documents reach you in the first place.

Most practices I've looked at assume they're in the second group and turn out to be in the first. The count is cheap to do, and it decides whether any of this applies to you at all.

Want to work out which group you're in, and what would actually attach to your ERP? Get in touch — scoping is free and takes half an hour. If you're earlier than that, here's how I judge whether a practice is ready for any of it: the AI readiness audit.