Plain Text Accounting

quote:

---

you could use .csv files or tab delimiters and build your own DB.

---

You absolutely could. The plain text format is pretty much the same, except it uses double-space as a delimiter. However, making your data fit into a spreadsheet is constricting. Putting your data into cells adds structure at the expense of flexibility. What is the benefit of that little bit of added structure, given that the plain text format is already well-structured and readable?

The only advantage that I can think of to storing PTA data in a spreadsheet would be if you want to do some calcs, but that is the anti-PTA way of doing calcs. As an example regarding flexibility, the PTA format allows values of the form "5 @ $2.50". PTA tools know that is equal to $12.50, but typical spreadsheet software does not.

The whole idea is quite well thought out, and it was devised by people who used to use spreadsheets for accounting, but ran into its limitations. If you absolutely must use spreadsheet software on your data, there is nothing preventing you from writing a script to export PTA data to something more spreadsheet friendly. In fact, I would be surprised if such a tool doesn't already exist. That is the intent behind the idea... the data is software agnostic.

Computer accounting circa 1980? Might work for a very small business. Other than simple “reporting” it would suck. Your program would literally have to read the whole file to get the “marked” data vs an indexed db and sql in a dbms. At scale your flat file query would take a very long time and utilize more resources than necessary. Makes no sense in reality though, bc to “try” to get the level of efficiency and reporting with a dbms and say Crystal , you would essentially be creating your own half arse dbms like system to manage all those text files. Dumb in my opinion, all the way around. They would be better off coming up with a “universal” data dictionary that can be applied to any dbms.

Wait until you corrupt one of those text files or huge spreadsheets.

There is a reason we have dbms now, it is bc this type of system sucked back in the day. I would seriously hate writing the code for the accounting system part, that would be hell.

Although you could go full old school and find a 75 year old cobol programmer to write it for you.

quote:

---

Computer accounting circa 1980?

---

Plain text files are not an "old" way of doing things. They are a tool, a choice.

quote:

---

Might work for a very small business.

---

There are ways to scale it, but yeah currently the tools available are best suited to small business and personal finances. However, given that it is simply a data format, it can be scaled given developer resources.

quote:

---

Other than simple “reporting” it would suck.

---

Extremely customized reports is one of the main strengths of PTA. You, or anyone, can write a script to generate any type of report you want. The reason I started looking into this is because the reporting on consumer desktop and web-based accounting software sucks.

quote:

---

Your program would literally have to read the whole file to get the “marked” data vs an indexed db and sql in a dbms. At scale your flat file query would take a very long time and utilize more resources than necessary.

---

A dbms at its core is little more than software that loads flat files into memory to make queries faster. Nothing at all prevents you from using PTA files to do the same. The only real difference is PTA files are human readable and editable.

quote:

---

Makes no sense in reality though, bc to “try” to get the level of efficiency and reporting with a dbms and say Crystal , you would essentially be creating your own half arse dbms like system to manage all those text files. Dumb in my opinion, all the way around. They would be better off coming up with a “universal” data dictionary that can be applied to any dbms.

---

Well, that's basically what a standardized PTA format achieves. Except instead of just being adaptable to any dbms, it can be used by any tool.

quote:

---

Wait until you corrupt one of those text files or huge spreadsheets.

---

This is actually one of the major advantages of plaintext file formats - you can use version control software. This kills several birds with one stone.

1. Data backups - the repository is the original, and your local copy (as well as those of other users) is the backup. The repository can also be backed up automatically.
2. Change history with unlimited undo
3. Branch/merge - multiple users can work with the same data on their own branches. Conflicts are caught during merge.
4. You can structure your journals however it makes sense to you. One file per year. One file per account. Whatever.

quote:

---

There is a reason we have dbms now, it is bc this type of system sucked back in the day.

---

We have databases because they are a useful tool. There are many useful tools, and many more yet to be written.

quote:

---

I would seriously hate writing the code for the accounting system part, that would be hell.

---

We are only talking about a data storage format here. How you choose to work with it is up to you. And yeah, I'm sure accounting software is a bitch to write, but it's been done numerous times. And the downside to relying on software written by others, software you can't modify, is that your data is not really your data. It is locked up in a format that you can't easily convert to another format.




For me, it all boils down to simplicity. The root of all accounting is the ledger. Every transaction is recorded in the ledger, and every report imaginable is generated from the ledger. If you insist on using a dbms, that adds a whole lot of complexity. In order to read or write a transaction, you must rely on a specific piece of software. And if you want data entry to be even remotely simple, you need another piece of software to talk to the db.

It's just a different approach to an extremely common task. It has many advantages over other approaches, and any current disadvantages can and will be solved/improved with wider usage and more developer resources. Like I said, it's just a data format, and one that is flexible, human readable, and future-proof. Writing a script to import PTA data into a database, or any other system, is trivial.

quote:

---

You are comparing apples to oranges.

---

I know, and that's kind of the point.

quote:

---

Producing those general ledger entries in QuickBooks is not simple.

---

You can say that again.

quote:

---

Create the chart of accounts. Create terms. Create the items. Create the employees. Create the customers. Enter consulting time by employee and customer. Create the invoice with a due date based on terms, a bill-to address pulled from the customer table and line items pulled from the employee time entries. That is a lot of work, but it produces an actual invoice you can send to a customer.

---

The PTA approach to this is that since all of this source data is text, why can't we just store it as text? That way the tool doesn't matter, and your data is not locked into a particular system.

Also, time is a commodity just like any other, so it can be handled as such. The business buys hours from employees. Hours are transferred to a customer account. The customer buys those hours with dollars. Each of these transactions can be easily stored in a ledger.

And producing an actual invoice is trivial. With plain text source data, you can write a script to generate and send invoices any way you like. There are command line programs to generate PDF documents, with which you can gather data from wherever you like (text, images) and produce a PDF laid out exactly as you define. Print and mail. Or, you can grab the data and email it. You can send invoices via text message. Hell, you can automate a phone call that uses text to speech to let customers know when payment is due or whatever.

quote:

---

QuickBooks produces the same general ledger entries, but it collects much more information along the way. That is why the company file is “tens of megs”.

---

How big is a brand new QB company file? I honestly don't know, but if it's bigger than 100KB, that seems like a lot. I don't think I've ever seen a QB file smaller than several megs. There's just a lot of overhead there. With even modest use, say a couple dozen customers and employees and a handful of sales per day, the file can easily balloon to 100MB. It just seems excessive, complex, and unnecessary. And they are easily corruptible.

quote:

---

QuickBooks is an information system. It collects and organizes data so business owners can make informed decisions.

---

And that's great. It's a tool, but one that is married to the data that it generates. PTA is another approach to the same problem.

quote:

---

Like you said, it is a tool. And it is great if it works for you. It would not work for me and my business.

---

My intent wasn't to start an accounting package war. I just wanted to see if anyone else liked the idea.

For me, PTA fits the UNIX philosophy, which roughly means that a tool should do one thing and do it well. The result or output of one tool should be expected to be the input for another. Text is a universal interface. Complex tasks are achieved via a series of simpler tasks. It's an adaptation of the principle of Occam's Razor.

Monolithic systems should be avoided, because they inevitably lead to unnecessary complexity and ecosystem lock-in.

Accounting is only complex because it has a lot of parts. Each part is simple. The underlying data is simple. Large accounting packages gather a lot of simple data, compile them into a complex data source, then expose simple tools for the user to manipulate the data. The user's input goes back into the complex pool of data, which the software then writes back as simple data again. It's like a game of telephone with data.

It sounds great, and in a lot of ways it is. But the end result is there is a disconnect between the user and the data he ultimately generates. And that data is only accessible in the ways the specific software allows.

That may work for most people, but it doesn't sit well with me. In my perfect world, PTA would take off and a whole system of simple tools would be written from which a full accounting package could be built. There is already a significant number of tools out there, but there is obviously a long way to go, and they need a lot of polish.

But for me, I think the tools are already good enough. I am a daily Linux user, so I have no problem using the command line and writing scripts to automate things. I'm not trying to do accounting for a large corporation. I just need to manage personal finances, a small business, and a small organization.

But I don't see any reason why these tools can't grow and scale to any size. It can be a full-featured accounting package, except one where each feature is its own simple component. And it all starts with the foundation of a plain text data standard.

Old bump, consider this thread my attempt to compensate for the lack of marketing resources for PTA.



After putting this idea on hold for a while, I got back into it over the past week due to frustrations with mint.com for personal stuff and other packages for small business accounting. So far I am very pleased with hledger, and I will be able to automate a lot of tasks that soaked up a lot of time using other tools.


Mint was nice for a while, but now every time I log in I have to fix some account connections, make sure it categorized all my spending correctly, find and fix where it imported double transactions, etc. And doing things like splitting transactions into multiple budget categories is a pain. It's supposed to be automatic, but I have found it to be quite a lot of work.

So now, using hledger, I do have to manually download the CSV files of my transactions periodically, but this is simpler and easier than fixing the connections in Mint all the time. I spent an hour or so writing rules for the hledger csv importer to automatically categorize most of my purchases to the right accounts, so now I have a cron job that watches my csv folder and imports new txns into my plain text ledger every day. A simple `hledger balance` command instantly shows me the balance of every account, and adding the `--budget` flag shows spending vs budgeted.

One big problem that I've always had with Mint is that it just has to guess at what all my Amazon purchases are. Groceries? Home supplies? Clothes? Shopping? Electronics? And considering we've spent over $9,000 in 415(!) transactions at Amazon over the past 12 months, this takes quite a bit of time switching from Mint to Amazon checking orders and totals (and order totals hardly ever match with what you are charged) to categorize spending, and $9k is a bit more than I'm willing to just toss into a "miscellaneous" budget category.

Plain text to the rescue! I installed a Chrome extension to download my Amazon order history as a CSV file (since Amazon recently removed that function from their site). My next step is to write a little script to visit each Amazon item page to scrape the price and department, which I can use to assign each purchase to the proper expense account. Nice.



Anyway, if you are at all into programming or are a Linux user (though you can do all this on any platform) or even if you are just into accounting, I highly recommend taking a look at some of these "ledger-likes", such as hledger, beancount, etc. I like hledger because it not only has the command line interface, but it also has a curses mode, an interactive "add transaction" mode, and a web UI. I have learned a lot about accounting in just a few days, and I think I have only scratched the surface of the power of making accounting programmable.

quote:

---

I REALLY don’t want to sound like the arse that I’m going to sound like but I can’t help it.

---

quote:

---

Who has this kind of time or motivation to do this kind of thing?

---

Well I only expect it to take an hour or two to write, one time, and I expect it to save me several hours per year indefinitely, since I won't be manually categorizing damn near $1k worth of Amazon purchases every month. I know a lot of people don't care to budget all that stuff at all, but I like to monitor things (especially spending) and I can't think of a better way to do this. If a tool already exists for this, I haven't found it yet.

And I think you would be amazed at the shite people spend their time working on. Spend a few minutes browsing github for little pet projects, and you might find that this project of mine is very reasonable.

And I will probably put my script(s) on github so others can use or improve it.

quote:

---

Do you own your own business? If not you really should consider it, with this kind of drive and dedication you’d be successful selling whatever you want.

---

I do own a (very) small software business. Do you need an app?

quote:

---

Seriously, between this and the effort into sound bar stuff...

---

I look at everything as a learning experience, and even if I never see a return on it, it still has value to me. So yeah, I hooked up the Pi-amp to a modest set of bookshelf speakers, and it sounds pretty damned good to me.

quote:

---

I look at everything as a learning experience

---

Wish more people did this. World would be a lot cooler place.

quote:

---

do own a (very) small software business. Do you need an app

---

I have an idea for a short video app where the users could share stuff and go viral... but we'd have to include all sorts of location tracking and facial recognition stuff.

Yeah, just reading through the plaintext accounting link and also browsing the subreddit, this is definitely accounting software for IT folks, not accounting software for accounting folks. It seems really cool for a small business solution particularly with regards to reporting; I certainly could never use it, though, because it's waaaaay too technical. But I do like the idea of being able to manipulate the data in any way because as you said, software packages are limited and often fall short of the kind of reporting you want.

Is it possible to still stick to a traditional accounting platform (like QBO or GP) but then at the end of every month dump the data into CSV (or whatever format), and then create reports from there?

Another thought: The only thing you might run into if you use this as your entire accounting tool, is if you needed an accountant to help you figure out a technical accounting issue - they may get pretty lost in the sauce trying to sort through code instead of looking at traditional entries and ledgers.

quote:

---

it's waaaaay too technical. But I do like the idea of being able to manipulate the data in any way because as you said, software packages are limited and often fall short of the kind of reporting you want.

---

So a note about how technical it is:

There is a certain amount of technicality and complexity inherent to accounting just by virtue of what it is and does. This is true of most of the things we use computers for. So we hide and abstract away the complexity, and give ourselves a simpler interface to work with.

The problem (for me) is if we go too far, then we are left with a black box that contains our data, and we are left with only the knobs and levers provided to us by the gatekeepers of our data. So this is part of a broader fight of mine to move away from this app-centric world.

So now my data is mine again, and I'm in charge of the knobs and levers that I want to provide to myself or others. And I can streamline the hell out of my workflow. Do the work up front so that later it's less work- and more -flow.