Tax filings for 2019 / The German IRS and Elster (again)
Earlier today, I filed my (German) taxes for 2019—and, for once, with a few days to spare. This through a combination of a general increase in the last date for filing (July 31st; previously, Mai 31st), my less stressful workload, and the fact that I had less positions to file.* It still cost me several hours distributed over two days, to get everything in order and to use ElsterOnline, that utter bullshit tool that the German “IRS” has forced down the throat of the users.
*I spent half of 2019 on a sabbatical and then switched from IT consulting to writing novels, with no bills issued, no income, and much less costs for e.g. hotels and travel than in previous years.
I am not going to give a complete overview of Elster, as I have discussed it repeatedly in the past.* However, a few new (?) observations:
*Search for “Elster”, “IRS”, and/or “Finanzamt”.
- There is a new free-text field where the user can add a message to the IRS within the filing—finally: this has been years overdue.
But: It is not possible to add line-breaks in this message. This repeats an inexcusable error, hostile to both the user and the IRS staff that later works with the filings, which was previously present in the specialized form for sending (external) messages. In that separate form, this error has been fixed—but it is still repeated here. Absolutely incredible!
- On several occasions, I tried to run my mouse over a field with outdated values to mark the contents, hit backspace, and then enter the new data. This was simply not possible, which is absurd for a functionality that works out of the box with a regular HTML form—unless somehow sabotaged, be it out of incompetence or malice. Instead, I had to click into the field, right-arrow until I was at the end, and then hit backspace until the field was empty.* This is the more annoying as the form based input and the structure of the forms more-or-less forced use of a mouse for tasks like navigating. This way, the user is forced to constantly switch between keyboard and mouse in a manner that goes too far. (And does it for no legitimate reason.)
*In my impression, I was always, by force, put at the beginning of the field, with no ability to “click” to another position; however, I did not verify whether this was true. It is also conceivable that I could have “deleted” my way backwards with the “delete key”, but it is awkwardly placed and requires a simultaneous “shift” on my notebook, so that would have been more work—if it actually did work at all …
- One of the forms had two (times three; cf. below) fields for the Steuernummer*, one in a “cover” part, one in a content part. The latter was correctly imported from last years forms; the former had to be entered manually. WTF!
*An identification number used by the IRS.
To make matters worse, the forms insist on dividing the Steuernummer into three parts, each with a field of its own, which implies that a simple one-step copy-and-paste is not possible. To copy it within a form, with no additional sources, the tax payer then has to go forward one (or more?) page(s?), copy part one, go back to the original page, paste, go forward again, copy part two, etc., until all three parts are filled. (Personally, I committed parts one and two to memory and copied just the third part, trading a slight risk of errors for a reduced work load.)
- The data import from my previous filing was not complete. At least the VAT portion likely had not one single data field filled, which makes the new filing harder: there are a great number of obscure, poorly named, and poorly explained fields, and having the ability to just look at the old fields makes it much easier to identify which to use this year. Moreover, when I cannot rely on the old fields being pre-filled (if with outdated values), I do not just have to identify the correct fields, I also have to go through the sum of all fields on a just-in-case basis.
- While data import from the old filing was possible, I had no way of actually looking at the old filing, e.g. for comparisons per the previous item. For some reason, likely an arbitrary, unnecessary, and destructive time limit, they cannot be opened.
And, no, there appears to be no way to save them locally in a reasonable format. (Something that I tried with my new filings, and likely last year too.) The only possibility to download the data, short of taking screenshots or saving countless individual HTML files, is a “save as PDF” functionality. This is sub-optimal and limiting to begin with, but, worse, this does not work at all on my computer (for reasons unknown). Odd: This should be a trivial task if implemented correctly: generate the PDF file server-side and then just let the browser download it. Possibly, the idiots are actually stupid enough to try generation client side, which is a recipe for unknown errors.* If it is server side and they still have bungled it, well, that is even worse.**
*No, it cannot be justified by data protection. Such concerns are often legitimate, but here we had no data that was not already present and (at least somewhat) permanently stored server-side.
**Software errors happen even to competent developers, but here we have a system that has been handling the 2019 taxes for almost seven months and is now in a high intensity phase. Not having fixed the problem by now, or having introduced it in the last few days, would be horrifyingly negligent. I also note that there was no error message of any kind, which would have been a must, had there been e.g. a temporary back-end problem, say, due to a temporary overload or system failure.
- Two fields were mandatory despite my having no value to provide (regarding transfer of assets from the private to the business sphere and vice versa). Here I had to add two entries of “0’, for no good reason. And, no, I could not just pick an existing field and enter the value “0”: these fields (in a wide sense) contained lists of fields, where each entry had to be manually added. Presumably, the IRS expects a detailed and enumerated list of each individual asset transferred, and it would then make sense to allow an empty list when no transfer has taken place. (This is indeed the case with other “list fields”.) But, no, an empty list was not allowed, and to signify that I had transferred no assets, I had to create two single list entries with the value “0” and an additional dummy “reason” (“name”, “details”, or whatnot).
This is a “Software Development 101” mistake.
(I have no recollection of this problem from prior years.)
I can only reiterate my yearly observation that this tool moves on a level of incompetence that is mind-numbing, including obviously faulty behavior, a complete disregard for established conventions, an extremely confused (and confusing) user interface, etc. As a former software developer, it boggles my mind that this type of shit can be made by (alleged) professionals—and while wasting tax payers money. Yes, I know, the government and incompetence, but still …
[…] chunks of time have disappeared on various necessary correspondence and other tasks (e.g. taxes), and the reduced time spent on my books have made it harder to get back to them. Conversely, some […]
Blogging, records, and new-beats-good | Michael Eriksson's Blog
July 31, 2020 at 7:45 am