actual
actual copied to clipboard
actualbudget
[WIP] Cashflow forecast
Having a crack at implementing a form of cashflow forecasting as discussed in #187, #517, #716.
The concept is pretty simple - take all the schedules, get the occurrences of them up to the desired forecast date, check for transfers to create a balancing transaction (if required based on filtering), run them through the calculator for balances and show them as a seperate set of 'future' expense, income bars and balance line.
Would appreciate a good review and some feedback on:
- the approach
- alignment with conventions
- plain old bad practices
- is the 'experimental' flag masking enough?
- anything unclear etc...
Some edge cases up for debate:
- Should a transfer to an off budget account show as an expense/income? Currently in the historical cashflow they don't... So I've kept that convention.
- Should a transfer to/from an account that is not in the graph filtering show up as an expense/income? Currently the change of balance is captured but it's not shown as a clear expense/income.
Thanks!
Deploy Preview for actualbudget ready!
| Name | Link |
|---|---|
| Latest commit | 428f69e35b25561304e33a89389ffccc7a61c252 |
| Latest deploy log | https://app.netlify.com/sites/actualbudget/deploys/658c19fe131f930008b0c3ac |
| Deploy Preview | https://deploy-preview-2126.demo.actualbudget.org/ |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Bundle Stats β desktop-client
Hey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle.
As this PR is updated, I'll keep you updated on how the bundle size is impacted.
Total
| Files count | Total bundle size | % Changed |
|---|---|---|
| 15 | 3.09 MB β 3.09 MB (+3.08 kB) | +0.10% |
Changeset
| File | Ξ | Size |
|---|---|---|
src/components/reports/spreadsheets/cash-flow-spreadsheet.tsx |
π +5.2 kB (+62.05%) | 8.39 kB β 13.59 kB |
src/components/reports/graphs/CashFlowGraph.tsx |
π +1.31 kB (+47.18%) | 2.77 kB β 4.08 kB |
src/components/reports/reports/CashFlow.tsx |
π +1.66 kB (+19.66%) | 8.45 kB β 10.11 kB |
src/components/reports/Header.jsx |
π +924 B (+13.14%) | 6.87 kB β 7.77 kB |
src/hooks/useFeatureFlag.ts |
π +29 B (+5.85%) | 496 B β 525 B |
src/components/settings/Experimental.tsx |
π +168 B (+4.08%) | 4.02 kB β 4.18 kB |
src/style/themes/light.ts |
π +106 B (+1.08%) | 9.56 kB β 9.66 kB |
View detailed bundle breakdown
Added
No assets were added
Removed
No assets were removed
Bigger
| Asset | File Size | % Changed |
|---|---|---|
| static/js/reports.chunk.js | 78.28 kB β 81.18 kB (+2.9 kB) | +3.70% |
| static/js/main.js | 1.43 MB β 1.43 MB (+193 B) | +0.01% |
Smaller
No assets were smaller
Unchanged
| Asset | File Size | % Changed |
|---|---|---|
| static/js/665.chunk.js | 824.28 kB | 0% |
| static/media/Inter-italic.var.woff2 | 239.29 kB | 0% |
| static/media/Inter-roman.var.woff2 | 221.86 kB | 0% |
| static/js/231.chunk.js | 117.38 kB | 0% |
| static/js/wide-components.chunk.js | 113.08 kB | 0% |
| static/js/narrow-components.chunk.js | 45.2 kB | 0% |
| static/js/553.chunk.js | 28.56 kB | 0% |
| static/js/473.chunk.js | 13 kB | 0% |
| static/js/resize-observer-polyfill.chunk.js | 8.88 kB | 0% |
| static/css/main.css | 7.41 kB | 0% |
| asset-manifest.json | 1.92 kB | 0% |
| index.html | 1.66 kB | 0% |
| static/media/browser-server.js | 911 B | 0% |
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Bundle Stats β loot-core
Hey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle.
As this PR is updated, I'll keep you updated on how the bundle size is impacted.
Total
| Files count | Total bundle size | % Changed |
|---|---|---|
| 2 | 2.23 MB β 2.23 MB (+238 B) | +0.01% |
Changeset
| File | Ξ | Size |
|---|---|---|
packages/loot-core/src/server/schedules/app.ts |
π +503 B (+2.90%) | 16.94 kB β 17.44 kB |
View detailed bundle breakdown
Added
No assets were added
Removed
No assets were removed
Bigger
| Asset | File Size | % Changed |
|---|---|---|
| kcab.worker.js | 1.24 MB β 1.24 MB (+238 B) | +0.02% |
Smaller
No assets were smaller
Unchanged
| Asset | File Size | % Changed |
|---|---|---|
| xfo.xfo.kcab.worker.js | 1014.46 kB | 0% |
Where in the demo build should I be looking? I've toggled on the experimental feature.
Is this in the cash flow report? In which case this isn't loading.
I'm hesitant to comment until I can see what it is you have in mind.
Where in the demo build should I be looking? I've toggled on the experimental feature.
Is this in the cash flow report? In which case this isn't loading.
I'm hesitant to comment until I can see what it is you have in mind.
Not off to a good start... There was a bug where it didn't handle non-reoccurring schedules. Which I didn't test for... Cashflow chart is loading in the deploy preview now.
Thanks for working on this. I've been clicking around a bit. I figure it would be eventually useful if someone could add some kind of dummy schedules to work with this, that the forecast can consider but the register doesn't display and expect action on. This'd help to fill out irregular things like grocery shopping in the forecast and other expenses via averages.
Also, this happens, a break in the line graph. If it's intended, it creates two tooltip overlays that ought to be dealt with:
--edit: Also, I just spot on the screenshot that the February income is missing. I have it scheduled on the 30th but before the weekend. With what February being 28 or 29 days. Seems a core issue, tho.
Where in the demo build should I be looking? I've toggled on the experimental feature. Is this in the cash flow report? In which case this isn't loading. I'm hesitant to comment until I can see what it is you have in mind.
Not off to a good start... There was a bug where it didn't handle non-reoccurring schedules. Which I didn't test for... Cashflow chart is loading in the deploy preview now.
It's all good, better to find them now than later. :)
My initial caution around forecasting doesn't apply here as we're looking at reporting.
General comments: My primary consideration for forecasting is the mechanics and limitations of it need to be clearly communicated to manage expectations and ensure there's no misunderstandings. We don't want people thinking their future is rosy, when in reality it isn't.
Personally, I don't see the value in forecasting if it doesn't cover all expenses as that feels misleading. For example I don't have a schedule for my grocery shopping, but I sure do that regularly!
To assist with the first part I'd suggest an explanation for how the forecasting is calculated, and what is and what isn't included as an additional heading and text under the graph in the style of what is already present.
On the second, I feel non-scheduled transactions need to be represented somehow. Such as something along the lines of 'scheduled only' and 'average of last X months only' options? Where X would be say, 3/6/12 months.
UI:
- The options across come across a bit odd as they relate in turn to:
- Historic time period, Forecasting period, Filter, Historic time period.
I'd suggest the simplest approach would be to move the forecasting period selection to the end. This also syncs up with the graph (historic on the left, forecasting on the right). Then ignore the fact filtering is in the middle.
- I think the forecasted section should be strongly visible distinct from the historic, potentially a substantially different colour? Dashed?
- Possibly include in the tool tip a mention it's forecasted?
Minor UI stuff for later, fixing theming in dark mode:
- And also the bars on the graph itself:
Should a transfer to an off budget account show as an expense/income? Currently in the historical cashflow they don't... So I've kept that convention.
Not sure how this should be handled either, an off budget account is often used to represent a debt, which is an expense, but this isn't always the case. Probably best to follow as-is for now and it could be addressed separately if someone wishes to.
Should a transfer to/from an account that is not in the graph filtering show up as an expense/income? Currently the change of balance is captured but it's not shown as a clear expense/income.
This is a tricky one, I think if someone is using filters it's reasonable to use the current settings as their frame of reference and as there is a negative or positive to the transfer when you only have one half of it you can determine whether to treat it as income or expense. It would need to be indicated somehow, tool tip? Stack another box in the chart? Other?
Personally, I don't see the value in forecasting if it doesn't cover all expenses as that feels misleading. For example I don't have a schedule for my grocery shopping, but I sure do that regularly!
I second this. Inaccurate representation of future expenses basically kills off the forecasting capability. How I used to work-around this before (not in Actual though):
- I created weekly dummy schedule for each category, e.g. grocery shopping. Amount equals monthly budget, divided by amount of weeks in that month (because I need day-to-day visibility, a week is the best suitable period).
- This schedule was always set on Sunday (end-of-week) and represented worst-case scenario spending for the previous week.
- On the end of each week, I deleted the scheduled transaction without posting, as actual spending was already posted throughout the week. Also I would delete it sooner if I already spent the budgeted amount to maintain visibility.
I then monitored transaction-based future view on a daily basis (somewhat similar like #1928 proposes), where I could see how future balance changes - taking into consideration scheduled "worst case" spendings. My timeframe would usually be a month ahead (to see whether I risk overspending the account before my income is due and if I need to transfer any funds to it from other accounts).
In context of this PR I could reintroduce my workflow but instead of looking at (forecasted) transactions and their impact on the balance through the Transactions page, I would see the same information in the Cashflow report and could see the forecasted balance by hovering the trendline.
What I would see as a huge opportunity in this implementation is to omit the "dummy" schedules completely as they represent a lot of clutter and extra work. Instead, reuse already present mechanics of "averaging", from Spending report if possible.
Every (maybe limit to unhidden?) category should be automatically counted in into the forecast and we would be able to select how to average its impact if needed.
That would ensure the future is almost never shown better than it actually is.
I have an idea, based on the assumption that habits repeat: Use the previous year's equivalent month in the forecasting, and if not available, use an average instead. How does that sound?
For instance, I'm on expensive-ass ski vacation each January and March. The forecasting would then consider that, because I have previous data in Actual currently.
I have an idea, based on the assumption that habits repeat: Use the previous year's equivalent month in the forecasting, and if not available, use an average instead. How does that sound?
For instance, I'm on expensive-ass ski vacation each January and March. The forecasting would then consider that, because I have previous data in Actual currently.
This is an interesting idea, at first I was thinking it wouldn't capture inflation, but you make a solid point. I also have large bills that come in twice a year. I'd have to use a 12 month average to capture these, which would actually make forecasting a tad inaccurate depending on the point in time I'm looking at, vs when these bills land.
Thanks for working on this. I've been clicking around a bit. I figure it would be eventually useful if someone could add some kind of dummy schedules to work with this, that the forecast can consider but the register doesn't display and expect action on. This'd help to fill out irregular things like grocery shopping in the forecast and other expenses via averages.
Yes! I believe this should be driven by the budget (otherwise we're duplicating things), but the specifics need to be worked through. E.g. there is no link currently between Category and expected Account. When and how often does the budgeted amount hit the account? etc. etc. Thought I'd start with this and seek feedback early.
Also, this happens, a break in the line graph. If it's intended, it creates two tooltip overlays that ought to be dealt with:
The break is expected as the balance today is different than what is expected at the end of the month. If you reduce the timeframe of the historical transactions (for example to 1 month) to display a daily cashflow, the lines should meet on the present day. But yes, the tool-tips need sorting on monthly view. π
Personally, I don't see the value in forecasting if it doesn't cover all expenses as that feels misleading. For example I don't have a schedule for my grocery shopping, but I sure do that regularly!
I mostly agree. However, I do get a bit of value seeing if any large transactions are on the way. Also, forecasting longer term savings accounts (minus interest) is handy. Integrating something based on budgets etc requires a bit more design, and given schedules are all there, this seemed like a logical place to start! :)
To assist with the first part I'd suggest an explanation for how the forecasting is calculated, and what is and what isn't included as an additional heading and text under the graph in the style of what is already present.
That's definitely a quick win!
On the second, I feel non-scheduled transactions need to be represented somehow. Such as something along the lines of 'scheduled only' and 'average of last X months only' options? Where X would be say, 3/6/12 months.
I personally would like to use the budget. When looking at a monthly overview, the exact dates won't matter so much then, so we can assume the first of each month. The only thing missing is a link from category to account. Which could be made on the budget screen.
The next step would be, providing different ways to forecast a category - on a specific day, weekly, averaged over the month etc.
UI:
The options across come across a bit odd as they relate in turn to:
- Historic time period, Forecasting period, Filter, Historic time period.
I'd suggest the simplest approach would be to move the forecasting period selection to the end. This also syncs up with the graph (historic on the left, forecasting on the right). Then ignore the fact filtering is in the middle.
Ignoring the forecasting, it's already a bit disjointed. I see it as the left is the current config (historic + forecast), followed by filtering, followed by shortcuts.
Simply moving it to the end doesn't look great IMO:
Right aligned might be okay? ...and syncs up with the graph as you mentions.
- I think the forecasted section should be strongly visible distinct from the historic, potentially a substantially different colour? Dashed?
- Possibly include in the tool tip a mention it's forecasted?
I like dashed. I wanted to do this actually but clearly forgot...
Thanks for the feedback!
The only thing missing is a link from category to account. Which could be made on the budget screen.
This is problematic, since the whole idea of zero budgeting(or even budgeting apps in general) is it doesn't matter where the money is. Only that you have the funds and keep an eye out to ensure the spending accounts have enough in them for the near term expenses.
The whole idea of digital envelopes is you look at them, rather than your account. Linking categories to accounts conflicts with this and has potential to create confusion.
It also creates issues where someone would keep money in a higher interest account until that infrequent bill came up for payment. From my own setup, I keep the overwhelming majority of cash on hand in two accounts, and only transfer expenses to a 3rd for day to day spending when it drops lowish.
Further, net worth is about the sum total of assets and obligations across all accounts.
The next step would be, providing different ways to forecast a category - on a specific day, weekly, averaged over the month etc.
Since AB is monthly based, I don't see any reason to worry about the specifics of when a payment/schedule/whatever falls within a month, just that it's capture and assigned to the right month. This also keeps it simpler and consistent.
Right aligned might be okay? ...and syncs up with the graph as you mentions.
Looks good. :)
The only thing missing is a link from category to account. Which could be made on the budget screen.
This is problematic, since the whole idea of zero budgeting(or even budgeting apps in general) is it doesn't matter where the money is. Only that you have the funds and keep an eye out to ensure the spending accounts have enough in them for the near term expenses.
The whole idea of digital envelopes is you look at them, rather than your account. Linking categories to accounts conflicts with this and has potential to create confusion.
Perhaps true for envelope budgeting but I use the budgeting feature as a reporting and tracking tool (in report budget mode). Mainly for insights of where the money goes etc with some rough targets on how much I want to spend in that area.
In terms of confusion, I don't see the link as something that must be done. Just optional for the purpose of forecasting, which is centred around account balances.
It also creates issues where someone would keep money in a higher interest account until that infrequent bill came up for payment. From my own setup, I keep the overwhelming majority of cash on hand in two accounts, and only transfer expenses to a 3rd for day to day spending when it drops lowish.
Can you describe the issue you would encounter here?
Further, net worth is about the sum total of assets and obligations across all accounts.
Yep.
The next step would be, providing different ways to forecast a category - on a specific day, weekly, averaged over the month etc.
Since AB is monthly based, I don't see any reason to worry about the specifics of when a payment/schedule/whatever falls within a month, just that it's capture and assigned to the right month. This also keeps it simpler and consistent.
I guess this might help those who live on a tighter balance identify any shortcomings in balance based on expected budgetary spending + their scheduled transactions.
I started typing, then re-wrote stuff, checked things, and ultimately I did some re-reading. Just to go back a bit as I think I'm not quite getting the purpose of linking a category to an account, can you clarify what creating this link enables presenting on the cash flow graph? And what does doing so add, given schedules can already be bound to an account?
I initially wrote some comments which I can re-write based on your response to the above rather than create confusion by including them here now. They mostly centered around where a given category could involve multiple accounts, how would someone determine which one would be linked, and wondering what the behaviour would be.
Mainly for insights of where the money goes etc with some rough targets on how much I want to spend in that area.
This is an aside, but the custom reporting Carkom has been working on is great here! I'd rate it as a better tool for understanding expenses per category. It lets you view expenditure per category, accounts, etc. In graph and tabular forms. The only bit it doesn't have it projecting the impact on balances in the future.
I started typing, then re-wrote stuff, checked things, and ultimately I did some re-reading. Just to go back a bit as I think I'm not quite getting the purpose of linking a category to an account, can you clarify what creating this link enables presenting on the cash flow graph? And what does doing so add, given schedules can already be bound to an account?
Yep! Good call. So the initial thought was about improving the accuracy of the forecast by including some additional info around spending that we don't necessarily schedule right? Like your groceries you mentioned! Perfect example.
So in trying to prevent an increase of configuration and overheads, using the budget to inform the forecast seems logical. The blocker is that the cash flow graph can be sliced by 'Account' so we need a way to set a kind of 'default account' for which spend from a category is expected to come from (or deposit into for income). Then when someone filters by account the graph will display an accurate (as possible) forecast of that accounts cash-flow.
I initially wrote some comments which I can re-write based on your response to the above rather than create confusion by including them here now. They mostly centered around where a given category could involve multiple accounts, how would someone determine which one would be linked, and wondering what the behaviour would be.
Yes! I did briefly think about this issue - and didn't have a great solution... I will encounter this in my own budget as I have a 'food and drink' category for example which can come from two seperate accounts: an 'essential expenses' and a 'treats' account. My strategy was to introduce an extra category to split the two. I appreciate this won't be a solution for everyone...
If there are no accounts filtered it doesn't matter - the whole budget can be used and just the net forecast will be displayed. Maybe this is suitable for most people?
Alternatively, an expected percentage could be set for each account in each category? Getting a little complex now...
Also, the challenge of not double counting schedules would need to be solved. I haven't thought this one through much but initial thoughts would be to subtract any scheduled amounts from the category budget if they are linked via a goal template. I suspect this won't work for the majority though. Given everything I'm talking about here relies on experimental features. π€£
Yep! Good call. So the initial thought was about improving the accuracy of the forecast by including some additional info around spending that we don't necessarily schedule right? Like your groceries you mentioned! Perfect example.
So in trying to prevent an increase of configuration and overheads, using the budget to inform the forecast seems logical. The blocker is that the cash flow graph can be sliced by 'Account' so we need a way to set a kind of 'default account' for which spend from a category is expected to come from (or deposit into for income). Then when someone filters by account the graph will display an accurate (as possible) forecast of that accounts cash-flow.
I'm actually wondering if simply not showing the forecast when the account split(and possibly all other splits as well) is the way to go. Possibly as a starting point and work on enabling this feature with each split option as a separate piece of work?
Question, what's driving you to obtain information from the budget and not from from the transactions themselves? They already have an account AND category tagged and no additional config, user action, or workflow change is required. Just remember splits are a thing. :)
They would have to be totaled up which is an extra step to code for, but this would also enable greater than monthly granularity you mentioned at some point in the future?
Yes! I did briefly think about this issue - and didn't have a great solution... I will encounter this in my own budget as I have a 'food and drink' category for example which can come from two seperate accounts: an 'essential expenses' and a 'treats' account. My strategy was to introduce an extra category to split the two. I appreciate this won't be a solution for everyone...
Aye, I don't think reporting should have an impact on how budgeting is done. Budgeting should (imo) be as simple as possible, and reporting is an added extra using existing information.
There are additional negative down stream effects as well. Such as the category spending report - spending would be split by the number of accounts for a given category so you can't see a single total. I mean technically you could filter for just those categories, but this is still an extra step, would have to be done for each multi-account category(now multiple) and obfuscates when looking at all categories together (no big picture view).
The same type of problem is also present when using the custom reports - a category is now split and requires additional mental maths to un-split them.
If there are no accounts filtered it doesn't matter - the whole budget can be used and just the net forecast will be displayed. Maybe this is suitable for most people?
That would be my take also, see my suggestion above around starting here and add support for splitting later on.
Alternatively, an expected percentage could be set for each account in each category? Getting a little complex now...
Just a tad. π€£
Also, the challenge of not double counting schedules would need to be solved. I haven't thought this one through much but initial thoughts would be to subtract any scheduled amounts from the category budget if they are linked via a goal template. I suspect this won't work for the majority though. Given everything I'm talking about here relies on experimental features. π€£
Hah yeah, best not link experimental features together, by their very nature they're subject to change and it'd be very unintuitive. Also consider where goal templates are used, but they're not linked to schedules(raises hand) or schedules don't even have a name (raises hand again). - Actually this last point made me go and check, names for schedules is actually something that was added after AB went open source, which explains why none of mine have a name, it just wasn't an option at the time.
What did you think of my thoughts above about keeping the two approaches separate? One set of forecasts by schedules transactions, the other by transactions.
I wanted to say thanks for working on this feature ... I've been following along this discussion and just wanted to offer up my personal use case, and why I would find a forecast simply based on scheduled transactions incredibly useful. I personally would not find it misleading at all.
To keep it simple, you could distill my budget into 3 working accounts: Checking, Savings, and Credit Card. All my daily spend like groceries, dining, some scheduled bills happen on the credit card. I'm fortunate enough to be able to pay off that credit card monthly and not carry over a balance (just collect points :smile:). I would not necessarily be interested in forecasting what my credit card balance is. It's highly variable, and any guesstimate is likely to be wrong.
What I do want to forecast: the daily balance on my checking account.
The paycheck comes in; the mortgage goes out; the credit card bill gets paid; every 6 months i pay auto insurance; twice a year i pay property tax; i pay myself first by periodically sweeping some cash into retirement accounts; etc.... all of these things are scheduled transactions for me and happen on various days throughout the month. The day those transactions fall on matter to me. I might have set aside some cash and budgeted monthly for the large expenses (keeping it in a high interest savings account, for example), but I need to make sure the funds are in the checking account when that payment is scheduled to go... so that's where I find this forecasting to be a killer feature -- what's my projected daily balance in the checking account when all those scheduled transactions are due to post? Do i need to move funds around? Is my checking balance too low (i need to transfer from savings)? or is it too high (why get 0% interest if I don't need immediate access to those funds)?
This use case is also my motivation for the feature i submitted (and I'm willing to implement if the maintainers would accept a PR): https://github.com/actualbudget/actual/issues/2148.
Hope you found this helpful! Thanks again for everyone's hard work. I really do appreciate it. After using Quicken for almost 20 years, I'm finding this app to be a breath of fresh air. :rocket:
Thanks for working on this mk, very excited to see this go live as it is the main missing item stoping me moving over from gnucash.
My two cents. For stage one, As you said I think utilising budgets is key to projecting, and the simplest approach to begin with. Keeping it simple and utilising these as a net expense no matter which accounts are selected. As others have said this wonβt take into account out of the ordinary spends like holidays etc. but this will allow people to understand what they could afford to spend on a holiday in x months time. if they stick with there expected budgets that is.
Looking at smarter ways of doing this (I.e averaging transactions from the same week in the last few years) can then be looked at as a phase 2. This would be cool, but I think it would only be useful for the tenured user and not for those just starting out.
One option is to have budget as a Sesperate line item in the account splice allowing you to include it as an expense if wanted. But also can be toggled of aswell. keeping the account level splice I think is key as you may want to exclude illiquid assets from this projection. I.e when projecting 10 years down the line I would want to see house etc to view total net worth. But when looking at the next few months I would want to exclude this as Iβm not going to sell it to go on holiday.
Should a transfer to an off budget account show as an expense/income? Currently in the historical cashflow they don't... So I've kept that convention.
Not sure how this should be handled either, an off budget account is often used to represent a debt, which is an expense, but this isn't always the case. Probably best to follow as-is for now and it could be addressed separately if someone wishes to.
This is where https://github.com/actualbudget/actual/issues/2021 is needed and should be a priority so that transactions can be more appropriately classified as expenses and savings (as opposed to the "transfer" catchall). As it's currently set up, following the recommended workflow for new users, where savings accounts are off-budget accounts, this logically implies the opposite and that transfers should lean closer to defaulting as "savings". I agree that it's probably best to leave as-is (which is as that excluded catchall) for now.
Mostly bringing this up to try to tie the various enhancement issues together for this project and to raise awareness since I don't think enough people are aware of the request in Issue #2021.
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This PR was closed because it has been stalled for 5 days with no activity.
I know this one is closed but I wanted to put my two cents in as it's getting some interest on the discord channel right now. Reading through the comments I don't know if the use case for for this is clear.
There appear to be some people that want to find out what's going to happen with their cashflow assuming they follow their budget and nothing changes. While I understand that I don't think we need a tool / report to tell us that. It's just the inflow - outflow * a number of months.
Where I see this tool being useful is in planning future events / changes in the budget / income to better understand our future financial position.
- If I have to save for x months what's going to happen?
- If I stop paying for daycare for the summer what's my budget going to look like
- When I get that raise in 6 months how does that affect my future outlook.
While this could (and should) take the current budget / income as a baseline, users should be able to manipulate the future values to account for anticipated events. Lunchmoney actually had a beta tool that did this alright, you put in the start and stop of the "event", the monetary change per month, and it calculated your future outlook.
Actual is really good at looking at the past so you can plan your very short term spending. But where it falls down (and most other budgeting software does as well) is we don't have a way to get a long term focus on the future. Ironically the long term view may actually cause you to go back and adjust your short term so I'd argue it's something important to pursue.
I'm new to Actual but I have to agree with @latetedemelon. It feels like looking down a foggy street coming from a long-term projected report budget. Sure, I can see what's ahead but I don't really know where I'm going.
I do also agree with @jasonmichalski, a projected account balance would be extremely useful on top of general cashflow / net worth projection.
