github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-20 22:21:38 -05:00
Code Issues 2.1k Packages Projects Releases 57 Wiki Activity

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

New Issue
Open
opened 2026-05-19 04:23:29 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-05-19 04:23:29 -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-05-19 04:23:30 -05:00
GiteaMirror commented 2026-05-19 04:23:34 -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-05-19 04:23:35 -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-05-19 04:23:36 -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-05-19 04:23:37 -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.
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
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#80586
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?