Reality check: e-invoices CAN spread a virus, malware and scareware

October 13, 2011  |  Electronic Invoicing, Featured Articles

SPAM 230x200 Reality check: e invoices CAN spread a virus, malware and scarewareYesterday, we posted ‘New US Postal Service campaign promotes paper invoices’ . In it we mentioned the phrase ‘A refridgerator has never been hacked’ that USPS used in one of its adds.

Ridiculous! An outrage! As if an e-invoice could be a carrier for spam, scam, virusses, malware or scareware. Of course it can’t. USPS get real!

The next day..

This morning we – that is our Dutch sister platform- received an e-mail from Italy that said: “Su richiesta inviamo una fattura, deve essere pagato prima del 15.1.2011.” Or in plain English: “On your request, we send an invoice that must be paid prior to 15.1.2011.” It also contained a link to the e-invoice.

spam invoice 1 Reality check: e invoices CAN spread a virus, malware and scareware

Even though we have clients in Italy, these clients are not a member of our Dutch platform. Also an invoice that has to be paid before a date in the past is a bit weird, So, our suspicion was raised. And what does everyone do (I hope), when you are suspicious about a link in an e-mail? Exactly, you hover over it to discover what the actual destination will be:

spam invoice 2 Reality check: e invoices CAN spread a virus, malware and scareware

A closer look at the hyperlink revealed that the destination link:
- was different from the sender’s address in the header
- didn’t sound familiar to us.
- referred to a ZIP file

Conclusion: this an attempt to spread a virus, malware or even scareware. Or maybe it is an scam- or skimming attempts. Or maybe a sick joke. In fact we don’t really know, as we don’t have the ambition to try it out. If anyone of you has, let us know. We’ll forward the mail.

What’s the fuzz about?

So, nothing went wrong. What is all the fuzz about? Well, it is a reality check. The reality is that with the advent of e-invoicing well see a –massive- uptake of these kinds of e-invoices.

From that perspective one might ask what measures need to be taken with liberalised e-invoicing: exchanging e-invoices without any technical guarantees. First question: how do we prevent these kinds of e-invoices to become a pain in the bottom. Second question: could wide scale straight through processing of e-invoicing perhaps be too vulnerable? Anyone?


Leave a Reply