Skip to content(if available)orjump to list(if available)

Security issues with electronic invoices

Security issues with electronic invoices

21 comments

·December 12, 2025

VoidWhisperer

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

a3w

DIN is not a government; CEN is an NGO, too.

But yes, for commercial offers, presumption of conformity mean you have to pay for norms to adhere to law. Big fail.

Especially since non-commercial but persistent and public, not "for profit", is still surmised in e.g. warranty laws. (E.g. geschäftsmäßige Nutzung / usage with said two terms, even for F/LOSS)

tnorgaard

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.

clickety_clack

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.

autoexec

> People will generally follow an optional standard to make their own lives easier

People invent their own standard to make their own lives easier at the cost of making everyone else's lives miserable.

Fraaaank

Electronic invoicing makes the live of the receiver easier. The sender has to adapt the standard.

Besides, many standards have been created over the past 20 years, yet most invoices are still only sent as PDF.

victorbjorklund

The accountancy bodies are national so it would end up with one standard per country. But yea should probably not be mandatory.

plantain

That's just not how the EU functions.

croes

If you want something to work in multiple countries, you have little choice. Otherwise you x standards

blipvert

Any reason why they wouldn’t use EDIFACT instead?

tnorgaard

As having implemented EDIFACT parsers and translation layers, Universal Business Language (Oasis UBL) is a bliss to work with. Yes, it's a big standard and looks scary when starting out with it, but it is very well designed for a complicated world.

blipvert

OK, it’s been a long time since I worked in this space. Seems like it’s an XML version of the INVOIC message, but is it required to support the XML syntax, or does the plain old EDI format suffice?

encom

>European Union

>needless complexity

First time?

moffkalast

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?

rullera

States have not starting to enforce them until recently. As I understand it the goal is to have all members using them in a couple of years time

IncreasePosts

Because when some things parse the document they do things like read files from the OS as specified in the document

Analemma_

The concern is that a malicious vendor could send you an evil invoice where the XML either references external entities that get downloaded and allow potential RCE, or where the document contains references to the local execution environment which allow data exfiltration (or both). In theory a properly-secured XML parser shouldn't allow this, but history has shown that's harder than you might think.