my accountant informed me about another problem with recurring invoices. According to german tax law, recurring invoice items are required to report the period of performance - in german Leistungszeitraum - which means the period of time this particular invoice item is referring to.
So, for example, if you’re putting “leased line” on the invoice, and bill this afterwards, the monthly invoice requires to refer the last month’s time period on it.
We thought about using :MONTH-1 for that, but there’s a problem with it: Since it only contains the month, we need to add the year to be consistant with german tax law. But, adding :YEAR doesn’t work because an invoice generated on January 1st would then report the period “December 2021” instead of “December 2020”.
Is there any way to solve this?
I personally would prefer something like {$date:m Y} as invoice description template option instead of :MONTH but I don’t think this will happen with 4.x while 5.x is almost available…
Do you have any details on this?
Because v5 is scheduled “later this year” which effectively means “ready for production environments not before next year” and therefore I have to find a solution with v4 for “now”, depending on how to address this requirement when v5 is ready to be used
You know, german law requires to set the period, and without having a solution to this probem, a tax inspection would be deadly for us.
Follow-Up question:
Would it be possible to add a note in the invoice template like “This invoice is valid for ${last month and year}” for example?
German law allows that I alternatively declare the period in the subject for the whole invoice instead of declaring it for each item. But this would mean that I can use some kind of date variables in the template design. Can I?
I don’t think that it would work this way, since the custom fields contain - AFAIK - only static content. I would have to dynamically set month and year in that field (like :MONTH-1 in the invoice items but with the matching year) to archieve what’s required by the german tax department.
Are there any developers around this forum, who might be able to answer this? Because this would be one more point where the german tax law collides with the capabilities of Invoice Ninja, which makes it more and more complicated to rely on it on a long-term basis…
The problem with the static field remains a problem, because it’s not only the year that needs to be changed, but also the month, and this every month. That’s too much of “manual” work where I try to automate mostly everything here. For example single invoices like traffic accounting or power consumption of the rackspace comes from another SQL database via JSON through the API - there I can set the period as comment in the product description field.
But I don’t have this solution with the recurring invoices, but since they have to charge monthly subscription items like a virtual server, they have to refer to the period of performance (or whatever Leistungszeitraum is properly translated).
The suggestion is to combine the :MONTH-1 field with the $company.customValue1, the month would change on its own and you would change the company value once a year. Just trying to help find a workaround, it’s possible the app simply won’t fit your needs.
Just to be clear: I’m very thankful for your help, and I appreciate your patience with me.
and yes, it’s possible that Invoice Ninja has some caveats not fitting my needs, which I didn’t realise beforehand. But as I wrote earlier, I checked out about a dozen different invoice software products and none of them has been shortlisted by me, because they all lacked too much of my requirements.
but… I came up with a bad ugly hack, but it works:
I set a company custom field to “Leistungszeitraum”, so I have the “custom_value1” from the accounts table for my period of performance.
Then I update this field per cron on the first of each month:
MariaDB [ninja]> update accounts set custom_value1 = DATE_FORMAT( DATE_SUB( NOW(), INTERVAL 1 MONTH ), "%m/%Y" ) where id = 1;
Query OK, 1 row affected (0.004 sec)
Rows matched: 1 Changed: 1 Warnings: 0
MariaDB [ninja]> select custom_value1 from accounts where id = 1;
+---------------+
| custom_value1 |
+---------------+
| 06/2020 |
+---------------+
Looks like this could work for me - well as long as the database structure doesn’t change
Awesome, glad you found a solution. Thanks for sharing it!
No worries, I get that it can be frustrating getting software to bend to your needs. I often write short responses (as I’m busy coding) which isn’t always a good idea.
Hi! I’ve migrated to invoiceninja recently and was just looking for a way to include the exact same information on the invoice (date of performance), since we are obliged by law to add that information on every invoice in Austria as well.
Could not figure this out using custom fields… is there maybe a way to add it as a dropdown option (at least) to the invoice template?
Ideally I could just check a box somewhere like date of performance = date of invoice, for invoices generated on the 1st or 2nd of the month it would be = last month and so on…
Current month would work with a simple footnote like “Time of performance is the month of the issue date of the invoice” or in German “Leistungszeitraum ist das Monat der Rechnungslegung”. But it doesn’t work for the month before, as tax lawyers would not accept it
Hello, any news on this feature? I’m from Austria too and this feature is legally required here.
I’d only need an option to be able to select a date period when creating an invoice.
Hello, I am new as well but I think I know what you mean and I think I know the answer.
Goto SETTINGS (Einstellungen) in the left menu, then click CUSTOM FIELDS (Benutzerdefinierte Felder).Then select INVOICES (Rechnungen) and add a custom field like LEISTUNGSDATUM, select the format DATE for the field and click on SAVE (Speichern).
From that time on, you can edit your designs for a bill and select the date.
Hope it helps
Is there a possibility to add the day in the future? This way, I could use it more flexibly for the client, and theoretically, I wouldn’t always have to start on the first of the month.
