Ah, also eher so:
Über ein Jahr verteilt folgende Trades:
1 BTC erhalten (einfachheitshalber nicht via Mining), dafür 100 EUR gezahlt. "Interner Preis" ab sofort 100 EUR pro BTC.
0.5 BTC verkauft, zu einem höheren Kurs, 100 EUR erhalten. Interner Preis ab sofort 200 EUR/BTC, 100 EUR nicht realisierter Gewinn, 0 EUR realer Gewinn.
weitere 0.25 BTC verkauft, wieder höherer Kurs, 100 EUR erhalten. Interner Preis ab sofort 400 EUR/BTC, 100 EUR nicht realisierter Gewinn, 100 EUR realer Gewinn.
Preis bricht ein.
Um 50 EUR 0.5 BTC gekauft. Interner Preis ab sofort 100 EUR/BTC, 75 EUR nicht realisierter Gewinn, 50 EUR realer Gewinn
Ich stehe also am Schluss mit 0.75 BTC da, die beim letzten Trade 75 EUR wert waren und habe 50 EUR Gewinn mit Trading gemacht.
Würde das so stimmen?
Ich nehme stark an, es sollte mit ledger auch möglich sein, Verkäufe auf ein Gewinnkonto zu buchen...
Topic: Bitcoin Buchhaltung fifo, lifo,... (scripte etc, work in progress) - page 6. (Read 28726 times)
November 11, 2013, 10:07:52 AM
November 11, 2013, 09:07:29 AM
Würden die Gewinne durch Trades nicht als entsprechende Balance übrigbleiben?
z.B.
1 BTC deposit, 0.50 BTC um 100 USD verkauft, *crash*, 0.30 BTC um 20 USD gekauft.
Endstand:
0.8 BTC, 80 USD
Gewinn in der Zeitspanne wäre also 80 USD - aktueller Wert von 0.2 BTC, oder?
z.B.
1 BTC deposit, 0.50 BTC um 100 USD verkauft, *crash*, 0.30 BTC um 20 USD gekauft.
Endstand:
0.8 BTC, 80 USD
Gewinn in der Zeitspanne wäre also 80 USD - aktueller Wert von 0.2 BTC, oder?
Die Methodik die ich hier machen will ermittelt den Gewinn als (
Deshalb braucht man auch die Töpfe (liste von {anzahl BTC, kaufpreis, Datum}), damit man den Kaufpreis ermitteln kann.
Dein Beispiel geht bei meiner Methodik schonmal garnicht, denn: wo hast du den 1 BTC denn her? Wir brauchen für den einen Kaufpreis "x USD". Dann könnten wir deinen Gewinn ermitteln als "0.5 * (x - 100) USD" Dein späterer kauf von 0.3 BTC erzeugt keinen Gewinn, nur der Verkauf.
November 11, 2013, 08:15:04 AM
Würden die Gewinne durch Trades nicht als entsprechende Balance übrigbleiben?
z.B.
1 BTC deposit, 0.50 BTC um 100 USD verkauft, *crash*, 0.30 BTC um 20 USD gekauft.
Endstand:
0.8 BTC, 80 USD
Gewinn in der Zeitspanne wäre also 80 USD - aktueller Wert von 0.2 BTC, oder?
z.B.
1 BTC deposit, 0.50 BTC um 100 USD verkauft, *crash*, 0.30 BTC um 20 USD gekauft.
Endstand:
0.8 BTC, 80 USD
Gewinn in der Zeitspanne wäre also 80 USD - aktueller Wert von 0.2 BTC, oder?
November 11, 2013, 07:33:45 AM
klinke mich hier mal ein.
November 11, 2013, 07:31:15 AM
Eventuell interessant ist es auch, sich ledger-cli aunzusehen und einen Converter von mtgox-csv auf Ledger zu erstellen. Dazu muss man vermutlich gar nicht mal so viel tun, nur ein paar Daten jonglieren (und eventuell Zeitzonen beachten) und anders formatiert abspeichern.
Das Ding ist recht flott im Berechnen von Daten und Darstellen lassen die sich auch recht brauchbar.
Importer für andere csv-files kann man dann auch einfachst ableiten.
Das Ding ist recht flott im Berechnen von Daten und Darstellen lassen die sich auch recht brauchbar.
Importer für andere csv-files kann man dann auch einfachst ableiten.
http://www.ledger-cli.org/features.html
das Ding tut's glaub nicht für unseren Anwendungsfall. Da müsstest du extern Buchungssätze generieren welche die Gewinne aus den Trades abbilden.
Ich hab übrigens nix dagegen wenn hier über Buchhaltungstools oder Buchhaltung allgemein diskutiert wird.
November 11, 2013, 07:28:19 AM
Sorry molecular, ich selbst habe zu wenig Ahnung von Buchhaltung allgemein und ehrlich gesagt auch kein Interesse hier arbeit reinzustecken.
Aber solltest du dich dazu durchringen zB einen PDF Guide oder sowas zu erstellen, würde ich mich eventuell anbieten diesen dann mit eventuellen Grafiken etc auszustatten.
Aber solltest du dich dazu durchringen zB einen PDF Guide oder sowas zu erstellen, würde ich mich eventuell anbieten diesen dann mit eventuellen Grafiken etc auszustatten.
ok, gut zu wissen. Danke für das Angebot.
Ist aber unwahrscheinlich.
November 11, 2013, 05:54:48 AM
Eventuell interessant ist es auch, sich ledger-cli aunzusehen und einen Converter von mtgox-csv auf Ledger zu erstellen. Dazu muss man vermutlich gar nicht mal so viel tun, nur ein paar Daten jonglieren (und eventuell Zeitzonen beachten) und anders formatiert abspeichern.
Das Ding ist recht flott im Berechnen von Daten und Darstellen lassen die sich auch recht brauchbar.
Importer für andere csv-files kann man dann auch einfachst ableiten.
Das Ding ist recht flott im Berechnen von Daten und Darstellen lassen die sich auch recht brauchbar.
Importer für andere csv-files kann man dann auch einfachst ableiten.
November 11, 2013, 04:52:22 AM
Sorry molecular, ich selbst habe zu wenig Ahnung von Buchhaltung allgemein und ehrlich gesagt auch kein Interesse hier arbeit reinzustecken.
Aber solltest du dich dazu durchringen zB einen PDF Guide oder sowas zu erstellen, würde ich mich eventuell anbieten diesen dann mit eventuellen Grafiken etc auszustatten.
Aber solltest du dich dazu durchringen zB einen PDF Guide oder sowas zu erstellen, würde ich mich eventuell anbieten diesen dann mit eventuellen Grafiken etc auszustatten.
November 11, 2013, 01:19:47 AM
so aus dem Bauch raus würde ich jetzt mal sagen: 95% der Trader sind Computertechnisch auf dem Niveau, das sie es in Word abtippen, Access nachinstallieren und dann dich fragen wieso es nicht funktioniert. 2% kennen Linux und wissen, das sie weiter windows nutzen, weil Linux viel zu kompliziert ist. 3% können wirklich etwas mit deinen Scripten anfangen. Aber das sind die nerds, die zwar 100% wissen wie jedes Bit im Bitcoinnetzwerk funktioniert, aber beim spekulieren nichtmal ansatzweise in einen Bereich kommen, das sie Steuern ans Finanzamt abführen müssen.
Aber nur mal so als Idee: baue das ganze aus, bastel eine GUI dazu und vermarkte es. Das Handwerkszeug dazu hast du und Ahnung von der Materie auch. Es gibt kein schlimmeres Programm, als das was ein programmierer entwirft der nie mit dem Produkt in Kontakt gekommen ist. Man muss aus der Sparte kommen um zu verstehen, was der Markt braucht und was nicht. Damit bist du den meisten programmierern einen Schritt voraus.
Denk auch mal dran: im Goldrausch sind die Schaufel und Hakenverkäufer reich geworden.
Aber nur mal so als Idee: baue das ganze aus, bastel eine GUI dazu und vermarkte es. Das Handwerkszeug dazu hast du und Ahnung von der Materie auch. Es gibt kein schlimmeres Programm, als das was ein programmierer entwirft der nie mit dem Produkt in Kontakt gekommen ist. Man muss aus der Sparte kommen um zu verstehen, was der Markt braucht und was nicht. Damit bist du den meisten programmierern einen Schritt voraus.
Denk auch mal dran: im Goldrausch sind die Schaufel und Hakenverkäufer reich geworden.
Du wirst es nicht glauben, aber daran habe ich auch schon gedacht.
Allerdings: eine solche software mal eben zu schreiben ist zwar nicht schwierig, aber sehr aufwendig.
Wie du auch schon eruiert hast, dürfte der Markt dafür (noch) recht klein sein. Wenn er dann groß ist, kommen bestimmt DATEV und Co. auf den Trichter. Das wäre dann wohl das KO für die Idee. Allerdings: wer den Verein kennt der weiss: die sind mehr als langsam. Es gibt aber auch Konkurrenz die schneller ist (sein muss) und auch auf die Idee kommen könnte um ein Alleinstellungsmerkmal in diesem Markt zu haben.
Mein derzeitiger (Business-)Plan ist:
- 1.) eigene Buchhaltungs-Systematik "entwickeln", mit Steuerberater abgestimmt. Schön wäre dann, wenn das FA diese auf Herz und Nieren prüfen würde. (nein liebes FA, dies ist keine Aufforderung)
- 2.) Hilfe anbieten (rein technisch, keine Steuerberatung): Leute die das machen wollen kommen 1, 2 Tage zu mir (unter Beratung ihres eigenen Steuerberaters, mit welchem die Systematik abgesprochen wird) und wir ziehen das durch... ganz diskret auf einem frisch installierten Rechner oder auf dem Rechner des Kunden, so daß ich auf keinen Fall Daten des Kunden irgendwie habe. (Profit)
- 3.) Dann mal weitersehen.
Da ich hier alles veröffentliche stehen diese Möglichkeiten jedem offen. Der stuff ist public domain, also habt ihr nicht mal GPL-Probleme und könnt closed-source-sachen basteln.
EDIT: Punkt 2.) könnte auch im Rahmen eines Workshops gemacht werden.
November 11, 2013, 01:10:23 AM
Hallo,
ich habe mir nicht den gesamten Thread durchgelesen, sondern wollte kurz mein Feedback geben.
Ihr dürft eure Trades nicht in Word oder Excel abtippen!!!
Buchhaltung muss IMMER in einem Medium erfolgen, indem es später nicht wieder geändert werden kann!! Das ist eins der grundsätze der Buchhaltung.
ich habe mir nicht den gesamten Thread durchgelesen, sondern wollte kurz mein Feedback geben.
Ihr dürft eure Trades nicht in Word oder Excel abtippen!!!
Buchhaltung muss IMMER in einem Medium erfolgen, indem es später nicht wieder geändert werden kann!! Das ist eins der grundsätze der Buchhaltung.
Danke für's lesen und Dein feedback.
Ich würde niemals 8000 trades in excel abtippen.
Ich würde auch niemals 8000 trades in einen alten Kalender reinschreiben, wie das hier im Forum mal vorgeschlagen wurde.
Das wäre ein unangemessener Aufwand.
Die Grundlage der Buchhaltungs-skripte, welche ich hier vorschlage (als deren Eingabedaten), sind allesamt "für mich unveränderbar", da es Exporte aus den Datenbanken der Exchanges sind. Ich erfinde hier also nichts und kann auch nichts manipulieren. Das FA kann ja per Gerichtsbeschluss die Daten von den Exchanges anfordern, bzw. ich kann ggf. unter Kooperation der Exchanges beweisen, daß ich nichts manipuliert habe.
Ich sehe hier kein Problem
Mein Steuerberater auch nicht.
Ich weiss auch nicht wie das anders gehen sollte. Der Vorschlag mit dem alten Kalender ist schlicht nicht durchführbar in meinem Falle. Auch die Buchhaltung an sich (man muss ja Töpfe führen), ist "von Hand" wohl kaum durchzuführen.
Ausserdem: was hält mich davon ab, das tolle "unveränderbare" Medium einfach nochmal neu aufzusetzen, wenn ich was ändern will?
November 10, 2013, 02:06:37 PM
Hallo,
ich habe mir nicht den gesamten Thread durchgelesen, sondern wollte kurz mein Feedback geben.
Ihr dürft eure Trades nicht in Word oder Excel abtippen!!!
Buchhaltung muss IMMER in einem Medium erfolgen, indem es später nicht wieder geändert werden kann!! Das ist eins der grundsätze der Buchhaltung.
Ihr könntet beispielsweise zusammen mit eurem Steuerberater eine Datev Schnittstelle einrichten. Dann gebt ihr eure Trades zu Hause in Datev ein und er sieht die dann alle und kann entsprechend die Abrechnung machen.
ich habe mir nicht den gesamten Thread durchgelesen, sondern wollte kurz mein Feedback geben.
Ihr dürft eure Trades nicht in Word oder Excel abtippen!!!
Buchhaltung muss IMMER in einem Medium erfolgen, indem es später nicht wieder geändert werden kann!! Das ist eins der grundsätze der Buchhaltung.
Ihr könntet beispielsweise zusammen mit eurem Steuerberater eine Datev Schnittstelle einrichten. Dann gebt ihr eure Trades zu Hause in Datev ein und er sieht die dann alle und kann entsprechend die Abrechnung machen.
Kann ich bitte mal eine Quelle dafür haben? Oder hast du möglicherweise *gewerbliche* Buchhaltung im Kopf, für die (vermute ich mal) strengere Regeln gelten. Wovon wir hier reden ist, denke ich jedenfalls, eine Erfassung von einzelnen Bitcoin Kauf/Verkauf Vorgängen von privaten Investoren/Händlern. Wäre mir komplett neu dass in diesem Fall die Wahl der Aufzeichnung/Software eingeschränkt sein sollte.
November 10, 2013, 08:56:39 AM
Hallo,
ich habe mir nicht den gesamten Thread durchgelesen, sondern wollte kurz mein Feedback geben.
Ihr dürft eure Trades nicht in Word oder Excel abtippen!!!
Buchhaltung muss IMMER in einem Medium erfolgen, indem es später nicht wieder geändert werden kann!! Das ist eins der grundsätze der Buchhaltung.
Ihr könntet beispielsweise zusammen mit eurem Steuerberater eine Datev Schnittstelle einrichten. Dann gebt ihr eure Trades zu Hause in Datev ein und er sieht die dann alle und kann entsprechend die Abrechnung machen.
ich habe mir nicht den gesamten Thread durchgelesen, sondern wollte kurz mein Feedback geben.
Ihr dürft eure Trades nicht in Word oder Excel abtippen!!!
Buchhaltung muss IMMER in einem Medium erfolgen, indem es später nicht wieder geändert werden kann!! Das ist eins der grundsätze der Buchhaltung.
Ihr könntet beispielsweise zusammen mit eurem Steuerberater eine Datev Schnittstelle einrichten. Dann gebt ihr eure Trades zu Hause in Datev ein und er sieht die dann alle und kann entsprechend die Abrechnung machen.
November 10, 2013, 07:38:13 AM
so aus dem Bauch raus würde ich jetzt mal sagen: 95% der Trader sind Computertechnisch auf dem Niveau, das sie es in Word abtippen, Access nachinstallieren und dann dich fragen wieso es nicht funktioniert. 2% kennen Linux und wissen, das sie weiter windows nutzen, weil Linux viel zu kompliziert ist. 3% können wirklich etwas mit deinen Scripten anfangen. Aber das sind die nerds, die zwar 100% wissen wie jedes Bit im Bitcoinnetzwerk funktioniert, aber beim spekulieren nichtmal ansatzweise in einen Bereich kommen, das sie Steuern ans Finanzamt abführen müssen.
Aber nur mal so als Idee: baue das ganze aus, bastel eine GUI dazu und vermarkte es. Das Handwerkszeug dazu hast du und Ahnung von der Materie auch. Es gibt kein schlimmeres Programm, als das was ein programmierer entwirft der nie mit dem Produkt in Kontakt gekommen ist. Man muss aus der Sparte kommen um zu verstehen, was der Markt braucht und was nicht. Damit bist du den meisten programmierern einen Schritt voraus.
Denk auch mal dran: im Goldrausch sind die Schaufel und Hakenverkäufer reich geworden.
Aber nur mal so als Idee: baue das ganze aus, bastel eine GUI dazu und vermarkte es. Das Handwerkszeug dazu hast du und Ahnung von der Materie auch. Es gibt kein schlimmeres Programm, als das was ein programmierer entwirft der nie mit dem Produkt in Kontakt gekommen ist. Man muss aus der Sparte kommen um zu verstehen, was der Markt braucht und was nicht. Damit bist du den meisten programmierern einen Schritt voraus.
Denk auch mal dran: im Goldrausch sind die Schaufel und Hakenverkäufer reich geworden.
November 10, 2013, 05:35:47 AM
hab mal in OP hingeschrieben was fifo und lifo heisst:
(FIFO heisst: First In First Out, LIFO: Last In First Out)
(FIFO heisst: First In First Out, LIFO: Last In First Out)
November 10, 2013, 05:30:24 AM
Respekt !
Anmerkung: Ich glaube du gehst von zuviel Vorwissen der Leser aus. Du wirfst mit "Fachbegriffen" um dich mit denen der Großteil der Leute vermutlich nichts anfangen kann. Davon abgesehen werden eher weniger Leute ahnung davon haben wie man zb deine "Scripte" (simpel ausgedrückt) benutzt oder allgemein anwendet/anpasst.
Klar kann man sich die Infos "zusammensuchen", aber wirklich TOP wäre es wenn du quasi einen "Guide" für absolute Anfänger schreiben würdest, wo zb erklärt wird was zb "FIFO" überhaupt ist und ansonsten auf englische sowie auf Fachbegriffe verzichtet wird bzw diese erklärt/umschrieben werden.
Anmerkung: Ich glaube du gehst von zuviel Vorwissen der Leser aus. Du wirfst mit "Fachbegriffen" um dich mit denen der Großteil der Leute vermutlich nichts anfangen kann. Davon abgesehen werden eher weniger Leute ahnung davon haben wie man zb deine "Scripte" (simpel ausgedrückt) benutzt oder allgemein anwendet/anpasst.
Klar kann man sich die Infos "zusammensuchen", aber wirklich TOP wäre es wenn du quasi einen "Guide" für absolute Anfänger schreiben würdest, wo zb erklärt wird was zb "FIFO" überhaupt ist und ansonsten auf englische sowie auf Fachbegriffe verzichtet wird bzw diese erklärt/umschrieben werden.
Wenn man den ersten post durchgeht sieht man, daß ich auch an die weniger erfahrenen gedacht hab (da sind erklärende Anmerkungen drin).
So einen Guide zu machen ist nochmal 'ne Ecke aufwendiger und dazu hab ich momentan weder Zeit noch Lust. Ausserdem ist es dafür noch viel zu früh da sich bestimmt noch alles mögliche ändert (siehe Titel: "work in progress")
Es geht jetzt (für mich) erstmal darum, das alles mal überhaupt hinzukriegen... da steckt noch viel Arbeit drin.
Ich könnte auch Hilfe brauchen, vielleicht willst du ja auch was beisteuern. Bräuchte zum Beispiel Wechselkurse PLN (polnischer Sloti oder wie der heisst), täglich ab 2011 als csv oder sonstwie.
November 10, 2013, 04:58:49 AM
Respekt !
Anmerkung: Ich glaube du gehst von zuviel Vorwissen der Leser aus. Du wirfst mit "Fachbegriffen" um dich mit denen der Großteil der Leute vermutlich nichts anfangen kann. Davon abgesehen werden eher weniger Leute ahnung davon haben wie man zb deine "Scripte" (simpel ausgedrückt) benutzt oder allgemein anwendet/anpasst.
Klar kann man sich die Infos "zusammensuchen", aber wirklich TOP wäre es wenn du quasi einen "Guide" für absolute Anfänger schreiben würdest, wo zb erklärt wird was zb "FIFO" überhaupt ist und ansonsten auf englische sowie auf Fachbegriffe verzichtet wird bzw diese erklärt/umschrieben werden.
Anmerkung: Ich glaube du gehst von zuviel Vorwissen der Leser aus. Du wirfst mit "Fachbegriffen" um dich mit denen der Großteil der Leute vermutlich nichts anfangen kann. Davon abgesehen werden eher weniger Leute ahnung davon haben wie man zb deine "Scripte" (simpel ausgedrückt) benutzt oder allgemein anwendet/anpasst.
Klar kann man sich die Infos "zusammensuchen", aber wirklich TOP wäre es wenn du quasi einen "Guide" für absolute Anfänger schreiben würdest, wo zb erklärt wird was zb "FIFO" überhaupt ist und ansonsten auf englische sowie auf Fachbegriffe verzichtet wird bzw diese erklärt/umschrieben werden.
November 10, 2013, 04:40:13 AM
weiter im Programm, wir brauchen currency rates
einige nützliche links auf stackoverflow
dort hab ich auch einen service der Federal Reserve gefunden: http://www.federalreserve.gov/datadownload/Choose.aspx?rel=H10
dort hab ich mir einen download configuriert mit folgenden parametern:
das file als FRB_H10.csv speichern.
da sind Zeilen mit "ND" als exchange rate drin, die hab ich mit "cat | grep" rausgemacht:
ergibt FRB_H10_NOND.csv (pastebin)
ab in die db damit (mit "psql", "bitbuch=#" weglassen, das ist der prompt):
leider sind die Daten von der FED lückenhaft (keine Einträge für Samstage, Sonntage, etc). Daher eine längliche query um die daten in einen "schönen" benutzbaren table reinzukriegen:
(ACHTUNG: der Table wird bis ende 2013 befüllt mit dem neusten vorliegenden Wert)
so, resultat:
schön, oder?
EDIT: added primary key to rate table
einige nützliche links auf stackoverflow
dort hab ich auch einen service der Federal Reserve gefunden: http://www.federalreserve.gov/datadownload/Choose.aspx?rel=H10
dort hab ich mir einen download configuriert mit folgenden parametern:
- currencies: GBP, EUR
- data format: csv
- format: "series as list"
- omit data labels
das file als FRB_H10.csv speichern.
da sind Zeilen mit "ND" als exchange rate drin, die hab ich mit "cat | grep" rausgemacht:
Code:
bash> cat FRB_H10.csv | grep -v ",ND" > FRB_H10_NOND.csv
ergibt FRB_H10_NOND.csv (pastebin)
ab in die db damit (mit "psql", "bitbuch=#" weglassen, das ist der prompt):
Code:
bash#> psql bitbuch
bitbuch=# create table fed_rates (name varchar(64), datum date, rate numeric(20,8));
bitbuch=# delete from fed_rates
bitbuch=# copy fed_rates(name, datum, rate) from '/nix/data/bitcoin/buchhaltung/FRB_H10_NOND.csv' delimiter ',' CSV;
bitbuch=# create table fed_rates (name varchar(64), datum date, rate numeric(20,8));
bitbuch=# delete from fed_rates
bitbuch=# copy fed_rates(name, datum, rate) from '/nix/data/bitcoin/buchhaltung/FRB_H10_NOND.csv' delimiter ',' CSV;
leider sind die Daten von der FED lückenhaft (keine Einträge für Samstage, Sonntage, etc). Daher eine längliche query um die daten in einen "schönen" benutzbaren table reinzukriegen:
(ACHTUNG: der Table wird bis ende 2013 befüllt mit dem neusten vorliegenden Wert)
Code:
bitbuch=# create table rate(datum date, currency varchar(3), rate numeric(20,8), primary key (datum, currency));
bitbuch=# insert into rate(datum, currency, rate)
select
d.datum,
case
when n.name = 'H10/H10/RXI$US_N.B.EU' then 'EUR'
when n.name = 'H10/H10/RXI$US_N.B.UK' then 'GBP'
else 'N/A'
end,
(select rate from fed_rates as r where r.name = n.name and r.datum <= d.datum order by datum desc limit 1) as rate
from (
select ('2011-01-01'::date + s.a) as datum
from generate_series(0, 365*3) as s(a)
) as d
inner join (
select name from fed_rates as r group by name
) as n on 1=1
;
bitbuch=# insert into rate(datum, currency, rate)
select
d.datum,
case
when n.name = 'H10/H10/RXI$US_N.B.EU' then 'EUR'
when n.name = 'H10/H10/RXI$US_N.B.UK' then 'GBP'
else 'N/A'
end,
(select rate from fed_rates as r where r.name = n.name and r.datum <= d.datum order by datum desc limit 1) as rate
from (
select ('2011-01-01'::date + s.a) as datum
from generate_series(0, 365*3) as s(a)
) as d
inner join (
select name from fed_rates as r group by name
) as n on 1=1
;
so, resultat:
Code:
bitbuch=# select * from rate order by datum desc limit 10;
datum | currency | rate
------------+----------+------------
2013-12-31 | GBP | 1.62080000
2013-12-31 | EUR | 1.35340000
2013-12-30 | GBP | 1.62080000
2013-12-30 | EUR | 1.35340000
2013-12-29 | EUR | 1.35340000
2013-12-29 | GBP | 1.62080000
2013-12-28 | GBP | 1.62080000
2013-12-28 | EUR | 1.35340000
2013-12-27 | GBP | 1.62080000
2013-12-27 | EUR | 1.35340000
datum | currency | rate
------------+----------+------------
2013-12-31 | GBP | 1.62080000
2013-12-31 | EUR | 1.35340000
2013-12-30 | GBP | 1.62080000
2013-12-30 | EUR | 1.35340000
2013-12-29 | EUR | 1.35340000
2013-12-29 | GBP | 1.62080000
2013-12-28 | GBP | 1.62080000
2013-12-28 | EUR | 1.35340000
2013-12-27 | GBP | 1.62080000
2013-12-27 | EUR | 1.35340000
schön, oder?
EDIT: added primary key to rate table
October 31, 2013, 06:53:25 AM
Ich meld mich wieder wenn ich mit dem Steuerberater gesprochen hab, vielleicht lern ich ja noch was interessantes das ich hier wiedergeben kann.
ok, super
October 31, 2013, 06:45:21 AM
Tag nochmal.
Ich antworte mal in deinem thread...
re: 1-Jahresfrist. Danke, verstehe es deutlich besser, und verstehe jetzt auch was das FIFO vs LIFO in diesem Kontext bedeutet.
re: FA Prüfung. Okay, ich sehe was du meinst. Ich kenne bisher halt Prüfungen nur vom ehemaligen Betrieb meiner Eltern, und da waren die "Bücher" halt immer irgendwas was von der Finanz-Buchhaltungs-Abteilung gemacht wurde und irgendwie offiziell ... aber wenn ich jetzt so drüber nachdenke, da hätte es natürlich auch Spielraum gegeben die Bücher zu "bearbeiten". Wird also interessant, wann ein dt. FA zum ersten mal einen richterlichen Beschluss erwirkt um die Accountdaten auf mtgox oder bitstamp nachzusehen.
Ich meld mich wieder wenn ich mit dem Steuerberater gesprochen hab, vielleicht lern ich ja noch was interessantes das ich hier wiedergeben kann.
Ich antworte mal in deinem thread...
re: 1-Jahresfrist. Danke, verstehe es deutlich besser, und verstehe jetzt auch was das FIFO vs LIFO in diesem Kontext bedeutet.
re: FA Prüfung. Okay, ich sehe was du meinst. Ich kenne bisher halt Prüfungen nur vom ehemaligen Betrieb meiner Eltern, und da waren die "Bücher" halt immer irgendwas was von der Finanz-Buchhaltungs-Abteilung gemacht wurde und irgendwie offiziell ... aber wenn ich jetzt so drüber nachdenke, da hätte es natürlich auch Spielraum gegeben die Bücher zu "bearbeiten". Wird also interessant, wann ein dt. FA zum ersten mal einen richterlichen Beschluss erwirkt um die Accountdaten auf mtgox oder bitstamp nachzusehen.
Ich meld mich wieder wenn ich mit dem Steuerberater gesprochen hab, vielleicht lern ich ja noch was interessantes das ich hier wiedergeben kann.
October 31, 2013, 02:36:48 AM
Hey molecular
moin!
Danke für den Link zu deinem thread. Hier ist mein eigener, im dt. Spekulations-Forum... sind aber bisher noch keine Antworten gekommen 
Um es gleich zu sagen: du bist mir um Längen vorraus. Um genau zu sein, ich vesteht tatsächlich weniger als die Hälfte von dem was du macht... hängt wahrscheinlich damit zusammen dass btc meine erste richtige Erfahrung mit börsenähnlichen Geschäften sind, und meine EkSt-Erklärung bisher immer recht schlicht ausfiel.
Um es gleich zu sagen: du bist mir um Längen vorraus. Um genau zu sein, ich vesteht tatsächlich weniger als die Hälfte von dem was du macht... hängt wahrscheinlich damit zusammen dass btc meine erste richtige Erfahrung mit börsenähnlichen Geschäften sind, und meine EkSt-Erklärung bisher immer recht schlicht ausfiel.
Ist bei mir ähnlich, bloss dass ich 'nen Steuerberater habe mit dem ich jetzt schon 3 mal über Bitcoin gequatscht hab.
Wenn du erlaubst, ein, zwei Fragen:
gerne: allerdings: ich bin kein Steuerberater, also bitte alles was ich sage mit Vorsicht geniessen und am besten selber einen Konsultieren.
Wenn ich es richtig verstanden habe sollen btc Spekulationsgewinne nach einem Jahr steuerfrei sein. Beinhaltet das den zwischenzeitigen Ver- und Rückkauf von btc, oder nicht?
Gehen wir mal davon aus, die Veräusserung von BTC nach einem Jahr "Haltedauer" sei steuerfrei. (Ob das so ist glaube ich dann, wenn das mal ein Gericht so bestätigt hat).
Wenn du zwischendurch den Bitcoin einmal verkaufst und gleich wieder kaufst (z.B. wegen trading), dann ist natürlich die "Haltedauer" wieder resetted. Sagen wir du kaufst 2 BTC im Februar 2011 für je €1. Dann verkaufst du einen davon im November 2012 für €3. Dann hast du €2 gewinn gemacht (haltedauer: 9 monate, einkaufspreis: 1€, verkaufspreis: 3€, gewinn = 1 * (3€ - 1€), zu versteuern als Einkommen aus privatem Veräußerungsgeschäft (wenn ich mich nicht täusche)).
Sagen wir du kaufst diesen bitcoin direkt dannach gleich wieder für €2.50. Kaufen hat erstmal keine steuerliche Auswirkung, nur Veräussern. Du hast nun im Depot: 1 BTC gekauft Februar 2011 für 1€ und 1 BTC gekauft November 2011 für €2.5.
Wenn du nun im Juni 2012 wieder einen deiner 2 BTC verkaufst macht es natürlich einen großen Unterschied, welchen du verkaufst... bei veräußerung des im Februar gekauften fällt wohl keine Steuer an, bei dem im November gekauften schon. Wenn du LIFO-Buchhaltung machst (Last in, first out), verkaufst du den November-coin. Bei FIFO den alten vom Februar.
Was besser ist hängt vom Einzelfall und dummerweise auch noch von der Zukunft ab. Man kann das Verfahren zwischendurch natürlich nicht einfach wechseln.
Du beschreibst den Download der mtgox Datenbank. Das sind nur deine eigenen trades, richtig? In dem Fall sind die also nicht öffentlich zugänglich, sondern nur aus deinem eigenen Account zugänglich (ich bin selber nicht auf mtgox, sondern bitstamp, aber ich nehme mal an es ist im wesentlichen gleich). Vielleicht verstehe ich nicht wirklich wie das FA arbeitet, aber was für eine Aussagekraft hat so eine selbst zusammengestellte Tabelle für die? Sie können auf die von mir getätigten trades nicht zugreifen (weil sie meinen Account nicht haben), und die Tabelle die ich mit einreiche kann ohne weiteres von mir geändert werden.
Du unterschätzt das FA ;-). Grundsätzlich ist es mal so, daß die davon ausgehen müssen, daß du sie nicht anlügst. Wenn sie natürlich den Verdacht bekommen (bei einer Prüfung zum Beispiel), daß du Steuer hinterziehst, dann können sie ja ein verfahren einleiten und ermitteln. mtGox sagt sie geben die Daten raus bei richterlichem Beschluss. Wenn du dann manipuliert hast... gut Nacht!
Ich treffe Ende des Jahres meinen/den Steuerberater meiner Mutter, und frag ihn auch mal um Rat. Ich befürchte, der wird nur sehr begrenzt die btc Aspekte verstehen, aber vielleicht lassen sich ja einige Dinge aus dem Börsenhandel etc. anwenden.
Sein größtes Problem wird mit Sicherheit die Einordnung von BTC sein. Wenn er weiss um was es sich handelt kann er Dir sicher helfen den Kram zu verbuchhalten. Am besten bringst du ihm die Antworten von Koschitz mit, oder wie der heisst (hier zu finden: http://www.frank-schaeffler.de/tag/bitcoin/)
Ich hoffe meine Ausführungen helfen Dir.
Mich würden natürlich auch ggf. existierende andere Meinungen hierzu interessiern.
Jump to: