4 ms·

With Beancount, I use metadata tags in my chart of accounts for the tax form and line number, e.g. 2017-01-01 open Expenses:GA:Insurance USD tax_form: "1

by dpifke 3y ago

With Beancount, I use metadata tags in my chart of accounts for the tax form and line number, e.g. 2017-01-01 open Expenses:GA:Insurance USD tax_form: "1040 Schedule C" tax_line: "15" tax_description: "Insurance (other than health)" I can then report my transactions based on the tax_form and tax_line attribute, which gets me much of the way there. I still have to do the math on derived lines on the forms, but this at least makes sure the inputs are gathered correctly. Being able to write comments is also super-useful. A real life example: ; We can make a "Section 1.263(a)-1(f) de minimis safe harbor election" to ; treat repairs and improvements to tangible property as an expense, which ; would otherwise have to be capitalized. A statement that we are making the ; election must be attached to our tax return and should include name, address, ; and Taxpayer Identification Number. Under the election, we must apply the de ; minimis safe harbor to all expenditures meeting the criteria for the election ; in the taxable year. The limit is $2,500 per invoice. ; ; https://www.irs.gov/businesses/small-businesses-self-employed/tangible-property-final-regulations 2016-01-01 open Expenses:RD:Hosting:Repairs:DeMinimis USD tax_form: "1040 Schedule C (R&E)" tax_line: "21" tax_description: "Repairs and maintenance"

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
mindslight 3y ago
Interesting idea, but wouldn't you be better off creating abstract categories and then assigning/verifying where they go at tax time? Line numbers can change from year to year.
- dpifke 3y ago
  Those are abstract categories (accounts). Transactions get assigned to accounts, then (at tax time) accounts get assigned to forms and line numbers. Remapping a transaction to a different tax line item (e.g. if tax law changes, as it did this year with § 174) is just a matter of updating the account metadata. This is much more convenient than having to go back through the books and reassign transactions to different accounts. It's plain text in Git, so I have the usual tools available. For example, `git diff` can tell me what changed between tax years, and I can check out a copy of my books as they existed at the time a past year's return was filed.
  - mindslight 3y ago
    Oh I see! I'm not familiar with Beancount syntax so I didn't realize that your example metadata pertained to an account rather than a transaction. Of course looking it at more closely that's obvious now.
sdfghswe 3y ago
I don't supposed you're also familiar with GnuCash and can compare and contrast? I've been using GnuCash for a couple of years. I like that it's free software and I control it, and I like that it stores its state in text files (XML?). That said, there's some annoyances. It's difficult to automate anything (e.g. all transactions that have a string X, should go into account Y). Also I don't think it supports labels (???!) I'm considering whether to move away from it but it would of course be a considerable investment of effort.
- dpifke 3y ago
  For me, the beauty of Beancount[0] is that it's just text files in Git. There's a web UI I use for generating reports, and a Python API with which I hacked together some import/export scripts, but 99% of my interactions with it are via Emacs[1] and Magit. GnuCash may use XML to store its data, but I'm pretty sure it's not designed around editing those XML files directly. A ton of repetitive bookkeeping tasks become so much easier when you can copy and paste, or use keyboard macros or something like multiple-cursors[2], rather than have to click tens or hundreds of times in a GUI. Many years ago I used QuickBooks, and basic tasks like importing a bank statement took at least an order of magnitude longer than they do now. Having my company's books in Git is also huge when it comes to auditing, concurrency, backups, and figuring out where things went wrong when accounts don't balance. As mentioned in another comment: `git diff` is a really powerful tool and it's awesome to be able to check out the books as they existed at a particular point in time. `git blame` is great for when you're trying to figure out where a number came from. Writing meaningful commit messages and comments keeps me sane when I try to remember a year later why something is recorded the way it is. The biggest downside—or advantage, depending on how you look at it—is that there's no default or built-in chart of accounts, so you need a certain level of accounting acumen (or professional advice) to set things up at first. I'm pretty sure GnuCash aims to be plug-and-play, whereas Beancount is more akin to a programming library that you use to build an accounting system. I agree with the grandparent commenter, who said that text-based accounting is "the best and most flexible accounting experience I've ever had." But the cost of that flexibility is that there's a fair amount of DIY involved. [0]: https://beancount.io/ https://beancount.io/ [1]: https://github.com/beancount/beancount-mode https://github.com/beancount/beancount-mode [2]: https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el

by dpifke 3y ago

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

mindslight 3y ago

Interesting idea, but wouldn't you be better off creating abstract categories and then assigning/verifying where they go at tax time? Line numbers can change from year to year.

dpifke 3y ago
Those are abstract categories (accounts). Transactions get assigned to accounts, then (at tax time) accounts get assigned to forms and line numbers. Remapping a transaction to a different tax line item (e.g. if tax law changes, as it did this year with § 174) is just a matter of updating the account metadata. This is much more convenient than having to go back through the books and reassign transactions to different accounts. It's plain text in Git, so I have the usual tools available. For example, `git diff` can tell me what changed between tax years, and I can check out a copy of my books as they existed at the time a past year's return was filed.
- mindslight 3y ago
  Oh I see! I'm not familiar with Beancount syntax so I didn't realize that your example metadata pertained to an account rather than a transaction. Of course looking it at more closely that's obvious now.

sdfghswe 3y ago

I don't supposed you're also familiar with GnuCash and can compare and contrast? I've been using GnuCash for a couple of years. I like that it's free software and I control it, and I like that it stores its state in text files (XML?). That said, there's some annoyances. It's difficult to automate anything (e.g. all transactions that have a string X, should go into account Y). Also I don't think it supports labels (???!) I'm considering whether to move away from it but it would of course be a considerable investment of effort.

dpifke 3y ago
For me, the beauty of Beancount[0] is that it's just text files in Git. There's a web UI I use for generating reports, and a Python API with which I hacked together some import/export scripts, but 99% of my interactions with it are via Emacs[1] and Magit. GnuCash may use XML to store its data, but I'm pretty sure it's not designed around editing those XML files directly. A ton of repetitive bookkeeping tasks become so much easier when you can copy and paste, or use keyboard macros or something like multiple-cursors[2], rather than have to click tens or hundreds of times in a GUI. Many years ago I used QuickBooks, and basic tasks like importing a bank statement took at least an order of magnitude longer than they do now. Having my company's books in Git is also huge when it comes to auditing, concurrency, backups, and figuring out where things went wrong when accounts don't balance. As mentioned in another comment: `git diff` is a really powerful tool and it's awesome to be able to check out the books as they existed at a particular point in time. `git blame` is great for when you're trying to figure out where a number came from. Writing meaningful commit messages and comments keeps me sane when I try to remember a year later why something is recorded the way it is. The biggest downside—or advantage, depending on how you look at it—is that there's no default or built-in chart of accounts, so you need a certain level of accounting acumen (or professional advice) to set things up at first. I'm pretty sure GnuCash aims to be plug-and-play, whereas Beancount is more akin to a programming library that you use to build an accounting system. I agree with the grandparent commenter, who said that text-based accounting is "the best and most flexible accounting experience I've ever had." But the cost of that flexibility is that there's a fair amount of DIY involved. [0]: https://beancount.io/ https://beancount.io/ [1]: https://github.com/beancount/beancount-mode https://github.com/beancount/beancount-mode [2]: https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el