Shell Scripts, Emacs and Taxes

Most of your income is typically reported to the tax authorities by your employer, brokerage, and so on. Thus, you don't really need to report these numbers again; that would be silly. They mostly just send you a tax bill.

... or at least this is how it's supposed to work. In practice, at least in the US, there are companies like Intuit lobbying for making filing taxes as hard as possible (so that they can provide excellent solutions to this problem, only for a small fee). See also this post on how you can profit from making things worse if you are large enough.

As a result, a lot of people just end up using TurboTax.

We, on this blog, are definitely not using TurboTax. (Practicing oppositional defiance sounds much more fun.)

In fact, oddly enough, this is not as terrible as it sounds like. Yes, you could theoretically file taxes by hand, too... but there are nice open source tools to automate this.

(... assuming you do know "computers" reasonably well. Your mileage might vary otherwise.)

If generating your text forms with a shell script sounds appealing to you though, read on.

OpenTaxSolver

Filing taxes is generally a combination of...

• gathering all the documents that various entities give you (... e.g. a W-2 from your employer); these are your inputs
• figuring out what tax forms to fill out & where to put which numbers from said inputs
• following instructions like "add line 11 and 12, subtract it from line 8" ... while trying to guess their intentions to decrease the chance of messing up without noticing that something went wrong.

OpenTaxSolver automates step 3, saving you from the boring & error-prone parts, without sheltering you too much from understanding what's going on with tax forms. (Actually, understanding how taxes work is somewhat useful anyway, while making the actual decisions about what financial actions to take.)

Here is their website:

As you might guess, them switching over to the latest and greatest (read: epic bloat) JavaScript framework is not something I'd be especially worried about: it's written in C and is hosted on SourceForge, having been maintained for... a long time by Aston Roberts, its main developer, and all the contributors around the project.

It has multiple parts: a GUI to create (input) text files with the inputs, the actual calculator, and a generator that makes PDFs out of the finished (text) tax forms. Using any of the stages is optional: I, for one, prefer to write the text files by hand and only use the last two stages of the pipeline to end up with the PDF.

Here is an example for how this looks like (this is their example input):

They do provide templates; you mostly just fill in some numbers. The tools then calculate the dependent ones.

Interlude: more Emacs

You may have noticed that we somehow have syntax highlighting for this. As it happens, if you are the kind of person who prefers to file taxes by editing text files, "making tax forms pretty" as an activity is fairly competitive with "actually finishing them"; in case you're curious, it takes 47 lines of elisp to do this, most of which being about specifying colors for things.

Pasting it all together

In theory, you could run the calculations and the PDF generator by hand every time. If you're somewhat into automation though, you end up writing a shell script for this. It:

• calls make for OpenTaxSolver, in case we need to edit the source
• makes a build/ directory, for all the output
• runs all the tax solver binaries
• generates the pdfs

... but then why stop here? We already have these other pdfs (W-2s, other forms, etc) around, some of which we'd need to (at least partially) attach to the actual (federal & state) returns. Instead of remembering everything, we can just use pdftk to...

pdftk US_1040_2023_out.pdf cat 1-2 output US_1040_2023_out_cover.pdf
pdftk US_1040_2023_out.pdf cat 9-17 output US_1040_2023_out_rest.pdf

pdftk \
    US_1040_2023_out_cover.pdf \
    US_1040_2023_out_rest.pdf \
    employer_w2_federal.pdf \
    ../f12345_done.pdf \
    cat output final_2023_federal.pdf
          

... same for the state returns. You then just print the two pdfs that come out, sign them & mail them. Done!

If you need to modify anything, you just rerun the entire pipeline. (It's pretty fast.)

The best part: it is fairly stable between tax years. If your main job is not filing tax returns, you will typically forget what and how to file by the time the next return is due. With this approach, you can just copy over the previous year's build.sh script to the current one; search and replace "2022" with "2023", adjust some page numbers, and fill in the fresh numbers to the templates. It's easy to notice that you had some number in a line last year & this year's is still missing.

Meanwhile, if you were to fill in financial transactions / stock sales for example, many brokerages provide XML or CSV versions of those; you can just add a few more scripts to turn them into a format OpenTaxSolver understands.

Is it the most efficient solution possible? Probably not. It's a surprisingly fun programming / data wrangling exercise though, given how... it's filing taxes.