u63725
March 25, 2021, 8:21am
1
Hi everyone, is Invoice Ninja comform with the German GOBD certification? And is there an integration to move over from Datev?
hillel
March 25, 2021, 8:26am
2
Hi,
Sorry I don’t think so, it’s the first I’ve heard of it.
Hi,
It is possible to export invoices etc. as a CSV (Text, ASCII file) and import this file into Datev. It might not be the standard Datev Format but you can set up an import profile in Datev to import any CSV file.
GODB should be possible if you lock invoice as soon as they are sent to the customer.
Cheers,
1 Like
Regarding GoDB there was a github issue 4 years ago where this thopic was addressed.
opened 05:31PM - 11 May 17 UTC
feature request
question
Hi everyone. Just to make sure: **What follows is no legal advice, but my person… al 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
1. Electronical Storage
Electronic invoices have to be saved and be kept in their original format for at least 10 years.
2. **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).
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.)
10. 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.
11. 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.
12. 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:
1. 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.
2. 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.
3. 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.)
4. 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.
5. 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.
6. This is given.
7. / 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.
9. 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).
10. 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.
11. Well, we don't have full-text search, I'm afraid. This has to be provided, though.
12. 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!**
Is there a timestamp available when the invoice was locked?
david
September 22, 2021, 10:40am
5
@Daimonion
One interesting feature in v5 is that we take a snapshot of the invoice each time it is modified and we store this in the backups table of the database.
Inside this table, we store the HTML and created and updated timestamps of each update so this provides an audit trail of any and every change ever made to the invoice.
This may be sufficient for your needs of proving immutability.
We also provide a locking feature where the user can set invoices lockable when they are sent or when they are paid.
3 Likes
Can we lock invoices?
Currently the credit note system is not usable in Europe because it requires you to alter an existing invoice if you only have one (which is not allowed). If your customer get’s multiple invoices you can use the negative balance on the next invoice. So I would say that that part is also not conform with the German GOBD.
https://forum2.invoiceninja.com/t/payment-cant-be-applied-to-a-credit-note/5963
2 Likes
In my opinion (but I am far away from knowing details about the GoBD) altering an invoice would be okay in v5 because the system takes a snapshot from the original invoice as @david says in it’s post…
1 Like
(Edit: Figured it out, it’s an option under workflow)