Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plain Text Accounting (PTA)

plaintextaccounting.org

Post reply on HN
Print view View original

11–20 of 123 posts

Re: Plain Text Accounting (PTA)

#11

Post by tonetegeatinst »

viraptor wrote: post #7
RivieraKid wrote: post #2

I've been using Beancount, really enjoyed learning it, writing tools for data import and having a hands-on experience with accounting. But it's been almost a year since I last imported data, I planned to do it monthly but it's a bit of a chore (it takes 30 to 60 mins despite a lot of it being automated).

I wish banks weren't actively sabotaging data export. I wrote some scripts for this in the past, reverse engineered the login with OCR, cleaned up the invalid entries, but... It's just too much effort to maintain this. Once the mobile confirmation started being required, I just gave up.

Wish their was a standard data format that all banks would use.

Re: Plain Text Accounting (PTA)

#14

Post by markgall »

bickfordb wrote: post #9
viraptor wrote: post #7

Earlier quoted context omitted.

I wish banks weren't actively sabotaging data export. I wrote some scripts for this in the past, reverse engineered the login with OCR, cleaned up the invalid entries, but... It's just too much effort to maintain this. Once the mobile confirmation started being required, I just gave up.

I use beancount and I use ofxget for some accounts and then keep a CSV archive for the rest and wrote some scripts to sync them into beancount when a new file shows up. It's annoying to download everything and keep it organized, but it gives me better piece of mind than all the other SaSS accounting systems

I've found that so few of my accounts support ofxget that it's not worth the trouble of dealing with it. I just occasionally download year-to-date statements from all my accounts and then run scripts to convert them to ledger format and append only the things after a given cutoff date (things like the credit card script are pretty interactive so I don't want to overwrite the old data). To know which accounts are in most dire need of a check, I have a script that shows the last transaction on each statement-generating account.

This basically works for me and catching up doesn't really take long. There are some accounts that I update very infrequently, but I've gotten over my OCD about this and it doesn't really matter. My wife doesn't appreciate being hassled for the statement from her work HSA every month -- nor does it really matter how much is in there at any given moment, unless we have a big medical expense -- so we just occasionally sit down and catch everything up, maybe twice a year.

Overall I find the automation means it's vastly less work than when I used gnucash, and the flexibility in expense structures and ease of assigning things mean I have much better budget data than when I used mint.com.

Re: Plain Text Accounting (PTA)

#15

Post by viraptor »

tonetegeatinst wrote: post #11
viraptor wrote: post #7

Earlier quoted context omitted.

I wish banks weren't actively sabotaging data export. I wrote some scripts for this in the past, reverse engineered the login with OCR, cleaned up the invalid entries, but... It's just too much effort to maintain this. Once the mobile confirmation started being required, I just gave up.

Wish their was a standard data format that all banks would use.

The format exists - OFX https://en.wikipedia.org/wiki/Open_Financial_Exchange

But even banks that use it make massive mistakes and break the basic assumptions. Unique ID repeating in the same day for example. Or using the minutes in place of the month...

Re: Plain Text Accounting (PTA)

#16

Post by XorNot »

candiddevmike wrote: post #4

I'd embrace plain text accounting more if it had a better schema. Ledger's is absolutely atrocious, and it drives my OCD nuts trying to use vim to "write" accounting entries. I think my ideal PTA would be some kind of jsonnet-based system where I can create/call functions to generate journal entries.

For a time I threw together a bunch of python scripts which did billing for me based on YAML files which struck a nice balance of readability vs programmability (since YAML turns into lines quite well and has less special character noise).

Re: Plain Text Accounting (PTA)

#17

Post by markgall »

binary132 wrote: post #12

First thing that came to mind was org-mode’s tables, which are great. This feels like an Emacs package suite just waiting to happen....

There is ledger-mode and beancount-mode which are both nice (depending on which program you use). I would say the majority of what I do in practice Python scripts to convert statements to ledger; the amount of stuff I do by hand is minimal enough that it would be easy to live without the emacs mode.

Re: Plain Text Accounting (PTA)

#19

Post by alchemist1e9 »

I use ledger for all bookkeeping and accounting for personal and many LLCs. If you’re a terminal rat and cli master, use vim or emacs, sed/awk know the basics, script in bash/python/perl/ruby regularly then just learn ledger and double entry accounting and switch to it and I suspect you will be much happier than whatever you are doing today.

A few basic tips:

- reckon is helpful for importing transactions quickly. https://github.com/cantino/reckon

- use “include” to break up the problem.

- bal —-dc is something US accountants might recognize a bit. but more likely than not they are incapable of understanding negatives correctly in the way ledger uses them, so easier to just write a few scripts to convert it to DR CR style for them. I’ve been shocked at how little abstraction accountants I’ve dealt with are capable of.

Re: Plain Text Accounting (PTA)

#20

Post by alchemist1e9 »

felixc wrote: post #13

I've written a series of posts on practical "recipes" for how to use Ledger (one of the leading plain text accounting systems) effectively in more complex situations beyond the basic tutorials: https://felixcrux.com/blog/ledger-practices

As a heavy ledger user these are great recipes in my opinion.

Since you’re here and clearly you know ledger well I’ll share a pattern I have that perhaps is a good idea or perhaps has an alternative approach.

We need to track customers and suppliers carefully and then assign payments both made and received to specific projects and categories within those projects. Invoices can contain a mix of these projects in either direction. So our workflow is:

- assign transactions to an account labeled by the counterparty when imported from bank account transactions.

- a script uses ledger print command and creates a 2nd journal file for each counterparty with a mirror transaction inverting the original transaction out of the counterparty account and into an Unknown project and Unknown category sub account as a place holder.

- transactions are then matched by bookkeeper to specific invoices and then assigned to Project:Category accounts in the counterparty journal file. transactions will be split if it’s needed at this point. so a single payment can be split to multiple Project:Category accounts.

- by including all bank transaction journals and all counterparty journals then ledger bal command show if all transactions have been processed by bookkeeping.

Post reply on HN