HN Reader

What was unclear in that article is that the XML is usually embedded in the invoice. For instance, Factur-X is the mandatory format in Germany, and it's a PDF which contains a metadata block with a XML EN16931 content.

This XML will usually not be read by the companies that pay the invoice. For instance, in France by the end of 2027, every business will have to send e-invoices, but never directly to the real recipient. The business sends the invoice to a registered go-between, which will ask a national platform for the address of the recipient's go-between, etc. So, only those official go-between companies will have to securely parse the XML.

BTW, in 2022 when the French government decided to make e-invoicing mandatory, it announced that it would develop a national unique go-between platform. Two years later, it dropped that part of the project and announced that there would be an official list of private platforms. So, by the end of 2026 or 2027, every French business will have to select one of the 112 platforms and buy a subscription. It give the State more control, but for small businesses it means higher costs and complexity.

This talk seems set out to prove that "XML is Bad". Yes XML-DSig isn't great with XPaths, but most of these attack vectors has been known for 10 years. There is probably a reason why the vulnerabilities found where in software not commonly used, e.g. SAP. Many of the things possible with XML and UBL simply isn't available in protobuf, json. How would you digitally sign a Json document and embed the signature in the document?

The article nor the talk appear to reference the XML standard that EN 16931 is built upon: Universal Business Language, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=... - which is freely available. Examples can be found here: https://github.com/Tradeshift/tradeshift-ubl-examples/tree/m... . It is a good standard and yes it's complex, but it is not complicated by accident. I would any day recommend UBL over IDOC, Tradacom, EDIFACT and the likes.

Funny enough, I’m currently adding e-invoice support to my open-source invoice generator.

Github: https://github.com/VladSez/easy-invoice-pdf

App: https://easyinvoicepdf.com/?template=stripe

I’m planning to use this package to generate e-invoice: https://github.com/gflohr/e-invoice-eu

UPD: issue to follow the progress https://github.com/VladSez/easy-invoice-pdf/issues/121

If you have any feedback or suggestions please feel free to reach out to me :)

Aside from the security issue, it seems like an awful idea for a government (or governments, in this case) to say 'hey, you need to follow this standard for invoicing. But also, you have to pay to see the entire standard'.. almost feels like extortion a bit

A standard for invoices seems like something that an accounting body should create that is optional for businesses, not something mandatory created by the government. People will generally follow an optional standard to make their own lives easier, but a mandatory one introduces a compliance middleman into the invoicing process.

Any reason why they wouldn’t use EDIFACT instead?

Nice that they do this since europeans are obsessed with their invoices.

How can there be security issues with a public document? Can't you just sign it with a cert like any other piece of data that needs a proven source?

But also let me get this straight, there is an actual EU standard for invoices? Why the does nobody follow this and I have to keep asking people to put the fucking VAT ID onto it like I'm a broken record?

Another project by Hanno Böck: https://youtube.com/@decarbonizeeverything?si=q6yczy30SZx_sA...