github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-11 10:02:07 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #7669] [Feedback]: Balance Forecast report #117534

New Issue
Open
opened 2026-06-11 12:45:56 -05:00 by GiteaMirror · 10 comments
GiteaMirror commented 2026-06-11 12:45:56 -05:00
Owner
Copy Link

Originally created by @youngcw on GitHub (Apr 30, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7669

Add all feedback for the experimental balance report here. Original PR #7310

Originally created by @youngcw on GitHub (Apr 30, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/7669 Add all feedback for the experimental balance report here. Original PR #7310
GiteaMirror added the experimental featurefeedback labels 2026-06-11 12:45:58 -05:00
GiteaMirror commented 2026-06-11 12:45:59 -05:00
Author
Owner
Copy Link

@emiltb commented on GitHub (May 4, 2026):

This looks like a really interesting report that I would love to use. I played around with the current deploy preview from #7310. I found a few issues and have a few questions.

  • The lowest point reported seems to be calculated based on daily iterations. I was confused at first, viewing the graph monthly, as it showed a negative lowest point for my budget, but the line was positive all the way. Viewing it daily told me what was going on, but the current situation was not intuitive to me. See screenshots below.
  • The color of the line seems to be red if it contains a negative value and green if all values are positive. It would make more sense, if the color changed when crossing 0.
  • Pressing the 'All future' button seems to have no effect
Image Image

A feature that I would really love to have implemented in some way, that I know is not easy, is to be able to take into account estimates of spending that cannot be scheduled. For me that would be stuff like the money I budget for food, house maintenance, gifts, clothes, etc. Having some way of factorying that in, would make the estimate more accurate, since only taking scheduled transactions into account, really only gives me an upper bound for my balance, in case I spend no other money. I can think of a few ways this could be implemented for such categories:

  • Use budgeted values from templates (i.e. my Food category uses #template-2 up to 3000 and house maintenance is just #template-5 1500). Assume the 'worst case scenario' and factor in the maximum amount withdrawn by such templates.
  • Use average spending from those categories for the last N months and project those into the forecast as well.

These could be factored into a single value for average daily spending on non-scheduled stuff, that would then be deducted daily for a more realistic forecast.

<!-- gh-comment-id:4374403399 --> @emiltb commented on GitHub (May 4, 2026): This looks like a really interesting report that I would love to use. I played around with the current deploy preview from #7310. I found a few issues and have a few questions. * The lowest point reported seems to be calculated based on daily iterations. I was confused at first, viewing the graph monthly, as it showed a negative lowest point for my budget, but the line was positive all the way. Viewing it daily told me what was going on, but the current situation was not intuitive to me. See screenshots below. * The color of the line seems to be red if it contains a negative value and green if all values are positive. It would make more sense, if the color changed when crossing 0. * Pressing the 'All future' button seems to have no effect <img width="771" height="503" alt="Image" src="https://github.com/user-attachments/assets/764164df-b85f-4db8-85b7-1d1f83ae7dc3" /> <img width="770" height="504" alt="Image" src="https://github.com/user-attachments/assets/a4c09a5f-9bc8-4dc3-a76c-e1e04a0617c8" /> A feature that I would really love to have implemented in some way, that I know is not easy, is to be able to take into account estimates of spending that cannot be scheduled. For me that would be stuff like the money I budget for food, house maintenance, gifts, clothes, etc. Having some way of factorying that in, would make the estimate more accurate, since only taking scheduled transactions into account, really only gives me an upper bound for my balance, in case I spend no other money. I can think of a few ways this could be implemented for such categories: * Use budgeted values from templates (i.e. my Food category uses `#template-2 up to 3000` and house maintenance is just `#template-5 1500`). Assume the 'worst case scenario' and factor in the maximum amount withdrawn by such templates. * Use average spending from those categories for the last N months and project those into the forecast as well. These could be factored into a single value for average daily spending on non-scheduled stuff, that would then be deducted daily for a more realistic forecast.
GiteaMirror commented 2026-06-11 12:46:00 -05:00
Author
Owner
Copy Link

@x-rous commented on GitHub (May 5, 2026):

Thanks for working on this @samaluk.

I can see why the current approach is based on schedules and account running balances, especially for the use cases described in #4244 and #517. For Envelope Budgeting, that is probably the only practical way to forecast future balances, because the budget itself is based on money currently available rather than future planned income/expenses.

I wanted to raise one point from a Tracking Budget perspective before the design settles too much around schedules only.

In Tracking Budget, the future plan already lives in the budget itself. Users are entering future expected income and future expected expenses directly into the budget months. So for this mode, a future balance forecast could be built from: starting balance + future budgeted income - future budgeted expenses (as described in https://github.com/actualbudget/actual/issues/517#issuecomment-2350645200)

This would make the forecast useful without requiring Tracking Budget users to duplicate their future plan as schedules just to make the report work, and it would also provide a general non-account specific "on-budget" balance.

I am not suggesting replacing the current schedule/account-based forecast. That approach makes sense for Envelope Budgeting and for account-level cashflow forecasting. But it would be great if the feature eventually supported a Tracking Budget forecast mode as well, where the source is the future budgeted income and expense values.

Otherwise, Tracking Budget users may end up with a forecast report that does not fully reflect how Tracking Budget is designed to be used, even though forecasting is one of the main reasons someone would choose Tracking Budget in the first place.

Edit:

One more point outside the scope of this PR and mainly directed to the maintainers, the current design allows forecasting up to 12 months into the future, is the 12-month limit based on a technical limitation, or is it more of a product/design decision?

From a longer-term planning perspective, especially for Tracking Budget users, it would be useful if Actual allowed users to plan and forecast beyond 12 months when needed. I understand that 12 months is probably the right default view, but having the option to extend further could make the forecast much more useful for multi-year planning.

<!-- gh-comment-id:4382050112 --> @x-rous commented on GitHub (May 5, 2026): Thanks for working on this @samaluk. I can see why the current approach is based on schedules and account running balances, especially for the use cases described in #4244 and #517. For Envelope Budgeting, that is probably the only practical way to forecast future balances, because the budget itself is based on money currently available rather than future planned income/expenses. I wanted to raise one point from a Tracking Budget perspective before the design settles too much around schedules only. In Tracking Budget, the future plan already lives in the budget itself. Users are entering future expected income and future expected expenses directly into the budget months. So for this mode, a future balance forecast could be built from: `starting balance + future budgeted income - future budgeted expenses` (as described in https://github.com/actualbudget/actual/issues/517#issuecomment-2350645200) This would make the forecast useful without requiring Tracking Budget users to duplicate their future plan as schedules just to make the report work, and it would also provide a general non-account specific "on-budget" balance. I am not suggesting replacing the current schedule/account-based forecast. That approach makes sense for Envelope Budgeting and for account-level cashflow forecasting. But it would be great if the feature eventually supported a Tracking Budget forecast mode as well, where the source is the future budgeted income and expense values. Otherwise, Tracking Budget users may end up with a forecast report that does not fully reflect how Tracking Budget is designed to be used, even though forecasting is one of the main reasons someone would choose Tracking Budget in the first place. **Edit:** One more point outside the scope of this PR and mainly directed to the maintainers, the current design allows forecasting up to 12 months into the future, is the 12-month limit based on a technical limitation, or is it more of a product/design decision? From a longer-term planning perspective, especially for Tracking Budget users, it would be useful if Actual allowed users to plan and forecast beyond 12 months when needed. I understand that 12 months is probably the right default view, but having the option to extend further could make the forecast much more useful for multi-year planning.
GiteaMirror commented 2026-06-11 12:46:00 -05:00
Author
Owner
Copy Link

@karimkodera commented on GitHub (May 7, 2026):

I would love to have this potential part of the chart above the accounts page rather than on the report page.

<!-- gh-comment-id:4396705803 --> @karimkodera commented on GitHub (May 7, 2026): I would love to have this potential part of the chart above the accounts page rather than on the report page.
GiteaMirror commented 2026-06-11 12:46:00 -05:00
Author
Owner
Copy Link

@samaluk commented on GitHub (May 15, 2026):

Thanks for the detailed feedback here.

A quick status update now that the initial Balance Forecast report has landed in #7310:

  • The All future range issue is fixed in #7849. The bug was in the range helper treating an available future month as a date and normalizing it back to the current/start month.
  • The line color behavior is addressed in #7850. Instead of making the whole line red whenever any visible point is negative, the chart now changes color at the zero-balance crossing and shows a zero reference line when negatives are present.
  • I also have follow-up stack work for making the lowest-point context clearer in the report caption/header, since the current “lowest point” can be based on daily data even while the chart is grouped monthly. That should make the monthly-vs-daily behavior less surprising.

On the larger forecasting-source questions:

  • The current report intentionally starts with scheduled transactions and account balances because that supports account-level cashflow forecasting and the envelope-budgeting use case.
  • I agree that Tracking Budget users should not need to duplicate their future plan as schedules. I have a follow-up branch for a Tracking Budget forecast mode that uses future budgeted income/expenses as the forecast source.
  • I also agree that unscheduled spending estimates are a useful next step, but I’d treat that separately from the initial schedule/account forecast so we can avoid mixing too many forecasting assumptions into the first experimental version.

For placement: the initial implementation includes both the full report and a dashboard widget. Putting this directly above the accounts page is an interesting idea, but I think that should be a separate product/design decision after the experimental report gets more feedback.

<!-- gh-comment-id:4460339107 --> @samaluk commented on GitHub (May 15, 2026): Thanks for the detailed feedback here. A quick status update now that the initial Balance Forecast report has landed in #7310: - The `All future` range issue is fixed in #7849. The bug was in the range helper treating an available future month as a date and normalizing it back to the current/start month. - The line color behavior is addressed in #7850. Instead of making the whole line red whenever any visible point is negative, the chart now changes color at the zero-balance crossing and shows a zero reference line when negatives are present. - I also have follow-up stack work for making the lowest-point context clearer in the report caption/header, since the current “lowest point” can be based on daily data even while the chart is grouped monthly. That should make the monthly-vs-daily behavior less surprising. On the larger forecasting-source questions: - The current report intentionally starts with scheduled transactions and account balances because that supports account-level cashflow forecasting and the envelope-budgeting use case. - I agree that Tracking Budget users should not need to duplicate their future plan as schedules. I have a follow-up branch for a Tracking Budget forecast mode that uses future budgeted income/expenses as the forecast source. - I also agree that unscheduled spending estimates are a useful next step, but I’d treat that separately from the initial schedule/account forecast so we can avoid mixing too many forecasting assumptions into the first experimental version. For placement: the initial implementation includes both the full report and a dashboard widget. Putting this directly above the accounts page is an interesting idea, but I think that should be a separate product/design decision after the experimental report gets more feedback.
GiteaMirror commented 2026-06-11 12:46:01 -05:00
Author
Owner
Copy Link

@matt-fidd commented on GitHub (May 25, 2026):

Nice feature, thanks for this.

It looks like splits are being double counted in balance calculations, sending them off by quite a way. In my file, it's the difference between a green line and a red line!

I believe removing the grouped splits option should do the trick, inline (the default mode) sorts that sort of thing out for you.

9388249517/packages/loot-core/src/server/forecast/forecast-filters.ts (L84)

It would be great to have this fixed before release if possible so we don't have an influx of people reporting it and unable to use it.

<!-- gh-comment-id:4537773045 --> @matt-fidd commented on GitHub (May 25, 2026): Nice feature, thanks for this. It looks like splits are being double counted in balance calculations, sending them off by quite a way. In my file, it's the difference between a green line and a red line! I believe removing the grouped splits option should do the trick, `inline` (the default mode) sorts that sort of thing out for you. https://github.com/actualbudget/actual/blob/938824951766884c08c42feafde6a159fb157d32/packages/loot-core/src/server/forecast/forecast-filters.ts#L84 It would be great to have this fixed before release if possible so we don't have an influx of people reporting it and unable to use it.
GiteaMirror commented 2026-06-11 12:46:01 -05:00
Author
Owner
Copy Link

@samaluk commented on GitHub (May 26, 2026):

Nice feature, thanks for this.

It looks like splits are being double counted in balance calculations, sending them off by quite a way. In my file, it's the difference between a green line and a red line!

I believe removing the grouped splits option should do the trick, inline (the default mode) sorts that sort of thing out for you.

actual/packages/loot-core/src/server/forecast/forecast-filters.ts

Line 84 in 9388249
.options({ splits: 'grouped' });

It would be great to have this fixed before release if possible so we don't have an influx of people reporting it and unable to use it.

Fixed in #7955.
You were right: posted split transactions were being double-counted in the Balance Forecast history path. The forecast query was loading grouped splits and then flattening them, which let both the split parent amount and the child split amounts flow into the running balance calculation.
The fix switches that query path to use inline splits, so only the non-parent rows are included in the posted balance math. I also added a regression test that reproduces the issue with a split parent plus child rows to make sure it stays fixed.
Thanks for flagging this before wider release.

<!-- gh-comment-id:4538587608 --> @samaluk commented on GitHub (May 26, 2026): > Nice feature, thanks for this. > > It looks like splits are being double counted in balance calculations, sending them off by quite a way. In my file, it's the difference between a green line and a red line! > > I believe removing the grouped splits option should do the trick, `inline` (the default mode) sorts that sort of thing out for you. > > [actual/packages/loot-core/src/server/forecast/forecast-filters.ts](https://github.com/actualbudget/actual/blob/938824951766884c08c42feafde6a159fb157d32/packages/loot-core/src/server/forecast/forecast-filters.ts#L84) > > Line 84 in [9388249](/actualbudget/actual/commit/938824951766884c08c42feafde6a159fb157d32) > .options({ splits: 'grouped' }); > > It would be great to have this fixed before release if possible so we don't have an influx of people reporting it and unable to use it. Fixed in #7955. You were right: posted split transactions were being double-counted in the Balance Forecast history path. The forecast query was loading grouped splits and then flattening them, which let both the split parent amount and the child split amounts flow into the running balance calculation. The fix switches that query path to use inline splits, so only the non-parent rows are included in the posted balance math. I also added a regression test that reproduces the issue with a split parent plus child rows to make sure it stays fixed. Thanks for flagging this before wider release.
GiteaMirror commented 2026-06-11 12:46:01 -05:00
Author
Owner
Copy Link

@emiltb commented on GitHub (May 29, 2026):

It seems that schedules are counted on their due date, even though the transaction for that schedule has already been posted. I have my salary scheduled and it was posted today. But if I look at the balance forecast graph, I see a jump of 2x my salary.

<!-- gh-comment-id:4578985011 --> @emiltb commented on GitHub (May 29, 2026): It seems that schedules are counted on their due date, even though the transaction for that schedule has already been posted. I have my salary scheduled and it was posted today. But if I look at the balance forecast graph, I see a jump of 2x my salary.
GiteaMirror commented 2026-06-11 12:46:02 -05:00
Author
Owner
Copy Link

@samaluk commented on GitHub (Jun 1, 2026):

It seems that schedules are counted on their due date, even though the transaction for that schedule has already been posted. I have my salary scheduled and it was posted today. But if I look at the balance forecast graph, I see a jump of 2x my salary.

Thanks for reporting this, you were right.

The forecast was adding both the posted transaction and the simulated schedule occurrence on the due date, so something like salary could show up twice when it was posted on the same day and next_date hadn’t moved forward yet.

This is fixed in #8029. Before projecting a schedule occurrence, we now check whether a posted transaction already satisfies that occurrence, using the same date-matching rules as the schedules UI (including early payments within the 2-day lookback for manual recurring schedules).

Once that’s merged, posting on the due date should only move the balance once, and later occurrences (e.g. next month) should still appear as expected.

If you can try the preview build on the PR and still see a double bump, let me know more schedule details to help narrow it down.

<!-- gh-comment-id:4597305570 --> @samaluk commented on GitHub (Jun 1, 2026): > It seems that schedules are counted on their due date, even though the transaction for that schedule has already been posted. I have my salary scheduled and it was posted today. But if I look at the balance forecast graph, I see a jump of 2x my salary. Thanks for reporting this, you were right. The forecast was adding both the posted transaction and the simulated schedule occurrence on the due date, so something like salary could show up twice when it was posted on the same day and next_date hadn’t moved forward yet. This is fixed in [#8029](https://github.com/actualbudget/actual/pull/8029). Before projecting a schedule occurrence, we now check whether a posted transaction already satisfies that occurrence, using the same date-matching rules as the schedules UI (including early payments within the 2-day lookback for manual recurring schedules). Once that’s merged, posting on the due date should only move the balance once, and later occurrences (e.g. next month) should still appear as expected. If you can try the preview build on the PR and still see a double bump, let me know more schedule details to help narrow it down.
GiteaMirror commented 2026-06-11 12:46:02 -05:00
Author
Owner
Copy Link

@IsThisThingStillOn commented on GitHub (Jun 3, 2026):

Feedback:
I'm not really sure what it's trying to accomplish. This report only shows predictions of schedules? It's not taking my income and spending habits from a chosen period of time into account and then predicts it into a future balance?

/E: just found the footnote:

This forecast shows the running total of matching posted transactions, plus upcoming scheduled transactions in the future.

From my point of view, any enhancement towards filtering and classification like the "crossover report", where I can choose my income and spending categories, would be a huge improvement. Bonus points for "spending and earning period" to include, "period of prediction", a custom "inflation rate" and "yearly salary increase".

<!-- gh-comment-id:4609599278 --> @IsThisThingStillOn commented on GitHub (Jun 3, 2026): Feedback: I'm not really sure what it's trying to accomplish. This report only shows predictions of schedules? It's not taking my income and spending habits from a chosen period of time into account and then predicts it into a future balance? /E: just found the footnote: > This forecast shows the running total of matching posted transactions, plus upcoming scheduled transactions in the future. From my point of view, any enhancement towards filtering and classification like the "crossover report", where I can choose my income and spending categories, would be a huge improvement. Bonus points for "spending and earning period" to include, "period of prediction", a custom "inflation rate" and "yearly salary increase".
GiteaMirror commented 2026-06-11 12:46:02 -05:00
Author
Owner
Copy Link

@jonathan-fang commented on GitHub (Jun 7, 2026):

I tried searching for a GitHub issue that took your region's specific inflation rate into account, and it led me here. Let me know if I should create this as its own issue. Would this feature integrate a feature that allows you to see if your account balance is meeting, below, or surpassing inflation? For example, if an account is sitting at $20k, over three years, the real purchasing power of that $20k isn't actually $20k, it's more like $18k.

<!-- gh-comment-id:4641775770 --> @jonathan-fang commented on GitHub (Jun 7, 2026): I tried searching for a GitHub issue that took your region's specific inflation rate into account, and it led me here. Let me know if I should create this as its own issue. Would this feature integrate a feature that allows you to see if your account balance is meeting, below, or surpassing inflation? For example, if an account is sitting at $20k, over three years, the real purchasing power of that $20k isn't actually $20k, it's more like $18k.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label experimental feature feedback
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#117534
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?