[Feature-Request] Compliance with German law for invoicing systems
Hi everyone. Just to make sure: What follows is no legal advice, but my personal opinion based on legal advice I have received myself.
I talked to my IT lawyer and we both agree that invoiceninja can't be legally used for invoicing in Germany as it is right now.
There's a German law named "Grundsätze zur ordnungsgemäßen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff" abbreviated as "GoBD". Electronic invoicing systems have to comply to this law. For an invoicing system this means it has to at least fulfill these 12 requirements:
Requirements
Electronical Storage Electronic invoices have to be saved and be kept in their original format for at least 10 years.
Immutability Electronic invoices have to be immutable. Especially changes after an invoice has already been billed (or sent, in our context) have to be either completely excluded or EVERY change has to be fully documented. This immutability has to be independent of any influence by hard- and software (for example the immutability may not be broken by change of one of the external software packages you use).
Readability Especially for cases of a business audit, electronic invoices have to be well-readable. In this context it is advised to be able to export them as XML or something alike.
Prompt entry of invoices/receipts Electronic invoices/receipts have to be entered promptly into the invoice system. If possible even at the moment of their receival or creation.
Special case: E-Mail Mails with a business intent or with receipts have to be kept in electronical form. If a mail is only meant as means of transporting an invoice (so it is nothing more than an envelope with an attachment), it doesn't need to be kept. In that case only what has been transported has to be kept (in our case: the invoice). Other than that any business may voluntarily keep all mail communication, so it can tell in the future which mail was sent to whom and when.
Traceability Electronic invoices have to provide a unique ID/index. It has to be made sure that an invoice may be found easily with its ID.
Digitalized paper invoices If invoices are received in paper format and scanned to a digital format, the so created digital invoice has to contain all data of the original paper invoice in a readable way. Only then you can discard the storage of the paper format invoice. Again, these documents have to be kept for at least 10 years.
Destruction of original invoices After scanning you are allowed (if not disallowed because of any special rules/law) under specific restrictions to destroy original paper invoices. The way of archiving has to especially comply with GoBD, which you can prove by providing a documentation of the archiving-workflow.
Deterministic Reproducibility For outgoing invoices you have to make sure that invoices contain always the same processed data if you enter the same input data over and over. This can be otherwise provided by creation of a "snapshot" image-format file (though PDFs seem to be allowed) on the moment of creation of an invoice. This would also let your invoices comply with GoBD if you'd need to migrate your data away from InvoiceNinja. (CSV or other exports can be easily manipulated on migration to another system.)
Conversion to intermediary formats On conversion of electronic invoices to a format used in your office, both versions have to be archived and to be administrated under the same ID and the converted version has to be marked as such. An exception to this are temporary cached results of data processions whose contents are fully transported into the finished electronical bookkeeping data. A conversion of formats may not lead to a constriction of machine-readability or make a machinable invoice not machinable anymore and also no changes to the content may be allowed.
Access to data In case of an audit by fiscal authorities you have to be able to provide an insight to the invoicing system and its invoices. The functionaries must be provided with a full-text search-function for the electronical invoices for research and machining.
Workflow-documentation For exchange of electronical invoices or digitalizing of paper invoices it is mandatory to provide a workflow-documentation. This is especially true because of the mandatory invoice receptance control workflow required by the VAT law in Germany that has to be in place. The workflow-documentation has to explain how the mentioned requirements are being provided. It has to be comprehensible for third parties and to be reviewable in a short timeframe, as well as be kept for at least 10 years for each of its versions (if it has been changed).
Problems/Solutions:
A corrupted database or problems after an update of the app leading to a corrupted database may hurt this point. It would be a lot safer if there was an option to download invoices of a specific timeframe as PDF, so you could save them to another storage.
This is by far the most controlled aspect of every invoicing system in Germany. Most invoicing systems provide this requirement by doing the following:
- When entering data for a new invoice, the rendered PDF creates a prominent watermark all over the document saying "DRAFT".
- As soon as the invoice is billed / being sent, the watermark is removed and the whole invoice data becomes completely immutable. You can't change anything about the invoice anymore.
- What you can do though, is click on a button which automatically creates a credit note for the created invoice
- Cancelling invoices and thus creation of credit notes should be its own ACL-category, because not every user should be able to do this.
- This credit note has to contain either Rechnungskorrektur, Stornorechnung or Korrekturrechnung as document description (perhaps as title).
- It also must contain the invoice ID of the invoice that is being canceled and it has to have its own credit note ID.
- This credit note has to be immutable and only cancel out the linked invoice. So it basically is identical to the invoice that has to be canceled, but instead of invoice it says credit note in German (one of the three labels above) and instead of "price" or "cost" it has to say recompense or payment, to imply that the money is not being owed by the customer but the other way round.
The other problem, though is, that you can manipulate this data all you want in the database. You have to find a way to make the data unusable as soon as someone touches any invoice-sensitive data in the database. A digital signature could be placed on mysql-data, so manipulation would be obvious. If such a manipulation is detected by the system it would not allow the creation or download of any more invoices. You could create a random immutable digital signature on the first startup of the database and afterwards sign all invoice-sensitive (even better, ALL of the) data with it. For this you could use Datomic (http://www.datomic.com/) or BigchainDB (https://www.bigchaindb.com/) I guess.
Another strategy would be to create a checksum of the whole database everytime the software changes the contents and save it signed/encrypted in the immutable database. Next time anything with the data happens in the invoice system it checks if the checksum is correct. If not, the data has been manipulated.
In any case: If invoiceninja keeps allowing manipulation of already billed invoices, it absolutely can't be legally used by any business in Germany for invoicing, sadly.
We do have an export but it doesn't list every detail of the invoice. It should especially list all articles and their individual cost, as well as all data surrounding the steps that led to the whole sum. (Tax, discount, etc.)
An invoicing system could cater towards this point IMO by not allowing the creation of invoices with any other date than the current one. (In any case you are not allowed to pick any date you want for the invoice in Germany. It HAS to be the date it is billed/sent on.) Also any upload of documents should contain a viewable timestamp, so you can for example prove the receptance and checking of an incoming invoice.
The mail about having received the payment of a customer contains the message in itself, without any attachment. This mail has to be stored. The easiest way to do this is by only allowing this function if the BCC mapping is activated. Actually, to be on the safe side, for German users it would be best to require the BCC mapping for any mail function to work.
This is given.
/ 8. The only thing to make sure here is that uploaded invoices are kept for 10 years. I've encountered only one problem with this by now: If you upload a PDF that is bigger than the webserver allows (max filesize limit), then you don't get an error at all. You save the expense and go to another page and when you go back to the expense it misses the document. An error message absolutely has to appear here, so you don't shredder your receipts too soon.
Since you are constantly changing the behaviour of the app, you can't provide deterministic creation of invoices. The only way out is to save each invoice as PDF on the system when the invoice is billed (marked as sent).
This should be given because the original invoice exists in the database and the converted invoice is a PDF. But I'm not too sure here. Especially the option to play around with invoice designs may be potentially dangerous here.
Well, we don't have full-text search, I'm afraid. This has to be provided, though.
InvoiceNinja has no German workflow-documentation. You need a documentation which shows every step of invoice-creation and how it complies with GoBD, as well as the invoice-uploading for expenses. Uploads of documents (to expenses for example) should also contain a timestamp of the upload (see point 4).
Conclusion
InvoiceNinja, as it is now, is IMO not legally usable in Germany. If an audit by fiscal authorities happens and they see that you use InvoiceNinja you will get in trouble and pay fines and/or extra-tax. The GoBD-law is full-on active since 2015 (except for some specific kinds for cash registers, but even those are included since January 2017).
I described what I think has to happen before you can use InvoiceNinja legally in Germany. There are some huges changes to consider. Especially the fact that data has to be immutable or that any change has to be documented or not possible at all after billing. This immutability can be provided by software-write-protection but this is hard to implement with one mutable database only, especially if it is a self-hosting application. I tried to provide a solution to this, though, and hope it will be incorporated.
Until above requirements are fulfilled I can not recommend InvoiceNinja to any German client, since they will be potentially risking to lose a lot of money just by using it.
I hope my writeup has been helpful for your further consideration.
EDIT: I just realized: The best thing would be to completely use Datomic or BigchainDB (or anything else immutable) for the billed invoices and receipts! This would be perfect because the data would be immutable!
Source: invoiceninja/invoiceninja