Jump to content

Empfohlene Beiträge

Danke für deine Antwort, jokin.

Spielen denn die Daten aus 2017 in dem Fall auch eine Rolle? Weil aus 2018 habe ich definitv alle drin. Ich habe die Positionen aus 2017 gelöscht um nicht über die 200 Trades zu kommen. Ich sehe schon - entweder Zahlen für Pro-Upgrade oder Alternative suchen <_<

Kann es sei ndas durch das Überschreiten von den 100 Käufen ein fehlerhafter Steuerreport erstellt wird? Falls ja - ich bin der Meinung das dann besser nichts berechnet werden sollte!

In der detailierten Ansicht steht als Meldung: Es liegt kein passender Kauf zu diesem Verkauf vor (alle Kaufpools erschöpft). Nehme Kauf am gleichen Tag für 0 EUR an.

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 3 Stunden schrieb Hackler:

Spielen denn die Daten aus 2017 in dem Fall auch eine Rolle? Weil aus 2018 habe ich definitv alle drin. Ich habe die Positionen aus 2017 gelöscht um nicht über die 200 Trades zu kommen. Ich sehe schon - entweder Zahlen für Pro-Upgrade oder Alternative suchen <_<

 

Ja das spielt natürlich eine Rolle. Sonst weiss Cointracking ja nicht wie lange du die Coins schon hälst und auf welchem Wallet/Börse. 

Deshalb müssen auch die älteren Käufe/Verkäufe korrekt eingetragen sein.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Danke ibins,

hatte es mir fast schon gedacht - ein User der 2-3 Jahre in Krypto ist und ein wenig umhergetradet hat kommt dann bei cointracking.info nicht um die unlimited Version umher. Und obwohl sie gerade einen Sale haben finde ich die Preis immer noch stolz.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 16 Stunden schrieb Hackler:

Kann es sei ndas durch das Überschreiten von den 100 Käufen ein fehlerhafter Steuerreport erstellt wird? Falls ja - ich bin der Meinung das dann besser nichts berechnet werden sollte!

Du meinst "Verkäufe"?

vor 2 Stunden schrieb Hackler:

hatte es mir fast schon gedacht - ein User der 2-3 Jahre in Krypto ist und ein wenig umhergetradet hat kommt dann bei cointracking.info nicht um die unlimited Version umher. Und obwohl sie gerade einen Sale haben finde ich die Preis immer noch stolz.

Ich bin zwar Unlimited-User, dennoch lege ich mir für jedes Jahr einen neuen Account an und übernehme den Endbestand des Vorjahres als Anfangsbestand des neuen Jahres.

Das mache ich aus Gründen der Übersichtlichkeit und weil die Anzahl der Trades die Cointracking-Server schon arg belastet. (keine Sorge, meine Tradeanzahl ist deutlich oberhalb von normalen Tradern)

Bei der Datenübernahme fasse ich die Käufe eines Coins dann sinnvoll zusammen. Mich betrifft zwar 2016 nicht, dennoch als Beispiel:

Alle noch nicht veräußerten Coins aus dem vorletzten Jahr werden zusammengefasst zum 31.12.2016 - wann genau die angeschafft wurden sehe ich ja im Report des Vorjahres falls es mal jemand ganz genau wissen will. Aus mehreren Kauf-Einträgen wird dann nur noch einer je Coin.

Weiterhin werden die Vorjahreskäufe zu Quartalen zusammen gefasst und ich hab nur noch max. 4 Käufe je Coin. Das macht nur Sinn, wenn ich die Verkäufe dann nicht nur 12 Monate nach dem Kauf vornehme sondern eben noch ein Quartal warte.

 

bearbeitet von Jokin

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 1 Stunde schrieb Jokin:

Du meinst "Verkäufe"?

Ich bin zwar Unlimited-User, dennoch lege ich mir für jedes Jahr einen neuen Account an und übernehme den Endbestand des Vorjahres als Anfangsbestand des neuen Jahres.

Danke für deine Infos, jokin :)

Ja vermutlich liegt es an den Verkäufen? Der von mir beschriebene Fehler entsteht durch binance-Positionen, welche ich getradet habe (wird ja als Kauf/Verkauf gewertet). Ich bin nun nochmal die binance-Transaktionen von 2018 durchgegangen. Auf binance kann ich leider immer nur für max. 3 Monate die csv ziehen. Habe mir das Jahr auch in Quartale eingeteilt. Mein Fehler lag/liegt wohl darin das ich die order-history csv-Datei nicht komplett in cointracking importiert habe. Es sind jetzt aktuell "nur" noch 18 Käufe nicht sauber vorhanden. Ich gehe später die binance Dateien nochmals durch.

Nimmst du für den Import in cointracking auch die Order-History csv oder importierst du ausschließlich Trade, Deposit und Withdrawl Files? Sollte ich ohne die Order-History arbeiten?

Wie machst du in der Praxis beim Neuanlegen eines Accounts den Import "Übernahme Entbestand des Vorjahres" ? Kannst du mir schreiben welche Files wie aufbereitet sein müssen und wie du diese exportierst um sie dann an anderer Stelle zu importieren? Ist das eventuell eine Funktion die dem Pro-Upgrade vorbehalten ist?

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 3 Minuten schrieb Hackler:

Nimmst du für den Import in cointracking auch die Order-History csv oder importierst du ausschließlich Trade, Deposit und Withdrawl Files? Sollte ich ohne die Order-History arbeiten? 

Ich habe noch gar keine Binance-Daten importiert und versuche das zu vermeiden. Würde ich das machen, dann hätte ich mal eben eine Tradeanzahl im 7-stelligen Bereich.

Daher habe ich das sehr einfach gelöst: In 2018 habe ich x ETH bei Bitcoin.de gekauft und diese an Binance gesendet. Gegen Ende 2018 habe ich den Gesamtbestand von Binance wieder an bitcoin.de gesendet und komplett verkauft.
Auf diese Weise habe ich meinen Ertrag direkt in Euro vorliegen.

In Cointracking sieht das dann so aus:
 

1. Kauf x ETH
2. Verkauf x ETH zu 0 Euro an Binance
3. Kauf y ETH zu 0 Euro von Binance
4. Kauf oder Verkauf der Differenz von x und y zu 0 Euro
5. Verkauf y ETH

Somit habe ich nur 5 Einträge in Cointracking trotz Hunderttausenden Einzeltrades.

Zu meinem kompletten Steuerreport (also nicht der von Cointracking) kommen dann noch die Deposit- und Withdrawal-History von Binance sowie ein Screenshot des Jahresendbestandes als Nachweis, dass der "0" beträgt.

vor 9 Minuten schrieb Hackler:

Wie machst du in der Praxis beim Neuanlegen eines Accounts den Import "Übernahme Entbestand des Vorjahres" ? Kannst du mir schreiben welche Files wie aufbereitet sein müssen und wie du diese exportierst um sie dann an anderer Stelle zu importieren?

In meinem kompletten Steuerreport 2017 führe ich den Jahresendbestand auf. Das ist der Screenshot des untersten Abschnitts des Cointracking-Reports. Dort stehen die Anschaffungskosten für jeden einzelnen Coin und das Datum.

In meinem neuen Account lege ich für jeden Coin einen "Kauf" an, der exakt dieselbe Menge zu exakt dem aufgeführten Preis enthält. Standardmäßig nehme ich den 31.12. wenn ich weiß, dass ich diese Coins ohnehin unterjährig verkaufen werde.
Im Fall von BCH habe ich die mit dem 01.08.2017 also dem Fork-Zeitpunkt aufgenommen gehabt, so konnte ich die auch in September 2018 verkaufen ohne dass der Verkauf steuerrelevant ist.

Sowas entscheide ich von Coin zu Coin und hängt auch mit dem Gesamtwert ab - wichtig ist nur, dass das alles nachvollziehbar bleibt, deshalb starte ich meinen Steuerreport 2018 auch mit dem zusammengefassten Jahresanfangsbestand, den ich durch den Vorjahresreport nachweise.

 

  • Thanks 1
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Großes Dankeschön für deine Infos :)

Deinen Ausführungen entnehme ich das du die gehodelten Coins in einer privaten wallet im Steuerschlaf hast. Was du Anfang des Jahres auf bitcoin.de gekauft hast schiebst du einmalig auf binance. Und erst Ende des Jahres kommt es wieder zurück. Ohne das du über das Jahr hinweg hin und herschiebst. Durch den totalen Verkauf Ende des Jahres gehst du bewusst "All out". Vermutlich kaufst du dann am Folgetag die Bestände wieder zurück?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hey zusammen.

@Jokin danke für deine Unterstützung 😊

 @Hackler Wenn du deine Binance Daten als CSV importierst, kannst du nur die TradeHistory.xlsx, DepositHistory.csv  und WithdrawalHistory.csv verwenden. Die OrderHistory lässt sich über unseren Importer nicht importieren. Das ist aber nicht schlimm, denn die drei genannten Dateien enthalten (fast) alle Informationen. 

Deine Referral Gewinne und Airdrops  findest du über folgende Links: 

 
Die Ursache für die Warnungen kann unter anderem daran liegen, dass ein Coin verkauft wurde für den es keinen Kaufpool gibt. Wahrscheinlich fehlen Kauf-Transaktionen in deinem Account. Bitte beachte, dass Ein- und Auszahlungen (Deposits und Withdrawels) keine Kostenbasis haben und nur als Bewegungen zwischen Börsen oder Wallets gelten. Aus diesem Grund werden sie im Steuer-Report nicht berücksichtigt. Falls du Coins gekauft hast, musst du sie in CoinTracking als Trade und nicht als Einzahlung eintragen. 
 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 25 Minuten schrieb CoinTracking Dominik:

Hey zusammen.

@Jokin danke für deine Unterstützung 😊

 @Hackler Wenn du deine Binance Daten als CSV importierst, kannst du nur die TradeHistory.xlsx, DepositHistory.csv  und WithdrawalHistory.csv verwenden. Die OrderHistory lässt sich über unseren Importer nicht importieren. Das ist aber nicht schlimm, denn die drei genannten Dateien enthalten (fast) alle Informationen.

Danke für die Infos :)

Ich habe eben nochmals nachgeprüft - ich kann wirklich die Order-History als csv bei euch einspielen. Sobald ich die OrderHistory.csv ausgewählt habe bekomme ich die Auswahlmöglichkeit "Einzahlungen" oder "Auszahlungen". Und nach Auswahl gehts weiter mit dem Import.

Also sollte ich immer nur mit TradeHistory, DepositHistory und WithdrawlHistory arbeiten? Bzw. für einen sauberen Steuerreport benötige ich nur die TradeHistory seitens binance? Und von bitcoin.de aber schon die Ein-Auszahlungen als csv ?

Noch eine Frage: Nehmen wir an ich kaufe auf bictoin.de BTC und schicke diese dann weiter an Ledger für den Steuerschlaf. Wie wird eine solche Transaktion in cointracking abgearbeitet? Als Auszahlung?

 

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich habe mich nun zu einem Pro-Account entschieden da meine Anzahl Trades das Free Account sprengen. Nachdem ich alle Daten von 2017 bis 31.12.2018 gesichert und geprüft hatte begann ich nochmals "from Scratch"! Steuerreport für 2017 ist bereits gegengeprüft und stimmte schon zuvor. Für 2018 wird mir jetzt lediglich noch 1 Short-Position mit einem Volumen von knapp 300 € von binance angezeigt. Diese gilt es nun noch auszubügeln und herauszufinden warum dies so ist.

Folgende Meldung erscheint: Es liegt kein passender Kauf zu diesem Verkauf vor (alle Kaufpools erschöpft). Nehme Kauf am gleichen Tag für 0 EUR an.

@ jokin und Dominik: Könnte ihr mir hierbei eventuell noch Ansätze oder Hilfestellung geben? Muss ich den fehlenden Kauf manuell suchen und einbinden?

 

 

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich kann da nicht helfen, da musst Du in Deinen Daten suchen. Da muss ja irgendwo ein Kauf fehlen.

Vielleicht hast Du auch eine "Einzahlung" drin, weil Du Coins zu Binance geschoben hast. Da muss vorher irgendwo eine Auszahlung sein und davor wiederum ein Kauf.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich meinte eher dahingehend das ihr eventuell klassiche Anfängerfehler mit cointracking.info kennt die man als Anfänger gerne macht. Ich denke das es einfach von meiner Seite noch nicht sauber durch ist/war - das ist schon klar. Aber z.b. so ne Art Checkliste welche Files denn nun wirklich importiert werden müssen wäre für Anfänger sinnvoll.

Ich habe es nun aktuell soweit durch das meine aktuellen Bestände nach dem Import stimmen und ein fast sauberer Steuerreport generiert werden kann.

Ich fasse kurz (auch für mich selbst für den Wiederholungsfall) zusammen:

Von bitcoin.de wird für den jeweiligen Coin die account statement.csv für den betreffenden Zeitraum benötigt.

Von binance werden die TradeHistory.xlsx , DepositHistory.csv sowie WithdrawalHistory.csv für die jeweiligen Zeiträume benötigt. (Achtung: binance lässt nur 3 Monatszeiträume zu. Daher am besten das Steuerjahr in Quartale splitten)

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 2 Stunden schrieb Jokin:

Ich kann da nicht helfen, da musst Du in Deinen Daten suchen. Da muss ja irgendwo ein Kauf fehlen.

Vielleicht hast Du auch eine "Einzahlung" drin, weil Du Coins zu Binance geschoben hast. Da muss vorher irgendwo eine Auszahlung sein und davor wiederum ein Kauf.

Wie soll/kann es sein das ein Kauf fehlen soll wenn man die Daten aus dem System zieht? Mehr als die Files von bitcoin.de und binance exakt für die Zeiträume auslesen und in cointracking importieren kann ich doch nicht machen?

Ich habe die Daten jetzt immer wieder ausgelesen und importiert. Es fehlt kein einziger und alle die vorhanden sind wurden in cointrackinginfo importiert.

Wenn folgende Meldung erscheint... Es liegt kein passender Kauf zu diesem Verkauf vor (alle Kaufpools erschöpft). Nehme Kauf am gleichen Tag für 0 EUR an.

...sollte der gesuchte Kauf doch in der Vergangenheit liegen weil FIFO, korrekt?

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ja, korrekt - der fehlende Kauf liegt davor.

Welcher Coin ist es? 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

BTC in USDT

In der Auflistung wird 1 Position vorher genau der  benötigte Restbetrag von xxx BTC als "verbleibt offen und wird mit dem nächsten Kaufpool verrechnet" angezeigt.

Das komische ist das die Verkaufsposition davor höher ist als der Bestand im Kaufpool. Somit kann die Verkaufsposition nicht komplett bedient werden mit dem Hinweis "Der Restbetrag von xxx BTC verbleibt offen und wird mit dem nächsten Kaufpool verrechnet". Da frage ich mich wieso binance die Verkaufsorder überhaupt annimmt. Beide Verkäufe haben übrigens denselben Timestamp da der zweite ja nur ausgelöst wurde durch die nicht vorhandene Deckung um den ersten zu bedienen. So langsam glaube ich das ist ein Bug seitens binance? In der Trade-History auf der Binanceseite ist diese 1. Verkaufsposition als "filled" markiert und somit ausgeführt worden. Nur in cointracking wird daraus dann eine zweite nicht erfüllte Verkaufsorder. Auch im OrderHistory auf binance ist der Verkauf als komplett vollzogen gelistet.

Was mir auffällt: 3 Minuten vor dem Verkauf habe ich die automatische Stopp Limit Order gecancelled und dann mit Limit Order verkauft. Wenn der Trade nicht abgedeckt wäre, hätte ich ihn gar nicht setzen können. Also geschieht der Fehler wohl doch bei der Auswertung in cointracking? Vor diesem Verkauf muss irgendwo der Fehler stecken das die Deckung für diesen Verkauf limitiert.

Wenn du möchtest kann ich dir auch gerne einen Screenshot senden, damit du siehst wie das aussieht.

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Zusatzinfo:

Setze ich beim Steuerreport vor der Berechnung den Haken bei "Berechne Margin Trades" wird der Steuerreport quasi bereinigt und es gibt keine offene Position mehr. Der Report wird als fehlerfrei angenommen.

bearbeitet von Hackler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 4 Stunden schrieb Hackler:

Zusatzinfo:

Setze ich beim Steuerreport vor der Berechnung den Haken bei "Berechne Margin Trades" wird der Steuerreport quasi bereinigt und es gibt keine offene Position mehr. Der Report wird als fehlerfrei angenommen.

Das ist aber nicht die Lösung. Denn durch Margin Trades können Verkäufe auch vor Käufen stattfinden.

Wir sollten da schon die genaue Ursache suchen. Die Dateien die du genannt hast sollten eigentlich ausreichen. Am besten du schreibst uns kurz ein Ticket über unseren HelpDesk (https://cointracking.freshdesk.com) mit Angabe deines Usernamen. Dann schauen wir das direkt in deinem Account an und finden so schneller eine Lösung :)

bearbeitet von CoinTracking Dominik

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich möchte hier kurz eine Rückmeldung geben:

Die Fehlerquelle für mein oben geschildertes Problem saß wie so oft 60 cm vor dem Bildschirm! Meine Daten waren einfach nicht sauber so wie schon von Jokin vermutet.

Und zwar hatte ich komplett eine Quelle verdrängt/vergessen - und zwar das traurige Thema Mining - in meinem Fall hashflare. Nachdem ich die Daten von dort ebenfalls eingepflegt hatte ist nun alles so wie es sein soll.

An der Stelle auch nochmals herzlichen Dank an Dominik vom cointracking Team - Danke für deine Unterstützung per Mail. Habe einiges dazu gelernt.

bearbeitet von Hackler
  • Love it 1
  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo,

wie geht man denn in cointracking korrekt mit einem re-brand, also der Umbenennung eines Coins um? Wird steuerlich ja (hoffentlich) kein Verkaufs/Neukauf-Ereignis sein...

Alle alten Käufe von Hand umbenamsen möchte ich ungern, weil die ältesten schon beim FA zu den Akten gingen.

Konkret geht's um Byteball > Obytes.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

@ibins_180

das ist doch genau was ich vermeiden wollte, alte Trades umbenennen, die schon beim FA abgegeben wurden.

aber wenn's nicht anders geht...

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo zusammen,

ich habe eine Frage zu meinem Steuerreport.

In dem letzten Punkt "Abschlussbericht zu nicht verkauften Positionen" sind teilweise Coins aufgelistet die ich nicht mehr besitze. In meiner Zusammenfassung auf Cointracking und auch bei den "Realisierte und unrealisierte Gewinne" gibt es diese Coins richtigerweise nicht mehr, beziehungsweise sind mit einer Null vermerkt.

Immerhin konnte ich mir schon zusammenreimen wie die Anzahl der Coins bei "Abschlussbericht zu nicht verkauften Positionen" zustande kommt. Anbei kurz die Erklärung:

In diesem Beispiel handelt es sich um den QSP-Token. Ich habe meine Tokens auf Binance gekauft und diese dann an meinen Ledger geschickt. Nach einigen Monaten habe ich diese Tokens wieder zurück an Binance geschickt und diese veräußert. Also ist Mein Portfolio an QSP genau gleich Null. Nach angaben des Steuerreports besitze ich jedoch noch 58 QSP, dieses ist genau die Anzahl an Tokens die mir Binance als damalige Transaktionsgebühr berechnet hat, dieses ist auch so in Cointracking eingetragen.

Transfer von Binance an meinen Ledger (1.058 QSP) - Gebühr Transaktion Binance 58 QSP - Erhalt Ledger: 1.000 QSP. 

 

Wieso wird mir also angezeigt, dass ich noch 58 QSP besitze? Kann mir hier vielleicht einer helfen? 

 

Vielen lieben Dank :)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo Donkey, die Transaktionsgebür -> ''Transfergebühr'' z.B. wie in deinem Beispiel von einer Börse an ein Wallet oder umgekehrt muss? separat als Verlust mit gleichem Datum und Uhrzeit eingetragen werden.

Also:

1 Eintrag mit dem Transfer Binance zum Ledger

1 Eintrag als Verlust mit gleichem Datum und Uhrzeit wie der Transfer

bearbeitet von ibins_180

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi ibins_180,

danke für deine Antwort, aber das kann eigentlich nicht sein. Ich habe deinen Vorschlag jetzt gerade einfach mal eingegeben und wie ich es mir schon gedacht hatte, habe ich nun einen negativen Bestand meiner Coins bei dem Reiter "Realisierte und unrealisierte Gewinne".

Dort steht aktuell komischerweise die richtige Anzahl an Coins, nämlich 0. Wenn ich die Kosten nun erneut eintrage, so wie du es vermutet hast, habe ich auf einmal minus 58 QSP und das kann nicht richtig sein :(

Ich komm da echt nicht weiter....

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


×
×
  • Neu erstellen...

Wichtige Information

Wir speichern Cookies auf Ihrem Gerät, um diese Seite besser zu machen. Sie können Ihre Cookie-Einstellungen anpassen, ansonsten gehen wir davon aus, dass Sie damit einverstanden sind. In unseren Datenschutzerklärungen finden sie weitere Informationen.