---

Tcost (and mental energy required) is formidable, but long-term Value is also very high , as explained in long-term roti@burn-rate trac . Therefore, I hope to reduce the tcost while maintaining the “value” —

• Leave the unexplained amount as “PersonalExp”. In contrast, “ATM}” amount can be easily computed from 104 account. Note these two amounts overlap to some extent but are not identical.
• .. sugg: move the non-electronic spending items to a category “PersonalExp”
• — tcost tips:
• sugg: incremental update, to spread out the tcost
• Sugg: earmark 2 focus hours to reach Completion. Then 2 more hours of optional fine tuning can be put off to a less busy time.
• — generic tips for Excel
• Tip: ctrl-backtick to toggle between show-formula vs show-result
• tip: categorization: use grouping tables + background color + text effect
• — generic tips for online banking
• DBS + MB ccard balance — look at available balance without OTP

In terms of approximation, I guess the two big areas are personalExp (see above) and NTUC card-spend. Luckily NTUC sums are easy to track electronically. Therefore, we have a promising solution !

0. — disambiguation
1. exp-tracking … is the overall goal and objective. There are many practical methods to achieve it.
2. exp-recon .. is the method and monthly process. I devised it by trial-n-error.

— estimates .. For all the estimates [including total banknote spend], the goal should ideally be a verifiable number. Otherwise, it’s a phantom target.

For example, there’s a MaybankCCardSupermarket sum. This is a best-effort approximation of a verifiable amount (I just don’t have time to verify.) If between EOD 30/1 to EOD 22/2 this sum is $999, then it means “All supermarket transaction between 31/1 and 22/2, charged to the Maybank ccard should add up to $999”

— snapshot frequency/interval
— paper banknote spend
— annotation on a cell
* excel comment .. highly visible:) but legwork:( + often covers up another cell 🙁
* theCellBelow as a comment box … plenty of space:) but takes up real estate 🙁
* #trailing comment .. but too long sometimes 🙁
— the recon(reconciliation) cycle

1. compute curBal – prevBal + incoming === outgoing.
2. classify outgoing items into
   • transfers to family members
   • investments… read the important blogpost on exclusion/inclusion criteria
   • bx
   • tax-like outlays. There’s a separate blogpost
   • otherOutlays

After that step, goal is a good-enough understanding of the otherOutlays. Here comes the recon, which often reveals that there’s $462 unexplained amount, whereas the typical unexplained/month is below $100. That’s a great opportunity to to dig deeper and identify mistake in the calc of curBalance, prevBalance or incoming. These mistakes are not uncommon. See basic principle.

The recon is as valuable as the math self-check I taught my son. Recon is more valuable than retracing the steps.

==== priorities: Given my limited t-budget, the priorities of this s/sheet are
* YY1) short-term iquid_NAV snapshot
* YY2) long-term couple NAV tracking .. not easy. Basically, the exp recon /system/ is not designed for this trendline.
* XX) burn rate recon/verification, categorization, (short-term)trending, (long-term)projection

LG2: these secondary priorities below can be computed relatively easily on the s/sheet.

• monthly savings amount [3]
• cumulative transfers
• cumulative investment
• cumulative incomes
• non-essential outlays each month
• short-term trend in liquid_NAV? Complicated by transfers to CPF/SRS and with eqMufu etc. During the years without these complications, the trendline would make a nice graph.

Q: focusing on YY, why is aggregate asset snapshot such a high priority? I want to spell out this “statement of principle” to share with others.
A: Fundamental principle of “absolute” burn rate accounting — start from /realized/ incomes (much easier to track) +  total asset snapshots (basically YY). From there, work out aggregate realized outgoing amount, then Explain the outgoing using high-level, recurring categories of expenses.

YY doesn’t require complicated system. /Transparency/ and simplicity can greatly enhance accuracy and reliability and are extremely valuable.

— [3] Tracking monthly savings amount .. a G10 priority. U.S. (and Sgp) pff advice is “Strive to Uphold monthly savings goals” but I don’t need such self-discipline.

The increment between successive liquid_NAV snapshots is a /nominal/ savings amount. It excludes II (monthly investment amounts). Even if I add the II, the savings amount is still highly inaccurate. In fact, tracking the actual savings amount has proved to be t-expensive and /unrewarding/ legwork with poor leverage. In contrast, exp recon decent leverage despite high tcost.

Note banknote spends are not a category and must not overlap with Category::kids_ePay, Category::tax-like, Category::outing_ePay.

For example, outing spends from bank note must NOT go into Category::outing_ePay. This type of rules require some getting-used-to.

( Banknote spends can be part of Category::misc, but I don’t bother with such a category. )

~~ Assumption: the Begin and End banknote stash_snapshots are accurate up to +/- $20 … good enough. Due to tcost, we don’t try to beat that precision.

• .. This snapshot captures all physical bank notes in all my wallets but not wife’s wallet.
• .. This stash decreases from spending, and increases from ATM withdrawals
• .. 🙂 the total ATM withdrawals are few and easily tracked.

~~ Begin – End + withdrawals == total banknote spend over the period.

Given limited record, when we /enumerate/ banknote spends, they often fall short of this total. An acceptable inaccuracy of an efficient process. If the discrepancy exceeds $50, then follow our recon process, and investigate

— terminology .. “ePay ^ offline spend” are the two phrases I have developed. I like ePay — concise. Offline spend is comparable to banknote spend.