[corty]

The invoice will be PDF with an embedded XML blob containing the machine-readable data part, signed with a PDF signature: https://www.pdf-tools.com/pdf20/en/zugferd/

pdf.js lacks capabilities to extract the XML or verify signatures, so the usual way will be to use Acrobat Reader or the usual bunch of "industry-standard" invoice-processing crap that now suddenly has to deal with malicious input.

The idea to do it differently might be nice in theory, but is lacking a smooth way to change over from the old paper-invoice ways. PDF will be the thing for some decades and we will have to deal with it.

[vbrandl]

Having implemented rudimentary ZUGFeRD support at $dayjob a few years ago (our main product is sending, receiving and validating invoices for energy companies in Germany), I don't see ZUGFeRD becoming relevant anytime soon. At least for b2b invoices, nothing has changed since the release of ZUGFeRD. They prefer sticking to EDI formats (many with some custom edge cases for their SAP monstrosities, e.g. putting the `-` sign for negative numbers _after_ the number like `10-` for `-10`...)

[corty]

Quite possible, yes. But the alternatives to zugferd look quite similar, due to requirements from the relevant laws: https://de.wikipedia.org/wiki/Elektronische_Rechnung translated excerpt: an electronic invoice must be [...] 3. human readable 4. origin of the invoice must be guaranteed (digital signature or internal controls) 5. integrity of the invoice must be guaranteed [...]

This means that while you might be able to use something other than PDF for the human-readable part, I don't think anything other than PDF will be used. All the other stuff (XML with embedded SVG or PNG, Word, plaintext) will have acceptance problems in one form or the other.

EDI is big business to big business, as evidenced by you mentioning SAP. There, you may be completely right, I don't know.