Bitcoin Buchhaltung fifo, lifo,... (scripte etc, work in progress)

[molecular]

Scripts sind outdated, ich hab neue, bessere. Wenn jemand ernsthaft interesse anmeldet, werde ich die Sachen hier updaten

Moin Jungs,

ich war mal wieder bei meinem Steuerberater... ich hatte ihm vorab die 2 Antworten von Koschyk zugesandt.

Hier in Kurzform was ich aus dem Gespräch mitgenommen hab:

• Die Unsicherheit kotzt Ihn genauso an wie uns, wirkliche Klarheit gibt's in 5-10 Jahren wenn der Bundesfinanzhof (oberstes Finanzgericht?) was entscheidet
• Er stimmt nicht mit Koschyk überein was die Umsatzbesteuerung gemineter coins angeht
• Wir können also jetzt nur eins tun und eine Gewinnermittlung fahren, welche für uns "nicht nachteilig" erscheint, müssen aber damit rechnen, daß der ganze Käse evtl. neu aufgerollt wird sollte der BFH eine relevante Entscheidung fällen
• Es gibt ein Urteil vom BFH welches besagt, daß Depots getrennt geführt werden dürfen. (Er sucht mir das Urteil noch raus). Inwiefern das auf Bitcoin passt bleibt meiner Ansicht nach zu beurteilen, mein Stuerberater ist sich aber sicher, daß das Urteil hier zur Anwendung gebracht werden darf (ich beschreibe weiter unten wie das geht mit getrennten Depots)

Nochmals zur Übersicht wie ich die Möglichkeiten der Verbuchhaltung sehe:

• 1.) FIFO über alle Depots (auch persönlicher Geldbeutel) vereinigt
• 2.) LIFO über alle Depots (auch persönlicher Geldbeutel) vereinigt
• 3.) FIFO separat pro Depot
• 4.) LIFO separat pro Depot

(FIFO heisst: First In First Out, LIFO: Last In First Out)

Getrennte Depots

Eine [F|L]IFO-Buchhaltung pro Depot getrennt abzufahren ist ja kein Problem. Jeder Exchange-Account kann als Depot betrachtet werden (es können nur Bitcoins verkauft werden, welche dort auch liegen). Zusätzlich kann man alle private Geldbeutel als 1 Depot führen (analog zu: "safe zuhause mit Aktien drin").

Bleibt die Frage was passiert beim Transfer von Bitcoins zwischen Depots: Grundsätzlich "klebt" an den coins natürlich das Kaufdatum und der Kaufpreis ("Topf"). Die Coins werden inklusive dieser infos transferiert. Wurden nun beispielsweise tatsächlich Bitcoins von mtGox Account in den privaten Geldbeutel transferiert, so ergibt sich natürlich die Frage: aus welchem Topf entnehme ich die coins aus dem mtGox Depot. Überraschende Antwort meines Steuerberaters: "Das können sie frei wählen".

Dies bedeutet also: Der Transfer zwischen Depots muss tatsächlich (nachweisbar) stattgefunden haben (Nachweis im Falle mtGox ist einfach: die Historie enthält ja "withdraw" und "deposit" events, die blockchain muss nicht bemüht werden, das FA kann gegebenenfalls die Daten von mtGox anfordern und alles prüfen). D.h: transfer zwischen Depots kann nicht "nachträglich" rein buchhalterisch gemacht werden. Was allerdings erst in der Buchhaltung festgelegt werden muss ist die Auswahl des Topfes und hier entsteht natürlich großes "Optimierungspotential" (wg. Unterschiedlichen Kaufpreisen und natürlich der 1-jährigen Haltefrist)

Und nun?

Ich will jetzt einfach mal versuchen für meinen Fall alle Möglichkeiten durchzuspielen. Das ist natürlich recht aufwendig und ich dachte mir ich teile mal 'ne kleine Anleitung und Scripte mit euch:


Datenbank erstellen

Erstmal brauchen wir 'ne Datenbank. Ich nehm hier Postgres:

Code:

bash$ psql postgres
postgres=# create database bitbuch;
postgres=# <CTRL-D>
bash$ psql bitbuch
bitbuch=# 

Datenimport

Ich verteile die Beschreibung der Datenimports auf einzelne posts und verlinke diese hier:

• mtgox
• bitcoin.de
• Bitcoin Central

Dannach kontrollieren wir jewils ob's gut aussieht und kriegen auch schon summarische Ergebnisse. ('mtgox' ggf mit 'intersango', 'bitcoin.de', etc... ersetzen)

Code:

bitbuch=# select * from trades where exchange = 'mtgox' order by datum limit 10;

bitbuch=# select extract(year from datum) as y, sum(delta_BTC) as BTC, sum(delta_fiat) as fiat, sum(fee_BTC) as fee_BTC, sum(fee_fiat) as fee_fiat
from trades where exchange = 'mtgox' group by y order by y asc;

bitbuch=# select extract(year from datum) as y, extract(month from datum) as m, sum(delta_BTC) as BTC, sum(delta_fiat) as fiat, sum(fee_BTC) as fee_BTC, sum(fee_fiat) as fee_fiat from trades where exchange = 'mtgox' group by y, m order by y, m asc;

Wechselkurse anwenden

Dieser Post beschreibt den Import von Wechselkursen (gegnüber USD). Das durchführen, dann können wir die _EUR-Spalten der trades-tabelle befüllen:

Code:

bitbuch=> update trades t set delta_eur = null, fee_eur = null;
bitbuch=> update trades t set delta_eur = t.delta_fiat / r.rate, fee_eur = t.fee_fiat / r.rate from rate r where t.fiat_currency = 'USD' and r.currency = 'EUR' and r.datum = t.datum::date;
bitbuch=> update trades t set delta_eur = (t.delta_fiat / r1.rate) * r2.rate, fee_eur = (t.fee_fiat / r1.rate) * r2.rate from rate r1, rate r2 where t.fiat_currency <> 'USD' and r1.currency = t.fiat_currency and r2.currency = 'EUR' and r1.datum = t.datum::date and r2.datum = t.datum::date;

und schauen, ob alle Einträge erwischt wurden:

Code:

bitbuch=> select * from trades t where delta_eur is null or fee_eur is null; -- should return 0 rows

(hier sollten 0 Ergebnisse kommen)

Buchhaltung (fifo oder lifo) durchführen

Nun kommt ein script zum einsatz, welches die [f|l]ifo-Buchhaltung durchführt. Zunächst braucht man aber "node" (node js) und ein paar abhängigkeiten, welche mit npm installiert werden können.

Code:

bash$ npm install moment  pg  request

Dann buchhalt.js downloaden und starten

Code:

bash$ wget http://slf-software.de/buchhalt.js
bash$ node buchhalt.js

Am Anfang von buchhalt.js kann man ein paar sachen konfigurieren, z.B. "method" ("fifo" oder "lifo").

Das Ding führt dann die Buchhaltung mit den Töpfen durch und schreibt ein csv-file weg ("out.csv"), in welchen die einzelnen Käufe und Verkäufe (mit ermitteltem Gewinn) ausweist. Des weiteren werden die 3 ältesten (bei fifo) oder neuesten (bei lifo) Töpfe ausgewiesen.

Das CSV mit office aufmachen (Trennzeichen: ",") und die Gewinn-Spalte aufsummieren (pro Jahr per autofilter oder sonstwie) ergibt dann ohne jegliche Gewähr den zu versteuernden Gewinn. Ich würde mich freuen, wenn jemand die Korrektheit nachvollziehen könnte.

Was noch fehlt bzw. nicht berücksichtigt ist:

• handling getrennte Depot-Führung
• beachtung der Haltefrist (momentan wird alles als Steuerpflichtig angesehen)
• Behandlung von Gebühren (?)
• Umrechnung Gewinn nach EUR laut Tageskurs EUR/USD
• import Daten intersango, bitcoin-central, bitcoin.de,...

Ich hoffe jemand hat hierfür Verwendung. Vielleicht steuert jemand auch was bei... z.B. import-code für andere Exchanges oder sogar Geld? (donation address: 1Cdx9apmXESPNdXik3e64LbgtoyYTUNwLm). Bin ausserdem für jeden Kommentar oder Bug-Report dankbar!


EDIT:

• 13.11.2013: change type of datum from date -> timestamp
• 13.11.2013: Datenimport mtGox in separaten Post ausgelagert
• 13.11.2013: Beschreibung Anwendung Wechselkurse hinzugefügt
• 24.11.2013: Adding bitcoin.de, Bitcoin Central imports

Scripts sind outdated, ich hab neue, bessere. Wenn jemand ernsthaft interesse anmeldet, werde ich die Sachen hier updaten

[molecular]

reserved

[Ente]

..ich glaube, auf dem Level betrittst du hier Neuland, vermutlich werden eher wenige Forenleser direkt ähnliches umsetzen.

Um mal für den Laien bei Null anzufangen: Es geht darum, Gewinne aus Tradinggeschäften bei MtGox buchhaltärisch zu erfassen, um sie plausibel und nachweisbar in die Buchhaltung oder STeuererklärung einbinden zu können?

Sehr wertvolle Arbeit, dankeschön!

Ente

[molecular]

..ich glaube, auf dem Level betrittst du hier Neuland, vermutlich werden eher wenige Forenleser direkt ähnliches umsetzen.

lol. Ich hätte schon früher gepostet, musste aber erst meine Eltern anrufen und ihnen erzählen, daß ich ich Pionier in Sachen Buchhaltung und Steuerangelegenheiten bin. Ich glaube die lachen immer noch. Ich hab dann einfach aufgelegt.

Aber im ernst: das dürfte eigentlich kein Neuland sein (höchstens in Bezug auf Bitcoin). Leute die mit Aktien oder sonstwas handeln müssen das ja schliesslich auch irgendwie machen. Da wird's also wohl software geben. Da ich aber selber coden kann, mach ich's lieber selbst... da weiss man was man hat.

Um mal für den Laien bei Null anzufangen: Es geht darum, Gewinne aus Tradinggeschäften bei MtGox buchhaltärisch zu erfassen, um sie plausibel und nachweisbar in die Buchhaltung oder STeuererklärung einbinden zu können?

Genau. Ausserdem geht es darum, Werkzeuge zur verfügung zu haben, welche erlauben die Parameter dieser Erfassung möglichst optimal festzulegen.

Am Ende kommt im Prinzip nur pro Jahr eine Zahl raus (vielleicht sogar "0"), aber wenn die Jungs vom FA prüfen, dann will ich vorbereitet sein.

Es gab 2 wirklich unangenehme Situationen in meinem Leben: das eine mal war ich pleite und das andere mal hatte ich 'ne Anzeige wegen Steuerverkürzung. Es war sehr teuer, unangenehm und aufwendig das Problem wieder loszuwerden (es geht nicht von selber weg sondern wird durch Ignorieren nur schlimmer) und ich habe daraus gelernt.

Das ist jetzt auch nicht gerade schön diesen Kram hier zu machen und ich will auch eigentlich niemanden dazu bewegen selbiges zu tun, aber in meinem Fall hab ich entschieden, daß es halt sein muss. Es kann auch alles "gut gehen" wenn man einfach nix macht, aber die Eier hab ich nicht.

Um keine Zweifel aufkommen zu lassen: Ich bin nicht gerade ein Anhänger von Steuern, Staat und Bürokratie. Aber ihr wisst ja: Waffengewalt und Freiheitsentzug und so. Man will ja handlungsfähig bleiben und so muss ich wohl - bis auf weiteres (an dieser Stelle gibt's zu tun) - diesen Mist machen.

Sehr wertvolle Arbeit, dankeschön!

Danke! Ich drücke mich gerade davor weiterzumachen, aber ich kann versichern: es wird updates geben.

[oda.krell]

Hey molecular

Danke für den Link zu deinem thread. Hier ist mein eigener, im dt. Spekulations-Forum... sind aber bisher noch keine Antworten gekommen :D

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.

Wenn du erlaubst, ein, zwei Fragen:

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?

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.


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.

[molecular]

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.

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.

[oda.krell]

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.

[molecular]

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

[molecular]

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:

• 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;

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
;

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

schön, oder?

EDIT: added primary key to rate table

[Polarstorm]

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.

[molecular]

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.

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.

[molecular]

hab mal in OP hingeschrieben was fifo und lifo heisst:

(FIFO heisst: First In First Out, LIFO: Last In First Out)

[Chefin]

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.

[candoo]

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.

[oda.krell]

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.

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.

[molecular]

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.

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?

[molecular]

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.

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.

[Polarstorm]

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.

[Sukrim]

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.

[molecular]

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.

ok, gut zu wissen. Danke für das Angebot.

Ist aber unwahrscheinlich.