Advice on alternative accounting system for trading (including daytrading)

[Marcio A. Vianna F. (mvianna)]

Hi, all.

Are you aware of accounting software targeted at a similar audience as Beancount, but meant for trading taxes, tracking and accounting? In common with Beancount, desirable features would be:

* flexible (customizable)

* extensible

* python

* for small businesses or personal use

* scalable at least to a certain point

All solutions I find on the internet are too limiting and may demand worksome workarounds.

The issue has been brought up some times on this board and it seems it is now acknowledged that this kind of application isn't in the scope of Beancount or its future developments (correct me if I'm wrong). I've been away from Beancount for some years, so that I cannot recall exactly what made Beancount a less-than-perfect fit for trading, but I think two needed features would be: time of transaction, mean value of inventories, inventories with negative balance (short positions). I could give up the plain-text advantages for sqlite or other rdms if needed.

Any tips in this regard?

Many thanks.

Marcio

[Marcio A. Vianna F. (mvianna)]

Just to make it clear: I've been thinking of using Beancount for general personal finance (tracking expenses, earnings etc.), with investment portfolio lumped up as "holdings" or so. These "holdings" would be updated from time to time with profits/losses or profit/losses accrued. Only the details of the actual single trades would have to be managed in the other application.

Marcio

[Martin Blais]

I've developed Johnny for that purpose (https://github.com/edgebips/johnny), in the context of retail trading (not pro).

It's not really in a state that's easy for others to use TBH. 

In theory it could be, but if you used it you'd be 90% sure to his some corner case that's not supported, e.g. some transaction type I've never encountered and don't support.

Broadly speaking, for that use case you need 

- more sophisticated transaction types wit some common fields

- the volume of transactions is such you'd want this in a table format, one line per transaction, ideally going to a database. Beancount is designed to be user-editable and too verbose.

- you'd also want to automate everything (ingest the data from your brokers, normalize it in the same schema, etc) with as little manual intervention as possible.

- Beancount doesn't handle derivatives with multipliers too great right now (futures and options), you have to multiply by hand, its symbology has to be extended to support that (Johnny does that fine)

So Beancount is fine for investments, say ~100 equities or funds positions with dividends and monthly transactions, but when you're talking about 1k-100k or more trades/month - still retail level but a bit more dedicated - Beancount isn't a great solution for that.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/71915cd3-429c-4d74-98d6-57b5586c3e08n%40googlegroups.com.

[Marcio A. Vianna Fº]

Hi, Martin,

Thanks for taking the time to answer.

I think I have already, but will again have a look at johnny.

Regards.

Marcio

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPLuq8SfPg3LL2Q9XpjDFzqkMj%2BpS1CiyEscnwqCnMpmA%40mail.gmail.com.

[Jakov Perica]

Does a more production ready alternative to johhny exist?

[Fang-Pen Lin]

Personally, I trade some stock options, and I'm also thinking about making my trade records automatically ingested into my beancount books. The frequency is fairly low for me, so it probably is lower than the day trader's volume. I haven't spent too much effort on this end yet, but I built beanhub-import and open-sourced it a while back, and I think it could help your case a little bit on the importing part:

https://github.com/LaunchPlatform/beanhub-import

It's a rule-based beancount import engine designed to act like a data pipeline system. As long as you can export your trading records as a CSV file or any other machine-readable format, you should be able to build your own beanhub-extract extractor class to help read the transactions from the file. I envision you can write beanhub-import rules to ingest your trading records like this:

inputs:
  - match: "import-data/my_broker/*.csv"
    config:
      extractor: my_broker
      default_file: "books/{{ date.year }}.bean"
      prepend_postings:
        - account: Assets:Bank:US:MyBank
          amount:
            number: "{{ amount }}"
            currency: "{{ currency | default('USD', true) }}"

imports:
  - name: Injest trading records
    match:
      extractor: my_broker
    actions:
      - file: "books/{{ date.year }}/{{ date.month }}.bean"
        txn:
          narration: "Trade stock {{ symbol }}"
          metadata:
          - name: "margin"
            value: "{{ margin }}"
          postings:
            - account: "Assets:Bank:US:MyBroker"
              amount:
                number: "{{ -amount / stock_price }}"
                currency: "{{ symbol }}"
              price:
                number: "{{ stock_price }}"
                currency: "USD"

Then, when you have the data updated in the import folder, you can run the import command (you need to install beanhub-cli):

bh import

You should have new transactions generated and updated automatically for you like this:

2024-07-03 * "Trade stock TESLA"
  import-id: "437826b4-be1a-48fa-8c43-b387b46fed80"
  import-src: "import-data/my_broker/2024-07-03.csv"
  margin: false
  Assets:Bank:US:MyBroker                     15.00 TESLA @ 247.38 USD
  Assets:Bank:US:MyBank                    -3710.70 USD

As you can see, the transaction can be added with extra metadata like the "margin" flag in the example, so some extra trading relative info could be added for your other plugin to process them. Currently, you can insert transactions to simply buy and sell stock like that, but for options, there are expiring dates and strike prices. Sometimes, there could be a combination of options for different strategies, making simple stock symbols like TESLA insufficient. I am considering using a cost label lot, but I wonder if that would be enough for the particular use cases. Like this:

2024-07-03 * "Trade stock TESLA option $195 PUT 7/15"
  import-id: "437826b4-be1a-48fa-8c43-b387b46fed80"
  import-src: "import-data/my_broker/2024-07-03.csv"
  margin: false
  Assets:Bank:US:MyBroker                     15.00 TESLA {"$195-PUT-7/5"} @ 247.38 USD
  Assets:Bank:US:MyBank                    -3710.70 USD

I am still deciding what the best practice is for trading complex options.

Are you trading stocks, options, or other commodities? Is the beanhub-import example I just showed you good enough for data importing for your use case? If you have some use cases that I think make sense to add, I might be able to add a few features to beanhub-import to help make your data importing much easier.

[Chary Chary]

On Thursday, July 4, 2024 at 3:12:56 AM UTC+2 Fang-Pen Lin wrote:

 I haven't spent too much effort on this end yet, but I built beanhub-import and open-sourced it a while back, and I think it could help your case a little bit on the importing part:

https://github.com/LaunchPlatform/beanhub-import

It's a rule-based beancount import engine designed to act like a data pipeline system. As long as you can export your trading records as a CSV file or any other machine-readable format, you should be able to build your own beanhub-extract extractor class to help read the transactions from the file. I envision you can write beanhub-import rules to ingest your trading records like this:

So, the beanhub-import seems to be another tool in the family of beangulp  and red's importers

https://groups.google.com/g/beancount/c/X7BkR7sHmHk/m/o1-hNWjpCAAJ

I haven't experimented yet with any of these tools but as I see one of the unique features of your tool are

• Auto-update existing transactions - When you update the rules or data, corresponding Beancount transactions will be updated automatically.
• Auto-move transactions to a different file - When you change the rules to output the transactions to a different file, it will automatically remove the old ones and add the new ones for you

 Am I correct?

[Martin Blais]

BTW, related to trading inputs, here's an odd idea I had: to support a table/CSV-like syntax in Beancount itself.

A set of accounts would have to be configured for a block, and the columns would dictate which accounts the numbers in columns are booked for.

This would provide a pretty compact yet still readable syntax for more dense sets of transactions.

Just a thought,

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/7fd78b28-53ad-4d1d-ae95-8f2dd38f0307n%40googlegroups.com.

[Fang-Pen Lin]

Yeah, so beanhub-import is somewhat similar to other importers, but one major difference is that it will parse existing Beancount files and manipulate them directly. It's taking a more data pipeline approach compared to other importers:



Personally, I like a declarative approach more because if I ever want to change the inserted transactions, I can modify the rule and rerun the import command. I recommend checking out the demo repository and try it out here:

https://github.com/LaunchPlatform/beanhub-import-demo

I have prepared some mock data and sample rules in the repository already. You should be able to change the import rules, rerun import, and run git diff to see the difference you made with the changes.

[Chary Chary]

On Monday, July 8, 2024 at 6:02:28 AM UTC+2 Fang-Pen Lin wrote:

Personally, I like a declarative approach more because if I ever want to change the inserted transactions, I can modify the rule and rerun the import command. 

I think this is one of the downsides of pure   PTA approach, as it is quite difficult to refactor data. Nice that you have a solution for it.

I personally  still maintain my data in spreadsheets and have scripts which extract relevant data and produce *.bean files. So, for me *.bean files are to large extent intermittent human-readable format, not the prime source I keep my data in.