[GH-ISSUE #6134] [Feedback]: Crossover point report #16853

New Issue

@tabedzki commented on GitHub (Nov 16, 2025):

When using the test budget file, if I click 3 months, 6 months or 1 year or All time, the tool reacts normally. If I click the other options (YTD, Previous YTD, or Last year), the app goes black and I have to reload the page to recover.

Edit: no errors in the dev console or in the terminal running yarn start.

@tabedzki commented on GitHub (Nov 16, 2025): When using the test budget file, if I click `3 months`, `6 months` or `1 year` or `All time`, the tool reacts normally. If I click the other options (`YTD`, `Previous YTD`, or `Last year`), the app goes black and I have to reload the page to recover. Edit: no errors in the dev console or in the terminal running `yarn start`.

GiteaMirror commented

@jonner commented on GitHub (Nov 18, 2025):

I just tried this out with my current budget file, and it could not calculate a crossover point at first. I had to expend a fair bit of mental energy figuring out why the report didn't give useful information. As far as I can tell, it's almost all because it defaulted to linear expense projection type. My budget file only has about 6 months of data in it, and I have recently had some larger expenses (child entering college, for example), so this report thinks that my average monthly expenses are rising at a relatively high rate. Based on the graph that it shows, it thinks that my expenses will be over $50,000/mo in a few years and continue rising.

That's just completely nonsensical. I cannot think of a single case where somebody's monthly expenses would follow a linear projection, even if the user had a much longer budget history and the data was relatively stable. Even a small linear slope will result in a pretty significant change in expenses over e.g. 40 years. In the opposite scenario where recent months expenses were lower, I can imagine the linear projection predicting that I will have negative monthly expenses after a number of years. That doesn't provide a user any useful information about their crossover point. So at a minimum, I don't think that linear projection should be the default. In fact, I don't think that it should even be an option, since I can't imagine a scenario where it would provide useful information. Or am I missing something?
(I don't mean this to sound overly critical. I love the feature, and thank you to whoever added it)

@jonner commented on GitHub (Nov 18, 2025): I just tried this out with my current budget file, and it could not calculate a crossover point at first. I had to expend a fair bit of mental energy figuring out why the report didn't give useful information. As far as I can tell, it's almost all because it defaulted to linear expense projection type. My budget file only has about 6 months of data in it, and I have recently had some larger expenses (child entering college, for example), so this report thinks that my average monthly expenses are rising at a relatively high rate. Based on the graph that it shows, it thinks that my expenses will be over $50,000/mo in a few years and continue rising. <img width="1403" height="894" alt="Image" src="https://github.com/user-attachments/assets/e94c97cd-df7c-46fe-960c-0607cbddaf7c" /> That's just completely nonsensical. I cannot think of a single case where somebody's monthly expenses would follow a linear projection, even if the user had a much longer budget history and the data was relatively stable. Even a small linear slope will result in a pretty significant change in expenses over e.g. 40 years. In the opposite scenario where recent months expenses were lower, I can imagine the linear projection predicting that I will have negative monthly expenses after a number of years. That doesn't provide a user any useful information about their crossover point. So at a minimum, I don't think that linear projection should be the default. In fact, I don't think that it should even be an option, since I can't imagine a scenario where it would provide useful information. Or am I missing something? (I don't mean this to sound overly critical. I love the feature, and thank you to whoever added it)

GiteaMirror commented

@jonner commented on GitHub (Dec 3, 2025):

I have another issue with the chart after playing with it a bit more. I have selected the "hampel filtered median" projection. In the most recent month of my budget, I happened to have unusually low expenses, which caused my expense line to drop below my 'investment income' line for one month. So this report now thinks that due to this unusual low expense month, I've reached my crossover point:

The help text in the popup for the "expense projection type" option suggests that it remove outliers before calculating a median value, but apparently no median or projection is even calculated when the most recent month has expenses below investment income.

@jonner commented on GitHub (Dec 3, 2025): I have another issue with the chart after playing with it a bit more. I have selected the "hampel filtered median" projection. In the most recent month of my budget, I happened to have unusually low expenses, which caused my expense line to drop below my 'investment income' line for one month. So this report now thinks that due to this unusual low expense month, I've reached my crossover point: <img width="1208" height="828" alt="Image" src="https://github.com/user-attachments/assets/00b9da6e-2ac6-4014-bffd-fc5217f75ff4" /> The help text in the popup for the "expense projection type" option suggests that it remove outliers before calculating a median value, but apparently no median or projection is even calculated when the most recent month has expenses below investment income.

GiteaMirror commented

2026-04-14 19:51:17 -05:00

@jonner commented on GitHub (Dec 3, 2025):

Another nice thing that could be added to this graph is a way for a user to manually alter some of the calculated values.

On the expense side: perhaps I want to travel a lot in retirement so I want to plan for expenses to be 120% of my current median monthly expenses. Or perhaps I plan to live frugally in retirement and only need to reach 90% of my current monthly expenses. It would be nice to offer the user a way to alter the target monthly income in some way.

On the income side: it would also be nice to consider off-budget 'fixed income' sources in the calculations. For example, in the US, I might want to include an estimated monthly social security payment as part of my income, or monthly income from a defined-benefit pension. If there were an input box where a user could enter these sorts of fixed income sources, they could be added to the calculated "investment income" value to arrive at a more complete picture of retirement income.

@jonner commented on GitHub (Dec 3, 2025): Another nice thing that could be added to this graph is a way for a user to manually alter some of the calculated values. On the expense side: perhaps I want to travel a lot in retirement so I want to plan for expenses to be 120% of my current median monthly expenses. Or perhaps I plan to live frugally in retirement and only need to reach 90% of my current monthly expenses. It would be nice to offer the user a way to alter the target monthly income in some way. On the income side: it would also be nice to consider off-budget 'fixed income' sources in the calculations. For example, in the US, I might want to include an estimated monthly social security payment as part of my income, or monthly income from a defined-benefit pension. If there were an input box where a user could enter these sorts of fixed income sources, they could be added to the calculated "investment income" value to arrive at a more complete picture of retirement income.

GiteaMirror commented

@sebastianfredette commented on GitHub (Dec 3, 2025):

I noticed the warning "Historical return calculation includes contributions and may not reflect actual investment performance," and I think that's well put. But I do wonder if, instead of either using the over-inflated return estimate (factoring in contributions) or a rule-of-thumb return (7% or so), we could do some combination of the two.

Basically, could we put in an expected rate of return as well as an expected monthly contribution? That way monthly growth due to contributions would be calculated linearly while investment return would be calculated exponentially.

@sebastianfredette commented on GitHub (Dec 3, 2025): I noticed the warning "Historical return calculation includes contributions and may not reflect actual investment performance," and I think that's well put. But I do wonder if, instead of either using the over-inflated return estimate (factoring in contributions) or a rule-of-thumb return (7% or so), we could do some combination of the two. Basically, could we put in an expected rate of return **as well as** an expected monthly contribution? That way monthly growth due to contributions would be calculated linearly while investment return would be calculated exponentially.

GiteaMirror commented

2026-04-14 19:51:17 -05:00

@mchal commented on GitHub (Dec 3, 2025):

I'm using version 25.12.0 released today.

Same problem with (YTD, Previous YTD, or Last year) - report goes blank; nothing in the console.

Feedback from me:

It would be great to show within a tooltip or somewhere what is projected Net worth based on selected income accounts.
there is no filter on expense categories which in my opinion is needed -
In my scenario - I'm using tags to exclude some expenses so that I can see how much I really spend monthly. If I have a one off big purchase on behalf of my company then it will inflate my "Target Monthly Income" - that's not my typical expense (in other reports I'm using tag "#company" to exclude those expenses)
~~Target Monthly Income is wrong when one specific "expense category" is excluded, i.e. stays the same regardless of date range (it works fine with others)~~
EDIT: I think I was wrong - I misunderstood how monthly target income is calculated. I thought it's average of expenses for the provided date range, but it's just last month.

‼️ ~~Example when it's wrong:~~

✅ ~~Example when it's good:~~

@mchal commented on GitHub (Dec 3, 2025): I'm using version 25.12.0 released today. Same problem with (YTD, Previous YTD, or Last year) - report goes blank; nothing in the console. Feedback from me: - It would be great to show within a tooltip or somewhere what is projected Net worth based on selected income accounts. - there is no filter on expense categories which in my opinion is needed - In my scenario - I'm using tags to exclude some expenses so that I can see how much I really spend monthly. If I have a one off big purchase on behalf of my company then it will inflate my "Target Monthly Income" - that's not my typical expense (in other reports I'm using tag "#company" to exclude those expenses) - ~Target Monthly Income is wrong when one specific "expense category" is excluded, i.e. stays the same regardless of date range (it works fine with others)~ EDIT: I think I was wrong - I misunderstood how monthly target income is calculated. I thought it's average of expenses for the provided date range, but it's just last month. ‼️ ~Example when it's wrong:~ <img width="1262" height="204" alt="Image" src="https://github.com/user-attachments/assets/af95fb5c-2c47-4ada-a754-e658c261f25b" /> <img width="1262" height="166" alt="Image" src="https://github.com/user-attachments/assets/d71d0929-db4e-488e-95bd-b1ac82cf73a3" /> --- ✅ ~Example when it's good:~ <img width="1252" height="212" alt="Image" src="https://github.com/user-attachments/assets/c96729b3-a509-4f43-ab83-f2705941213d" /> <img width="1264" height="211" alt="Image" src="https://github.com/user-attachments/assets/5e043960-feb3-4b6f-a95e-a2a8f3e04922" />

GiteaMirror commented

2026-04-14 19:51:17 -05:00

@TerborX commented on GitHub (Dec 4, 2025):

Additional thoughts:

Allow the use of tag filters; i have a lot of expenses tagged as kid expenses that will go away in the future. It would be good to predict spending without those amounts
Check out Beyond Rule 4. This site is a good example of crossover calculation options that was made to work with nYNAB. It has some of the options/features suggested by @jonner

@TerborX commented on GitHub (Dec 4, 2025): Additional thoughts: - Allow the use of tag filters; i have a lot of expenses tagged as kid expenses that will go away in the future. It would be good to predict spending without those amounts - Check out [Beyond Rule 4](https://beyondrule4.jmmorrissey.com/forecasting). This site is a good example of crossover calculation options that was made to work with nYNAB. It has some of the options/features suggested by @jonner

GiteaMirror commented

2026-04-14 19:51:18 -05:00

@dojoca commented on GitHub (Dec 5, 2025):

Additional thoughts:

* Allow the use of tag filters; i have a lot of expenses tagged as kid expenses that will go away in the future. It would be good to predict spending without those amounts

* Check out [Beyond Rule 4](https://beyondrule4.jmmorrissey.com/forecasting). This site is a good example of crossover calculation options that was made to work with nYNAB. It has some of the options/features suggested by [@jonner](https://github.com/jonner)

Wow that BeyondRule4 site is really good. Hopefully we get somethng similar to use with ActualBudget.

@dojoca commented on GitHub (Dec 5, 2025): > Additional thoughts: > > * Allow the use of tag filters; i have a lot of expenses tagged as kid expenses that will go away in the future. It would be good to predict spending without those amounts > > * Check out [Beyond Rule 4](https://beyondrule4.jmmorrissey.com/forecasting). This site is a good example of crossover calculation options that was made to work with nYNAB. It has some of the options/features suggested by [@jonner](https://github.com/jonner) Wow that BeyondRule4 site is really good. Hopefully we get somethng similar to use with ActualBudget.

GiteaMirror commented

2026-04-14 19:51:18 -05:00

@nmathey commented on GitHub (Dec 6, 2025):

Great features: loving it!
Would it be possible to include inflation parameter?

@nmathey commented on GitHub (Dec 6, 2025): Great features: loving it! Would it be possible to include inflation parameter?

GiteaMirror commented

2026-04-14 19:51:18 -05:00

@youngcw commented on GitHub (Dec 17, 2025):

Im noticing that the dashboard card shows a different number than if I click into the report. If I save the report again it seems to fix the problem. Ill see if I can recreate it, but my guess is that it has something to do with a month rolling over and certain values changing

@youngcw commented on GitHub (Dec 17, 2025): Im noticing that the dashboard card shows a different number than if I click into the report. If I save the report again it seems to fix the problem. Ill see if I can recreate it, but my guess is that it has something to do with a month rolling over and certain values changing

GiteaMirror commented

@Lunchtime0614 commented on GitHub (Dec 17, 2025):

I'm not sure I understand how to set it up - do I create at least one account that is off-budget called retirement with a single line for beginning balance - nothing else just what my retirement account balance is? Then just pick budget categories in the report that I expect to continue in retirement and then just the one off-budget income source - the 'retirement' account?

If this is it - I tried this, and it showed 0 for income - just flatlined at 0 even though the investment account had a value and I entered an expected rate of return.

@Lunchtime0614 commented on GitHub (Dec 17, 2025): I'm not sure I understand how to set it up - do I create at least one account that is off-budget called retirement with a single line for beginning balance - nothing else just what my retirement account balance is? Then just pick budget categories in the report that I expect to continue in retirement and then just the one off-budget income source - the 'retirement' account? If this is it - I tried this, and it showed 0 for income - just flatlined at 0 even though the investment account had a value and I entered an expected rate of return.

GiteaMirror commented

@sjones512 commented on GitHub (Dec 18, 2025):

@Lunchtime0614 - That is one way to do it, however there is no requirement that your retirement account be off-budget or that it only has a single line for beginning balance. You can have other transactions in the account just like you normally would any other account.

Yes, you want to pick the budget categories in the report that you expect to continue in retirement. For the income source you can select as many accounts as you'd like, their balance will just be lumped together.

My guess for why you are seeing 0 is that the report currently does not include the current month. This is because it tries to calculate your average expenses, and those will be artificially low in the current month before all of the money for the month has been spent. If your beginning balance for your retirement account is in December, the chart will not see any balance in your retirement account. You can either entire the balance the account had in November, or wait until January.

If this isn't the issue, maybe you can provide some screen shots to better help us understand what might be happening.

@youngcw I have a feeling you are correct and it is similar to the changes that #6383 . I forgot to update the Card when updating the main chart. I'll try and get a PR together soon.

@sjones512 commented on GitHub (Dec 18, 2025): @Lunchtime0614 - That is one way to do it, however there is no requirement that your retirement account be off-budget or that it only has a single line for beginning balance. You can have other transactions in the account just like you normally would any other account. Yes, you want to pick the budget categories in the report that you expect to continue in retirement. For the income source you can select as many accounts as you'd like, their balance will just be lumped together. My guess for why you are seeing 0 is that the report currently does not include the current month. This is because it tries to calculate your average expenses, and those will be artificially low in the current month before all of the money for the month has been spent. If your beginning balance for your retirement account is in December, the chart will not see any balance in your retirement account. You can either entire the balance the account had in November, or wait until January. If this isn't the issue, maybe you can provide some screen shots to better help us understand what might be happening. @youngcw I have a feeling you are correct and it is similar to the changes that #6383 . I forgot to update the Card when updating the main chart. I'll try and get a PR together soon.

GiteaMirror commented

@Lunchtime0614 commented on GitHub (Dec 18, 2025):

@Lunchtime0614 - That is one way to do it, however there is no requirement that your retirement account be off-budget or that it only has a single line for beginning balance. You can have other transactions in the account just like you normally would any other account.

Yes, you want to pick the budget categories in the report that you expect to continue in retirement. For the income source you can select as many accounts as you'd like, their balance will just be lumped together.

My guess for why you are seeing 0 is that the report currently does not include the current month. This is because it tries to calculate your average expenses, and those will be artificially low in the current month before all of the money for the month has been spent. If your beginning balance for your retirement account is in December, the chart will not see any balance in your retirement account. You can either entire the balance the account had in November, or wait until January.

If this isn't the issue, maybe you can provide some screen shots to better help us understand what might be happening.

Yes this did solve the problem I was having. Thanks!

@Lunchtime0614 commented on GitHub (Dec 18, 2025): > [@Lunchtime0614](https://github.com/Lunchtime0614) - That is one way to do it, however there is no requirement that your retirement account be off-budget or that it only has a single line for beginning balance. You can have other transactions in the account just like you normally would any other account. > > Yes, you want to pick the budget categories in the report that you expect to continue in retirement. For the income source you can select as many accounts as you'd like, their balance will just be lumped together. > > My guess for why you are seeing 0 is that the report currently does not include the current month. This is because it tries to calculate your average expenses, and those will be artificially low in the current month before all of the money for the month has been spent. If your beginning balance for your retirement account is in December, the chart will not see any balance in your retirement account. You can either entire the balance the account had in November, or wait until January. > > If this isn't the issue, maybe you can provide some screen shots to better help us understand what might be happening. > Yes this did solve the problem I was having. Thanks!

GiteaMirror commented

2026-04-14 19:51:20 -05:00

@Daedalus359 commented on GitHub (Jan 2, 2026):

All of the features for projections for returns and expenses produce unbelievable output on my Off budget account data for reasons others have already discussed. of the two implemented options, I agree that the median should be the default for expense projection. The return projection relies on assumptions that apply to a minority of people (those who have been "coastFI" for the entire analysis period, basically).

I think that a manually entered estimated return should be the default for return projections, and there should also be a space to manually input a monthly contribution of $x/mo. The monthly contribution number could also be used to better approximate a historical return based on real account data if the user's monthly contributions have been fairly steady over the analysis period. Getting good results with this approach would likely require setting different analysis periods for spending vs returns calculations for a lot of people.

While making these changes to manually specified parameters would bring the tool in line with already available web tools such as this one, just having a version of that kind of tool integrated into Actual which uses median spending data and which stays up to date with my current account balances would be helpful to me.

The current tool is already useful after some tweaks, and a lot of the pieces needed for my ideal version are already in place. Thanks for making it.

@Daedalus359 commented on GitHub (Jan 2, 2026): All of the features for projections for returns and expenses produce unbelievable output on my Off budget account data for reasons others have already discussed. of the two implemented options, I agree that the median should be the default for expense projection. The return projection relies on assumptions that apply to a minority of people (those who have been "coastFI" for the entire analysis period, basically). I think that a manually entered estimated return should be the default for return projections, and there should also be a space to manually input a monthly contribution of $x/mo. The monthly contribution number could also be used to better approximate a historical return based on real account data if the user's monthly contributions have been fairly steady over the analysis period. Getting good results with this approach would likely require setting different analysis periods for spending vs returns calculations for a lot of people. While making these changes to manually specified parameters would bring the tool in line with already available web tools such as [this one](https://networthify.com/calculator/earlyretirement?income=50000&initialBalance=0&expenses=20000&annualPct=5&withdrawalRate=4), just having a version of that kind of tool integrated into Actual which uses median spending data and which stays up to date with my current account balances would be helpful to me. The current tool is already useful after some tweaks, and a lot of the pieces needed for my ideal version are already in place. Thanks for making it.

GiteaMirror commented

@jonner commented on GitHub (Jan 6, 2026):

It might also be nice to add a non-filtered median as a projection type to the crossover point report. If I have a large expense that is due once per year, I don't necessarily want to filter out that "outlier" expense from my projections since I will (probably) need to that that expense during retirement as well.

@jonner commented on GitHub (Jan 6, 2026): It might also be nice to add a non-filtered median as a projection type to the crossover point report. If I have a large expense that is due once per year, I don't necessarily want to filter out that "outlier" expense from my projections since I will (probably) need to that that expense during retirement as well.

GiteaMirror commented

2026-04-14 19:51:20 -05:00

@Daedalus359 commented on GitHub (Jan 6, 2026):

I just took a look at calculateHampelFilteredMedian, and there are a few things about it that don't make sense to me. Removing outliers just to calculate a median seems unlikely to have a meaningful impact on the final value. The use of the constant 1.4826 in the calculations suggests an assumption that the monthly spending data is sampled from a gaussian distribution. This is a typical and reasonable assumption to make, but it's also one which basically guarantees that the Hampel filtering won't make much difference for anyone with more than a few months of spending data. It doesn't make a big difference to leave it in, but it's worth keeping in mind when thinking about comments like the one above.

A Hampel filtered mean could be useful. A median yearly mean could also be good, and that's probably the best choice of the three for dealing with periodic jumps in monthly spending.

@Daedalus359 commented on GitHub (Jan 6, 2026): I just took a look at `calculateHampelFilteredMedian`, and there are a few things about it that don't make sense to me. Removing outliers just to calculate a median seems unlikely to have a meaningful impact on the final value. The use of the constant 1.4826 in the calculations suggests an assumption that the monthly spending data is sampled from a gaussian distribution. This is a typical and reasonable assumption to make, but it's also one which basically guarantees that the Hampel filtering won't make much difference for anyone with more than a few months of spending data. It doesn't make a big difference to leave it in, but it's worth keeping in mind when thinking about comments like the one above. A Hampel filtered mean could be useful. A median yearly mean could also be good, and that's probably the best choice of the three for dealing with periodic jumps in monthly spending.

GiteaMirror commented

2026-04-14 19:51:20 -05:00

@jonner commented on GitHub (Jan 6, 2026):

@Daedalus359 It does in fact have a meaningful impact on the final value in certain cases. For instance, in my budget, I have only six months of data, and in my crossover report, I have excluded an expense category that includes things like piano lesson tuition for my kids. But after toggling this category to include these extra expenses in the calculations, it made the crossover date sooner. Apparently the month that I paid the semester's piano lesson bill was a relatively low expense month and when I removed the piano lesson expense, it was low enough to be considered an outlier and was removed from analysis. But when adding that expense to the analysis, that month just became a slightly-below average expense month and therefore reduced the median value calculation.

What do you mean by "median yearly mean"? And how would that interact with the different date ranges you can select for the report?

@jonner commented on GitHub (Jan 6, 2026): @Daedalus359 It does in fact have a meaningful impact on the final value in certain cases. For instance, in my budget, I have only six months of data, and in my crossover report, I have excluded an expense category that includes things like piano lesson tuition for my kids. But after toggling this category to *include* these extra expenses in the calculations, it made the crossover date **sooner**. Apparently the month that I paid the semester's piano lesson bill was a relatively low expense month and when I removed the piano lesson expense, it was low enough to be considered an outlier and was removed from analysis. But when *adding* that expense to the analysis, that month just became a slightly-below average expense month and therefore reduced the median value calculation. What do you mean by "median yearly mean"? And how would that interact with the different date ranges you can select for the report?

GiteaMirror commented

2026-04-14 19:51:21 -05:00

@Daedalus359 commented on GitHub (Jan 6, 2026):

That's a fair point. I guess Actual is a new enough project to have a significant number of users with only a few months of budget data. I'm someone who has almost a decade of data imported from YNAB, so that's the case I was thinking about.

Median yearly mean could be:

Group monthly spending numbers by calendar year
Calculate the monthly mean for each of those groups
Take the median of those values

This is admittedly not a good fit for a situation like yours, but I do think it could work well for people with seasonal spending patterns (a yearly vacation, for example) but who also have a handful of rare large expenses, e.g. house down payment / had to replace the car. It might produce similar output to a Hampel filtered mean, though, and the latter might be easier to implement via a minor tweak to the existing code.

Your case might be one where it makes sense to just let people manually input certain parameters for the report. The other reports already present in Actual would allow you to take a look at that much data and, combined with your own additional knowledge, get a reasonable guess for the monthly value you would want to project.

@Daedalus359 commented on GitHub (Jan 6, 2026): That's a fair point. I guess Actual is a new enough project to have a significant number of users with only a few months of budget data. I'm someone who has almost a decade of data imported from YNAB, so that's the case I was thinking about. Median yearly mean could be: 1. Group monthly spending numbers by calendar year 2. Calculate the monthly mean for each of those groups 3. Take the median of those values This is admittedly not a good fit for a situation like yours, but I do think it could work well for people with seasonal spending patterns (a yearly vacation, for example) but who also have a handful of rare large expenses, e.g. house down payment / had to replace the car. It might produce similar output to a Hampel filtered mean, though, and the latter might be easier to implement via a minor tweak to the existing code. Your case might be one where it makes sense to just let people manually input certain parameters for the report. The other reports already present in Actual would allow you to take a look at that much data and, combined with your own additional knowledge, get a reasonable guess for the monthly value you would want to project.

GiteaMirror commented

2026-04-14 19:51:21 -05:00

@sjones512 commented on GitHub (Jan 7, 2026):

Perhaps it would be best to get rid of the "Expense Projection Type" parameter altogether and just replace it with an unfiltered median or mean, which would simplify the report.

The two shortcoming I see with that are

Without the hampel filter, the only way to exclude anomalous transactions is budget category filter. Perhaps a better solution for this would be adding a secondary way to exclude transactions such as a tags.
I liked the idea of trying to create a positive feedback loop if expenses have been decreasing in recent months. However, the Linear Trend doesn't accomplish this well. One possibility could be weighting more recent months, but would probably require separate parameters to allow configuring the weighting. I'm not sure if there is a good way to do this that isn't overly complicated and also susceptible to magnifying a recent expensive month.

Good discussion. In the mean time I have been using the Hampel Filtered Median and it does seem to work ok.

@sjones512 commented on GitHub (Jan 7, 2026): Perhaps it would be best to get rid of the "Expense Projection Type" parameter altogether and just replace it with an unfiltered median or mean, which would simplify the report. The two shortcoming I see with that are 1. Without the hampel filter, the only way to exclude anomalous transactions is budget category filter. Perhaps a better solution for this would be adding a secondary way to exclude transactions such as a tags. 2. I liked the idea of trying to create a positive feedback loop if expenses have been decreasing in recent months. However, the Linear Trend doesn't accomplish this well. One possibility could be weighting more recent months, but would probably require separate parameters to allow configuring the weighting. I'm not sure if there is a good way to do this that isn't overly complicated and also susceptible to magnifying a recent expensive month. Good discussion. In the mean time I have been using the Hampel Filtered Median and it does seem to work ok.

GiteaMirror commented

2026-04-14 19:51:21 -05:00

@jonner commented on GitHub (Jan 8, 2026):

Here's what I'm currently playing with:

Sumary:

Instead of selecting categories by clicking checkboxes in a list, use the existing 'filter' infrastructure that is used to filter transactions in other reports or in your account transaction table. This allows you to include or exclude things other than category (e.g. payees, tags, etc). The UI isn't great, but it does allow a lot more flexibility.
the target income adjustment was already merged in #6373
Removed the projection type and just use the default for now. As I mentioned here, I'm thinking about replacing this with a checkbox named something like "filter outliers" which just switches between plain median and hampel filtered median calculations.
Change the "estimated return" input field to a "use custom growth projections" checkbox.
- If the box is unchecked, it uses the calculated historical return for the selected income accounts.
- If it is checked, it shows additional input fields that allow you to specify a return rate (APY) and a monthly contribution amount

Comments welcome. UX is not my strong suit, so the UI is a little bit rough, but as a proof of concept I think it works pretty well.

@jonner commented on GitHub (Jan 8, 2026): Here's what I'm currently playing with: <img width="1415" height="895" alt="Image" src="https://github.com/user-attachments/assets/f73e8083-8805-459b-ab00-f461da670a70" /> Sumary: - Instead of selecting categories by clicking checkboxes in a list, use the existing 'filter' infrastructure that is used to filter transactions in other reports or in your account transaction table. This allows you to include or exclude things other than category (e.g. payees, tags, etc). The UI isn't great, but it does allow a lot more flexibility. - the target income adjustment was already merged in #6373 - Removed the projection type and just use the default for now. As I mentioned [here](https://github.com/actualbudget/actual/pull/6589#issuecomment-3723939813), I'm thinking about replacing this with a checkbox named something like "filter outliers" which just switches between plain median and hampel filtered median calculations. - Change the "estimated return" input field to a "use custom growth projections" checkbox. - If the box is unchecked, it uses the calculated historical return for the selected income accounts. - If it is checked, it shows additional input fields that allow you to specify a return rate (APY) and a monthly contribution amount Comments welcome. UX is not my strong suit, so the UI is a little bit rough, but as a proof of concept I think it works pretty well.

GiteaMirror commented

2026-04-14 19:51:22 -05:00

@TerborX commented on GitHub (Jan 8, 2026):

I really like the additions of the target income adjustment and the custom growth option (especially expected monthly contribution piece of that).

Having the filter option for expenses is definitely something that interests me. Without playing with it, I'm sure if they should fully replace the category picker that currently exists. Sometimes the checkboxes are easier to manipulate, but the quick switch ability of saved filters might be enough of a favorable trade-off.

Any thoughts on adding additional crossover points? They might be useful for some folks and of course there are various interpretations of what these mean. I got my definitions from: https://choosefi.com/podcast-episode/032-milestones-fi

FU Money : 2-3 years of yearly expenses saved up
Half FI : halfway to FI
Crossover : think this is technically savings grows faster in year than current income
Flex FI : 20x annual spend
FI : 25x annual spend
Fat FI : 30x annual spend

@TerborX commented on GitHub (Jan 8, 2026): I really like the additions of the target income adjustment and the custom growth option (especially expected monthly contribution piece of that). Having the filter option for expenses is definitely something that interests me. Without playing with it, I'm sure if they should fully replace the category picker that currently exists. Sometimes the checkboxes are easier to manipulate, but the quick switch ability of saved filters might be enough of a favorable trade-off. Any thoughts on adding additional crossover points? They might be useful for some folks and of course there are various interpretations of what these mean. I got my definitions from: https://choosefi.com/podcast-episode/032-milestones-fi - FU Money : 2-3 years of yearly expenses saved up - Half FI : halfway to FI - Crossover : think this is technically savings grows faster in year than current income - Flex FI : 20x annual spend - FI : 25x annual spend - Fat FI : 30x annual spend

GiteaMirror commented

2026-04-14 19:51:22 -05:00

@sjones512 commented on GitHub (Jan 8, 2026):

With changes for contributions, I would consider having the same tools and methods decided on for Expenses to use for Contributions.

So you could specify which category(s) are contributions and we use the same median method for projecting them in the future.

I guess a downside is you would still probably need a text box for contributions for payroll deductions that aren't tracked in the budget, and supporting both might crowd the UI.

But the power of having this in the budget tool and not a separate spreadsheet is using the Actual data.

@sjones512 commented on GitHub (Jan 8, 2026): With changes for contributions, I would consider having the same tools and methods decided on for Expenses to use for Contributions. So you could specify which category(s) are contributions and we use the same median method for projecting them in the future. I guess a downside is you would still probably need a text box for contributions for payroll deductions that aren't tracked in the budget, and supporting both might crowd the UI. But the power of having this in the budget tool and not a separate spreadsheet is using the Actual data.

GiteaMirror commented

2026-04-14 19:51:22 -05:00

@jonner commented on GitHub (Jan 8, 2026):

With changes for contributions, I would consider having the same tools and methods decided on for Expenses to use for Contributions.

So you could specify which category(s) are contributions and we use the same median method for projecting them in the future.

Hmm, I didn't even consider this, since it wouldn't really be useful to me. The majority of my retirement account contributions come from payroll deductions directly into an investment account and therefore are not even present in my on-budget transaction data. My (possibly ignorant) gut feeling is that the vast majority of people would not have complete retirement contribution information in their budget and therefore it probably isn't worth complicating the UI to add this feature. But I could be wrong about that.

@jonner commented on GitHub (Jan 8, 2026): > With changes for contributions, I would consider having the same tools and methods decided on for Expenses to use for Contributions. > > So you could specify which category(s) are contributions and we use the same median method for projecting them in the future. Hmm, I didn't even consider this, since it wouldn't really be useful to me. The majority of my retirement account contributions come from payroll deductions directly into an investment account and therefore are not even present in my on-budget transaction data. My (possibly ignorant) gut feeling is that the vast majority of people would not have complete retirement contribution information in their budget and therefore it probably isn't worth complicating the UI to add this feature. But I could be wrong about that.

GiteaMirror commented

2026-04-14 19:51:23 -05:00

@sjones512 commented on GitHub (Jan 8, 2026):

Agreed. I imagine I'm in the minority tracking payroll deductions in the budget.
But if we make the switch from the category selector to the more robust (and complex) transaction filter would you be able to select transactions by payee in off budget accounts that could be your payroll deducted contributions?

This also raises the thought of if there should be an "additional income" text box for people that like to try to include other retirement income that maybe be hard to track in the budget, like social security or a pension.

@sjones512 commented on GitHub (Jan 8, 2026): Agreed. I imagine I'm in the minority tracking payroll deductions in the budget. But if we make the switch from the category selector to the more robust (and complex) transaction filter would you be able to select transactions by payee in off budget accounts that could be your payroll deducted contributions? This also raises the thought of if there should be an "additional income" text box for people that like to try to include other retirement income that maybe be hard to track in the budget, like social security or a pension.

GiteaMirror commented

2026-04-14 19:51:23 -05:00

@TerborX commented on GitHub (Jan 9, 2026):

I also track payroll deductions so I have retirement contribution expense categories to exclude. Filtering transfers might work to exclude them for me since I show them that way.

@TerborX commented on GitHub (Jan 9, 2026): I also track payroll deductions so I have retirement contribution expense categories to exclude. Filtering transfers might work to exclude them for me since I show them that way.

GiteaMirror commented

2026-04-14 19:51:23 -05:00

@jonner commented on GitHub (Jan 9, 2026):

But if we make the switch from the category selector to the more robust (and complex) transaction filter would you be able to select transactions by payee in off budget accounts that could be your payroll deducted contributions?

Nope, I don't track my retirement account besides reconciling the total balance every so often. So contributions and investment growth are not distinguishable.

@jonner commented on GitHub (Jan 9, 2026): > But if we make the switch from the category selector to the more robust (and complex) transaction filter would you be able to select transactions by payee in off budget accounts that could be your payroll deducted contributions? Nope, I don't track my retirement account besides reconciling the total balance every so often. So contributions and investment growth are not distinguishable.

GiteaMirror commented

@sjones512 commented on GitHub (Jan 9, 2026):

Fair enough. I guess I didn't mean you individually, but that would be a use case we could support if we decided to try to use the Transaction Filter instead of the Category Filter for identifying contributions and projecting them.

@sjones512 commented on GitHub (Jan 9, 2026): Fair enough. I guess I didn't mean you individually, but that would be a use case we could support if we decided to try to use the Transaction Filter instead of the Category Filter for identifying contributions and projecting them.

GiteaMirror commented

@nmathey commented on GitHub (Jan 9, 2026):

Hi guys,
I’m not sure this is the right place to ask, but should we also consider the inflation rate? Would it make sense to include this parameter when estimating the target income?

@nmathey commented on GitHub (Jan 9, 2026): Hi guys, I’m not sure this is the right place to ask, but should we also consider the inflation rate? Would it make sense to include this parameter when estimating the target income?

GiteaMirror commented

@jonner commented on GitHub (Jan 9, 2026):

Hi guys, I’m not sure this is the right place to ask, but should we also consider the inflation rate? Would it make sense to include this parameter when estimating the target income?

There's already a PR for inflation: #6495

@jonner commented on GitHub (Jan 9, 2026): > Hi guys, I’m not sure this is the right place to ask, but should we also consider the inflation rate? Would it make sense to include this parameter when estimating the target income? There's already a PR for inflation: #6495

GiteaMirror commented

@sjones512 commented on GitHub (Jan 9, 2026):

I wonder if the inflation parameter is worth it? Can't it kind of be approximated by using the real return instead of the nominal return for the expected return?

@sjones512 commented on GitHub (Jan 9, 2026): I wonder if the inflation parameter is worth it? Can't it kind of be approximated by using the real return instead of the nominal return for the expected return?

GiteaMirror commented

@jonner commented on GitHub (Jan 9, 2026):

Yes, if you enter a custom 'estimated return' value, then you can make a conscious decision to discount that rate by the rate of expected inflation in order to approximate the inflation parameter. But this may not be obvious to the casual user, whereas if there was an inflation parameter with a reasonable default, then casual users would be more likely to make sane projections.

In addition, if you use the auto-calculated return rate, then inflation is not accounted for at all.

@jonner commented on GitHub (Jan 9, 2026): Yes, if you enter a custom 'estimated return' value, then you can make a conscious decision to discount that rate by the rate of expected inflation in order to approximate the inflation parameter. But this may not be obvious to the casual user, whereas if there was an inflation parameter with a reasonable default, then casual users would be more likely to make sane projections. In addition, if you use the auto-calculated return rate, then inflation is not accounted for at all.

GiteaMirror commented

@youngcw commented on GitHub (Jan 12, 2026):

Im still having issues with the dashboard card showing a different number than if I click into the report. Im guessing its something to do with the month change still.

@youngcw commented on GitHub (Jan 12, 2026): Im still having issues with the dashboard card showing a different number than if I click into the report. Im guessing its something to do with the month change still.

GiteaMirror commented

@sjones512 commented on GitHub (Jan 13, 2026):

@youngcw odd. Is it possible that the chart needs to be saved again after the latest changes were pushed?

@sjones512 commented on GitHub (Jan 13, 2026): @youngcw odd. Is it possible that the chart needs to be saved again after the latest changes were pushed?

GiteaMirror commented

@youngcw commented on GitHub (Jan 13, 2026):

@sjones512 I saved it again and there is still a difference in numbers.

@youngcw commented on GitHub (Jan 13, 2026): @sjones512 I saved it again and there is still a difference in numbers.

GiteaMirror commented

@youngcw commented on GitHub (Jan 21, 2026):

Is anyone else seeing an issue on edge where the graph constantly grows taller and taller? (when the report is opened)

@youngcw commented on GitHub (Jan 21, 2026): Is anyone else seeing an issue on edge where the graph constantly grows taller and taller? (when the report is opened)

GiteaMirror commented

@jonner commented on GitHub (Jan 21, 2026):

Is anyone else seeing an issue on edge where the graph constantly grows taller and taller? (when the report is opened)

I just noticed that. git bisect suggests the offending commit is de0f4e9440

@jonner commented on GitHub (Jan 21, 2026): > Is anyone else seeing an issue on edge where the graph constantly grows taller and taller? (when the report is opened) I just noticed that. git bisect suggests the offending commit is de0f4e9440d45c315b5a0520cba3b3dacf5179fd

GiteaMirror commented

@sjones512 commented on GitHub (Jan 22, 2026):

@youngcw Are you still seeing different numbers on the dashboard card and the full report? If so, are you able to share any more details. I'm not sure if it would be possible to share a meta object that reproduces the issue?

@sjones512 commented on GitHub (Jan 22, 2026): @youngcw Are you still seeing different numbers on the dashboard card and the full report? If so, are you able to share any more details. I'm not sure if it would be possible to share a `meta` object that reproduces the issue?

GiteaMirror commented

2026-04-14 19:51:27 -05:00

@youngcw commented on GitHub (Jan 22, 2026):

@youngcw Are you still seeing different numbers on the dashboard card and the full report? If so, are you able to share any more details. I'm not sure if it would be possible to share a meta object that reproduces the issue?

I am still seeing it. Making a brand new one also gives different numbers. Here is the export of that report. Doesn't seem to have anything special in it. Using a demo file I don't see the problem, just with my budget.

dashboard.json

@youngcw commented on GitHub (Jan 22, 2026): > [@youngcw](https://github.com/youngcw) Are you still seeing different numbers on the dashboard card and the full report? If so, are you able to share any more details. I'm not sure if it would be possible to share a `meta` object that reproduces the issue? I am still seeing it. Making a brand new one also gives different numbers. Here is the export of that report. Doesn't seem to have anything special in it. Using a demo file I don't see the problem, just with my budget. [dashboard.json](https://github.com/user-attachments/files/24800061/dashboard.json)

GiteaMirror commented

@ezgibas commented on GitHub (Jan 23, 2026):

Great feature! There seems to be a formatting issue on the right upper corner. (Screenshots: full screen vs. half screen on a 15.6 in laptop using Firefox)

@ezgibas commented on GitHub (Jan 23, 2026): Great feature! There seems to be a formatting issue on the right upper corner. (Screenshots: full screen vs. half screen on a 15.6 in laptop using Firefox) <img width="1338" height="631" alt="Image" src="https://github.com/user-attachments/assets/ca22ef60-5f40-4761-8400-ad52a3f0b430" /> <img width="606" height="587" alt="Image" src="https://github.com/user-attachments/assets/af6009be-77af-424c-951c-5ce995adf980" />

GiteaMirror commented

2026-04-14 19:51:27 -05:00

@Mikesco3 commented on GitHub (Jan 31, 2026):

I just tried this out with my current budget file, and it could not calculate a crossover point at first. I had to expend a fair bit of mental energy figuring out why the report didn't give useful information. As far as I can tell, it's almost all because it defaulted to linear expense projection type. My budget file only has about 6 months of data in it, and I have recently had some larger expenses (child entering college, for example), so this report thinks that my average monthly expenses are rising at a relatively high rate. Based on the graph that it shows, it thinks that my expenses will be over $50,000/mo in a few years and continue rising.
That's just completely nonsensical. I cannot think of a single case where somebody's monthly expenses would follow a linear projection, even if the user had a much longer budget history and the data was relatively stable. Even a small linear slope will result in a pretty significant change in expenses over e.g. 40 years. In the opposite scenario where recent months expenses were lower, I can imagine the linear projection predicting that I will have negative monthly expenses after a number of years. That doesn't provide a user any useful information about their crossover point. So at a minimum, I don't think that linear projection should be the default. In fact, I don't think that it should even be an option, since I can't imagine a scenario where it would provide useful information. Or am I missing something? (I don't mean this to sound overly critical. I love the feature, and thank you to whoever added it)

It should be an estimated moving average in my opinion... and to make it even better it would be nice if one could even chose the EMA size, (1 year, 6 months, 3 months), I feel that would show better info...

You could have two lines where based on one ema the proyection leads to one figure, and based on the other the projection leads to another.

@Mikesco3 commented on GitHub (Jan 31, 2026): > I just tried this out with my current budget file, and it could not calculate a crossover point at first. I had to expend a fair bit of mental energy figuring out why the report didn't give useful information. As far as I can tell, it's almost all because it defaulted to linear expense projection type. My budget file only has about 6 months of data in it, and I have recently had some larger expenses (child entering college, for example), so this report thinks that my average monthly expenses are rising at a relatively high rate. Based on the graph that it shows, it thinks that my expenses will be over $50,000/mo in a few years and continue rising. > > <img alt="Image" width="1403" height="894" src="https://private-user-images.githubusercontent.com/2267/515944652-e94c97cd-df7c-46fe-960c-0607cbddaf7c.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Njk4NDE1MDgsIm5iZiI6MTc2OTg0MTIwOCwicGF0aCI6Ii8yMjY3LzUxNTk0NDY1Mi1lOTRjOTdjZC1kZjdjLTQ2ZmUtOTYwYy0wNjA3Y2JkZGFmN2MucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDEzMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjAxMzFUMDYzMzI4WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NmZhNzNjNTQxNWEyMjNlMmZmZWM4ZTE1YjAwMzU1ZjM1MGNlMmZhZDUzMmNiYzljYjhiYTE0ZGFjY2ZiZDJlOSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.rOyyJhfqqW2Lkgm-i4UrLmR_bgtoVB1hHxaWoynyqlo"> > That's just completely nonsensical. I cannot think of a single case where somebody's monthly expenses would follow a linear projection, even if the user had a much longer budget history and the data was relatively stable. Even a small linear slope will result in a pretty significant change in expenses over e.g. 40 years. In the opposite scenario where recent months expenses were lower, I can imagine the linear projection predicting that I will have negative monthly expenses after a number of years. That doesn't provide a user any useful information about their crossover point. So at a minimum, I don't think that linear projection should be the default. In fact, I don't think that it should even be an option, since I can't imagine a scenario where it would provide useful information. Or am I missing something? (I don't mean this to sound overly critical. I love the feature, and thank you to whoever added it) It should be an estimated moving average in my opinion... and to make it even better it would be nice if one could even chose the EMA size, (1 year, 6 months, 3 months), I feel that would show better info... You could have two lines where based on one ema the proyection leads to one figure, and based on the other the projection leads to another.

GiteaMirror commented

2026-04-14 19:51:27 -05:00

@Mikhail773 commented on GitHub (Feb 6, 2026):

Curious if it would make sense to have more configurable custom return percentages and expected contributions. It would be feasible to expect higher returns further from retirement and for a more conservative portfolio mix closer to retirement. Maybe an option for a glide path or or something along those lines.

@Mikhail773 commented on GitHub (Feb 6, 2026): Curious if it would make sense to have more configurable custom return percentages and expected contributions. It would be feasible to expect higher returns further from retirement and for a more conservative portfolio mix closer to retirement. Maybe an option for a glide path or or something along those lines.

GiteaMirror commented

@youngcw commented on GitHub (Feb 12, 2026):

@sjones512 I think the difference in data between the dashboard card and the open report is because of months used. I get the same crossover date if I shift each month back by 1 in the open report

@youngcw commented on GitHub (Feb 12, 2026): @sjones512 I think the difference in data between the dashboard card and the open report is because of months used. I get the same crossover date if I shift each month back by 1 in the open report

GiteaMirror commented

@pstone05 commented on GitHub (Feb 12, 2026):

@youngcw Are you still seeing different numbers on the dashboard card and the full report? If so, are you able to share any more details. I'm not sure if it would be possible to share a meta object that reproduces the issue?

I am still seeing it. Making a brand new one also gives different numbers. Here is the export of that report. Doesn't seem to have anything special in it. Using a demo file I don't see the problem, just with my budget.

dashboard.json

For me it looks like the difference in Years to Retire between the dashboard card and the open report is due to hidden categories. When I select to show hidden categories and save the report the years to retire is then matches the dashboard card.

@pstone05 commented on GitHub (Feb 12, 2026): > > [@youngcw](https://github.com/youngcw) Are you still seeing different numbers on the dashboard card and the full report? If so, are you able to share any more details. I'm not sure if it would be possible to share a `meta` object that reproduces the issue? > > I am still seeing it. Making a brand new one also gives different numbers. Here is the export of that report. Doesn't seem to have anything special in it. Using a demo file I don't see the problem, just with my budget. > > [dashboard.json](https://github.com/user-attachments/files/24800061/dashboard.json) For me it looks like the difference in Years to Retire between the dashboard card and the open report is due to hidden categories. When I select to show hidden categories and save the report the years to retire is then matches the dashboard card.

GiteaMirror commented

@MatissJanis commented on GitHub (Apr 1, 2026):

@sjones512 just checking in: are there issues we should address for crossover reports before removing the feature flag? Would love to clean up the feature flag.

@MatissJanis commented on GitHub (Apr 1, 2026): @sjones512 just checking in: are there issues we should address for crossover reports before removing the feature flag? Would love to clean up the feature flag.

GiteaMirror commented