As a follow-up to our blog topic on the usage of one-time accounts, we received an email from one of our loyal readers, who reported two scenarios that he has encountered in practice that we felt it was important to share with you. One of them relates to the highly topical subject of electronic invoices (e-invoices) and the second relates to a type of attack that has its origins in the field of IT security: the so-called “Man-in-the-Middle” attack.
In response to the series of one-time accounts
Invoicing in the internet era
At the start of July 2011, Germany implemented the EU Directive 2010/45/EU on e-invoicing and made e-invoices equivalent to traditional paper invoices by changes made to Section 14 of the German Value Added Tax Act. The aim of this directive was to enable business processes to be performed simply and efficiently.
The only requirements are as follows (translated from this German Wikipedia entry):
- Electronic invoicing shall be subject to acceptance by the recipient.
- It must be issued, sent, received and processed in an electronic format (e.g. PDF, JPEG, GIF, etc.)
- It must be readable by humans
- Authenticity of origin must be able to be ensured
- Integrity must be guaranteed
- All other accounting features/requirements for VAT deduction must be present
The first scenario for the use of one-time accounts addresses exactly the first point:
Electronic invoicing shall be subject to acceptance by the recipient.
Acceptance of e-invoices does not have to take any particular form. Thus, “tacit approval by actual practice” or “implied consent” is itself sufficient for the acceptance of e-invoices.
It is exactly this point that can have unfortunate consequences in SAP when it comes to the use of one-time accounts under the following scenario:
A supplier sends an e-invoice by e-mail. The customer account is a one-time account. The invoice recipient receives the e-invoice and pays it. In this case, this constitutes an implicit acceptance of e-invoicing. A payment obligation arises and the supplier assumes that e-invoices are clearly accepted. Unfortunately, this information cannot be stored in SAP, due to a lack of a customer account. The next invoice (this time an invoice for a higher amount) is again posted to a one-time customer account – the customer does not pay for weeks and requires a paper invoice. As a result, he uses up the full payment period. This in turn may result in cash flow problems and, potentially, loss of interest (though not in this case). A brief analysis of acceptance of e-invoicing would have helped at this point, but it was not possible to perform such an analysis due to the use of one-time accounts.
The attack of the double-faced Janus, also known as the Man-in-the-Middle attack
While the risk associated with the first scenario remains limited, a so-called man-in-the-middle attack can lead to considerable damage. More on this once we have explained briefly what the term means.
As we have already mentioned, the term “man-in-the-middle” comes from the field of IT security. An attacker attempts to intercept communication between two parties and act as one of the two parties. If this type of attack is successful, the attacker can, for example, change invoices and send them to the actual recipient. In the worst case scenario, the presence of the attacker remains undetected and the changes thus go unnoticed. This makes the invoice seem to come from the right sender. In theory, that is all there really is to a “man-in-the-middle” attack. In practice though, this type of attack is technically very complex and not as easy to perform as it is to explain. Nevertheless, if such an attack is successful, it can cause considerable damage.
This is also exactly what happens in our second scenario:
A supplier sends an e-invoice to his customer. This is intercepted by an attacker (these days NOT that unusual). The attacker successfully manipulates the e-invoice and changes the bank account details. The attacker then sends the changed e-invoice to the original recipient. Because the customer only uses one-time vendors, the invoice details are not checked against the vendor master data. As a result, the customer does not establish any irregularities concerning the bank account details and settles the invoice using the changed bank details. The payment disappears into the ether, or goes to the devil, we might say! There is virtually no System of Internal Control in the payment system that could have prevented such a process from occurring, so the only way of minimizing the risk is by strictly limiting the use of one-time accounts.
Have you already had any nasty experiences yourself or heard any scare stories from colleagues resulting from the use of one-time accounts? Send us an email and we will publish the best stories –of course in full anonymity and only after consultation with you.
