Transaction Builders
Transaction builders specialize in putting together the set of postings for each entry. I’ve found three classes where this specialization is handy, discussed below
- Banking
- Investments/brokerages
- Paychecks
The code for these can be found in beancount_reds_importers
Banking and Credit Cards
Banks and credit cards benefit from a postings predictor like smart_importer. Hence, the transaction builders for these are the simplest, producing only a single posting per account, with the assumption that the other posting(s) will be automatically filled in by smart_importer.
Paychecks are a special case of banking transactions, discussed in detail below.
Investments
Building transaction entries for investments need to handle several cases, all of which are deterministic, but may involve complex and sometimes ugly parsing and inferring:
- stock and fund transactions including buys and sells (lot matching, however, is left to the user)
- commissions, fees
- money market transactions, to be detected: these should use price conversions instead of being held at cost, for simplicity
- balance assertions must extracted from the source when they exist.
- available cash computation: part of, but slightly different from balance assertions
- price entries: as mentioned here, this is particularly helpful in cases where public sources of prices are not available
- CUSIP to fund matching from user-supplied database (some brokerage houses identify funds only by cusip or other custom tickers in the ofx)
Paychecks
Paychecks typically contain very many pre-determined postings in a single transaction, that must be extracted, typically out of a PDF or a multi-table CSV, parsed, the sum checked, and classified based on a user-supplied config.