US taxes in python and beancount

[redst...@gmail.com]

Just wanted to share, for users in the US:

I've used this python-taxes code from user davidcmoore for several years now together with beancount, primarily to generate tax forms including a W2. The package includes several advanced federal tax forms (and California forms if you live there). I have a bridge script that passes on numbers from beancount queries as input to python-taxes.

I don't use it to file taxes, but rather, to verify my taxes computed using other means, and to estimate taxes to make payments and such. In the last 3-4 years, this process has yielded with very little time spent, numbers that are the same or close enough to make it very useful in verification and estimation.

Of course, there are fundamental limitations. Eg: foreign taxes paid via investments, qualified dividends, tax exempt interest, etc. are typically not stored in beancount. For these, a quick approximation based on past years works surprisingly well for the purposes of estimation.

[Martin Blais]

Very cool.

I've been dreaming of something like this, but that would accept a large protobuf instead of being embedded in code.

Combine that with some offline thing that could insert numbers render on top of a PDF and that's something powerful.

--
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/5f51d89b-411b-48ae-ace9-2119ad2a8063n%40googlegroups.com.

[Chris Hasenpflug]

I would be very curious to know more about how you've set up beancount with all the appropriate categories to feed in as part of your script. I imagine the W2/wage work is pretty straight forward, but things like taxable investing (even without the foreign component) and LT vs . ST would be interesting to see how you've approached.

[Red S]

Great questions. It's all fundamentally very straightforward, but there are plenty of ideas and gotchas that would save time for anyone building this for the first time for themselves. I'll do a short writeup soon, and post here.

[Red S]

Here is the write-up. I hope this is useful. Constructive feedback appreciated.

I'd also be interested in hearing about tax situations that you are able to, or not able to solve by leveraging Beancount. Feel free to leave questions and comments on that page (github account required), or post here in this thread.

[Red S]

PS: my code is also linked to from the article below. Hope it helps.

[Chris Hasenpflug]

Thanks for the write-up, Red! I'm still working on putting some of your other automation tips/tricks in play, but this is all very helpful to keep in mind.

> Long vs short capital gains: for my personal circumstances, I don’t have a need to automate whether to book a sale (or part of it) to long or short term gains. If you do, I’d imagine it should be easy to write a plugin to automate this. Please do share it if you do :).

Of course this is one of the pieces I was interested in how you managed! :) 

[Red S]

Thanks for the write-up, Red! I'm still working on putting some of your other automation tips/tricks in play, but this is all very helpful to keep in mind.

You're welcome, and glad these are helpful!

 

> Long vs short capital gains: for my personal circumstances, I don’t have a need to automate whether to book a sale (or part of it) to long or short term gains. If you do, I’d imagine it should be easy to write a plugin to automate this. Please do share it if you do :).

Of course this is one of the pieces I was interested in how you managed! :)

I just finished an experimental plugin to do this. See the long_short plugin here. Warning: it needs more testing, doesn't work for leap years.

[Chris Hasenpflug]

Dang, you work fast!  Thanks again, Red!

[Red S]

Of course!

[Red S]

Just wanted share that I did my usual end of the year ballpark estimate of taxes owed and tax bracket for planning. It took me all of two minutes. I used 2021's code for the python-taxes part, which is close enough for this part.

Hope this serves as encouragement to get your own taxes-with-beancount setup.

On Saturday, April 23, 2022 at 6:10:57 PM UTC-7 Red S wrote:

[cha...@gmail.com]

This is really neat. A couple things I've noted from doing mine:

• I split my tax expenses like Expenses:Taxes:TY{tax-year}:Federal:(Income|Medicare|SS). I think this is helpful especially if you either get a large refund or pay a large tax bill when filing so you can allocate taxes paid to the tax year rather than calendar year which they are paid or received.
• I see this as being really useful for helping you figure out around the beginning of Q4 how much additional you need to withhold to get into the income tax safe harbor in order to not pay a penalty if you will have a tax bill due come April.

Thanks for another good use case Red!

[Red S]

You hit a couple of very good points. Not sure if you had a chance to read the article in full, but I cover them both there:

Article: Computing Taxes with Beancount

This is really neat. A couple things I've noted from doing mine:

• I split my tax expenses like Expenses:Taxes:TY{tax-year}:Federal:(Income|Medicare|SS). I think this is helpful especially if you either get a large refund or pay a large tax bill when filing so you can allocate taxes paid to the tax year rather than calendar year which they are paid or received.

Agree, solving this problem is very much a necessity to ensure things stay simple, clean, and queriable. I do it via the approach below though. Compared to the Expenses:Taxes:TY{tax-year}:* approach, it is automation friendly for imports. I.e., you don't have to update or code your importer to book your paychecks to the current year. You only have to fix the one or two exceptions like refunds or payments. Anyway, either approach works fine :). From the article:

I use my effective_date plugin to book every single Expense posting related to a tax year, in that tax year. Doing so is key to keeping queries simple and maintainable. Eg:

2020-05-15 * "2019 Federal refund received"

     Assets:Bank 10 USD

     Expenses:Federal-Income-Tax:Refund

       effective_date: 2019-12-31

 

• I see this as being really useful for helping you figure out around the beginning of Q4 how much additional you need to withhold to get into the income tax safe harbor in order to not pay a penalty if you will have a tax bill due come April.

Totally---that's actually precisely the primary reason I started doing this a few years ago. So it's the very first bullet I mention in the article:

I don’t use this setup to file taxes, given the complexity of keeping up with forms and the law each year. Instead, I use it for:

• estimating taxes, including to make estimated payments
• ...

 

Thanks for another good use case Red!

Of course, glad it's helpful :).

[Red S]

Missed this from long ago. Indeed, that would be awesome. It would produce something that's ready to file with almost no effort. 

However, it seems like the larger challenge with any tax preparation software that one can use to file, is ensuring that it is up to date with tax law and constant changes. A widely used open source effort would do it. Building something open source that gets widely used is of course the challenge. I imagine it would need either a supporting business model, or a set of dedicated accounting + tax prep + software experts to volunteer their time. Even better (and even more impossible) would be extreme simplification of the tax code.