Topic: CoinTracking - Gewinn/Verlust Portfolio und Steuer Reporting für digitale Coins - page 40. (Read 211510 times)

Updates und Verbesserungen
- Neuer Blockchain Import: Stellar (XLM)
- Neuer Blockchain Import: Binance Chain (BNB)
- Neuer CSV Import: Relai
- Neuer CSV Import: Binance Komplett-Import (Beta)
- Neuer API Import: Binance v2 (Beta)

- HitBTC CSV Import unterstützt jetzt das neue Dateiformat
- ByBit CSV Import unterstützt jetzt das neue Dateiformat
- Bitpanda CSV Import unterstützt jetzt das neue Dateiformat
- AscendEX CSV Import Update (Fix für Gebühren)
- Kraken CSV Import Update (Fix für Transaktionen)
- Cake Defi CSV Import Update (Fix für Liquiditäts-Trades, Bonus Trade-Typen)
- Iconomi CSV Import Update unterstützt jetzt das neue Dateiformat

- Binance API Import Update (Fix für Transaktionen und Duplikate)
- Binance Pro API Import Update (Fix von Rate Limits Fehler, Einzahlungen, Gebühren)
- Bitfinex API Import Update (Fix für Margin Trades, Bilanzen, API Fehler, Reward Trades)
- Bitstamp API Import Update (Fix für Gebühren)
- Luno API Import Update (Fix für Standard Import)
- Bitstamp API Import Update (Fix für undefined Fehlermeldung)
- Gemini API Import Update (neuer Tradetyp "admincredit" hinzugefügt, Fix für Earn Trades)
- Liquid API Import Update (Fix für Ein-/Auzahlungen)
- Kucoin API Import Update (Fix für Rate Limits)
- Poloniex API Import Update (Fix für fehlerhafte Zeichen in Kommentaren)

- Ethereum Blockchain Import Update (Fix für Liquiditätsprozess und weitere DeFi Prozesse)
- Binance Smart Chain Blockchain Import Update (Fix für DeFi Prozesse)

- Steuerbericht Update für die Umrechnungseinstellung "Bester Preis" (Stable Coins werden bei der "Bester Preis" Berechnung nun höher gerankt als andere Coins)
- Affiliate Programm wurde mit weiteren Auszahlungsmethoden erweitert
- Mehrere Anpassungen zu Ticker Zuweisungen und Preis Historien
- TurboTax Dateiexport Anpassungen

Ich habe mal eine Frage zu Tixl und Cointracking.
Ich habe mal ein paar MTXLT gekauft. Die habe ich über 365 Tage gehalten und dann in BNB getauscht.
Angenommen es waren 2 MTXLT und dafür gab es dann 13 BNB.

Danach allerdings wurde MTXLT zu TXL. Es gab für einen MTXLT = 1000 TXL. Jetzt habe ich in Cointracking MTXLT und Txl drinne. Weil ich nicht alle MTXLT getauscht habe und der Rest ja in TXL
umgewandelt worden ist. Wie muss ich das jetzt ändern in Cointracking ? So kann es ja nicht stehen bleiben weil es das Steuerjahr 2020 betrifft und mein SB dann bestimmt nachfragt.
Das ist alles recht nervlich wenn es immer wieder neue Token oder wie bei SONM dann statt 100 nur noch einen gibt usw. Das bringt echt alles durcheinander

Mich würde interessieren ob der Bitpanda Crypto Index von Cointracking richtig erkannt wird in der monatlichen neukalkulation des Index ?

Andreas von CoinTracking: Könntest Du nochmal schauen, ob Du zu meinem Post vom Sonntag Auskunft geben kannst? Damit wäre mir sehr geholfen, danke!

Eigentlich würde ich Cointracking gerne nutzen, aber wenn es keine Möglichkeit eines automatischen Imports aus Polgyon/Matic gibt, wird's schwierig...

Was ich bisher gesehen habe sind diese 2 Optionen.
1) Liste von Steuerberatungen mit CT Erfahrung... die wissen also Bescheid und sollten daher gut helfen können: https://cointracking.info/law/
2) FullService: https://cointracking.info/full_service.php (aktuell nur in Englisch verfügbar)

Vermutlich ist noch mehr in diese Richtung geplant denn die Anfragen werden sicher mehr

Hey.
Ist etwas wie ein Service bei dem ein Steuerberater noch mal die Daten überprüft und evtl Tipps gibt,.. geplant?
Ähnlich wie bei Accointing ?

Hallo,

ich frage mich ob es einen einfachen Weg gibt, Wallets aus dem Polygon/Matic Mainnet in Cointracking abzubilden, im wesentlichen also Metamask.

Der Wallet/Blockchain-Import beschränkt sich ja leider auf einige gängige Blockchains. Metamask lässt sich auch wunderbar als ETH-Wallet oder als BSC-Wallet einbinden. Dummerweise läuft viel des aktuellen Yield Farmings mit verträglichen Gas-Fees über Polygon. Insofern überlege ich, ob ich bei Cointracking wirklich händisch alle Transaktionen (Swaps, Rewards usw.) aus dem Polygon Network eintragen will oder ob es eine gute Alternative gibt?

Danke für die Hilfe!

Super. Danke für die Antwort!
Ich hatte das erst durch das Auswählen aller IOT Trades auf Binance und dem normalen "Editieren" versucht. Aber so wie du es mir beschrieben hast, komme ich zum Erfolg 

Für die einfache Anpassung so vieler Daten gibt es den "Gruppiert Editieren/Löschen" Punkt auf der https://cointracking.info/enter_coins.php Seite.

Mit "Überschreibe Coins" solltest du da IOTA auf MIOTA oder umgekehrt ändern können.
Klar es muss auch generell gelöst werden aber als Übergangslösung hilft dir das sicher weiter

Aber sind die Werte auch in unterschiedlichen Einheiten?
https://www.blockchaincenter.net/rechner/iota-rechner/

Oder ist nur der Tracker falsch? Wenn nur das Kürzel nicht stimmt sollte es doch von der Gesamtanzahl trotzdem stimmen.

Hallo.
Ich habe folgendes Problem:
Auf Bitfinex wird IOTA als "MIOTA" importiert und auf Binance als "IOT". Gibt es eine Möglichkeit das anzupassen. Leider kann ich es nicht per Hand abändern, da es sich auf jeder Exchange um mehrere Tausend Trades handelt.

Hallo community,

Verständnisfrage zur Verwendung der OPTI-Methode und den zwei Optionen je nach Behandlung der long-term Coins.

OPTI geht wie folgt vor bei den zwei Methoden.

a.) Option ohne long-term Begünstigung:
1.   short loss
2.   long loss
3.   long profit
4.   short profit
 
b.) OPTI mit Begünstigung long-term:
1.   long profit
2.   short loss
3.   long loss
4.   short profit

Jetzt frage ich mich, ob nicht Variante a) immer besser wäre, auch, wenn long-term Coins steuerlich begünstigt sind.
Wäre es nicht immer besser nach Variante a) vorzugehen?

Selbst wenn in meinem Land long-term Coins steuerfrei sind, wäre es doch sinnvoll immer erst short-Verluste zu veräußern, anstatt auf die steuerfreien long-profits zuzugreifen.
So habe ich short-Verluste realisiert, welche mit anderen short-Gewinnen verrechnet werden können.
Der effektive zu versteuernde Gewinn auf Short-Term wäre so geringer. Die long-term Profits sind dann ohnehin immer steuerfrei.

welchen Sind hat es die long-Gewinne zu bevorzugen?
Gibt es da einen von mir nicht berücksichtigten Grund dafür?

LG aus long-term steuerfrei Österreich

@Andreas_CoinTracking
danke für die Rückmeldung. Ich verstehe es jetzt hoffenltich besser. Aber logisch find ich das Handling in cointracking leider immer noch nicht....

In meinem Fall hatte ich per CSV mehrere hundert Transaktionen gleichzeitig importiert, zuviele um nachzuvollziehen was cointracking dann daraus macht. Jetzt habe ich das Einpflegen von Daten stattdessen "zu Fuß" mit wenigen Transaktionen nochmal gemacht und siehe da, wie du schreibst, verrechnet cointracking tatsächlich die Gebühren bereits im Trade. Und damit sind die Gebühren auch in der Kapitalertragsberechnung verrechnet. Blöd bzw. mindestens verwirrend ist es aber, dass dann im gleichen Steuerreport in der "Gebührenbericht" die Gebühren mit 0 Eur angegeben werden. Verrechnet ja... verrechnet nein... Das ist schon missverständlich, oder? Ich habe dann noch weiter getestet und wenn ich Gebühren für Auszahlungen angebe, dann werden diese Auszahlungsgebühren plötzlich im Steuerreport in der Gebührenbericht angezeigt. Mit Einzahlungen wahrscheinlich auch. Je nach Transaktionstyp sind die Gebühren also angegeben oder nicht. Sorry, aber das erschließt sich für mich überhaupt nicht. Kannst du das erklären? Ist denn irgendwo transparent welche Transaktionstypen Gebühren im Gebührenbericht verursachen und welche nicht? Und was ist der Hintergrund? Wäre es nicht besser man würde alle Gebühren dort angeben, gerne in Transaktionentypen gruppiert, Hauptsache nachvollziehbar?

Und wenn die Gebühren ja bereits verrechnet sind, was hat es dann mit der Aussage auf sich, dass man nicht in jedem Land die Gebühren gegen die Gewinne verrechnen kann? Offenbar lässt einem cointracking ja keine andere Wahl, die Gebühren sind doch immer drin. Oder? Und wenn ich die Gebühren jetzt gesondert beim Finanzamt angebe, dann würde ich das ja somit doppelt machen. Das kann ja auch nicht sein.

@Mathias
Könntest du uns dazu bitte ein Ticket mit Account Name senden, um das zu prüfen? Hier müssen wir in deinen Account schauen. Evtl. sind dort Fehler enthalten.
Realisierte Gewinne Seite und Steuerbericht Seite sind in jedem Fall gleich, wenn alles in deinem Account richtig eingetragen ist.
Den Gewinnkalkulator nutzen wenige und den müssten wir prüfen.
Danke.

Hallo Andreas,

1.) Ich habe mich etwas mit dem Gewinn Kalkulator auf der realisierten und unrealisierten Gewinne Seite versucht und festgestellt,
dass der errechnete Gewinn im Kalkulator nicht mit dem tatsächlichen Ergebnis bei Steuerreport zusammenpasst. (Habe dann den Verkauf fiktiv ins Depot eingespielt - Ergebnis ist anders, als im Kalkulator)

Folgendes festgestellt:
* Wenn ich "Depottrennung" ein oder aus schalte, ändert sich das Ergebnis des Kalkulators nicht - es bleibt immer gleich.
Daher berücksichtigt der Kalkulator die Depottrennung nicht, obwohl man sie ein und ausschalten kann.
Im Grunde auch klar, weil ich kann im Kalkulator nicht eingeben, von welcher Wallet/Depot ich verkaufen möchte.

2.) Die "realisierte/unrealisierte Gewinne" Seite rechnet bei OPTI nicht richtig.
Folgendes stelle ich fest:

* Portfolio IST-Zustand zeigt bei "unrealisierte Gewinne" mit OPTI Methode große Coinsummen long-term an.
Diese Summen dürften im Grunde nicht long-term sein, wenn ich nach OPTI vorgehe. Ich tradete diese Coins im Jahr 2020 viel (In Summe mehr, als ich jemals long-term besaß)
Daher OPTI müsste immer als erstes long-term verkaufen im Trade. So hätte ich keine long-term mehr von diesen Coins.

* Im Gewinnkalkulator rechnet CT mir bei großer Summe long-term Verkauf dieser Coins

* wenn ich dann fiktiv eine große Summe dieser Coins als Trade Verkauf einspiele und tatsächlich einen Steuerreport erstelle,
dann erziele ich jedoch diese Summe rein als Short-Trade (Also so, wie es auch tatsächlich sein müsste, da ich ja keine long-term besitze)

* gehe ich dann wieder auf die "realisierten Gewinne" - so zeigt er mir den nun realisierten Gewinn als long-term an.
Also wie es auch vorhin im Kalkulator und "realisierte/unrealisierte Gewinne" enthalten war.

Kann sein, dass OPTI Methode vor einiger Zeit anders vorging, dies dann im Steuerreport aktualisiert wurde, jedoch in der "realisierte/unrealisierte Gewinne"-Berechnung noch Altstand darstellt?
Vielleicht wurde bei OPTI damals 1.) Verkauf Short-Verluste 2.) Verkauf long-Gewinne gerechnet?

Kurzfassung: Die Übersichten "realisierte/unrealisierte Gewinne" und der Gewinnkalkulator rechnet anders, als ein dann erstellter Steuerreport.


LG Mathias

@Queenvio
Ja, es gibt dafür einen Slider in den erweiterten Steuerberichtseinstellungen "Coins aus Einnahmen", den du aktivieren kannst, wenn diese aus der Kapitalertragsberechnung ausschließen möchtest.

Hallo.

Kurze Frage zum Thema staking:

Nehmen wir an ich stake DOT auf Kraken, dann muss der Reward ja versteuert werden.
Danach sind die Reward-Coins beim verkaufen ja Steuerfrei. Ist das in CoinTracking berücksichtigt?

Grüße

Danke Mathias für dein Feedback. Prima, dass FIFO für dich passt.

Ich danke dir für die Abklärung und Info dazu - das hilft mir sehr weiter.
Im Grunde ist es für zB meine Gesamtbetrachtung sogar optimal, wenn innerhalb der Depottrennung immer FIFO verwendet wird.
Dies sollte meines Erachtens so beibelassen werden - man muss es nur wissen, sodass man interne Depotübertragungen für sich richtig managen kann.

Beispiel:

ich besitze große Summen long-term Coins zu sehr niedrigen Kaufkursen auf einer Wallet extern Börse.
auf der selben Wallet generiere ich Stakingrewards.

Ich möchte HPFO verwenden inkl. Depottrennung!
Wenn ich nun Coins von dieser Wallet auf eine Börse sende und dort verkaufen möchte, ist FIFO für die Depottrennung perfekt, da ich die long-term Coins übertrage und steuerfrei verkaufen kann.
Würde innerhalb der Depots ebenfalls HPFO (wie gewählte Steuermethode) verwendet werden, so würde ich jeweils die erhaltenen Stakingrewards short-term verkaufen = Steuer!

Zusammengefasst oder als Anreiz, falls etwas geändert werden sollte:

* Ich finde FIFO innerhalb Depottrennung perfekt - vorausgesetzt man weiß es, dass dies so gehandhabt wird. (So kann man das selbst planen mit den Eigentransfers)

* Falls dies angepasst wird, sollte die Möglichkeit weiterhin bestehen einzelne Tranchen zuordnen zu können.
daher vielleicht im Grunde FIFO zu verwenden, jedoch ergänzend eine Zuordnungsmöglichkeit zu haben. (wie die damalige Trade-Allocation)
So könnte ich zB. von FIFO ausgehen, dann trotzdem bei speziellem Bedarf einen gewissen Eigenübertrag einem Kaufpool zuordnen, welcher übertragen werden soll.

LG Mathias

@Matbert
Ja, wir verwenden derzeit immer FIFO bei Depottrennung, egal welche Kalkulationsmethode gewählt ist.
Wir nehmen dies zum Anlass, um hier ggf. eine Anpassung vorzunehmen. Nicht alle Fälle sind so klar wie dein Beispiel.

Bitte, gern.
1. Schon importierte Transaktionen werden niemals überschrieben. Nur gelöschte werden nochmals importiert beim nächsten Check.
2. Genau. Ein Trade führt immer zu Erneuerung Haltefrist und Gewinn/Verlust. Wenn es kein Trade ist bzw. du das nicht möchtest, dann mit Aus/Einzahlung der BTC arbeiten (auch wenn es eine Warnung für die Zeit im "fehlenden Transaktionsbericht" gibt) und den Abholschein Token als "Einnahme/Ausgabe (steuerfrei)" kennzeichnen.

Wir implementieren diese Logik gerade im ETH Importer, dann BSC usw.
a) Also bitte hier analog ändern in Ein/Auszahlung.
b) nein - s.o.
c) Einnahme/Ausgabe steuerfrei - siehe FAQ: "Anleihe und deren Rückzahlungen" (https://cointracking.freshdesk.com/a/solutions/articles/29000033408?lang=de)
d) ja ist korrekt. Wenn er morgen einen Wert hast und du ihn verkaufst, würdest du die Veränderung von 0 auf den Wert als Gewinn haben.