WIP: Budgeting V1 #1584

2024-12-31T06:42:07+08:00

zachgoll commented

2024-12-31 06:42:07 +08:00

(Migrated from github.com)

This PR introduces a basic budgeting module along with some updates to categorization of transactions.

Transfers and Payments

One of the major goals of this app is to treat "transfers" and "payments" as first-class citizens rather than a categorical afterthought. Most personal finance apps leave it to the user to identify transfers and payments, which generally ends in the user asking, "How do I incorporate transfers in my budget and goals?". This leads to inaccurate calculations of spending, income, and overall budgets because the app does not give the user a clear way to separate these concepts from expenses and income (the primary purpose of budgeting). Our goal is to give transfers/payments a clear "home" in the app and assist the user in identifying them. Below are some technical definitions of each:

Transfer - any transaction that is simply a compositional shift of wealth. A transfer does NOT affect a users net worth because it is simply a movement from one of their accounts to another.
- Example: User moves $5,000 from a checking account (asset) to a Brokerage account (asset), which does not affect net worth, but changes the composition of the user's balance sheet.
Payment - a payment is a specific type of transfer where a user makes a transfer from an asset account to a liability account, therefore reducing debt.
- Example: User moves $2,000 from a checking account (asset) to a Credit card account (liability), which reduces both account values, but does NOT change net worth.

Transfer/Payment treatment

Transfers and payments are incorporated into a user's budget based on the classification of account in which they correspond to.

All transfers are excluded from budgets since they are neither "spending" nor "income"
Payments made to/from credit card accounts are excluded from budgets to avoid "double counting"
- Since all the credit card account transactions will be categorized and summed up, we need to exclude the monthly payment made from the user's Checking account to avoid double counting. A credit card is a "Suspense" or "Clearing" account that acts as a temporary holding area for categorized transactions that will eventually be cleared by the debt servicing payment.
Payments made to loan accounts are included in budgets, because this is a monthly "expense" that a user must budget for

Transfer identification

One of the biggest challenges when dealing with transfers is identifying them. Our app can identify 90% of transfers by looking at the amount, account, and date. Two transactions with opposite amounts, within a few days of each other from different accounts give high confidence that we're dealing with a transfer.

That said, there are always edge cases. The most notable one is where the user has made a transfer to an account that does not exist in Maybe yet, or one that is being tracked by value only and doesn't have a corresponding transaction. In this case, we must rely on the user to tell us that this was a transfer.

This PR introduces a basic budgeting module along with some updates to categorization of transactions. ## Transfers and Payments One of the major goals of this app is to treat "transfers" and "payments" as first-class citizens rather than a categorical afterthought. Most personal finance apps leave it to the _user_ to identify transfers and payments, which generally ends in the user asking, "How do I incorporate transfers in my budget and goals?". This leads to inaccurate calculations of spending, income, and overall budgets because the app does not give the user a clear way to separate these concepts from expenses and income (the primary purpose of budgeting). Our goal is to give transfers/payments a clear "home" in the app and assist the user in identifying them. Below are some technical definitions of each: - **Transfer** - any transaction that is simply a _compositional shift_ of wealth. A transfer does NOT affect a users net worth because it is simply a movement from one of their accounts to another. - Example: User moves $5,000 from a checking account (asset) to a Brokerage account (asset), which does not affect net worth, but changes the composition of the user's balance sheet. - **Payment** - a payment is a _specific type of transfer_ where a user makes a transfer from an _asset_ account to a _liability_ account, therefore reducing debt. - Example: User moves $2,000 from a checking account (asset) to a Credit card account (liability), which reduces _both_ account values, but does NOT change net worth. ### Transfer/Payment treatment Transfers and payments are incorporated into a user's budget based on the _classification_ of account in which they correspond to. - All transfers are excluded from budgets since they are neither "spending" nor "income" - Payments made to/from credit card accounts are _excluded_ from budgets to avoid "double counting" - Since all the credit card account transactions will be categorized and summed up, we need to _exclude_ the monthly payment made from the user's Checking account to avoid double counting. A credit card is a "Suspense" or "Clearing" account that acts as a temporary holding area for categorized transactions that will eventually be cleared by the debt servicing payment. - Payments made to _loan_ accounts are _included_ in budgets, because this is a monthly "expense" that a user must budget for ### Transfer identification One of the biggest challenges when dealing with transfers is identifying them. Our app can identify 90% of transfers by looking at the amount, account, and date. Two transactions with opposite amounts, within a few days of each other from different accounts give high confidence that we're dealing with a transfer. That said, there are _always_ edge cases. The most notable one is where the user has made a transfer to an account that _does not exist in Maybe yet_, or one that is being tracked by value only and doesn't have a corresponding transaction. In this case, we must rely on the user to tell us that this was a transfer.

zachgoll commented

2025-01-01 06:43:50 +08:00

(Migrated from github.com)

Will open new PR for this. #1585 covers a good portion of the changes here.

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gavin/maybe#1584