Beancount: Double-entry accounting from text files

Transactions with a specific regex payee need to be reclassified into a specific expense account. Yes, I could write a sed script to do this. No, I will not write a sed script to do this.

My company and I have been using Beancount since 2017 for all financial records. My company has about 60 employees and there are three individuals working in/on the financials regularly. Beancount (plaintext accounting) was the only solution that worked for us. We have many hundreds of thousands of transactions. We do both cash basis accounting (personal) and accrual accounting (company). We use Sublime Text with the Beancount plugin along with Git for version control.

In the beginning we--like virtually anyone else doing accounting--used QuickBooks. As we grew QuickBooks was less and less of a solution because of the issues we had with multi-user collaboration along with historical/rollback change tracking, e.g. knowing who made what change where and when. In other words, we started to outgrow QB. Further, there were lots of accounting needs we had where QB continued to fall short and get in the way.

We started to look around at various proprietary and open-source systems which were either locally installed or cloud hosted. Local installations came with problems surrounding collaboration and OS compatibility (Mac/Linux/Windows users) while cloud-hosted ones had issues around durability or longevity of the underlying company and sub-par data entry latency.

Further, we had additional needs including strong tracking of cost basis, alternate currencies, the concept of "lots" (FIFO/LIFO/cost averaging) of stock sales, short/long capital gain/loss, along with cost of goods sold, among other things. Finally, we wanted to get away from all paper records entirely meaning that any paper receipts would be scanned and tracked alongside the corresponding transaction which helped with collaboration because it made researching a transaction easier. (The receipt tracking we did via a customer document meta tag along with an associated ID attached to that tag residing in each transaction.)

As a software development company, we aren't afraid of a little bit of code and so the idea of a simple, plaintext accounting system with version control really appealed to us. The strongest contender that fit the model of our specific requirements was Beancount among all of the ledger-based derivatives. We've been very pleased with our results.

For our taxes, we do an HTML export of the financials using "bean-bake" and our CPA can navigate our financials without trouble. We use Fava (a Beancount web GUI) for various reports.

One place where Beancount really shines is the ability to edit multiple transactions at a time. Because it's just simple text files, you can easily use the "multiple cursors" option to make bulk edits or you can do simple search/replace. Because of Git-based checkpoints, there's no worry that we're going to break someone else while experimenting with an idea of how to express a given concept or the meaning of a set of transactions in the financial records.

That said, one place where Beancount still needs some polish is on the reporting side. Even with Fava, getting reports has never been as easy as QB. It often takes a little bit of Beancount SQL (SQL-like) querying to get the data you want. For getting loans and other things where paper-based reports are required this can require a bit of extra time.

Another weak point (at first) was for transaction import. This was soon overcome as we wrote some code that uses OFXTools to bring in all the credit card and banking transactions and to write them to the appropriate text files and then we go back through and categorize.

One last thing to mention is that, while the core business logic for Beancount is sound and far more capable than any other accounting program we have experienced, I can see how the choice of Python (or more specifically parsing of large text files with Python) can start to be problematic in terms of performance and delay. We're seeing the slowdown a little but it's not terribly inconvenient and doesn't interrupt the workflow. It's more akin to the compile time for a small application, e.g. 2+ seconds. I could see file-based checksum/caching into an internal binary/proprietary format helping quite a bit--kind of like those annoying little python .pyc files that show up when you execute Python.

Technically yes you are correct.

But the intention of your parent was "when funds start to co-mingle or you get more complicated accounts" and saying "Don't co-mingle" doesn't help answer the question for those who do co-mingle and asked for help in this thread.

All of my high-volume (in terms of number of transactions) accounts are easily importable. There are a few that don't have great import functionality, but I only have 1-2 transactions on them a month so haven't felt the toil pain to better automate them. 1-2 hours a month of balancing is not worth optimizing down to 0.5-1 hour to me.

Is there a good way to use Beancount to handle inventory stock levels in/out?