Sent is not filed: the missing-UPO check an accounting office should run after every deadline

The Question That Makes a Room Go Quiet

Ask an accounting office how many of last month's filings have a UPO. Almost everyone says all of them. Then ask them to show you. It goes quiet.

They're not wrong, as a rule. Usually they're right, or near enough. The trouble is that nobody in the room can prove it within the hour, because the office tracks something else: whether a file was sent. The software shows wysłano, the operator ticks the client off, and the month moves on.

Yesterday's post on Optima's multi-company module went through the five declaration statuses that module keeps per client and month: brak → w buforze → zatwierdzona → wysłano → odebrano UPO. Four of them are the installation noting what it intended to do. Only one is evidence that came back from outside. This post is about the gap between the last two. It's the cheapest control an office can build, and almost nobody has it.

What the UPO Actually Is

Send a JPK_V7 or an e-declaration to the Ministry of Finance gateway and you don't get an answer. You get a reference number. Everything after that is a status attached to that number, and the codes are worth knowing by heart:

• 100 / 120 — the upload session has started, or it's finished and the document is being verified.
• 301, 302, 303 — still processing: formal verification, certificate checks, signature verification.
• 200 — processed correctly, UPO ready to download.
• 4xx — rejected. 401 is the classic: the file doesn't match its XSD schema. The rest of the 400s cover signatures, certificates and malformed packages.

Only 200 means filed. A 4xx file was never filed, whatever your screen says.

The law reads the same way. The Tax Ordinance (art. 12 §6) treats an electronic deadline as met when the sender holds proof of receipt. So without the UPO you don't have a late filing — you have an unproven one. During an inspection, the two feel much the same.

ZUS submissions from Płatnik work on the same pattern, with their own confirmation and their own states. Everything below applies to them unchanged.

Three Ways a File Is Sent and Not Filed

In practice the gap comes from three places, and each needs different handling.

1. A rejection nobody read. The file went. The sending software recorded wysłano. An hour later the gateway came back with a 401, and that answer landed in a status window nobody opens once the client's been ticked off. This is the expensive one. The declaration doesn't exist, the deadline passes, and the office finds out from a letter.

2. A file stuck in processing at the peak. Around the 25th the gateway slows down and statuses sit in 301 or 302 for hours. The operator closes the window, meaning to check later, then works through thirty other clients. Most of these files turn into 200 on their own. Some don't. And until somebody queries the reference number again, the ones that didn't look exactly like the ones that did.

3. A UPO that arrived and was never put away. Downloaded into some folder, or left inside the sending software, not attached to the client and month it belongs to. Legally harmless — the document was received. But in any report it looks identical to cases 1 and 2, so it inflates the gap and teaches people to ignore it.

All three have a nasty variant: the reference number itself goes missing. You can only query the status with that number, so getting it back means digging through the sending software's logs or ringing the helpdesk. Store the reference number as a proper field, next to the client and the month. That one change is what makes everything else in this post possible.

KSeF Is a Different Question

It's tempting to fold KSeF invoices into the same check. Don't — you'd be checking the wrong thing.

Under the VAT Act, a structured invoice is issued on the day it's sent to KSeF and received on the day KSeF assigns it a number. The Ministry has also said there's no obligation to download and archive the KSeF UPO, which only becomes available once the session is closed anyway. So the KSeF UPO isn't the evidence that matters. The KSeF number is.

Which makes the KSeF version of this control: invoices with a session reference and no KSeF number. For the buyer, that invoice doesn't exist. It won't appear in their automated KSeF download, and the first sign of trouble is a phone call about an unpaid document the customer says they never received. Same shape as the JPK gap. Different field.

The Check Itself

One table. One row per submission: client, period, form, reference number, time sent, last known status code, UPO yes or no. For an office with forty clients, that's around a hundred rows a month once you count VAT, ZUS and income tax advances.

Then one number: rows sent without status 200. Three working days after the 25th, it should be zero. If it isn't, every remaining row is a real question for a real person.

There's no noise floor here, and that's what sets it apart from almost every other dashboard an office can build. The readiness board from yesterday's post needs an applicability map before it stops lying. The receivables list in the enova365 receivables post needs a filter for false overdues. This one needs nothing. Every row is either fine or a problem.

In the offices where I've run this count, the first result was rarely zero. Usually a handful of rows — mostly case 3, now and then case 1. Nobody knew. Nobody had counted.

What an Agent Does Here and What It Must Not

As a first job for an agent in an accounting office, this is close to ideal. It's read-only, and it runs on data the office already has.

The agent can:

• re-query every reference number still in 30x after 24 hours;
• attach each UPO to the right client and period as soon as it arrives;
• turn a 4xx code into a sentence someone can act on (schema mismatch in section C, probably an old form version);
• pass anything still unresolved after 48 hours to whoever is responsible for that client.

What it must not do is resend. A corrected file sent to the tax office is a submission on the client's behalf — the step I put on the far side of the line in the post on who signs. The agent prepares the case in a minute: what was sent, what came back, what's probably wrong, how much time is left. A person decides. If the rejected file is a JPK_V7, that decision often involves a correction too, and corrections are rarely a data problem.

Why Start Here

Most offices want to start automating with document posting, because that's where the hours go. I get it. But posting needs mappings, exceptions and a month of tuning before anyone trusts it. The UPO gap needs one table, one week, and no decisions about what's correct. The tax authority has already made them.

It also gives you a metric that actually means something: the share of client-months with a UPO by the 27th. That's the distribution idea from the month-end close post, applied to the thing the office is really paid to deliver. To see where this check sits inside a full agent for an office, read the walkthrough of how such an agent works.

Do you know how many of last month's filings in your office have a UPO? Get in touch. One export from your sending software is usually enough to answer that, and the answer tells us whether there's a project here at all.