I assume your export does have some attributes which are not supported yet by opensteuerauszug.
Can you please post the relevant lines which contain those attributes here in the forum or even better as GitHub issue?
And as a workaround for now, just try to remove those attributes from your XML, and try converting it again. Most probably they are not even needed. Needless to say, but you really need to double check the created PDF in detail before using it for the tax return.
Edit: I couldnt set the custom date range to the whole year since I opened up the account in April
In that case, I would just try the first available date until end of year.
Thanks, that worked. The Output seems okayish, made it still way easier than manually adding every single position.
I had to double check every position, especially some acc ETF that didnt had a “Ertrag” value. Im guessing these are a bit problematic since they were FOP transfers.
Was it only the two XML attributes Trade.initialInvestment and EquitySummaryByReportDateInBase.liteSurchargeAccruals which causes issues?
I had to double check every position, especially some acc ETF that didnt had a “Ertrag” value. Im guessing these are a bit problematic since they were FOP transfers.
Does that mean you had to do manual adjustments? Were things in the generated PDF missing / off? In that case, exact reports would help in order to improve it.
No, I created a slimmed down XML with just the critical fields and options.
This one gave me the ValueError: Failed to parse IBKR Flex XML file /Users/xxx/Downloads/opensteuerauszug2.xml with ibflex: Trade.initialInvestment - Can’t convert ‘Yes’ to <class ‘decimal.Decimal’> error.
Then I simply deleted every initialInvestment value to none or ““, re-run opensteuerauszug agains this xml with these parameters:
python -m opensteuerauszug.steuerauszug --importer ibkr /Users/xxx/Downloads/opensteuerauszug2.xml --period-from 2025-04-10 --period-to 2025-12-31 --tax-year 2025 -o ibkr-2025.pdf
I then successfully imported this pdf in ZHprivateTax.
Does that mean you had to do manual adjustments? Were things in the generated PDF missing / off? In that case, exact reports would help in order to improve it.
The positions that I transferred to IBKR this year did not have any Ertrag values after importing. Since I did not buy or sell anything, the amount stayed the same for the entire year. To double-check, I manually imported this position with the amount at the start of the year and again at the end. privateTax then correctly calculated the Ertrag values. I then simply corrected the empty value in the eSteuerauszug position of the corresponding ETF.
Edit: The one ETF that I started buying this year, was correct
That should work out pretty well I assume. The precject allows hooking in any importers as far as I have seen. Using extensive export sample data (best would be some machine readable format like CSV or XML) which privides all needed data (also PDF could work), optionally an ecport documentation, and the two existing importers (IBKR, Schwab), I would assume an agentic AI can create a very good vasis to build on. That would be an interesting experiment for any bank or broker which does not offer eSteuerauszug or charges for it extra.
I read that the java library is supposed to be open source, but is this documented anywhere? If so, then maybe it makes more sense to focus on the IBKR → XML conversion if we have a verified and usable XML → PDF converter.
Die API wird als Open Source Software unter Apache Lizenz
V 2.0 über die nachfolgende URL zur Verfügung gestellt. Die Quellen, Java Doc und Beispiele
stehen ebenfalls über die nachfolgende URL in der Datei taxstatement-api-2.2.zip zur
Verfügung.
This is pretty clear. I wonder if we can just take the JAR file we have found in official tax software (see posts above), decompile it and make it available on GitHub under the described Apache licence. The decompiled code looks quite readable. I could do this with minimal efforts.
Does anybody see blockers or potential legal issues here?
The main issue is that you don’t really have proof of what the license is (I don’t think the jar carries licensing information). (You’d need access to the zip to confirm what the actual license is)
If you want to have fun, you could have a clean room setup with two Claude Code Setup
One Claude Code writes description/documentation (without copying the code). And the other does not have access to the original and writes the code (potentially in another language).
If you combine that with a harness to test compatibility (have the second cc be able to run tests against the original lib for behavior testing), it would probably work and not have any copyright issue)
I’m also sceptical as to whether the whole thing was released and even if it was, it looks like they tried to walk it back and remove all links to it, so I wouldn’t try to poke the bear. Nonetheless, it could be worthwhile to decompile and analyze to understand how it works and learn from it even if we cannot integrate the jar directly into our own software.
I am getting to the point where I actually should be doing my tax return instead of hacking on this. Did anybody try the behavior on private tax for DA-1. Does it still have an option / warning to add supporting evidence for the withholding if you provide a steuerauszug?
Context: I am wondering how much we need to provide evidence that we actually saw a matching withholding in the broker export [seperate issue if the DA-1 folk will actually accept it]
A generated pdf should not be able to replace the da-1 evidence. (I don’t even know if it might be considered fraud, but it’s definitely playing with fire). Trying to trick the software to avoid filing out the fields manually is one thing, replacing the requested documented proof with ones you created yourself is entirely different.
I don’t even know if it might be considered fraud, but it’s definitely playing with fire
I do not really agree here. We are not trying to provide fake information, trick them or such. The only thing we are doing is improving the data quality of the imported data (automated is less error prone than manually typing), and simplify our and their life.
Did anybody try the behavior on private tax for DA-1. Does it still have an option / warning to add supporting evidence for the withholding if you provide a steuerauszug?
ZH: There is no option to attach an additional document to the e-taxstatement import as the is when you manually enter a position. If you really want to attach a “official” document, you can attach an activity report at the end before handing in the tax return (there is a dedicated section for attachments to the securities declaration).
But I will not attach it. As always, tax authorities can ask for an additional proof (they also did that in the past in my case for other deductions). Since all things we are handing in here are legit, it is not an issue for us to send the the officially expected activity report on request.
If this approach of non-officially generated e-taxstatement would not be accepted, it would basically void datalevel’ IBKR e-taxstatement, which the sell, as well. I would assume that they did some validation of their business model before building it.
By reading and partipating to this forum, you confirm you have read and agree with the disclaimer presented on http://www.mustachianpost.com/
En lisant et participant à ce forum, tu confirmes avoir lu et être d'accord avec l'avis de dégagement de responsabilité présenté sur http://www.mustachianpost.com/fr/
Durch das Lesen und die Teilnahme an diesem Forum bestätigst du, dass du den auf http://www.mustachianpost.com/de/ dargestellten Haftungsausschluss gelesen hast und damit einverstanden bist.
