[GH-ISSUE #2354] [Bug]: Future transactions should not be included in the account balance summary #26718

New Issue

GiteaMirror · 2026-04-18T03:01:58-05:00

GiteaMirror commented

2026-04-18 03:01:58 -05:00

Originally created by @tavlima on GitHub (Feb 11, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/2354

Verified issue does not already exist?

I have searched and found no existing issue

I have checked my server logs and could not see any errors there
I will be attaching my server logs to this issue
I will be attaching my client-side (browser) logs to this issue
I understand that this issue will be automatically closed if insufficient information is provided

What happened?

TL;DR; I'd like to see my balances as-of today in the left panel.

I have a lot of future transactions (mostly credit card installments) that I create ahead of time and that is messing up with the accounts balance summary shown in the left panel. I don't think future transactions should impact my current balances, as the balances should match what is reported by the bank.

It may be debatable if that is ok for credit card accounts, but given Actual doesn't have any concept of "credit card account", the same rule is applied for everything, which, I think, is wrong.

What error did you receive?

No response

Where are you hosting Actual?

None

What browsers are you seeing the problem on?

No response

Operating System

None

Originally created by @tavlima on GitHub (Feb 11, 2024). Original GitHub issue: https://github.com/actualbudget/actual/issues/2354 ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### Is this related to GoCardless, Simplefin or another bank-sync provider? - [ ] I have checked my server logs and could not see any errors there - [ ] I will be attaching my server logs to this issue - [ ] I will be attaching my client-side (browser) logs to this issue - [ ] I understand that this issue will be automatically closed if insufficient information is provided ### What happened? TL;DR; I'd like to see my balances **as-of today** in the left panel. I have a lot of future transactions (mostly credit card installments) that I create ahead of time and that is messing up with the accounts balance summary shown in the left panel. I don't think future transactions should impact my **current** balances, as the balances should match what is reported by the bank. It may be debatable if that is ok for credit card accounts, but given Actual doesn't have any concept of "credit card account", the same rule is applied for everything, which, I think, is wrong. ### What error did you receive? _No response_ ### Where are you hosting Actual? None ### What browsers are you seeing the problem on? _No response_ ### Operating System None

GiteaMirror added the transactions bug labels 2026-04-18 03:01:58 -05:00

GiteaMirror closed this issue

2026-04-18 03:01:58 -05:00

GiteaMirror commented

2026-04-18 03:02:00 -05:00

@youngcw commented on GitHub (Feb 11, 2024):

Are you adding those early installments in place of schedules? Schedule are meant for this, were you can see the transactions before hand but they don't actually affect the balances

@youngcw commented on GitHub (Feb 11, 2024): Are you adding those early installments in place of schedules? Schedule are meant for this, were you can see the transactions before hand but they don't actually affect the balances

GiteaMirror commented

2026-04-18 03:02:01 -05:00

@tavlima commented on GitHub (Feb 12, 2024):

They are monthly installments, not yearly. And I get schedules are meant
for that, but

I couldn’t find any API for that (those are coming from my custom
importer, that pulls from the bank);
does it really matter? IMHO, future transactions, no matter the
“source”, should not affect current balance, only forecasts. Indeed, there
is a feature request to treat future transactions just like scheduled.

On Sat, Feb 10, 2024 at 23:24 youngcw @.***> wrote:

Are you adding those early installments in place of schedules? Schedule
are meant for this, were you can see the transactions before hand but they
don't actually affect the balances

—
Reply to this email directly, view it on GitHub
https://github.com/actualbudget/actual/issues/2354#issuecomment-1937397668,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJZKI5J5TDI5RUBVAZPQHTYTATWFAVCNFSM6AAAAABDDEXA3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGM4TONRWHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

@tavlima commented on GitHub (Feb 12, 2024): They are monthly installments, not yearly. And I get schedules are meant for that, but 1) I couldn’t find any API for that (those are coming from my custom importer, that pulls from the bank); 2) does it really matter? IMHO, future transactions, no matter the “source”, should not affect current balance, only forecasts. Indeed, there is a feature request to treat future transactions just like scheduled. On Sat, Feb 10, 2024 at 23:24 youngcw ***@***.***> wrote: > Are you adding those early installments in place of schedules? Schedule > are meant for this, were you can see the transactions before hand but they > don't actually affect the balances > > — > Reply to this email directly, view it on GitHub > <https://github.com/actualbudget/actual/issues/2354#issuecomment-1937397668>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAJZKI5J5TDI5RUBVAZPQHTYTATWFAVCNFSM6AAAAABDDEXA3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGM4TONRWHA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

GiteaMirror commented

2026-04-18 03:02:01 -05:00

@Waseh commented on GitHub (Feb 12, 2024):

I agree with this.
I use the gocardless integration to pull transactions from my bank which indeed also adds future transactions (bills scheduled to be paid and so forth) which is messing up the current balance.

@Waseh commented on GitHub (Feb 12, 2024): I agree with this. I use the gocardless integration to pull transactions from my bank which indeed also adds future transactions (bills scheduled to be paid and so forth) which is messing up the current balance.

GiteaMirror commented

2026-04-18 03:02:02 -05:00

@youngcw commented on GitHub (Feb 13, 2024):

I disagree that future transactions should be excluded from the budget or account summary. I would expect that to cause more confusion than help. That also would remove the possibility of budget projections.

I do think it would make sense to not import transactions that are in the future with bank syncing.

@youngcw commented on GitHub (Feb 13, 2024): I disagree that future transactions should be excluded from the budget or account summary. I would expect that to cause more confusion than help. That also would remove the possibility of budget projections. I do think it would make sense to not import transactions that are in the future with bank syncing.

GiteaMirror commented

2026-04-18 03:02:02 -05:00

@Teprifer commented on GitHub (Feb 13, 2024):

I disagree that future transactions should be excluded from the budget or account summary. I would expect that to cause more confusion than help. That also would remove the possibility of budget projections.

I do think it would make sense to not import transactions that are in the future with bank syncing.

I'd seen the comments flow through on this and wasn't sure what I thought for a bit because I could see some reasons each way, but ultimately I'm inclined to agree. If a transaction has been added, then it should affect the balance. Having two different rules for how transactions affect an account and the budget doesn't flow.

I can see the view with this being inconsistent with the notion of 'now', but if someone is adding a transaction, it should behave the same as any other transaction to remain consistent in that respect, that it's in the future is beside the point. There are no doubt workflows setup off the current approach for some where they expect their future transactions to affect the balance. so they can 'forecast'.

Whether these shouldn't be imported at all, or imported as an 'upcoming' record in the same manner of a one off scheduled transactions that can be posted manually (or automatically when the date comes due). I don't know.

@Teprifer commented on GitHub (Feb 13, 2024): > I disagree that future transactions should be excluded from the budget or account summary. I would expect that to cause more confusion than help. That also would remove the possibility of budget projections. > > I do think it would make sense to not import transactions that are in the future with bank syncing. I'd seen the comments flow through on this and wasn't sure what I thought for a bit because I could see some reasons each way, but ultimately I'm inclined to agree. If a transaction has been added, then it should affect the balance. Having two different rules for how transactions affect an account and the budget doesn't flow. I can see the view with this being inconsistent with the notion of 'now', but if someone is adding a transaction, it should behave the same as any other transaction to remain consistent in that respect, that it's in the future is beside the point. There are no doubt workflows setup off the current approach for some where they expect their future transactions to affect the balance. so they can 'forecast'. Whether these shouldn't be imported at all, or imported as an 'upcoming' record in the same manner of a one off scheduled transactions that can be posted manually (or automatically when the date comes due). I don't know.

GiteaMirror commented

2026-04-18 03:02:03 -05:00

@Kidglove57 commented on GitHub (Feb 13, 2024):

I agree @Teprifer but I have also noted how my most recent alternative app (Banktivity on Mac) deals with this. It gives the option to display in the sidebar either Today’s Value, Today's Cleared Value or the Total Value (ie net of all future posted transactions). However, it does include future manually posted transactions in the budget because they are posted - but not scheduled transactions.
Apologies if I have misunderstood any of the previous comments but for me, once a transaction is manually posted on the ledger (or imported) in Actual, even if with a future date, it will inevitably show both in the budget and in the account balance. Anything else seems to me like a recipe for confusion. UNLESS a choice is given as to what account balance to display in the side bar.

It occurs to me that if we allow the sidebar balance to be different then the budget will also look as if it is completely out of kilter - ie budget available should = total of all on budget account balances.

@Kidglove57 commented on GitHub (Feb 13, 2024): I agree @Teprifer but I have also noted how my most recent alternative app (Banktivity on Mac) deals with this. It gives the option to display in the sidebar either Today’s Value, Today's Cleared Value or the Total Value (ie net of all future posted transactions). However, it does include future manually posted transactions in the budget because they are posted - but not scheduled transactions. Apologies if I have misunderstood any of the previous comments but for me, once a transaction is manually posted on the ledger (or imported) in Actual, even if with a future date, it will inevitably show both in the budget and in the account balance. Anything else seems to me like a recipe for confusion. UNLESS a choice is given as to what account balance to display in the side bar. It occurs to me that if we allow the sidebar balance to be different then the budget will also look as if it is completely out of kilter - ie budget available should = total of all on budget account balances.

GiteaMirror commented

2026-04-18 03:02:04 -05:00

@tavlima commented on GitHub (Feb 14, 2024):

To be clear, I’m not saying those should be excluded from the budget, just from the accounts totals/summary, as I think it is more intuitive to display the current values in your bank account, not future. Budgeted amounts in the future (and scheduled/future transactions for that matter) seem to work just fine. I’m only talking about the accounts summary.

nYNAB, for example, shows the current balance. GNUCash, as the accounting app that it is, can display a column with the “posted” and another with the “current” balance of the accounts.

As a solution, I think a settings/preference option would suffice, as I don’t think this would change how things are internally calculated too much, but mostly just displayed. A custom query to the DB with a date constraint would likely be needed (assuming that is not being computed in the UI), but not much else.

I hope that clears things up.

@tavlima commented on GitHub (Feb 14, 2024): To be clear, I’m not saying those should be excluded from the budget, just from the accounts totals/summary, as I think it is more intuitive to display the current values in your bank account, not future. Budgeted amounts in the future (and scheduled/future transactions for that matter) seem to work just fine. I’m only talking about the accounts summary. nYNAB, for example, shows the current balance. GNUCash, as the accounting app that it is, can display a column with the “posted” and another with the “current” balance of the accounts. As a solution, I think a settings/preference option would suffice, as I don’t think this would change how things are internally calculated too much, but mostly just displayed. A custom query to the DB with a date constraint would likely be needed (assuming that is not being computed in the UI), but not much else. I hope that clears things up.

GiteaMirror commented

2026-04-18 03:02:04 -05:00

@rich-howell commented on GitHub (Feb 14, 2024):

I raised this a long time ago as it completely breaks my workflow. Here is an example.

I get paid on the 23rd of the month, I usually get a pay slip one week before which tells me exactly how much I am going to get paid.

I enter the amount into the Account Register with a date of the 23rd (which is almost always in the future)

The value that I add appears in my To Be Budgeted and my Account Balance increases by the amount I added.

This is wrong in my mind, because my bank balance does not yet have that extra money, I have just added it ready.

@rich-howell commented on GitHub (Feb 14, 2024): I raised this a long time ago as it completely breaks my workflow. Here is an example. I get paid on the 23rd of the month, I usually get a pay slip one week before which tells me exactly how much I am going to get paid. I enter the amount into the Account Register with a date of the 23rd (which is almost always in the future) The value that I add appears in my To Be Budgeted and my Account Balance increases by the amount I added. This is wrong in my mind, because my bank balance does not yet have that extra money, I have just added it ready.

GiteaMirror commented

2026-04-18 03:02:05 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

To be clear, I’m not saying those should be excluded from the budget, just from the accounts totals/summary, as I think it is more intuitive to display the current values in your bank account, not future. Budgeted amounts in the future (and scheduled/future transactions for that matter) seem to work just fine. I’m only talking about the accounts summary.

How would the be functionally different than looking at the cleared vs uncleared balance? If the transactions are still included in the budget view then this sounds like the same number as the uncleared balance.

@youngcw commented on GitHub (Feb 14, 2024): > To be clear, I’m not saying those should be excluded from the budget, just from the accounts totals/summary, as I think it is more intuitive to display the current values in your bank account, not future. Budgeted amounts in the future (and scheduled/future transactions for that matter) seem to work just fine. I’m only talking about the accounts summary. How would the be functionally different than looking at the cleared vs uncleared balance? If the transactions are still included in the budget view then this sounds like the same number as the uncleared balance.

GiteaMirror commented

2026-04-18 03:02:06 -05:00

@rich-howell commented on GitHub (Feb 14, 2024):

To be clear, I’m not saying those should be excluded from the budget, just from the accounts totals/summary, as I think it is more intuitive to display the current values in your bank account, not future. Budgeted amounts in the future (and scheduled/future transactions for that matter) seem to work just fine. I’m only talking about the accounts summary.

How would the be functionally different than looking at the cleared vs uncleared balance? If the transactions are still included in the budget view then this sounds like the same number as the uncleared balance.

Have a look at my example above this reply.

@rich-howell commented on GitHub (Feb 14, 2024): > > To be clear, I’m not saying those should be excluded from the budget, just from the accounts totals/summary, as I think it is more intuitive to display the current values in your bank account, not future. Budgeted amounts in the future (and scheduled/future transactions for that matter) seem to work just fine. I’m only talking about the accounts summary. > > > > How would the be functionally different than looking at the cleared vs uncleared balance? If the transactions are still included in the budget view then this sounds like the same number as the uncleared balance. Have a look at my example above this reply.

GiteaMirror commented

2026-04-18 03:02:07 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

@rich-howell You and Tavlima are giving different examples. He is saying don't show in the account but do include on budget, you are saying exclude from budget (and maybe account?).

@youngcw commented on GitHub (Feb 14, 2024): @rich-howell You and Tavlima are giving different examples. He is saying don't show in the account but do include on budget, you are saying exclude from budget (and maybe account?).

GiteaMirror commented

2026-04-18 03:02:08 -05:00

@Kidglove57 commented on GitHub (Feb 14, 2024):

Future but unposted regular transactions should (in my view) be dealt with via scheduled transactions - updating the scheduled figure as needed. Isn’t that what schedules are designed for ?

I have seen other folk say that they want to post all their transactions for the month early to see the effect on their budget and accounts so it sort of feels that the devs can’t win whatever they do. Unless of course an option is given as to which bank balance should be displayed.

@Kidglove57 commented on GitHub (Feb 14, 2024): Future but unposted regular transactions should (in my view) be dealt with via scheduled transactions - updating the scheduled figure as needed. Isn’t that what schedules are designed for ? I have seen other folk say that they want to post all their transactions for the month early to see the effect on their budget and accounts so it sort of feels that the devs can’t win whatever they do. Unless of course an option is given as to which bank balance should be displayed.

GiteaMirror commented

2026-04-18 03:02:08 -05:00

@Waseh commented on GitHub (Feb 14, 2024):

I disagree that future transactions should be excluded from the budget or account summary. I would expect that to cause more confusion than help. That also would remove the possibility of budget projections.

I do think it would make sense to not import transactions that are in the future with bank syncing.

From my perspective in regards to the bank syncing just not importing transactions that are in the future would be my preferred solution, or at least getting the option of not importing transactions that are in the future.

@Waseh commented on GitHub (Feb 14, 2024): > I disagree that future transactions should be excluded from the budget or account summary. I would expect that to cause more confusion than help. That also would remove the possibility of budget projections. > > I do think it would make sense to not import transactions that are in the future with bank syncing. From my perspective in regards to the bank syncing just **_not_** importing transactions that are in the future would be my preferred solution, or at least getting the option of not importing transactions that are in the future.

GiteaMirror commented

2026-04-18 03:02:09 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

From my perspective in regards to the bank syncing just not importing transactions that are in the future would be my preferred solution, or at least getting the option of not importing transactions that are in the future.

@Waseh Could you make a separate feature request or issue ticket for that? I feel like that should at least be an option.

@youngcw commented on GitHub (Feb 14, 2024): > From my perspective in regards to the bank syncing just **_not_** importing transactions that are in the future would be my preferred solution, or at least getting the option of not importing transactions that are in the future. @Waseh Could you make a separate feature request or issue ticket for that? I feel like that should at least be an option.

GiteaMirror commented

2026-04-18 03:02:10 -05:00

@tavlima commented on GitHub (Feb 14, 2024):

How would the be functionally different than looking at the cleared vs uncleared balance

It would be different as I wouldn't have to go through each of the accounts having future transactions to get a hold of their current balance.

Let's see how Actual currently behaves... Given this account/transactions...

This is what I see in the budget section...

I honestly can't, for the life of me, understand how some do not consider this inconsistent... How can my "To Budget" for February show 100.00, while the account summary itself shows only 75.00?

The options, as I see:

Introduce a settings/preference option on whether to show the posted or current balance in the accounts summary

Pros: existing users that are OK with the current behavior can continue with their lives, while users like me (and seemingly others) can switch to more intuitive behavior (as we see it, ofc).

Cons: one more setting for the users, which some may consider a problem.

Introduce an API to create/update scheduled transactions

Pros: no behavior change in the app/calculations

Cons: switching between two APIs for importing transactions (past vs future) will definitely increase the complexity of the importers.

Additional notes: This is good in itself, as exposing additional APIs will definitely be useful (if not to me, but others). In this particular use-case, though, I'm afraid it will be really troublesome to implement, as the API for scheduled transactions should (IMHO) behaves the exact same way as regular transactions in regards to match/deduplication. It is important to have in mind that a transaction that is in the future as of today (and thus a "scheduled transaction") may no longer be tomorrow, when the importer runs again. This will be tricky to handle in the importers as well.

@tavlima commented on GitHub (Feb 14, 2024): > How would the be functionally different than looking at the cleared vs uncleared balance It would be different as I wouldn't have to go through each of the accounts having future transactions to get a hold of their current balance. --- Let's see how Actual currently behaves... Given this account/transactions... <img width="1511" alt="image" src="https://github.com/actualbudget/actual/assets/1283363/ceffa41e-a9ea-43ee-89bd-4dd82c297366"> This is what I see in the budget section... <img width="1508" alt="image" src="https://github.com/actualbudget/actual/assets/1283363/114744bb-3963-4bb7-b807-067f00b537a9"> I honestly can't, for the life of me, understand how some **do not** consider this inconsistent... How can my "To Budget" for February show 100.00, while the account summary itself shows only 75.00? --- The options, as I see: ## Introduce a settings/preference option on whether to show the posted or current balance in the accounts summary **Pros**: existing users that are OK with the current behavior can continue with their lives, while users like me (and seemingly others) can switch to more intuitive behavior (as we see it, ofc). **Cons**: one more setting for the users, which some may consider a problem. ## Introduce an API to create/update scheduled transactions **Pros**: no behavior change in the app/calculations **Cons**: switching between two APIs for importing transactions (past vs future) will definitely increase the complexity of the importers. **Additional notes**: This is good in itself, as exposing additional APIs will definitely be useful (if not to me, but others). In this particular use-case, though, I'm afraid it will be really troublesome to implement, as the API for scheduled transactions should (IMHO) behaves the exact same way as regular transactions in regards to match/deduplication. It is important to have in mind that a transaction that is in the future as of today (and thus a "scheduled transaction") may no longer be tomorrow, when the importer runs again. This will be tricky to handle in the importers as well.

GiteaMirror commented

2026-04-18 03:02:11 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

I honestly can't, for the life of me, understand how some do not consider this inconsistent... How can my "To Budget" for February show 100.00, while the account summary itself shows only 75.00?

In this case your budget and account do have 100 left in February. The expenditure only happens in March which shouldn't affect February since that is in the future from February. By adding those March transactions you are living in the future. If those transactions weren't there the 100 would be exactly what would be in the account, so if the transactions were added in March, when they posted, the 100 would still be accurate for February and would still be sitting there.

So at the end of February your account has $25, TB has 100 and the budget has -75. Which is correct for the month where 100+(-75)=25. Then for March the math is still correct with 125+(-50)=75.

@youngcw commented on GitHub (Feb 14, 2024): > I honestly can't, for the life of me, understand how some **do not** consider this inconsistent... How can my "To Budget" for February show 100.00, while the account summary itself shows only 75.00? In this case your budget and account **do have 100 left** in February. The expenditure only happens in March which shouldn't affect February since that is in the future from February. By adding those March transactions you are living in the future. If those transactions weren't there the 100 would be exactly what would be in the account, so if the transactions were added in March, when they posted, the 100 would still be accurate for February and would still be sitting there. So at the end of February your account has $25, TB has 100 and the budget has -75. Which is correct for the month where 100+(-75)=25. Then for March the math is still correct with 125+(-50)=75.

GiteaMirror commented

2026-04-18 03:02:12 -05:00

@rich-howell commented on GitHub (Feb 14, 2024):

Future but unposted regular transactions should (in my view) be dealt with via scheduled transactions - updating the scheduled figure as needed. Isn’t that what schedules are designed for ?

I have seen other folk say that they want to post all their transactions for the month early to see the effect on their budget and accounts so it sort of feels that the devs can’t win whatever they do. Unless of course an option is given as to which bank balance should be displayed.

You can't make deposits using schedules, at least I can't in my install or in the demo.

@rich-howell commented on GitHub (Feb 14, 2024): > Future but unposted regular transactions should (in my view) be dealt with via scheduled transactions - updating the scheduled figure as needed. Isn’t that what schedules are designed for ? > > I have seen other folk say that they want to post all their transactions for the month early to see the effect on their budget and accounts so it sort of feels that the devs can’t win whatever they do. Unless of course an option is given as to which bank balance should be displayed. You can't make deposits using schedules, at least I can't in my install or in the demo.

GiteaMirror commented

2026-04-18 03:02:12 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

You can't make deposits using schedules, at least I can't in my install or in the demo.

That sounds like a bug. I have my paycheck as a schedule
... hmm looks like this broke again. I fixed that once before. Chrome works for me, but not firefox

@youngcw commented on GitHub (Feb 14, 2024): > You can't make deposits using schedules, at least I can't in my install or in the demo. That sounds like a bug. I have my paycheck as a schedule ... hmm looks like this broke again. I fixed that once before. Chrome works for me, but not firefox

GiteaMirror commented

2026-04-18 03:02:13 -05:00

@Teprifer commented on GitHub (Feb 14, 2024):

You can't make deposits using schedules, at least I can't in my install or in the demo.

That sounds like a bug. I have my paycheck as a schedule ... hmm looks like this broke again. I fixed that once before. Chrome works for me, but not firefox

Just tested in Chrome desktop, can't toggle the - to a + in the demo.
Tried Chrome mobile(view desktop site) for my own install of three latest release and I can't toggle there either.

@Teprifer commented on GitHub (Feb 14, 2024): > > You can't make deposits using schedules, at least I can't in my install or in the demo. > > That sounds like a bug. I have my paycheck as a schedule ... hmm looks like this broke again. I fixed that once before. Chrome works for me, but not firefox Just tested in Chrome desktop, can't toggle the - to a + in the demo. Tried Chrome mobile(view desktop site) for my own install of three latest release and I can't toggle there either.

GiteaMirror commented

2026-04-18 03:02:13 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

Just tested in Chrome desktop, can't toggle the - to a + in the demo.
Tried Chrome mobile(view desktop site) for my own install of three latest release and I can't toggle there either.

Ok, so it is only working with existing schedules for me. So a work around for now is to create a schedule with the wrong amount. Then edit the schedule and it should work

@youngcw commented on GitHub (Feb 14, 2024): > Just tested in Chrome desktop, can't toggle the - to a + in the demo. > Tried Chrome mobile(view desktop site) for my own install of three latest release and I can't toggle there either. Ok, so it is only working with existing schedules for me. So a work around for now is to create a schedule with the wrong amount. Then edit the schedule and it should work

GiteaMirror commented

2026-04-18 03:02:14 -05:00

@tavlima commented on GitHub (Feb 14, 2024):

So at the end of February your account has $25, TB has 100 and the budget has -75. Which is correct for the month where 100+(-75)=25. Then for March the math is still correct with 125+(-50)=75.

I never questioned the math. From the budget perspective, it looks good enough for me. It is the account summary that is inconsistent, IMO.

@tavlima commented on GitHub (Feb 14, 2024): > So at the end of February your account has $25, TB has 100 and the budget has -75. Which is correct for the month where 100+(-75)=25. Then for March the math is still correct with 125+(-50)=75. I never questioned the math. From the budget perspective, it looks good enough for me. It is the account summary that is inconsistent, IMO.

GiteaMirror commented

2026-04-18 03:02:15 -05:00

@Kidglove57 commented on GitHub (Feb 14, 2024):

You can't make deposits using schedules, at least I can't in my install or in the demo.

Thanks for spotting this @youngcw. I was puzzled as I have about a dozen scheduled income events.

As an aside I am mulling over how the software should react when used in a way for which it was never designed. I would imagine that this use case would cause a problem for any envelope budgeting system.

@Kidglove57 commented on GitHub (Feb 14, 2024): > > You can't make deposits using schedules, at least I can't in my install or in the demo. > Thanks for spotting this @youngcw. I was puzzled as I have about a dozen scheduled income events. As an aside I am mulling over how the software should react when used in a way for which it was never designed. I would imagine that this use case would cause a problem for any envelope budgeting system.

GiteaMirror commented

2026-04-18 03:02:16 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

That sounds like a bug. I have my paycheck as a schedule
... hmm looks like this broke again. I fixed that once before. Chrome works for me, but not firefox

For everyone here. There isn't a bug. You have to make the amount non-zero before you can change the sign. Its weird and probably should be changed to not be confusing. See #2360

@youngcw commented on GitHub (Feb 14, 2024): > That sounds like a bug. I have my paycheck as a schedule > ... hmm looks like this broke again. I fixed that once before. Chrome works for me, but not firefox For everyone here. There isn't a bug. You have to make the amount non-zero before you can change the sign. Its weird and probably should be changed to not be confusing. See #2360

GiteaMirror commented

2026-04-18 03:02:17 -05:00

@tavlima commented on GitHub (Feb 14, 2024):

I would imagine that this use case would cause a problem for any envelope budgeting system.

@Kidglove57, if you are talking about the future transaction issue that is being discussed here, I already called out how that works in other systems.

nYNAB, for example, shows the current balance. GNUCash, as the accounting app that it is, can display a column with the “posted” and another with the “current” balance of the accounts.

@tavlima commented on GitHub (Feb 14, 2024): > I would imagine that this use case would cause a problem for any envelope budgeting system. @Kidglove57, if you are talking about the future transaction issue that is being discussed here, I already called out how that works in other systems. > nYNAB, for example, shows the current balance. GNUCash, as the accounting app that it is, can display a column with the “posted” and another with the “current” balance of the accounts.

GiteaMirror commented

2026-04-18 03:02:19 -05:00

@tavlima commented on GitHub (Feb 14, 2024):

For the reference, this is nYNAB, which I think is much more intuitive and expected.

It doesn't make any distinction between future posted transactions or recurrent scheduled expenses: they are all future and (perhaps) subject to change, thus do not impact either budgeted amounts (the expense/income didn't happen yet) or the balances (for the same reason).

@tavlima commented on GitHub (Feb 14, 2024): For the reference, this is nYNAB, which I think is much more intuitive and expected. ![image](https://github.com/actualbudget/actual/assets/1283363/a2bbec62-7c81-4c19-9030-5dd6f5ca278e) ![image](https://github.com/actualbudget/actual/assets/1283363/c58d7e7e-2d50-494b-9fbe-093e76f8433b) It doesn't make any distinction between future posted transactions or recurrent scheduled expenses: they are all future and (perhaps) subject to change, thus do not impact either budgeted amounts (the expense/income didn't happen yet) or the balances (for the same reason).

GiteaMirror commented

2026-04-18 03:02:20 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

@tavlima I would be open to adding something like this as long as its possible to post early, thus applying to the budget.

@youngcw commented on GitHub (Feb 14, 2024): @tavlima I would be open to adding something like this as long as its possible to post early, thus applying to the budget.

GiteaMirror commented

2026-04-18 03:02:20 -05:00

@Kidglove57 commented on GitHub (Feb 14, 2024):

I was referring to @youngcw comments about posting into the following month.

However in fairness to you, I have never posted transactions more than a day or so in advance - I just look at the prospective running balance alongside the upcoming scheduled transactions to see where I am headed.

I also expand the balance figure at top left of each account register to see what the notional balance on the account is (after all posted transactions) and what the current cleared balance is and what uncleared transactions remain. So I would be referencing the cleared balance as the correct balance on my bank account.

I have no objection to a menu giving users the choice as to which balance is displayed in the sidebar. Although I do want to retain as a default the basic logic that:
Balance of all "for budget" accounts =
Balance available in budget + income held for next month

@Kidglove57 commented on GitHub (Feb 14, 2024): I was referring to @youngcw comments about posting into the following month. However in fairness to you, I have never posted transactions more than a day or so in advance - I just look at the prospective running balance alongside the upcoming scheduled transactions to see where I am headed. I also expand the balance figure at top left of each account register to see what the notional balance on the account is (after all posted transactions) and what the current cleared balance is and what uncleared transactions remain. So I would be referencing the cleared balance as the correct balance on my bank account. I have no objection to a menu giving users the choice as to which balance is displayed in the sidebar. Although I do want to retain as a default the basic logic that: Balance of all "for budget" accounts = Balance available in budget + income held for next month

GiteaMirror commented

2026-04-18 03:02:22 -05:00

@tavlima commented on GitHub (Feb 14, 2024):

@tavlima I would be open to adding something like this as long as its possible to post early, thus applying to the budget.

Couldn't that also be gated by the same settings?

@tavlima commented on GitHub (Feb 14, 2024): > @tavlima I would be open to adding something like this as long as its possible to post early, thus applying to the budget. Couldn't that also be gated by the same settings? ![image](https://github.com/actualbudget/actual/assets/1283363/1c421828-3b2c-4c90-99d4-63de95e95b83)

GiteaMirror commented

2026-04-18 03:02:22 -05:00

@youngcw commented on GitHub (Feb 14, 2024):

yes it could. Im just saying that the option needs to be there before any changes are made

@youngcw commented on GitHub (Feb 14, 2024): yes it could. Im just saying that the option needs to be there before any changes are made

GiteaMirror commented

2026-04-18 03:02:23 -05:00

@Kidglove57 commented on GitHub (Feb 14, 2024):

It doesn't make any distinction between future posted transactions or recurrent scheduled expenses: they are all future and (perhaps) subject to change, thus do not impact either budgeted amounts (the expense/income didn't happen yet) or the balances (for the same reason).

I recall this now from nYNAB (its a while ago for me) - i always explained it to myself as nYNAB treating any future dated transaction as if it were a one-off scheduled transaction.

I looked at another envelope budgeting app (Moneywell on Mac). That displays in a way that would suit your use case - it treats all future dated transactions as pending and not part of the sidebar balance. Hands up, I have used Actual since April 2019 and got used to its way of doing things and as a result rarely post future dated transactions. As I say, I just use the arrows to expand the account balance view at the top of each account register so as to easily see what the cleared and uncleared balances are.
PS Banktivity on Mac offers a choice as to which balance is displayed in the side bar
PPS I am not trying to be quarrelsome but I would regard this as a Feature Request rather than a Bug since for right or wrong the current treatment is by design.

@Kidglove57 commented on GitHub (Feb 14, 2024): > It doesn't make any distinction between future posted transactions or recurrent scheduled expenses: they are all future and (perhaps) subject to change, thus do not impact either budgeted amounts (the expense/income didn't happen yet) or the balances (for the same reason). I recall this now from nYNAB (its a while ago for me) - i always explained it to myself as nYNAB treating any future dated transaction as if it were a one-off scheduled transaction. I looked at another envelope budgeting app (Moneywell on Mac). That displays in a way that would suit your use case - it treats all future dated transactions as pending and not part of the sidebar balance. Hands up, I have used Actual since April 2019 and got used to its way of doing things and as a result rarely post future dated transactions. As I say, I just use the arrows to expand the account balance view at the top of each account register so as to easily see what the cleared and uncleared balances are. PS Banktivity on Mac offers a choice as to which balance is displayed in the side bar PPS I am not trying to be quarrelsome but I would regard this as a Feature Request rather than a Bug since for right or wrong the current treatment is by design.

GiteaMirror commented

2026-04-18 03:02:24 -05:00

@rich-howell commented on GitHub (Feb 15, 2024):

The moment this becomes a feature request it will loose any traction it has and just fall into the endless pit of ideas. Hopefully someone is willing to pick this up before that happens.

nYNAB does exactly what i would like, if I create a one of schedule for a future posted transaction, after the posted date will it still appear in the schedules list? So I could end up with hundreds of schedules in a list that potentially have passed?

@rich-howell commented on GitHub (Feb 15, 2024): The moment this becomes a feature request it will loose any traction it has and just fall into the endless pit of ideas. Hopefully someone is willing to pick this up before that happens. nYNAB does exactly what i would like, if I create a one of schedule for a future posted transaction, after the posted date will it still appear in the schedules list? So I could end up with hundreds of schedules in a list that potentially have passed?

GiteaMirror commented

2026-04-18 03:02:24 -05:00

@Kidglove57 commented on GitHub (Feb 15, 2024):

So I could end up with hundreds of schedules in a list that potentially have passed?

My experience is that a completed schedule is hidden from the schedules list - but I take your point. I only need a very few one off future dated transactions a year so I guess this is a case of various users commenting who have very different use cases. In fairness to the original Dev I assume he felt that the display (by clicking the arrows) of the cleared, uncleared balances at the top of each register would address this?

HOWEVER I am all for pending transactions being marked as such and not included in the account balance OR a choice being given to the user.

Did you want these future transactions to be hidden from both the account balance AND the budget until their due date arrives? Other users seemed in the past to have varying opinions about this. Some wanted to post all their month’s transactions in advance to see the effect on their budget. I think that is where I have got a bit confused and apologies therefore to @tavlima for my initial misunderstanding.

A question - UNLESS the budget is unaffected, would this not mean that the available balances in the budget (net of future transactions) would be out of line with the recorded balance for the “for budget” accounts which could lead to difficulties for users reconciling this. Unless the “cleared total” balance figure available already against the Budgeted Accounts view (top left of register revealed by arrows) is used for this?

@Kidglove57 commented on GitHub (Feb 15, 2024): > So I could end up with hundreds of schedules in a list that potentially have passed? My experience is that a completed schedule is hidden from the schedules list - but I take your point. I only need a very few one off future dated transactions a year so I guess this is a case of various users commenting who have very different use cases. In fairness to the original Dev I assume he felt that the display (by clicking the arrows) of the cleared, uncleared balances at the top of each register would address this? HOWEVER I am all for pending transactions being marked as such and not included in the account balance OR a choice being given to the user. Did you want these future transactions to be hidden from both the account balance AND the budget until their due date arrives? Other users seemed in the past to have varying opinions about this. Some wanted to post all their month’s transactions in advance to see the effect on their budget. I think that is where I have got a bit confused and apologies therefore to @tavlima for my initial misunderstanding. A question - UNLESS the budget is unaffected, would this not mean that the available balances in the budget (net of future transactions) would be out of line with the recorded balance for the “for budget” accounts which could lead to difficulties for users reconciling this. Unless the “cleared total” balance figure available already against the Budgeted Accounts view (top left of register revealed by arrows) is used for this?

GiteaMirror commented

2026-04-18 03:02:25 -05:00

@Waseh commented on GitHub (Feb 15, 2024):

From my perspective in regards to the bank syncing just not importing transactions that are in the future would be my preferred solution, or at least getting the option of not importing transactions that are in the future.

@Waseh Could you make a separate feature request or issue ticket for that? I feel like that should at least be an option.

Sure thing, just did - #2361

@Waseh commented on GitHub (Feb 15, 2024): > > From my perspective in regards to the bank syncing just **_not_** importing transactions that are in the future would be my preferred solution, or at least getting the option of not importing transactions that are in the future. > > @Waseh Could you make a separate feature request or issue ticket for that? I feel like that should at least be an option. Sure thing, just did - #2361

GiteaMirror commented

2026-04-18 03:02:26 -05:00

@xentara1 commented on GitHub (Feb 19, 2024):

Stupid question and apologies if already covered.
should this not be handled by cleared vs uncleared transactions.
i.e future transactions are not cleared.
This can then be seen in the uncleared breakdown. (Setting can be set to adjust if cleared or uncleared is default view)
Then once the transaction actually clears it can be marked as such and thus feed the cleared balances.

This way the only change needs to be a setting adjusting if the default view is for cleared balances only or all balances.

@xentara1 commented on GitHub (Feb 19, 2024): Stupid question and apologies if already covered. should this not be handled by cleared vs uncleared transactions. i.e future transactions are not cleared. This can then be seen in the uncleared breakdown. (Setting can be set to adjust if cleared or uncleared is default view) Then once the transaction actually clears it can be marked as such and thus feed the cleared balances. This way the only change needs to be a setting adjusting if the default view is for cleared balances only or all balances.

GiteaMirror commented

2026-04-18 03:02:26 -05:00

@Kidglove57 commented on GitHub (Feb 19, 2024):

This way the only change needs to be a setting adjusting if the default view is for cleared balances only or all balances.

That is certainly the way I see it too.

@Kidglove57 commented on GitHub (Feb 19, 2024): > This way the only change needs to be a setting adjusting if the default view is for cleared balances only or all balances. That is certainly the way I see it too.

GiteaMirror commented

2026-04-18 03:02:27 -05:00

@Teprifer commented on GitHub (Feb 19, 2024):

This way the only change needs to be a setting adjusting if the default view is for cleared balances only or all balances.

That is certainly the way I see it too.

Can already add a filter, but it doesn't save.

I'm not sure repurposing the cleared flag is ideal. It would make it difficult for anyone with future transactions, and current transactions that haven't bank cleared yet.

Any proposal, in my view, shouldn't break existing workflows and app behaviour.

I think the ideal method is some form along the lines of how scheduled transactions show before they're due. Similar to YNAB upcoming.

@Teprifer commented on GitHub (Feb 19, 2024): > > This way the only change needs to be a setting adjusting if the default view is for cleared balances only or all balances. > > That is certainly the way I see it too. Can already add a filter, but it doesn't save. I'm not sure repurposing the cleared flag is ideal. It would make it difficult for anyone with future transactions, and current transactions that haven't bank cleared yet. Any proposal, in my view, shouldn't break existing workflows and app behaviour. I think the ideal method is some form along the lines of how scheduled transactions show before they're due. Similar to YNAB upcoming.

GiteaMirror commented

2026-04-18 03:02:28 -05:00

@xentara1 commented on GitHub (Feb 19, 2024):

It’s not repurposing the cleared flag.
A uncleared transactions is simply a transaction that the bank is aware of but is subject to change.
This to me sounds the same as a future transaction, which is a transaction you are aware of, but is subject to change.

From my understanding this issue is not about scheduled transactions which are treated differently already. It’s specifically about future dated transactions. Which as per above just sound like uncleared transactions to me.

@xentara1 commented on GitHub (Feb 19, 2024): It’s not repurposing the cleared flag. A uncleared transactions is simply a transaction that the bank is aware of but is subject to change. This to me sounds the same as a future transaction, which is a transaction you are aware of, but is subject to change. From my understanding this issue is not about scheduled transactions which are treated differently already. It’s specifically about future dated transactions. Which as per above just sound like uncleared transactions to me.

GiteaMirror commented

2026-04-18 03:02:29 -05:00

@Teprifer commented on GitHub (Feb 19, 2024):

It’s not repurposing the cleared flag. A uncleared transactions is simply a transaction that the bank is aware of but is subject to change. This to me sounds the same as a future transaction, which is a transaction you are aware of, but is subject to change.

From my understanding this issue is not about scheduled transactions which are treated differently already. It’s specifically about future dated transactions. Which as per above just sound like uncleared transactions to me.

It is repurposing, at the moment a transaction has an impact, cleared or not. To user it as a filter you'd have to stop it affecting budget calculations too. Now the behaviour has changed and it can't be used as it currently is.

Uncleared transactions are not future transactions, for example a payment involving a foreign currency which the bank takes time to settle the exact amount. It has happened, you want it reflected in your budget, but you don't want to mark it cleared as the value may change slightly.

A future transaction just outright hasn't happened, which is why they're asking for it not to affect balances or the budget.

These are two very different behaviours.

@Teprifer commented on GitHub (Feb 19, 2024): > It’s not repurposing the cleared flag. A uncleared transactions is simply a transaction that the bank is aware of but is subject to change. This to me sounds the same as a future transaction, which is a transaction you are aware of, but is subject to change. > > From my understanding this issue is not about scheduled transactions which are treated differently already. It’s specifically about future dated transactions. Which as per above just sound like uncleared transactions to me. It is repurposing, at the moment a transaction has an impact, cleared or not. To user it as a filter you'd have to stop it affecting budget calculations too. Now the behaviour has changed and it can't be used as it currently is. Uncleared transactions are not future transactions, for example a payment involving a foreign currency which the bank takes time to settle the exact amount. It has happened, you want it reflected in your budget, but you don't want to mark it cleared as the value may change slightly. A future transaction just outright hasn't happened, which is why they're asking for it not to affect balances or the budget. These are two very different behaviours.

GiteaMirror commented

2026-04-18 03:02:30 -05:00

@tiagodj commented on GitHub (Apr 26, 2024):

Here are my 2 cents. This is a practical example of mine, that brought me here to this thread.

I have multiple checking accounts. I have bills and credits in both of them. The option of moving everything to a single account, for me, is not ideal.

So, a scenario that I see myself in often is: how much money do I need in this account in the foreseeable future, in order to cover incoming charges?

For schedules (expected and transactions with a known amount), it works fine.

But, for example, for credit card payments it is trickier. CC payments are not really payments; they are transfers. So the money for the purchases made in the card are already accounted for in the budget, but are not necessarily in the correct account where the transfer payment will come out of.

Now, I've received the CC bill and I know it will be debited, for example, in 2 and a half weeks. But I don't have the money in the right account right now, for example because I am paid bi-weekly and haven't received the money yet. Or maybe the money is in an investment account, because I want to make some interest gains in the mean time.

So in this scenario, I'd like to enter a future transfer transaction, with the CC bill amount, so that I can see in the upcoming list that I will need to have this money ready by that day.

If I already have enough money to move beforehand, sure, I could do that. But when I don't have it right away, this visibility gives me a heads up to transfer the money in in time.

An extra bonus feature that could spawn from this is to have some kind of Alert in the UI showing that I have a transaction in X days for a specific account, but there are insufficient funds in that account (is there such a functionality? I haven't been in this scenario yet to see it).

Being able to see the future is very useful, and I believe it should be easier to manage that. I understand that the envelop system uses the money we have right now, and I agree with it. But that doesn't stop us from adding this extra layer to prepare for what's coming up.

@tiagodj commented on GitHub (Apr 26, 2024): Here are my 2 cents. This is a practical example of mine, that brought me here to this thread. I have multiple checking accounts. I have bills and credits in both of them. The option of moving everything to a single account, for me, is not ideal. So, a scenario that I see myself in often is: how much money do I need in this account in the foreseeable future, in order to cover incoming charges? For schedules (expected and transactions with a known amount), it works fine. But, for example, for credit card payments it is trickier. CC payments are not really payments; they are transfers. So the money for the purchases made in the card are already accounted for in the budget, but are not necessarily in the correct account where the transfer payment will come out of. Now, I've received the CC bill and I know it will be debited, for example, in 2 and a half weeks. But I don't have the money in the right account right now, for example because I am paid bi-weekly and haven't received the money yet. Or maybe the money is in an investment account, because I want to make some interest gains in the mean time. So in this scenario, I'd like to enter a **future** transfer transaction, with the CC bill amount, so that I can see in the upcoming list that I will need to have this money ready by that day. If I already have enough money to move beforehand, sure, I could do that. But when I don't have it right away, this visibility gives me a **heads up** to transfer the money in in time. An extra bonus feature that could spawn from this is to have some kind of Alert in the UI showing that I have a transaction in X days for a specific account, but there are insufficient funds in that account (is there such a functionality? I haven't been in this scenario yet to see it). Being able to see the future is very useful, and I believe it should be easier to manage that. I understand that the envelop system uses the money we have right now, and I agree with it. But that doesn't stop us from adding this extra layer to prepare for what's coming up.

GiteaMirror commented

2026-04-18 03:02:31 -05:00

@cati-chatou commented on GitHub (May 30, 2024):

Another case of future transactions is as following:

I know that I will have an expense on specific date, I know the amount. It is recurring but not regular expense, it does not make sense to put it on schedule. I want to see it in my future expenses so I can plan additional budget money for it. But I don't want it to impact my accounts balances or budget until the transaction actually happen, especially that in might be more than month in future.

Toolkit for YNAB additionally shows up sum of future transactions in specific month for category. This is very useful for budgeting flow: planning budget - using template as usual - seeing that I have this additional expense planned - allocating additional money.

The way Actual does it currently is plenty confusing - I have a planned (future) transaction and it treats it as "Spent", affecting budget and accounts (I caught myself few times thinking: oh no, I didn't budgeted for this - while I did, it just already have "eaten" that budget, treating it as already spent).

I think that part of budgeting is to plan for the future - be it saving, a transfer between accounts to assure that I will have the payments covered, adjusting budget to planned transactions.

@cati-chatou commented on GitHub (May 30, 2024): Another case of future transactions is as following: I know that I will have an expense on specific date, I know the amount. It is recurring but not regular expense, it does not make sense to put it on schedule. I want to see it in my future expenses so I can plan additional budget money for it. But I don't want it to impact my accounts balances or budget until the transaction actually happen, especially that in might be more than month in future. Toolkit for YNAB additionally shows up sum of future transactions in specific month for category. This is very useful for budgeting flow: planning budget - using template as usual - seeing that I have this additional expense planned - allocating additional money. The way Actual does it currently is plenty confusing - I have a planned (future) transaction and it treats it as "Spent", affecting budget and accounts (I caught myself few times thinking: oh no, I didn't budgeted for this - while I did, it just already have "eaten" that budget, treating it as already spent). I think that part of budgeting is to plan for the future - be it saving, a transfer between accounts to assure that I will have the payments covered, adjusting budget to planned transactions.

GiteaMirror commented

2026-04-18 03:02:31 -05:00

@Elarcis commented on GitHub (Sep 28, 2024):

Hi, chiming in with a personal use case:

In my country, mortgages payments are scheduled when I contract my loan — I know exactly what I’m going to pay each month for the next 10 years!

But the amount varies for each payment — each month it’s a little lower due to fees being higher at the start of the loan. I also have an off-budget account representing my loan, with a negative balance — excluding bank fees. In YNAB I just scheduled my transactions for the whole year as a split transaction, a set amount of which goes into my “loan” account, the rest goes to my bank. This represents more than €7,000 each year, which makes a non-negligible impact on my account balance on Actual.

Doing so with schedules and rules is incredibly tedious. I need to create a schedule for each month with a precise amount, then edit it as a rule and use the rule editing UI to set that to a split transaction.

Some features ideas that would help in these cases:

Allow duplicating schedules and/or rules (especially one-off schedules)
Allow inputting split transactions in schedules (or even just transactions, with note and category, automatically translated into a rule)
Facilitating split transactions in rules, like showing the split transaction editor (with payee, category and notes) with the transaction total amount locked, for example.

@Elarcis commented on GitHub (Sep 28, 2024): Hi, chiming in with a personal use case: In my country, mortgages payments are scheduled when I contract my loan — I know exactly what I’m going to pay each month for the next 10 years! But the amount varies for each payment — each month it’s a little lower due to fees being higher at the start of the loan. I also have an off-budget account representing my loan, with a negative balance — excluding bank fees. In YNAB I just scheduled my transactions for the whole year as a split transaction, a set amount of which goes into my “loan” account, the rest goes to my bank. This represents more than €7,000 each year, which makes a non-negligible impact on my account balance on Actual. Doing so with schedules and rules is _incredibly tedious_. I need to create a schedule for each month with a precise amount, then edit it as a rule and use the rule editing UI to set that to a split transaction. Some features ideas that would help in these cases: - Allow duplicating schedules and/or rules (especially one-off schedules) - Allow inputting split transactions in schedules (or even just transactions, with note and category, automatically translated into a rule) - Facilitating split transactions in rules, like showing the split transaction editor (with payee, category and notes) with the transaction total amount locked, for example.

GiteaMirror commented

2026-04-18 03:02:32 -05:00

@jfdoming commented on GitHub (Sep 28, 2024):

Hi, chiming in with a personal use case:

In my country, mortgages payments are scheduled when I contract my loan — I know exactly what I’m going to pay each month for the next 10 years!

But the amount varies for each payment — each month it’s a little lower due to fees being higher at the start of the loan. I also have an off-budget account representing my loan, with a negative balance — excluding bank fees. In YNAB I just scheduled my transactions for the whole year as a split transaction, a set amount of which goes into my “loan” account, the rest goes to my bank. This represents more than €7,000 each year, which makes a non-negligible impact on my account balance on Actual.

Doing so with schedules and rules is incredibly tedious. I need to create a schedule for each month with a precise amount, then edit it as a rule and use the rule editing UI to set that to a split transaction.

Some features ideas that would help in these cases:

Allow duplicating schedules and/or rules (especially one-off schedules)

Allow inputting split transactions in schedules (or even just transactions, with note and category, automatically translated into a rule)

Facilitating split transactions in rules, like showing the split transaction editor (with payee, category and notes) with the transaction total amount locked, for example.

I see value in the use case for sure! That said, as of a few releases ago you can input splits in rules (and also in schedules by clicking "Edit as rule"). Have you had a chance to try that? Is something not working as it should? (Disclosure: I'm the person who worked on this feature, so I'm interested in feedback 😅)

@jfdoming commented on GitHub (Sep 28, 2024): > Hi, chiming in with a personal use case: > > In my country, mortgages payments are scheduled when I contract my loan — I know exactly what I’m going to pay each month for the next 10 years! > > But the amount varies for each payment — each month it’s a little lower due to fees being higher at the start of the loan. I also have an off-budget account representing my loan, with a negative balance — excluding bank fees. In YNAB I just scheduled my transactions for the whole year as a split transaction, a set amount of which goes into my “loan” account, the rest goes to my bank. This represents more than €7,000 each year, which makes a non-negligible impact on my account balance on Actual. > > Doing so with schedules and rules is _incredibly tedious_. I need to create a schedule for each month with a precise amount, then edit it as a rule and use the rule editing UI to set that to a split transaction. > > Some features ideas that would help in these cases: > > * Allow duplicating schedules and/or rules (especially one-off schedules) > * Allow inputting split transactions in schedules (or even just transactions, with note and category, automatically translated into a rule) > * Facilitating split transactions in rules, like showing the split transaction editor (with payee, category and notes) with the transaction total amount locked, for example. I see value in the use case for sure! That said, as of a few releases ago you can input splits in rules (and also in schedules by clicking "Edit as rule"). Have you had a chance to try that? Is something not working as it should? (Disclosure: I'm the person who worked on this feature, so I'm interested in feedback 😅)

GiteaMirror commented

2026-04-18 03:02:33 -05:00

@omnizach commented on GitHub (Dec 5, 2024):

I would like to import future transactions that align with loan payments. The issue here is that the interest/principal amounts change each payment, so it's not possible to schedule them. I get that the actual payment is constant, but that's more of the on-budget use case. For the actual mortgage and tracking the loan balance (an off-budget account), you need this break down or the balance isn't reflected accurately.

@omnizach commented on GitHub (Dec 5, 2024): I would like to import future transactions that align with loan payments. The issue here is that the interest/principal amounts change each payment, so it's not possible to schedule them. I get that the actual payment is constant, but that's more of the on-budget use case. For the actual mortgage and tracking the loan balance (an off-budget account), you need this break down or the balance isn't reflected accurately.

GiteaMirror commented

2026-04-18 03:02:34 -05:00

@mullermn commented on GitHub (Jan 13, 2025):

I want to add a vote to the general sentiment that Actual should handle future dated transactions rather than ignoring them as has been suggested in some comments above. I know this can be a contentious topic among budgeters and I won't rehash my personal reasoning for this here, but I just want to add a tick in the 'for' column.

@mullermn commented on GitHub (Jan 13, 2025): I want to add a vote to the general sentiment that Actual should handle future dated transactions rather than ignoring them as has been suggested in some comments above. I know this can be a contentious topic among budgeters and I won't rehash my personal reasoning for this here, but I just want to add a tick in the 'for' column.

GiteaMirror commented

2026-04-18 03:02:34 -05:00

@mullermn commented on GitHub (Mar 4, 2025):

Apologies for replying to myself, this is an independent issue that has just come up that relates to this - I think Actual needs to review how reconciliation works with respect to future dated transactions. Currently, I can't pick the point in time against which to reconcile, but since Actual is aware of transactions that have-but-haven't happened yet, this creates a rather dumb situation where I have to pounce at the right moment when Actual's view of the balance coincides with the bank.

Right now I would like to reconcile but I can't because I'm out to the tune of £4, so Actual wants to create a reconciliation transaction - which would appear right next to the genuine, uncleared transaction that Actual is already aware of!

@mullermn commented on GitHub (Mar 4, 2025): Apologies for replying to myself, this is an independent issue that has just come up that relates to this - I think Actual needs to review how reconciliation works with respect to future dated transactions. Currently, I can't pick the point in time against which to reconcile, but since Actual is aware of transactions that have-but-haven't happened yet, this creates a rather dumb situation where I have to pounce at the right moment when Actual's view of the balance coincides with the bank. Right now I would like to reconcile but I can't because I'm out to the tune of £4, so Actual wants to create a reconciliation transaction - which would appear right next to the genuine, uncleared transaction that Actual is already aware of! ![Image](https://github.com/user-attachments/assets/2070330e-bc24-4761-b437-268dc512e85d)

GiteaMirror commented

2026-04-18 03:02:35 -05:00

@matt-fidd commented on GitHub (Mar 4, 2025):

Apologies for replying to myself, this is an independent issue that has just come up that relates to this - I think Actual needs to review how reconciliation works with respect to future dated transactions. Currently, I can't pick the point in time against which to reconcile, but since Actual is aware of transactions that have-but-haven't happened yet, this creates a rather dumb situation where I have to pounce at the right moment when Actual's view of the balance coincides with the bank.

Right now I would like to reconcile but I can't because I'm out to the tune of £4, so Actual wants to create a reconciliation transaction - which would appear right next to the genuine, uncleared transaction that Actual is already aware of!

Future transactions should be handled with schedules, not transactions dated into the future.
If that transaction has posted at your bank, then you can mark it as cleared in Actual to match and reconciliation will work as expected.
If that transaction has not yet posted at your bank then the cleared balance is correct at 8003.48 and you are inputting the cleared+pending balance, which will not work.

@matt-fidd commented on GitHub (Mar 4, 2025): > Apologies for replying to myself, this is an independent issue that has just come up that relates to this - I think Actual needs to review how reconciliation works with respect to future dated transactions. Currently, I can't pick the point in time against which to reconcile, but since Actual is aware of transactions that have-but-haven't happened yet, this creates a rather dumb situation where I have to pounce at the right moment when Actual's view of the balance coincides with the bank. > > Right now I would like to reconcile but I can't because I'm out to the tune of £4, so Actual wants to create a reconciliation transaction - which would appear right next to the genuine, uncleared transaction that Actual is already aware of! > > ![Image](https://github.com/user-attachments/assets/2070330e-bc24-4761-b437-268dc512e85d) Future transactions should be handled with schedules, not transactions dated into the future. If that transaction has posted at your bank, then you can mark it as cleared in Actual to match and reconciliation will work as expected. If that transaction has not yet posted at your bank then the cleared balance is correct at 8003.48 and you are inputting the cleared+pending balance, which will not work.

GiteaMirror commented

2026-04-18 03:02:36 -05:00

@mullermn commented on GitHub (Mar 4, 2025):

Future transactions should be handled with schedules, not transactions dated into the future. If that transaction has posted at your bank, then you can mark it as cleared in Actual to match and reconciliation will work as expected. If that transaction has not yet posted at your bank then the cleared balance is correct at 8003.48 and you are inputting the cleared+pending balance, which will not work.

OK, I was assuming that tampering with the bank-sync imported data was a bad idea, but if that's an acceptable workflow that does work around this. Thanks

@mullermn commented on GitHub (Mar 4, 2025): > Future transactions should be handled with schedules, not transactions dated into the future. If that transaction has posted at your bank, then you can mark it as cleared in Actual to match and reconciliation will work as expected. If that transaction has not yet posted at your bank then the cleared balance is correct at 8003.48 and you are inputting the cleared+pending balance, which will not work. OK, I was assuming that tampering with the bank-sync imported data was a bad idea, but if that's an acceptable workflow that does work around this. Thanks

GiteaMirror commented

2026-04-18 03:02:37 -05:00

@SalocinHB commented on GitHub (Mar 4, 2025):

OK, I was assuming that tampering with the bank-sync imported data was a bad idea, but if that's an acceptable workflow that does work around this. Thanks

With v2025.3 you can disable importing uncleared transactions. Then those transactions won’t show up until they've actually cleared in your bank account.

@SalocinHB commented on GitHub (Mar 4, 2025): > OK, I was assuming that tampering with the bank-sync imported data was a bad idea, but if that's an acceptable workflow that does work around this. Thanks With v2025.3 you can disable importing uncleared transactions. Then those transactions won’t show up until they've actually cleared in your bank account.

GiteaMirror commented

2026-04-18 03:02:39 -05:00

@felipewnp commented on GitHub (Mar 4, 2025):

+1 on this.

Doesn't make sense to just "ignore" something that is clearly not right.

If it's not yet in the "envelope" it shouldn't show as it is.

Just because I will receive a monthly deposit of 10,000.00 for 10 years doesn't mean I have 1,200,000.00 right now.

And people should not "just ignore" this.

@felipewnp commented on GitHub (Mar 4, 2025): +1 on this. Doesn't make sense to just "ignore" something that is clearly not right. If it's not yet in the "envelope" it shouldn't show as it is. Just because I will receive a monthly deposit of 10,000.00 for 10 years doesn't mean I have 1,200,000.00 right now. And people should not "just ignore" this.

GiteaMirror commented

2026-04-18 03:02:39 -05:00

@andersoal commented on GitHub (Apr 26, 2025):

@cati-chatou said something that is important to this discussion

Toolkit for YNAB additionally shows up sum of future transactions in specific month for category. This is very useful for budgeting flow: planning budget - using template as usual - seeing that I have this additional expense planned - allocating additional money.

This is true, even without Toolkit for YNAB (extension) YNAB shows upcoming transactions (schedules) to help budget Month Ahead Strategy.

Considering the layout of Actual that allows to budget 2 or more months at the same time, the Month Ahead Strategy has a much better experience than other apps.

But we need to see how much a category needs in the next month.

Currently, with future transactions it has a benefit to see the upcoming transactions and try the Month Ahead Strategy to cover the spend that is already an obligation because it's money that was borrowed, so I'm carrying debt and have to deal with that in the upcoming month.

But the Account Balance calculation doesn't consider Date (Until Today) or Cleared/Reconciled, even though is debatable in the case of On Budget Account for Credit Card because some will want to see all the money that was borrowed (all future debt that will be needed to be paid in the coming months), and others will want to see what was Cleared/Reconciled.

#1995

About Schedules
It is supposed to be the feature to deal with future transactions with or without a limit of repetition/date (much better than YNAB by the way).

But the experience overall is not align with the Month Ahead Strategy, see #4815 for consideration.

⚠️ I had to Edit as Rule the schedule to define the category even though I used an existing transaction that already has the category defined to create the schedule (some improvement for the future).

So, I think it will be a step backwards if somehow prevents transactions from being inserted in the future, forcing to being schedules. By the way, for comparison, as far I remember, YNAB doesn't import future transactions and this is one of the reasons I struggle to keep using it because the schedules are very challenging to maintain in their app.

💡 From my point of view, It would be nice to consider only showing the Account Balance considering Date Until Today or if allowed just considered Cleared/Reconciled transactions. It makes sense, and it will work very well, specially with On Budget Account and allow future transactions.

Also, it's important to consider the Tracking Budget.

@andersoal commented on GitHub (Apr 26, 2025): @cati-chatou said something that is important to this discussion > Toolkit for YNAB additionally shows up sum of future transactions in specific month for category. This is very useful for budgeting flow: planning budget - using template as usual - seeing that I have this additional expense planned - allocating additional money. This is true, even without Toolkit for YNAB (extension) YNAB shows upcoming transactions (schedules) to help budget [Month Ahead Strategy](https://actualbudget.com/docs/getting-started/envelope-budgeting#the-month-ahead-strategy). ![Image](https://github.com/user-attachments/assets/932d0c95-14d3-4d3e-9c5a-1bf23c9cc72d) --- Considering the layout of Actual that allows to budget 2 or more months at the same time, the Month Ahead Strategy has a much better experience than other apps. But we need to see how much a category needs in the next month. Currently, with **future transactions** it has a benefit to see the upcoming transactions and try the [Month Ahead Strategy](https://actualbudget.com/docs/getting-started/envelope-budgeting#the-month-ahead-strategy) to cover the spend that is already an obligation because it's money that was borrowed, so I'm [carrying debt](https://actualbudget.com/docs/budgeting/credit-cards/carrying-debt) and have to deal with that in the upcoming month. ![Image](https://github.com/user-attachments/assets/24557aa2-eae2-4b27-8b9c-6b68b4e49439) But the **Account Balance** calculation doesn't consider **Date (Until Today)** or **Cleared/Reconciled**, even though is debatable in the case of [**On Budget Account for Credit Card**](https://actualbudget.com/docs/accounts/#:~:text=On%20budget%20accounts%20affect%20the%20budget%2C%20and%20transactions%20can%20be%20categorized.%20These%20are%20accounts%20where%20you%20want%20to%20track%20cash%20flow%20and%20use%20the%20budget%2C%20like%20checking%20accounts%20and%20credit%20cards.) because some will want to see all the money that was borrowed (all future debt that will be needed to be paid in the coming months), and others will want to see what was **Cleared/Reconciled**. #1995 --- About **Schedules** It is supposed to be the feature to deal with **future transactions** with or without a limit of repetition/date (much better than YNAB by the way). But the experience overall is not align with the [Month Ahead Strategy](https://actualbudget.com/docs/getting-started/envelope-budgeting#the-month-ahead-strategy), see #4815 for consideration. ![Image](https://github.com/user-attachments/assets/57b0c42b-e25a-4820-925e-de47f98a0411) ⚠️ I had to [Edit as Rule the schedule to define the category](https://actualbudget.com/docs/schedules#how-to-use-rules-with-schedules:~:text=By%20clicking%20the%20%2B%20arrow%20on%20in%20the%20Then%20apply%20these%20actions%20area%2C%20you%20can%20define%20the%20category%20this%20schedule%20should%20be%20assigned%20against%20as%20well%20as%20any%20notes%20you%20might%20want%20to%20include.) even though I used an existing transaction that already has the category defined to create the schedule (some improvement for the future). ![Image](https://github.com/user-attachments/assets/b9c5af36-9011-4d81-af21-5481bf7e4c7e) --- So, I think it will be a step backwards if somehow prevents transactions from being inserted in the future, forcing to being schedules. By the way, for comparison, as far I remember, YNAB doesn't import future transactions and this is one of the reasons I struggle to keep using it because the schedules are very challenging to maintain in their app. 💡 From my point of view, It would be nice to consider only showing the **Account Balance** considering **Date Until Today** or if allowed just considered **Cleared/Reconciled** transactions. It makes sense, and it will work very well, specially with **On Budget Account** and allow **future transactions**. Also, it's important to consider the [Tracking Budget](https://actualbudget.com/docs/getting-started/tracking-budget/).

GiteaMirror commented

2026-04-18 03:02:41 -05:00

@kabo commented on GitHub (Jul 9, 2025):

Would it be very hard to have a setting, "only include cleared transactions in the sidebar balance" or similar?

@kabo commented on GitHub (Jul 9, 2025): Would it be very hard to have a setting, "only include cleared transactions in the sidebar balance" or similar?

GiteaMirror commented

2026-04-18 03:02:41 -05:00

@atgrey24 commented on GitHub (Jul 28, 2025):

Would it be very hard to have a setting, "only include cleared transactions in the sidebar balance" or similar?

You can already filter transactions by Cleared status, and save that for reuse. Or do you mean in the budget view? I don't think that's a good idea. In theory, you entered the transaction because you know that it's real, so it's important to have that reflected in your budget. You know that you spent the money, even if it takes a few days for the bank to acknowledge that it was processed.

@atgrey24 commented on GitHub (Jul 28, 2025): > Would it be very hard to have a setting, "only include cleared transactions in the sidebar balance" or similar? You can already filter transactions by Cleared status, and save that for reuse. Or do you mean in the budget view? I don't think that's a good idea. In theory, you entered the transaction because you know that it's real, so it's important to have that reflected in your budget. You know that you spent the money, even if it takes a few days for the bank to acknowledge that it was processed.

GiteaMirror commented

2026-04-18 03:02:42 -05:00

@cati-chatou commented on GitHub (Jul 28, 2025):

Would it be very hard to have a setting, "only include cleared transactions in the sidebar balance" or similar?

You can already filter transactions by Cleared status, and save that for reuse. Or do you mean in the budget view? I don't think that's a good idea. In theory, you entered the transaction because you know that it's real, so it's important to have that reflected in your budget. You know that you spent the money, even if it takes a few days for the bank to acknowledge that it was processed.

I think it was about account balances side bar view. And it is indeed a simple solution for those who do not want to see future transactions accounted in today’s balance. I for one. I enter the transaction because I know it would happen, be it tomorrow or in week or month time. For example irregular doctor’s appointment - it doesn’t make sense to put it on schedule, I know the amount required already, I put it there to not forget to budget for it, but I would much prefer for it not to skew my today’s balances.

@cati-chatou commented on GitHub (Jul 28, 2025): > > Would it be very hard to have a setting, "only include cleared transactions in the sidebar balance" or similar? > > You can already filter transactions by Cleared status, and save that for reuse. Or do you mean in the budget view? I don't think that's a good idea. In theory, you entered the transaction because you know that it's real, so it's important to have that reflected in your budget. You know that you spent the money, even if it takes a few days for the bank to acknowledge that it was processed. I think it was about account balances side bar view. And it is indeed a simple solution for those who do not want to see future transactions accounted in today’s balance. I for one. I enter the transaction because I know it would happen, be it tomorrow or in week or month time. For example irregular doctor’s appointment - it doesn’t make sense to put it on schedule, I know the amount required already, I put it there to not forget to budget for it, but I would much prefer for it not to skew my today’s balances.

GiteaMirror commented

2026-04-18 03:02:42 -05:00

@atgrey24 commented on GitHub (Jul 28, 2025):

@cati-chatou scheduled transactions aren't strictly for recuring transactions, they're basically just reminders for known future transactions. Your example definitely one of the use cases for scheduled transactions.

That said, I definitely understand the friction of needing to go into schedules for that instead of simply entering the transaction like normal. One thing I really like about nYNAB's implementation is that you created future/scheduled transactions the same way as any other. If you make a transaction with a future date, it just become a "scheduled transaction" automatically. You get a warning on the budget screen that there's an upcoming transaction, but it does not affect your account balances or appear as "spent" unless you choose to post the transaction early.

I would love it if Actual could implement a similar seamless workflow. You'd still have the regular schedules interface when you want that extra granular control.

@atgrey24 commented on GitHub (Jul 28, 2025): @cati-chatou scheduled transactions aren't strictly for recuring transactions, they're basically just reminders for known future transactions. Your example definitely one of the use cases for scheduled transactions. That said, I definitely understand the friction of needing to go into schedules for that instead of simply entering the transaction like normal. One thing I really like about nYNAB's implementation is that you created future/scheduled transactions the same way as any other. If you make a transaction with a future date, it just become a "scheduled transaction" automatically. You get a warning on the budget screen that there's an upcoming transaction, but it does not affect your account balances or appear as "spent" unless you choose to post the transaction early. I would love it if Actual could implement a similar seamless workflow. You'd still have the regular schedules interface when you want that extra granular control.

GiteaMirror commented

2026-04-18 03:02:43 -05:00

@mullermn commented on GitHub (Jul 28, 2025):

I don't think this is a question with one 'correct' answer. If I'm reviewing how my finances are today, I don't want transactions that haven't occurred yet to factor in to those numbers because that future might yet change, and because Actual's numbers wouldn't reconcile with any other party like my bank.

However, if I'm doing something forward-facing, like budgeting (which is after all the entire reason software like Actual exists), I absolutely do want those transactions that I 'know' are going to happen to factor in those numbers, because otherwise I'm just doing mental busy work to remember that the 100.00 I have in that category is really 80 because I'm going to spend 20 next week.

I think you need a top level toggle that turns on/off whether future dated transactions are factored in, and that toggle would affect both account balances and category balances in the budget view. 'Show me how things are now' vs. 'show me how things are if they play out as I think they will'.

@mullermn commented on GitHub (Jul 28, 2025): I don't think this is a question with one 'correct' answer. If I'm reviewing how my finances are today, I don't want transactions that haven't occurred yet to factor in to those numbers because that future might yet change, and because Actual's numbers wouldn't reconcile with any other party like my bank. However, if I'm doing something forward-facing, like budgeting (which is after all the entire reason software like Actual exists), I absolutely do want those transactions that I 'know' are going to happen to factor in those numbers, because otherwise I'm just doing mental busy work to remember that the 100.00 I have in that category is really 80 because I'm going to spend 20 next week. I think you need a top level toggle that turns on/off whether future dated transactions are factored in, and that toggle would affect both account balances and category balances in the budget view. 'Show me how things are now' vs. 'show me how things are if they play out as I think they will'.

GiteaMirror commented

2026-04-18 03:02:44 -05:00

@ngist commented on GitHub (Aug 8, 2025):

Hi, chiming in with a personal use case:
In my country, mortgages payments are scheduled when I contract my loan — I know exactly what I’m going to pay each month for the next 10 years!
But the amount varies for each payment — each month it’s a little lower due to fees being higher at the start of the loan. I also have an off-budget account representing my loan, with a negative balance — excluding bank fees. In YNAB I just scheduled my transactions for the whole year as a split transaction, a set amount of which goes into my “loan” account, the rest goes to my bank. This represents more than €7,000 each year, which makes a non-negligible impact on my account balance on Actual.
Doing so with schedules and rules is incredibly tedious. I need to create a schedule for each month with a precise amount, then edit it as a rule and use the rule editing UI to set that to a split transaction.
Some features ideas that would help in these cases:

Allow duplicating schedules and/or rules (especially one-off schedules)

Allow inputting split transactions in schedules (or even just transactions, with note and category, automatically translated into a rule)

Facilitating split transactions in rules, like showing the split transaction editor (with payee, category and notes) with the transaction total amount locked, for example.

I see value in the use case for sure! That said, as of a few releases ago you can input splits in rules (and also in schedules by clicking "Edit as rule"). Have you had a chance to try that? Is something not working as it should? (Disclosure: I'm the person who worked on this feature, so I'm interested in feedback 😅)

@jfdoming

I just started with actual a few days ago and discovered the ability split transactions in rules, it worked beautifully for my mortgage use case. I setup one account for the loan and another for escrow balance. The mortgage payment is fixed but escrow changes every now and again. I was able to split up the last year of transactions automatically and easily.

The issue i'm struggling with now is how to best subdivide the principle and interest since they change every month, I looked at actual-helpers project but it won't backfill data. I can easily generate a spreadsheet of transactions and import for the historical data, and possible future transactions, but I'm worried that will cause me issues with correct balance computation. Maybe I'll try using actual-helpers after I manually backfill.

@ngist commented on GitHub (Aug 8, 2025): > > Hi, chiming in with a personal use case: > > In my country, mortgages payments are scheduled when I contract my loan — I know exactly what I’m going to pay each month for the next 10 years! > > But the amount varies for each payment — each month it’s a little lower due to fees being higher at the start of the loan. I also have an off-budget account representing my loan, with a negative balance — excluding bank fees. In YNAB I just scheduled my transactions for the whole year as a split transaction, a set amount of which goes into my “loan” account, the rest goes to my bank. This represents more than €7,000 each year, which makes a non-negligible impact on my account balance on Actual. > > Doing so with schedules and rules is _incredibly tedious_. I need to create a schedule for each month with a precise amount, then edit it as a rule and use the rule editing UI to set that to a split transaction. > > Some features ideas that would help in these cases: > > > > * Allow duplicating schedules and/or rules (especially one-off schedules) > > * Allow inputting split transactions in schedules (or even just transactions, with note and category, automatically translated into a rule) > > * Facilitating split transactions in rules, like showing the split transaction editor (with payee, category and notes) with the transaction total amount locked, for example. > > I see value in the use case for sure! That said, as of a few releases ago you can input splits in rules (and also in schedules by clicking "Edit as rule"). Have you had a chance to try that? Is something not working as it should? (Disclosure: I'm the person who worked on this feature, so I'm interested in feedback 😅) @jfdoming I just started with actual a few days ago and discovered the ability split transactions in rules, it worked beautifully for my mortgage use case. I setup one account for the loan and another for escrow balance. The mortgage payment is fixed but escrow changes every now and again. I was able to split up the last year of transactions automatically and easily. The issue i'm struggling with now is how to best subdivide the principle and interest since they change every month, I looked at actual-helpers project but it won't backfill data. I can easily generate a spreadsheet of transactions and import for the historical data, and possible future transactions, but I'm worried that will cause me issues with correct balance computation. Maybe I'll try using actual-helpers after I manually backfill.

GiteaMirror commented

2026-04-18 03:02:45 -05:00

@ksmithbaylor commented on GitHub (Aug 23, 2025):

Throwing my hat in the ring on the "future transactions" issue, I like to enter my expected income a few months ahead of time so I can budget out a few months. Schedules aren't reflected as income in future months' budgets, so what I do is have an on-budget "Future income" account. When those paychecks (or whatever) actually hit my accounts, I move them from that account to whichever account they should be in. This lets me budget ahead but still keep each account accurate to what's there already.

For me, it would be useful to be able to select subsets of accounts to display totals for, or at least exclude specific accounts from the total.

@ksmithbaylor commented on GitHub (Aug 23, 2025): Throwing my hat in the ring on the "future transactions" issue, I like to enter my expected income a few months ahead of time so I can budget out a few months. Schedules aren't reflected as income in future months' budgets, so what I do is have an on-budget "Future income" account. When those paychecks (or whatever) actually hit my accounts, I move them from that account to whichever account they should be in. This lets me budget ahead but still keep each account accurate to what's there already. For me, it would be useful to be able to select subsets of accounts to display totals for, or at least exclude specific accounts from the total.

GiteaMirror commented

2026-04-18 03:02:46 -05:00

@rtbick commented on GitHub (Oct 16, 2025):

I enter all transactions manually, so each of these things is really important to my workflow:

Confirming the account's total in Actual matches the real account, as a way to check for errors
Scheduling transactions as much as possible (both one-time and recurring)
Using the mobile app to enter a transaction soon after it occurs, instead of waiting for access to my PC

The mobile app currently doesn't allow access to Schedules (see my feature request here). So, if I need to add a future transaction on mobile, I must add it as a "normal" transaction. This makes the account balance no longer match the real account, and adds cognitive overhead for the next time I look at my budget on PC, where I need to set it up properly as a Schedule.

One thing I really like about nYNAB's implementation is that you created future/scheduled transactions the same way as any other. If you make a transaction with a future date, it just become a "scheduled transaction" automatically. You get a warning on the budget screen that there's an upcoming transaction, but it does not affect your account balances or appear as "spent" unless you choose to post the transaction early.

I would love it if Actual could implement a similar seamless workflow. You'd still have the regular schedules interface when you want that extra granular control.

I agree strongly with @atgrey24 here, as a user coming from nYNAB. I find it very intuitive for a transaction with a future date to be automatically be considered a scheduled transaction. In fact, I think that entering future transactions as way to project account balances contradicts the envelope budgeting philosophy. I'm accustomed to only budgeting the funds that I currently have.

I also feel that the Transaction workflow to add a one-time future transaction is more intuitive than going into the Schedules page. The Schedule options, while powerful, feel like overkill for one-time transactions.

Would auto-converting future-dated transactions into Scheduled transactions solve @tavlima's use case? Or should I make a separate issue to discuss that idea?

@rtbick commented on GitHub (Oct 16, 2025): I enter all transactions manually, so each of these things is really important to my workflow: - Confirming the account's total in Actual matches the real account, as a way to check for errors - Scheduling transactions as much as possible (both one-time and recurring) - Using the mobile app to enter a transaction soon after it occurs, instead of waiting for access to my PC The mobile app currently doesn't allow access to Schedules [(see my feature request here)](https://github.com/actualbudget/actual/issues/5938#issue-3522787749). So, if I need to add a future transaction on mobile, I must add it as a "normal" transaction. This makes the account balance no longer match the real account, and adds cognitive overhead for the next time I look at my budget on PC, where I need to set it up properly as a Schedule. > One thing I really like about nYNAB's implementation is that you created future/scheduled transactions the same way as any other. If you make a transaction with a future date, it just become a "scheduled transaction" automatically. You get a warning on the budget screen that there's an upcoming transaction, but it does not affect your account balances or appear as "spent" unless you choose to post the transaction early. > > I would love it if Actual could implement a similar seamless workflow. You'd still have the regular schedules interface when you want that extra granular control. I agree strongly with @atgrey24 here, as a user coming from nYNAB. I find it very intuitive for a transaction with a future date to be automatically be considered a scheduled transaction. In fact, I think that entering future transactions as way to project account balances contradicts the envelope budgeting philosophy. I'm accustomed to only budgeting the funds that I currently have. I also feel that the Transaction workflow to add a one-time future transaction is more intuitive than going into the Schedules page. The Schedule options, while powerful, feel like overkill for one-time transactions. Would auto-converting future-dated transactions into Scheduled transactions solve @tavlima's use case? Or should I make a separate issue to discuss that idea?

GiteaMirror commented

2026-04-18 03:02:47 -05:00

@Crosis47 commented on GitHub (Nov 3, 2025):

I feel an easy quick fix for this would be to just add a "year-to-date" balance that shows the running balance as of today's date in the balance information that is available when clicking on the balance under the account name.

I have just begun the process of switching from Quicken to Actual and I am currently doing this by filtering transactions to only include less than or equal to today and then the filtered balance is my year to date but this should honestly just be always visible as having to do these steps to just see how much money I actually have right now is kind of silly.

@Crosis47 commented on GitHub (Nov 3, 2025): I feel an easy quick fix for this would be to just add a "year-to-date" balance that shows the running balance as of today's date in the balance information that is available when clicking on the balance under the account name. I have just begun the process of switching from Quicken to Actual and I am currently doing this by filtering transactions to only include less than or equal to today and then the filtered balance is my year to date but this should honestly just be always visible as having to do these steps to just see how much money I actually have right now is kind of silly.

GiteaMirror commented

2026-04-18 03:02:47 -05:00

@youngcw commented on GitHub (Nov 7, 2025):

A new feature was just added to Actual that allows a user to create a non-repeating schedule directly from the account view. The option will show up anytime a transaction has a date in the future. This way a user can decide if they want the upcoming transaction to be a regular transaction, and included in the account balance and budget, or the transaction to become a schedule and not be included in the account balance or budget. If the transaction is turned into a schedule then it will show up in the account page with other upcoming schedules.

The feature is currently available on the edge build. You can try it using https://edge.actualbudget.org

@youngcw commented on GitHub (Nov 7, 2025): A new feature was just added to Actual that allows a user to create a non-repeating schedule directly from the account view. The option will show up anytime a transaction has a date in the future. This way a user can decide if they want the upcoming transaction to be a regular transaction, and included in the account balance and budget, or the transaction to become a schedule and not be included in the account balance or budget. If the transaction is turned into a schedule then it will show up in the account page with other upcoming schedules. The feature is currently available on the edge build. You can try it using https://edge.actualbudget.org

GiteaMirror commented

2026-04-18 03:02:49 -05:00

@kabo commented on GitHub (Nov 8, 2025):

Hmm, that new feature doesn't help me at least.
I've started doing the workaround described by ksmithbaylor here
https://github.com/actualbudget/actual/issues/2354#issuecomment-3217412459

A bit clunky but gets the job done. It would be nice if there was just a setting for the sidebar totals to only include cleared transactions...

@kabo commented on GitHub (Nov 8, 2025): Hmm, that new feature doesn't help me at least. I've started doing the workaround described by ksmithbaylor here https://github.com/actualbudget/actual/issues/2354#issuecomment-3217412459 A bit clunky but gets the job done. It would be nice if there was just a setting for the sidebar totals to only include cleared transactions...

GiteaMirror commented

2026-04-18 03:02:52 -05:00

@SLahti commented on GitHub (Nov 10, 2025):

I enter all transactions manually, so each of these things is really important to my workflow:

Confirming the account's total in Actual matches the real account, as a way to check for errors

Scheduling transactions as much as possible (both one-time and recurring)

Using the mobile app to enter a transaction soon after it occurs, instead of waiting for access to my PC

The mobile app currently doesn't allow access to Schedules (see my feature request here). So, if I need to add a future transaction on mobile, I must add it as a "normal" transaction. This makes the account balance no longer match the real account, and adds cognitive overhead for the next time I look at my budget on PC, where I need to set it up properly as a Schedule.

One thing I really like about nYNAB's implementation is that you created future/scheduled transactions the same way as any other. If you make a transaction with a future date, it just become a "scheduled transaction" automatically. You get a warning on the budget screen that there's an upcoming transaction, but it does not affect your account balances or appear as "spent" unless you choose to post the transaction early.
I would love it if Actual could implement a similar seamless workflow. You'd still have the regular schedules interface when you want that extra granular control.

I agree strongly with @atgrey24 here, as a user coming from nYNAB. I find it very intuitive for a transaction with a future date to be automatically be considered a scheduled transaction. In fact, I think that entering future transactions as way to project account balances contradicts the envelope budgeting philosophy. I'm accustomed to only budgeting the funds that I currently have.

I also feel that the Transaction workflow to add a one-time future transaction is more intuitive than going into the Schedules page. The Schedule options, while powerful, feel like overkill for one-time transactions.

Would auto-converting future-dated transactions into Scheduled transactions solve @tavlima's use case? Or should I make a separate issue to discuss that idea?

I agree with all of this. I also use Actual in a similar fashion.

A new feature was just added to Actual that allows a user to create a non-repeating schedule directly from the account view. The option will show up anytime a transaction has a date in the future. This way a user can decide if they want the upcoming transaction to be a regular transaction, and included in the account balance and budget, or the transaction to become a schedule and not be included in the account balance or budget. If the transaction is turned into a schedule then it will show up in the account page with other upcoming schedules.

The feature is currently available on the edge build. You can try it using https://edge.actualbudget.org

Isn't that a bit flawed? Shouldn't schedules be reflected in the budget? That way you know what you need to allocate to cover the expected spending(isn't that the purpose of schedules?). Maybe it could be decided by the "Upcoming length" setting or just show none/all schedules in the budget. Otherwise the purpose of schedules seems to me as just a list of things you need to remember to budget for. My list of schedules is very long so this is a time consuming effort. Sure I can use upcoming length to see that my account balances can cover the upcoming spendings but it doesn't help me with budgeting/planning. Sorry about the rant, I do love Actual despite this issue.

@SLahti commented on GitHub (Nov 10, 2025): > I enter all transactions manually, so each of these things is really important to my workflow: > > * Confirming the account's total in Actual matches the real account, as a way to check for errors > * Scheduling transactions as much as possible (both one-time and recurring) > * Using the mobile app to enter a transaction soon after it occurs, instead of waiting for access to my PC > > The mobile app currently doesn't allow access to Schedules [(see my feature request here)](https://github.com/actualbudget/actual/issues/5938#issue-3522787749). So, if I need to add a future transaction on mobile, I must add it as a "normal" transaction. This makes the account balance no longer match the real account, and adds cognitive overhead for the next time I look at my budget on PC, where I need to set it up properly as a Schedule. > > > One thing I really like about nYNAB's implementation is that you created future/scheduled transactions the same way as any other. If you make a transaction with a future date, it just become a "scheduled transaction" automatically. You get a warning on the budget screen that there's an upcoming transaction, but it does not affect your account balances or appear as "spent" unless you choose to post the transaction early. > > I would love it if Actual could implement a similar seamless workflow. You'd still have the regular schedules interface when you want that extra granular control. > > I agree strongly with [@atgrey24](https://github.com/atgrey24) here, as a user coming from nYNAB. I find it very intuitive for a transaction with a future date to be automatically be considered a scheduled transaction. In fact, I think that entering future transactions as way to project account balances contradicts the envelope budgeting philosophy. I'm accustomed to only budgeting the funds that I currently have. > > I also feel that the Transaction workflow to add a one-time future transaction is more intuitive than going into the Schedules page. The Schedule options, while powerful, feel like overkill for one-time transactions. > > Would auto-converting future-dated transactions into Scheduled transactions solve [@tavlima](https://github.com/tavlima)'s use case? Or should I make a separate issue to discuss that idea? I agree with all of this. I also use Actual in a similar fashion. > A new feature was just added to Actual that allows a user to create a non-repeating schedule directly from the account view. The option will show up anytime a transaction has a date in the future. This way a user can decide if they want the upcoming transaction to be a regular transaction, and included in the account balance and budget, or the transaction to become a schedule and not be included in the account balance or budget. If the transaction is turned into a schedule then it will show up in the account page with other upcoming schedules. > > The feature is currently available on the edge build. You can try it using https://edge.actualbudget.org Isn't that a bit flawed? Shouldn't schedules be reflected in the budget? That way you know what you need to allocate to cover the expected spending(isn't that the purpose of schedules?). Maybe it could be decided by the "Upcoming length" setting or just show none/all schedules in the budget. Otherwise the purpose of schedules seems to me as just a list of things you need to remember to budget for. My list of schedules is very long so this is a time consuming effort. Sure I can use upcoming length to see that my account balances can cover the upcoming spendings but it doesn't help me with budgeting/planning. Sorry about the rant, I do love Actual despite this issue.

GiteaMirror commented

2026-04-18 03:02:54 -05:00

@Juulz commented on GitHub (Nov 10, 2025):

I'd be happy just to get a darker line (red, blue, purple, dark gray) in the transaction lists demarcating below anything newer than today. I can use the running balance to see today's balance.

@Juulz commented on GitHub (Nov 10, 2025): I'd be happy just to get a darker line (red, blue, purple, dark gray) in the transaction lists demarcating below anything newer than today. I can use the running balance to see today's balance.

GiteaMirror commented

2026-04-18 03:02:54 -05:00

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

I'd be happy just to get a darker line (red, blue, purple, dark gray) in the transaction lists demarcating below anything newer than today. I can use the running balance to see today's balance.

I made this exact request and was told that's what schedules are for.

@Crosis47 commented on GitHub (Dec 5, 2025): > I'd be happy just to get a darker line (red, blue, purple, dark gray) in the transaction lists demarcating below anything newer than today. I can use the running balance to see today's balance. I made this exact request and was told that's what schedules are for.

GiteaMirror commented

2026-04-18 03:02:55 -05:00

@cati-chatou commented on GitHub (Dec 5, 2025):

I sort of gave up.

So now I'm using schedules for some recurring-regular-always-same-amount expenses, but... for all the other expected transactions (including regular but amount changing payments) I'm using either external notes (pity) or I'm adding them to templates.

I still think that expected transactions impacting current balance is just wrong. But Actual budget is still useful, robust and free, so I can live with that.

@cati-chatou commented on GitHub (Dec 5, 2025): I sort of gave up. So now I'm using schedules for some recurring-regular-always-same-amount expenses, but... for all the other expected transactions (including regular but amount changing payments) I'm using either external notes (pity) or I'm adding them to templates. I still think that expected transactions impacting current balance is just wrong. But Actual budget is still useful, robust and free, so I can live with that.

GiteaMirror commented

2026-04-18 03:02:56 -05:00

@d2718nis commented on GitHub (Dec 8, 2025):

Here's how YNAB does it:

Upcoming transactions do not appear in the account balance summary until its set date, they are visually distinct from the current ones and it's super useful.

I made this exact request and was told that's what schedules are for.

Schedules are useful for the recurring transactions, but if it's a oneshot or in case the amount is variable creating them manually on the account is a much more user-friendly approach.

In the end, is this a question of product design or insufficient resources to implement this feature?

@d2718nis commented on GitHub (Dec 8, 2025): Here's how YNAB does it: <img width="1415" height="879" alt="Image" src="https://github.com/user-attachments/assets/8b2b5d84-d6d5-47d6-9879-6d287c60b408" /> Upcoming transactions do not appear in the account balance summary until its set date, they are visually distinct from the current ones and it's super useful. > I made this exact request and was told that's what schedules are for. Schedules are useful for the recurring transactions, but if it's a oneshot or in case the amount is variable creating them manually on the account is a **much more user-friendly** approach. In the end, is this a question of product design or insufficient resources to implement this feature?

GiteaMirror commented

2026-04-18 03:02:56 -05:00

@atgrey24 commented on GitHub (Dec 9, 2025):

@d2718nis the 25.12.0 patch notes say that #6065 has been implemented already

@atgrey24 commented on GitHub (Dec 9, 2025): @d2718nis the 25.12.0 patch notes say that #6065 has been implemented already

GiteaMirror commented

2026-04-18 03:02:57 -05:00

@SLahti commented on GitHub (Dec 10, 2025):

@d2718nis the 25.12.0 patch notes say that #6065 has been implemented already

For me this works as a solution. However it still clogs the schedule page with "unnecessary" one offs until they are solved. It is good enough though.

@SLahti commented on GitHub (Dec 10, 2025): > [@d2718nis](https://github.com/d2718nis) the 25.12.0 patch notes say that [#6065](https://github.com/actualbudget/actual/pull/6065) has been implemented already For me this works as a solution. However it still clogs the schedule page with "unnecessary" one offs until they are solved. It is good enough though.

GiteaMirror commented

2026-04-18 03:02:58 -05:00

@d2718nis commented on GitHub (Dec 13, 2025):

@d2718nis the 25.12.0 patch notes say that #6065 has been implemented already

Cool, thanks for letting me know! A bit weird that you need that extra step but it's a design choice and it's fine.

For me this works as a solution. However it still clogs the schedule page with "unnecessary" one offs until they are solved. It is good enough though.

Maybe adding a quick filter for oneshot vs recurring schedules on that Schedules view would be a good idea?

@d2718nis commented on GitHub (Dec 13, 2025): > [@d2718nis](https://github.com/d2718nis) the 25.12.0 patch notes say that [#6065](https://github.com/actualbudget/actual/pull/6065) has been implemented already Cool, thanks for letting me know! A bit weird that you need that extra step but it's a design choice and it's fine. > For me this works as a solution. However it still clogs the schedule page with "unnecessary" one offs until they are solved. It is good enough though. Maybe adding a quick filter for oneshot vs recurring schedules on that Schedules view would be a good idea?

GiteaMirror commented

2026-04-18 03:02:59 -05:00

@Crosis47 commented on GitHub (Apr 8, 2026):

Maybe adding a quick filter for oneshot vs recurring schedules on that Schedules view would be a good idea?

I second this. I'd also like to see the one-off schedules self-delete upon entry into the register.

@Crosis47 commented on GitHub (Apr 8, 2026): > Maybe adding a quick filter for oneshot vs recurring schedules on that Schedules view would be a good idea? I second this. I'd also like to see the one-off schedules self-delete upon entry into the register.

Sign in to join this conversation.

Branches Tags

master

claude/hide-default-categories-1cwBZ

matiss/crdt-source-loading

youngcw/unlock-duplicates

matiss/crdt-protobuf

release/26.5.0

claude/update-issue-template-ykMNn

claude/fix-issue-7667-DPXi3

cursor/formula-feedback-improvements-4223

cursor/resolve-pr-7449-ee11

claude/fix-typescript-build-error-JPtZ5

jfdoming/api-tokens-part-3

jfdoming/api-tokens-part-2

jfdoming/api-tokens-part-1

claude/speed-up-vrt-workflow-ZAyI5

claude/crdt-version-auto-publish-Ph1BH

copilot/add-repository-configs-to-packages

worktree-compressed-drifting-ritchie

worktree-mellow-strolling-dawn

matiss/browser-api

claude/api-consumer-verification-kfz1K

feature/enable-banking

cursor/transaction-table-rewrite-f077

pr-7454

claude/fix-issue-7410-LLLQ4

release/v100.0.0

revert-7350-trim-deps

revert-7220-sankey-report

revert-7242-fix/split-parent-update-corruption

revert-7281-generate-icons

claude/electron-to-tauri-migration-LjBN8

worktree-remotion

release/vv26.4.0-pre

claude/browser-compatible-api-QbhHh

claude/improve-cli-transactions-waTUY

claude/publish-react-native-ios-j8qoT

js-proxy

claude/fix-flaky-ci-job-5gDdz

react-query-rules

react-query-useSchedules

claude/nightly-theme-validation-scan-DzOGD

claude/debug-simplefin-error-ZuKzB

matiss/desktop-client-subpath-imports

claude/fix-simplefin-ssrf-T31gX

claude/release-notes-validation-X7rvR

add-claude-github-actions-1772738270730

cursor/sync-performance-notification-9899

react-query-prefs

matiss/chunked-sync-and-progress-ux

v26.2.1

copilot/sub-pr-6880

fix-react-query-clear-on-close-budget

copilot/sub-pr-6140

feat/auto-note

feat/scoped-bank-sync

cursor/desktop-transactions-react-table-1d0c

fix-exhaustive-deps-App

copilot/fix-find-replace-bug

release/v26.2.0-pre

matiss/browser-tests

mobile-fix-drag-and-drop-across-groups

budget-table-v2

PayeeAutocomplete2

pglite

bugfix/plugins/fix-plugins-sw

feat/plugins/plugins-core-package

prerelease

matiss/unicode-minus-fix

cursor/fix-actual-github-issue-6206-gemini-3-pro-preview-9c37

TransactionFormPage

cursor/implement-mortgage-and-loan-account-type-78ca

tests-update-fill-with-pressSequentially

mobile/link-modal

deps/25.11

cursor/fix-update-vrt-apply-ci-job-dispatch-b324

sync-server-plugins

cursor/propose-patch-for-github-issue-5680-2a18

fix/compiler-preserve-inner-dollar-escapes

cursor/analyze-actual-budget-issue-and-propose-fix-5b70

coderabbitai/docstrings/0c070e5

cursor/add-wip-prefix-and-comment-to-prs-d78d

jfdoming/08-21-auto-focus-on-navigate-in-all-browsers

show-totals-on-mobile-budget-banners

allow-child-transactions-make-transfer

mobile-calculator-keyboard

payee-geolocation

enhance/restore_scroll_position

dm-fix-second-click-on-mobile-new-transaction-2

scrollToLocationBudget

alert-autofix-38

tsconfig-composite

mobile-fix-uncategorized-transactions-on-tracking-budgets

server-budget-handlers

fix-sql-injection-in-cleanup-template

non-chrome-draggable-workaround

mobile-budget-page-swipe-navigation

ts-db-all

stable

dark-theme-with-brand-colors

fix-mobile-delete-group

ts-db-select

UnderKoen/reconcile-context-menu

master-before-server-merge

v25.2.1

ts-runQuery

rename-redux-hooks

UnderKoen/3557-persist-state-in-history

remove-redux-CLOSE_BUDGET

fix-exhaustive-deps-errors-FinancesApp

redux-toolkit-createSlice-backup

accounts-function-component

ts-useSplitsExpanded

loot-core-server-package

useTransactios-in-TransactionEdit

react-aria-input

move-redux-to-desktop-client

QueryState-type

fix-themes-applied-late

mobile-vrts

revert-3295-spendingCardFix

react-aria-button-4

split-payee-on-mobile

twk3/pin-apis-crdt

notes-tag-autocomplete

ts-LoadBackup

dnd-kit

package-upgrades

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/actual#26718