e-Declarations and JPK in enova365: the 'awaiting confirmation' status and the gap nobody counts

Two Buttons, One Assumption

In enova365, filing an e-declaration takes two separate actions. Wyślij sends the signed file to the Ministry of Finance gateway. Potwierdź goes back later and asks what happened to it. The software even offers a combined Wyślij, potwierdź, which tells you something: the vendor knows that people press the first button and forget the second.

Yesterday I wrote about the missing-UPO check an accounting office should run after every deadline: the gap between sent and filed, and why only status 200 plus a UPO counts as evidence. That post was software-neutral. This one looks at where the gap lives in enova365, and enova365 makes it harder to see than most. It splits the gap across two registers. It gives it two different names. And in an office running dozens of client databases, it spreads it across every one of them.

The Statuses, in enova365's Own Words

An e-declaration in enova365 (CIT, PIT and the other forms handled by the e-Deklaracje module) moves through a short, explicit sequence:

• (empty): calculated, approved and saved, but not yet generated as an e-declaration;
• Do podpisania: generated, waiting for a signature (qualified certificate, or the unverified signature with an income amount for the forms that allow it);
• Do wysłania: signed, not sent;
• Do potwierdzenia odbioru: sent, answer not yet collected;
• Potwierdzona: the Ministry's verification came back positive, and the UPO number appears on the declaration printout (field 2, Nr dokumentu).

JPK files are handled elsewhere. They're generated from the Ewidencja dokumentów list, filtered by period and JPK type, and they have their own states: nieokreślona for a fresh file, Przetwarzanie after sending, Pobrano UPO once the confirmation has been collected.

The status that matters in the first list is Do potwierdzenia odbioru. In the second, it's Przetwarzanie. Both mean the same thing: enova365 doesn't know yet. That's not a verdict from the Ministry. It just tells you nobody has asked. A declaration can sit there already accepted, still processing, or rejected with a 401 because the schema didn't match. All three look identical in the list until someone runs Potwierdź.

Why the Gap Is Bigger in enova365 Than It Looks

Three things about how enova365 is set up make this gap easy to miss.

1. Two registers, two vocabularies. VAT goes out as JPK_V7 from Ewidencja dokumentów. Income tax declarations go out through e-Deklaracje. Different lists, different status names, often different people. An office that built a habit around one list (usually JPK, because it's monthly and the deadline is loud) has half a control and full confidence in it.

2. One database per client. Accounting offices on enova365 usually keep each client in a separate database and use the Praca na wielu bazach extension to generate and send e-declarations in bulk. That's a real time saver on the 25th. It also means bulk sending isn't bulk confirming. Checking fifty databases one by one after the deadline is exactly the kind of job people postpone and then skip. The sending scales. The follow-up doesn't, unless you build it.

3. The test gateway. enova365 lets you choose between the testowa and oficjalna gateway. A file sent to the test gateway goes through the whole process, and the data never reaches the Ministry. This is rare. When it does happen, it's usually after a configuration change or with a new client database cloned from a test setup. You don't need to worry about it daily. You need to check it once per database, write the result down, and check again after any migration. It's the one failure the status list can hide completely.

The Count, enova365 Edition

The control is the same as in yesterday's post: one row per submission, one number, zero expected three working days after the 25th. In enova365 the row comes from two places:

Source	"Not done" states	"Done" state
e-Deklaracje	Do podpisania, Do wysłania, Do potwierdzenia odbioru	Potwierdzona
JPK (Ewidencja dokumentów)	nieokreślona, Przetwarzanie	Pobrano UPO

For each client database: every declaration and JPK file for the period, its status, and the gateway setting. The number that matters is everything sent that isn't in a "done" state. Do podpisania and Do wysłania go in a separate column. They aren't a UPO problem. They're a file that never left, which is worse, though much easier to spot if anyone looks.

For an office with forty clients, that's around a hundred rows a month. The row count isn't what makes it tedious. The number of databases you have to open is.

Getting the Data Out Without Opening Fifty Databases

This is where the enova365-specific plumbing matters. There are three realistic routes, the same three I went through in the post on KSeF and JPK data in enova365:

• WebAPI, per database. A read-only service account in each client database and a script that pulls declaration and JPK statuses for the period. Does your version expose each status field cleanly through the API? Check that on your own installation before you promise anyone a dashboard. The WebAPI developer guide covers what to test first. The account should be able to read and nothing else, and the service-account post explains what "read-only" actually means in enova365.
• A scheduled export. If the API route is awkward, a task in Harmonogram zadań can export the lists to a file on a schedule. Less elegant, but it works on any version. The catch is the same as with every scheduled job: one that silently stops producing files looks exactly like a month with no problems. So the export needs its own heartbeat.
• Someone opens every database. The baseline. It's also what falls over around the 25th.

Whichever route you pick, put the reference number and the database name on every row. Without the database name, you can't trace a problem row back to its client.

What an Agent Does Here

The boundary is the same as yesterday, with one enova365 wrinkle: Potwierdź is not a submission. It asks the gateway about something already sent and stores the answer. That makes it safe for an agent to run on a schedule across every database. It's a write to enova365, level 3 in the permission levels from the liability post, but it doesn't put anything new in front of the tax authority.

So the agent can:

• run Potwierdź on everything in Do potwierdzenia odbioru or Przetwarzanie older than 24 hours, across all databases;
• report every rejection in plain language, with the database, the client, the form and the period;
• flag Do wysłania items the day before the deadline, while there's still time to act;
• check the gateway setting in every database once a month, and after every migration;
• produce the single number the partner looks at: client-months without a UPO.

What it doesn't do is re-sign and resend. In enova365, signing is a person's act by definition: the signature is either a qualified certificate or an income-verified signature tied to a specific taxpayer. And resending is a new submission. So the agent hands a person the case instead: what went out, what came back, what's probably wrong, how many days are left.

Where This Fits

If you run an office with clients on several ERPs, the enova365 half of this check is usually the easier one to automate, because the statuses are explicit and the data lives in a proper database rather than a folder of XML files. It's also a good first project on enova365, for the same reason as yesterday: it's read-mostly, the Ministry has already decided what "correct" means, and it produces a number on day one.

How many of last month's filings across your enova365 databases are still waiting for confirmation? Get in touch. One read-only pass is usually enough to find out.