You are currently viewing all posts tagged with finance.

Tracking Cash with Ledger

In a double-entry accounting system like Ledger, money always moves from one account to another. Money cannot be magicked in or out of existence.

Previously I mentioned that I sometimes do not track cash transactions. If the transaction is less than $20 and is not related to a category of expense I care about, I may not bother with it. At first glance, this may seem like it conflicts with the inability to magically disappear money. If I take cash out of my checking account, I have to represent that withdrawal or else the balance of the account will be screwy and I’ll never be able to reconcile it against the bank’s statement. Transforming money from electrons in a bank account to Federal Reserve Notes in my pocket has no impact on its value, so one’s initial thought may to represent the cash as an asset account.

2020-07-13 ATM
    Assets:Cash                               $40.00
    Assets:Bank:Checking

This would be technically correct, and the best way to do things if every last penny of that cash was going to be tracked. But logging the withdrawal that way will not work if, over some period of time, I spend the $40 cash in a serious of small, untracked transactions. In that case, my Assets:Cash account would show that I have $40 more than reality. When asset accounts are not accurate, the world ends.

The solution is to treat cash as an expense account. The balance of an expense account is less important. It tells you how much money you’ve spent on that category of thing, but it doesn’t represent money that you hold. Effectively, this is saying that the $40 was spent when it was withdrawn at the ATM. It no longer contributes to assets or net worth.

2020-07-13 ATM
    Expenses:Cash                             $40.00
    Assets:Bank:Checking

The transaction would look similar if I asked for cash back while buying groceries.

2020-03-20 Lucky Dragon Markets
    Expenses:Food:Groceries                   $58.89
    Expenses:Cash                             $40.00
    Assets:Bank:Checking

But the trick is that money doesn’t have to move between an expense account and an asset account. Money can move between any accounts, including two expense accounts. I am strict about tracking food related expenses, so if I buy a burrito with that cash, I’ll want to log it. I can do that like this:

2020-07-18 A Taqueria
    Expenses:Food:Dining:Lunch                 $8.23
    Expenses:Cash

If part of your savings are in cash – in a safe deposit box, stuffed in your mattress, buried in the hills, whatever – you would want to treat it as an asset so that you can track the balance.

2020-08-30 ATM
    Assets:Mattress                          $100.00
    Assets:Bank:Checking

To illustrate the degree to which I do track cash: Ledger currently reports the balance of Expenses:Cash to be $3797.29. I’ve certainly dealt with significantly more cash than that since 2012. The balance of that account is simply the amount of cash I have acquired but failed to log as spent.

Organizing Ledger

Ledger is a double-entry accounting system that stores data in plain text. I began using it in 2012. Almost every dollar that has passed through my world since then is tracked by Ledger.1

Ledger is not the only plain text accounting system out there. It has inspired others, such as hledger and beancount. I began with Ledger for lack of a compelling argument in favor of the alternatives. After close to a decade of use, my only regret is that I didn’t start using earlier.

My Ledger repository is stored at ~/library/ledger. This repository contains a data directory, which includes yearly Ledger journal files such as data/2019.ldg and data/2020.ldg. Ledger files don’t necessarily need to be split at all, but I like having one file per year. In January, after I clear the last transaction from the previous year, I know the year is locked and the file never gets touched again (unless I go back in to rejigger my account structure).

The root of the directory has a .ledger file which includes all of these data files, plus a special journal file with periodic transactions that I sometimes use for budgeting. My ~/.ledgerrc file tells Ledger to use the .ledger file as the primary journal, which has the effect of including all the yearly files.

$ cat ~/.ledgerrc
--file ~/library/ledger/.ledger
--date-format=%Y-%m-%d

$ cat ~/library/ledger/.ledger
include data/periodic.ldg
include data/2012.ldg
include data/2013.ldg
include data/2014.ldg
include data/2015.ldg
include data/2016.ldg
include data/2017.ldg
include data/2018.ldg
include data/2019.ldg
include data/2020.ldg

Ledger’s include format does support globbing (ie include data/*.ldg) but the ordering of the transactions can get weird, so I prefer to be explicit.

The repository also contains receipts in the receipts directory, invoices in the invoices directory, scans of checks (remember those?) in the checks directory, and CSV dumps from banks in the dump directory.

$ tree -d ~/library/ledger
/home/pigmonkey/library/ledger
├── checks
├── data
├── dump
├── invoices
└── receipts

5 directories

The repository is managed using a mix of vanilla git and git-annex.2 It is important to me that the Ledger journal files in the data directory are stored directly in git. I want the ability to diff changes before committing them, and to be able to pull the history of those files. Every other file I want stored in git-annex. I don’t care about the history of files like PDF receipts. They never change. In fact, I want to make them read-only so I can’t accidentally change them. I want encrypted versions of them distributed to my numerous special remotes for safekeeping, and someday I may even want to drop old receipts or invoices from my local store so that they don’t take up disk space until I actually need to read them. That sounds like asking a lot, but git-annex magically solves all the problems with its largefiles configuration option.

$ cat ~/library/ledger/.gitattributes
*.ldg annex.largefiles=nothing

This tells git-annex that any file ending with *.ldg should not be treated as a “large file”, which means it should be added directly to git. Any other file should be added to git-annex and locked, making it read-only. Having this configured means that I can just blindly git annex add . or git add . within the repository and git-annex will always do the right thing.

I don’t run the git-annex assistant in this repository because I don’t want any automatic commits. Like a traditional git repository, I only commit changes to Ledger’s journal files after reviewing the diffs, and I want those commits to have meaningful messages.

Notes

  1. I do not always track miscellaneous cash transactions less than $20. If a thing costs more than that, it is worth tracking, regardless of what it is or how it was purchased. If it costs less than that, and it isn't part of a meaningful expense account, I'll probably let laziness win out. If I buy a $8 sandwich for lunch with cash, it'll get logged, because I care about tracking dining expenses. If I buy a $1 pencil erasure, I probably won't log it, because it isn't part of an account worth considering.
  2. I bet you saw that coming.

Experience at the Bitcoin ATM

Recently I had need of Bitcoin. For a thing.

I decided to use this need as an excuse to try a Bitcoin ATM. I’d noticed them appearing throughout town over the past few years but never had a reason to use one.

The liquor store that I chose had a General Bytes BATMTwo. It was simple to use, but slow. After selecting the button to begin, it sat at a loading screen for a good minute. After loading, it showed me the current exchange rate for BTC (there was no option for a different currency) and asked if I wanted to deposit more or less than $1000 USD. I selected less. It then asked me to input a phone number where it could send an SMS. After giving it my number I waited around for about another minute until it sent me a message with a 5 digit number. I entered that number into the ATM, after which it allowed me to proceed.

It next prompted me to scan a QR code for an existing destination wallet, or to hit another button if I did not yet have a wallet created. I didn’t see any option to manually enter an address. I assumed it would want a QR code, so before I embarked on this journey of discovery I had generated a new wallet on my computer, saved its address as both a QR code and as plain text, and copied those files to my phone. Getting it scan the QR code from my phone screen took a few seconds of finagling, but this is typical of reading any barcode from a phone in my experience. After it read the code it took me to the next screen and prompted me to insert bills. This screen also showed the destination address, how much fiat currency I had deposited, and what the amount of Bitcoin received would be. I opened the text file on my phone where I had saved the wallet address and verified that this matched what it had decoded from the QR code.

I wanted to deposit multiple bills, but it did not indicate if I should feed all of them in at once or one at time. I decided to insert them one at a time. As I did this it correctly displayed the amount of money I had deposited. It read all the bills successfully. However, the BTC amount stayed at 0, and it displayed a loading message in one corner of the screen. This began another wait, again of about 60 seconds, until it calculated the amount of BTC I would receive. I suppose it was fetching the current exchange rate, though if it gets an updated rate at this stage I’m not sure why it wasted time fetching the exchange rate back in the initial step.

Once it had showed me the amount of BTC I would receive I hit the button indicating I was done inserting bills. It immediately displayed a confirmation screen that said the transaction was complete, with a confirmation of the USD deposited, the BTC received, and a transaction ID. At this point it asked me if I was done or if I wanted a receipt. I selected the receipt option to see what it would look like. It asked if I would like a receipt via SMS or email. Since it already had my phone number, I selected SMS. It immediately said that the receipt was sent, and then a few seconds later when back to its idling screen for the next customer. About a minute later the SMS receipt arrived. The message included the transaction ID, localized timestamp, USD deposited, BTC purchased, and destination wallet address.

I didn’t get back to my computer until about 45 minutes later. When I checked the funds were in my wallet, but I’m not sure how immediately they appeared.

The ATM claimed to impose no fees, but the exchange rate it offered is substandard. At the time I completed the transaction I believe the price on Coinbase was about $10,123.47. Given the amount of BTC that ended up in my wallet, the price the machine offered me was about $12,208.17.

Still, the process was simple, and the results quick. This is the first time I purchased Bitcoin with cash since circa 2012, when there was a service that would allow you to make a cash deposit into a random Wells Fargo account in exchange for Bitcoin. I used this service half a dozen times or so and never had a bad experience, but the whole transaction took a few hours to complete – and I remember hearing that the person who ran it was later arrested for something or other. The ATM experience certainly felt less shady.

From a privacy standpoint, the only personal information required by the ATM was a phone number that was able to receive a SMS. I’m not sure what General Bytes feels they are accomplishing by going through the steps for the SMS token, but it is a requirement that is easy enough to satisfy.

Lately I've had trouble finding prepaid debit cards in denominations greater than $50.

It’s 2016, and stuffing cash in an envelope and mailing it to a small island nation is sometimes still the best way to move money with some degree of privacy.

This is not the cyberpunk dystopia I was promised.

I stopped worrying and embraced the security freeze.

A credit security freeze denies access to your credit file. I first learned about it last summer from Brian Krebs, but didn’t implement it until a couple months later. It took me about 45 minutes and $20 to activate the freeze with the five major credit bureaus. This goes a long way to reducing the threat of identify theft, with very little energy expenditure required. A proactive defense is superior to reactive monitoring services. If you need your credit pulled monthly or more frequently, constantly freezing and unfreezing your file would probably be an annoying inconvenience. For the rest of us, I’m not sure if there is any good reason not to enable the freeze.

Financial Defense Through Proxies

Brian Krebs’ recent experience highlights PayPal’s insecurity. The convenience and ease of use of PayPal give them a wide customer base, but their inherent untrustworthiness has long been reason for concern. For as long as I’ve used the service, I’ve been concerned about external attacks, like what Krebs experienced, as well as the internal threat – PayPal themselves have a history of freezing and diverting their users’ funds. Both of these concerns can be addressed via a proxy bank.

In 2008 I opened an online checking account with a new bank, completely separate from the financial institutions I normally use. The account has no “overdraft protection” or any line of credit. As with my PayPal account, I keep no money in the checking account. This checking account is the only account I associate with PayPal. When I want to make a purchase via PayPal, I transfer the needed funds from my primary financial institution to the checking account at the proxy bank. Since banks still subscribe to the archaic notion of “business days”, this transfer can sometime take up to week, but more frequently completes within 2-3 days.

The brief wait period is acceptable to me (it certainly reduces the ability to impulse buy) and gives me a level of security that otherwise cannot be achieved with PayPal. If someone breaks into my PayPal account, there’s nothing for them to steal. Even PayPal themselves have limited ability to steal funds. If an attacker is lucky, they may gain access to the account when I’m transferring funds in preparation for a purchase. My PayPal transactions are typically low-value, so at most this lucky attacker will acquire $100 or so. That’s an acceptable risk for the convenience of PayPal.

In the past I used this multilayer approach for all online purchases. A debit card from a proxy checking account at a different bank with no access to my primary accounts was the only thing I would use to make online purchases. When the account was compromised, the wait period for a new card wasn’t the inconvenience it normally is, since it had no impact on my day-to-day spending with my primary accounts. I think this type of security is required for shopping online, but responsible use of a credit card can offer acceptable protection for non-PayPal transactions without the hassle of a proxy account.

I wrote an article about anonymous debit cards on ITS Tactical.

I have previously mentioned prepaid debit cards. On ITS I discuss using prepaid debit cards for anonymous, cash-like digital transactions a bit more in-depth.

Gwern offers an excellent overview of Silk Road.

In the essay he introduces the website and describes his experience as a user purchasing illegal drugs. It is well worth the read. I’ve spent hours on his website perusing his other works.