> And, well, there are other kinds of documents that already have to be
> uploaded to said ministry's servers in XML format [1].  In case of
> these, I found the API used by accounting companies not to be available
> to the businessmen themselves.  At least not officially (because
> scraping the government's webapp doesn't seem that hard).

It turns out what I wrote there is not correct.  The "other kinds of
documents" that I referred to is the monthly/quarterly JPK-VAT, among
others.  When I was investigating this 1 and a half years ago, I could
not make much sense of the JPK-VAT interfaces spec.  I somehow got the
impression that the API is not available to businessmen directly.  Now
I see evidence to the contrary, particularly this (nonfree, CC-BY-NC)
program [1].  Sorry for the confusion.

[1] https://github.com/piotrkot/jpk-vdek

> Hello,
> 
> This appears to be the documentation for the Polish e-invoicing system:
> 
> https://ksef.mf.gov.pl/
> 
> Can someone here check if this can be implemented in free software? And 
> if not, what are the problems?

It seems that for both the JPK-VAT [2] and the e-invoices [3] (and
likely other documents), the APIs themselves are not discriminative.
However, authorization is required and free software for this might or
might not be available.

[2] 
https://www.podatki.gov.pl/media/7536/specyfikacja-interfejs%C3%B3w-us%C5%82ug-jpk-wersja-3-5.pdf
[3] https://ksef.mf.gov.pl/document/InterfaceSpecification/1.4/EN

According to [3], the e-invoices interface allows authorization with
either

1. qualified signature
2. qualified seal
3. signature made with Profil Zaufany ("Trusted Profile" — a government
   service that can be accessed through the browser)
4. an authorization token — this one can be generated after already
   being authorized; useful to speed up subsequent authorizations but
   not feasible to use if none of the other vectors is available to us
   in the first place

As to 1. and 2. — I am not sure to what extent qualified
signatures/seals can be made with free software.  In the scheme I've
seen, a hardware device is used to hold the keys and sign documents.
A (possibly nonfree) application running on the computer is used to
communicate with the device.

It seems EU has some list of hardware devices that can be used for this
[4].  I don't know if any of them can be talked to with a free software
application.  And if so — which ones.  What worries me is that even if
we achieve *software* freedom by using one of these security modules,
they are still out of user's control.  What about hardware freedom?
Would it be possible for a business to use a self-manufactured hardware
device here?

[4] https://eidas.ec.europa.eu/efda/api/v2/notification/export/pdf/qscd_sscd

Btw, setting up a qualified signature is also an additional hussle and
expense.  Regardless of freedom issues, someone who is just starting a
business could prefer to use sth else to upload one's first e-invoices.
So, let's move forward.

As to 3., I shall first explain how I've seen Profil Zaufany used in
other scenarios:

1. Mr. Paweł Nowak interacts with the website of some office (it can
   be the tax office but also, e.g., the Social Insurance Institution)
2. Paweł wants to send some document to the office via the website.
   Paweł uploads or fills in the document and chooses to sign it using
   "Profil Zaufany".
3. The office's website redirects Paweł's browser to Profil Zaufany's
   website where Paweł authenticates with, e.g., a password + an SMS
   code.
4. Paweł clicks on the "Sign document" button (possibly after
   previewing the document, but the preview feature of Profil Zaufany
   tends not to work, even in case of frequently uploaded formats).
5. Profil Zaufany redirects Paweł's browser back to the office's
   website, with the latter being sent a signed copy of the document.
6. Paweł clicks a — now ungreyed — "Send Signed Document" button on the
   office's website.

Obviously, this is not the scheme we'd like a non-browser-based, free
software application to use.  In the past I searched for an API of
Profil Zaufany.  I found that an API exists [5], but is only for other
*systems* (e.g., for use by a programmer creating a web app of another
office).  That API is not available to someone willing to sing an
arbitrary file from one's computer, as would be the case here.

[5] https://pz.gov.pl/Instrukcja_Integratora_PZ.pdf

It is [5] that made me believe that Profil Zaufany can only be used to
sign documents when requested by another system.  And because I knew
the JPK-VAT's interface [2] accepts signatures from Profil Zaufany, I
concluded that JPK-VAT's API is only for other systems.  That is the
incorrect information I shared that I apologize for.

It turns out Profil Zaufany *can* actually be used to sign files from
disk, for later manual sending, as documented here [6].  Still, there
seems to be no API for this and the website of Profil Zaufany uses
nonfree JS.  I should be easy to scrape, tho — I've seen no invisible
captcha there (nor any other captcha, actually).  And a free software
client to Profil Zaufany could verify that the signed document (XML
file) really has the original file embedded in it (and not some other
one that hypothetically a compromized server of Profil Zaufany would
like to swap in)!

[6] https://www.biznes.gov.pl/pl/portal/0074#7

Best!

--
W. Kosior

website: https://koszko.org/koszko.html
fediverse: https://friendica.me/profile/koszko/profile
PGP fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A


On Mon, 2 Jun 2025 12:09:00 +0200
Krzysztof Siewicz <[email protected]> wrote:

> Hello,
> 
> This appears to be the documentation for the Polish e-invoicing system:
> 
> https://ksef.mf.gov.pl/
> 
> Can someone here check if this can be implemented in free software? And 
> if not, what are the problems?
> 
> KS
> 
> On 18.03.2025 14:45, W. Kosior via Discussion wrote:
> >> Hello,
> >>
> >> Is it accurate to say that electronic invoicing is mandatory under
> >> certain conditions? If yes, what are those conditions? Which
> >> governing body created such a requirement, and for what purpose?  
> > Here, in Poland, they are "being made" mandatory for polish businesses
> > selling to other polish businesses.  With the goal of eliminating tax
> > fraud, of course.  First, "e-faktury" were supposed to be required by
> > 2023.  Then the requirement was postponed to 2024. And current plans
> > are to require it from 2026.
> >
> > I did not fully believe in this happening the last time and I cannot
> > say I do now…
> >
> > Btw, here, the state needs some kind of permission from the European
> > Commission to implement such a thing.  They have one but I heard it
> > shall expire if they don't complete it before certain deadline.  Also,
> > IIUC, Poland can serve as some kind of sandbox, with other EU countries
> > implementing a similar thing once it works out here.
> >
> > What I find to be the bigger problem is lack of free software for
> > interacting with government's servers.  XML?  I can dump it to my
> > terminal.  Also, writing some code to make a human-readable document
> > from it is trivial.  But for uploading XMLs a businessman has to choose
> > between using a nonfree webapp from the government and having the
> > accounting done by a specialized company.  In the latter case, one uses
> > the accounting company's nonfree software and the company can use some
> > API to send the electronic documents to the Ministry of Finance.
> >
> > And, well, there are other kinds of documents that already have to be
> > uploaded to said ministry's servers in XML format [1].  In case of
> > these, I found the API used by accounting companies not to be available
> > to the businessmen themselves.  At least not officially (because
> > scraping the government's webapp doesn't seem that hard).
> >
> > Also, the XML schemas designed for such things tend to be crap.  Just
> > look at the tag names required here [1].  K_12, K_13, K_14?  The
> > XSDs for validation are fortunately available but unfortunately
> > without a free license attached.  Not sure to what extent one would be
> > allowed to use it in development of a free program (or a nonfree one —
> > doesn't matter).
> >
> > Best!
> > Wojtek
> >
> > [1] https://www.gov.pl/attachment/aa25bab7-1932-49b1-8b49-d84ffc90c665
> >
> > --
> > W. Kosior
> >
> > website: https://koszko.org/koszko.html
> > fediverse: https://friendica.me/profile/koszko/profile
> > PGP fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >
> >
> > On Tue, 18 Mar 2025 08:42:49 -0400 (EDT)
> > Alex via Discussion <[email protected]> wrote:
> >  
> >> Hello,
> >>
> >> Is it accurate to say that electronic invoicing is mandatory under certain 
> >> conditions? If yes, what are those conditions? Which governing body 
> >> created such a requirement, and for what purpose?
> >> _______________________________________________
> >> Discussion mailing list -- [email protected]
> >> To unsubscribe send an email to [email protected]
> >>
> >> This mailing list is covered by the FSFE's Code of Conduct. All
> >> participants are kindly asked to be excellent to each other:
> >> https://fsfe.org/about/codeofconduct  
> >
> >
> > _______________________________________________
> > Discussion mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> >
> > This mailing list is covered by the FSFE's Code of Conduct. All
> > participants are kindly asked to be excellent to each other:
> > https://fsfe.org/about/codeofconduct  
> 


Attachment: pgpwGlPW0DxNI.pgp
Description: OpenPGP digital signature

_______________________________________________
Discussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]

This mailing list is covered by the FSFE's Code of Conduct. All
participants are kindly asked to be excellent to each other:
https://fsfe.org/about/codeofconduct

Reply via email to