KSeF and JPK data in enova365: what the WebAPI actually gives you

Most accounting automation projects on enova365 do not fail at the interesting part. They fail two weeks earlier, on a question nobody put in the proposal: can this data leave the system, on a schedule, in a form that still means something once it is outside?

Let me be blunt about why this post exists. Of everything published here, the pages people actually find are the enova365 technical ones — the developer's guide to the WebAPI earns more search traffic than the entire accounting cluster put together. So here is the accounting question, asked from the side people actually arrive from: you have enova365, the KSeF mandate has already changed what sits in your invoice records, and you want to know what an automated process can see.

Three ways data leaves enova365, and the one you will regret

Three routes. The choice usually gets made badly — whichever one is available first wins, rather than whichever one survives the next version upgrade.

The WebAPI, pulling. A REST surface, JWT-authenticated, with dynamic controllers that expose document and record data, and static controllers for the things Soneta modelled explicitly. This is the supported route. It is also a paid module — the sentence that stalls more projects than every technical problem in this article combined. Check that first, before anything else.

Harmonogram Zadań, pushing. enova365's own scheduler can be made to call out rather than sit there waiting to be asked. For a nightly reconciliation that matters less than people think. But for anything that has to react the same day — a rejected KSeF submission, a document that changed after a summary was generated — a push is the difference between a check and an alert.

A read-only SQL replica. Fastest to stand up, and I have shipped it more than once when the WebAPI licence was clearly not going to arrive inside the project window. Just understand what you are buying: a database schema is not a contract. Nothing obliges Soneta to keep a column where your query expects it, and the day it moves, your integration is not degraded — it is silently wrong. Use it as a bridge with an end date, keep every query in one file, and say out loud that this is what you are doing.

What KSeF actually changed, at the field level

The mandate gets discussed as a compliance event. For anyone building on this data it was something narrower and far more useful: it added a reliable key.

Every structured invoice that goes through the national system comes back with a KSeF number, and that number is unique. Before this, deduplicating a document set meant matching contractor plus amount plus date and then living with the false positives — two identical monthly service invoices to the same client are not an error, and no heuristic ever told them apart cleanly. A repeated KSeF number is a fact. That is a genuinely different class of check.

It added a second thing too, and it is the one worth watching: whether a document your books treat as real was actually accepted. The failure I keep meeting in practice is not a rejected invoice. A rejection is loud, and someone deals with it. The dangerous one is the invoice that never got as far as a send attempt — a session that dropped, a token that expired over a weekend, a document created in a way that quietly bypassed the send path. Your books say the invoice exists. The state's register says nothing. And nobody discovers it on the day, because nothing broke; something merely failed to occur.

Reconciling those two lists is a query, not an AI problem. On a portfolio of forty clients and roughly 2 400 documents a month it runs in seconds. I have never once seen it come back empty in the first month.

The JPK_V7 fields are already there

This is the part that surprises people who assume a pre-submission check means rebuilding the file. It does not. Almost everything a mechanical check needs is already a field on a document enova365 holds: the GTU markers, the procedure and document markers, the classification that decides whether a line lands in one bucket or another, and the amounts that make the record part and the declaration part agree — or not.

So a pre-flight check is a read. Pull the month's documents, apply the rules, produce a list. Run it on the third, when a fix costs a phone call, rather than on the 24th when it costs the only week you do not have. The distinction that makes this worth doing — and the reason the list of checks is short rather than infinite — is the one I wrote about in what an agent fixes in a JPK_V7 file and what it must never touch: a file that disagrees with itself is a data problem with a correct answer. A file that faithfully records a wrong understanding is not.

The API only ever helps with the first kind. That is still most of the volume.

What the WebAPI will not give you

An honest integration plan needs this list more than it needs the previous one.

Anything interpretive. Which period a correcting invoice belongs to depends on when both sides agreed the new terms — and that agreement was often a phone call, written down later if at all. No field holds it. An agent can flag every correction where it found no supporting document, which is useful, and which is a completely different thing from deciding.

Custom fields you did not ask about. enova365 installations accumulate add-ons, and the fields those add-ons introduce are frequently the ones the business actually runs on. Dynamic controllers will not volunteer them. Ask early for the list of custom fields in use at each client — before you scope, not halfway through testing.

The reason behind a value. A missing GTU code and a correctly absent GTU code look identical in the data. The best your check can ever say is "this looks like it should have had one." Then a human reads the list.

Anything about documents that never arrived. The most expensive gaps in an accounting month are absences: the invoice a client has not sent, the statement nobody imported. No API will tell you about a record that does not exist. That check has to be built against an expectation — what should be here by now — which is a different design, and usually a later phase.

What I would build first

If you have enova365 and you want one thing running inside a fortnight rather than a roadmap, build a nightly job with three checks and no write access at all:

1. KSeF status reconciliation — documents in the books whose submission never completed, listed with age in days.
2. Duplicates by KSeF number — cheap now, impossible before.
3. Marker coverage — lines whose classification implies a GTU or document marker that is absent. And the reverse, which nobody ever goes looking for.

The output is an email. Nothing is written back, nothing is approved, no document changes state. That keeps the whole thing on the safe side of the boundary I described in the piece on who signs when an agent gets it wrong — reading and proposing, never sending — and it means the first version needs no policy decisions from anyone.

What decides your timeline is not the build. It is how long it takes for a connector to hold working read-only credentials against production, and I have watched that take one day on one project and five weeks on a comparable one. The honest version of that arithmetic is here.

So ask one question this week: is the WebAPI module active on your licence, and on which build? Everything above is downstream of the answer.

Want a straight read on which of these checks is worth building against your enova365 setup, and which would only produce noise? Write to me — scoping it is free and takes half an hour.