Question 1

Did the operational system have to go?

Accepted Answer

No. We added an invoicing module next to existing documents. Cases, attachments and statuses stay. What changes is the source of the invoice: from external software to a record in the same system.

Question 2

Why upload a PDF and read amounts from the file?

Accepted Answer

Because the invoice was born outside the system. The upload put the document on the case; reading amounts avoided retyping. With KSeF that bridge is not enough — the invoice must be structured and have ministry status.

Question 3

Could KSeF have been wired to the old invoicing programme?

Accepted Answer

In this case the programme had to change anyway. Instead of a new vendor and another upload, we pulled issuing into the operational system and wired KSeF from there.

Question 4

What do incoming invoices add?

Accepted Answer

The same module receives invoices from KSeF. Operational costs sit on the case in the system — no manual entry and no extra PDF to read. That changed the scope: not only issuing, but a cost picture in operations.

Question 5

How does KSeF handle an advance and a final invoice?

Accepted Answer

In the module you settle advances on the case. The advance invoice and the final invoice go to KSeF as one flow: linked in FA(3), so amounts are not counted twice. Not two separate rituals in the portal.

Question 6

How do status and UPO work?

Accepted Answer

After submit the system polls KSeF and stores status on the invoice. When the ministry acknowledges receipt, the record holds the KSeF number and UPO — not in a separate programme and not in email.

Question 7

Can you test before production?

Accepted Answer

Yes. Test, demo and production are separate. Production submit needs explicit configuration — it does not ride along with a test.

KSeF forced a change of invoicing software — instead of a third tool: one system