Joel  have a look at the inspector it tells you how much money is left after the pending transaction. When you go below 0 after a pending transaction the budget item becomes orange. Eg 50 outflow and only 40 in the category and you have an orange budget item. Which you can ignore and then becomes red on the date of the transaction

Faness at YNAB 

I have to admit that it blows my mind that “check the inspector” and “if you over extend it will turn yellow” is the answer YNAB somehow finds acceptable here.   The whole point is that it should be an OPTION to make it a future dated transaction that impacts your category and account balances NOW.   I don’t want to overspend in the first place, turning it yellow after the fact does not help prevent the overspending.  I want a quick glance at what is available, not to have to dig into it to figure it out.  

Faness at YNAB

Just starting a trial with YNAB.  I understand that the Official Party Line is that future dated transactions should not be recognized.  I would prefer to recognize future dated outflows as I schedule them, but not recognize future dated inflows until they happen.  YNAB 4's distinction between scheduled transactions and future dated transactions allowed me to take this conservative approach.  So, the first thing I notice is that future dated transactions show up in the register in gray, and that the toolkit supplies the running balance.  So far, so good; though I do wish the category were affected on the budget page.

So here's my problem:  I have a scheduled inflow for December 1, and a future dated outflow for December 6.  The running balance does not reflect what I want to see between now and November 30.  Okay, the outflow needs to come out of the December budget.  Move to December, and it shows nothing spent in that category.  It faithfully shows the negative amount I budgeted to bring the category balance to zero; but that happened in YNAB 4.  I don't know how I would see that in web YNAB in order to properly work my December budget.  (If you care, the category is Utilities:Water, it gets paid every 3 months, and when I pay it I true the category up to zero before accruing my monthly estimate the next month.)

While it appears that I will be able to achieve what I did in YNAB 4, for the most part, it is disappointing to see how much extra work is involved.

I have also failed to find how to look at the scheduled transaction to *see* what frequency is scheduled.  I see how to enter it on a new transaction; but how do I look at an existing transaction to examine and possibly edit the frequency that it will occur?

Faness I can't figure out how to remove a flag, as you have suggested. Can you explain how? Thanks.

JoeDid Thank you for tagging me - I somehow missed the comments here! To remove a flag in the web app, click on the color of the current flag. If you click Red once, it will add a red flag, if you click Red again, it will remove the flag.

nkull Sorry I missed your comment! We want you to plan ahead for those transactions, but "spending" those funds before they're spent teeters on the line of forecasting - which we don't want. YNAB is meant to focus on the present, but scheduling those transactions allows you to keep them in mind. I'm not saying you should depend on the category going yellow so that you know you've overspent, you should plan for those transactions and the category will turn yellow as a safety net if you haven't budgeted enough.

Patzer I know it's been a while, but would you mind sharing what you've been doing to work around this situation? I read back through the thread and we have the 'Enter Now' option, but I understand this is a preference to see those transactions affect the budget without affecting the account, correct?

Faness 

Faness said:
Patzer I know it's been a while, but would you mind sharing what you've been doing to work around this situation? I read back through the thread and we have the 'Enter Now' option, but I understand this is a preference to see those transactions affect the budget without affecting the account, correct?

Incorrect.  The transactions should affect both the account and the budget.  "Enter Now" is incorrect, because it changes the date to today.  That is wrong.  The date should be the future date the transaction will occur, and the funds should be gone from the account as of that date (and as of the ending balance of the account).  The funds should be spent from the budget in the month of the actual transaction date, whether that is this month or next month.

This remains my biggest frustration with web-based YNAB, because I have not found a good workaround.  I can work around the lack of Income for Next Month.  I can manually create walled months.  I can avoid all the insane things web-based YNAB does with credit cards by simply telling it my credit cards are really checking accounts.  But I have no good workaround for future dated committed transactions.

To recap, I am a fiscal conservative.  If it's May 24 and I receive a water bill due on June 15, I will schedule a payment to be made three business days prior to June 15 (most often June 10, because most often "3 business days" crosses a weekend.)  That transaction will happen for the scheduled amount on the scheduled date unless I affirmatively intervene to change it.  The money should show as gone from my account, and spent from my June budget.

Using the Toolkit, I get a running balance.  (This is something else that really ought to be part of the base YNAB offering.)  The Toolkit running balance shows the balance after the next instance of each scheduled transaction.  As long as I have no true scheduled transaction (example:  my pension payment) happening before my future committed transaction (example: my water bill payment), I see what I need to see.  If in the real world, I have a scheduled pension payment on June 1,  which is 9 days before the committed water bill payment on June 10, and I am not seeing the conservative "what it looks like when all the committed spending catches up" balance in my account.  The only workarounds I have for the account are, look at it in YNAB 4 (which will only work until Microsoft breaks YNAB 4 or I stop keeping my budget in parallel on both platforms); or look at my parallel records in Quicken (which is not a solution for most YNAB users.)

One category at a time, I can look at the inspector and see the category balance when things catch up.  That is sub-optimal, but I grudgingly admit I can work with it.  I just have to look at account or category detail to see if I remembered to schedule the gas & electric bill payment, instead of just looking at the category outflow on the budget page.  I need to look in the specific account registers to see whether I have scheduled my credit card payments, instead of simply looking at the balances in the sidebar.  This is clumsier, but possible.

For now, I am distinguishing future committed outflows with a purple flag (everything is done, in my workflow) while true scheduled transactions have a red flag (further user action is required, in my work flow.)  So at least I get the minor benefit that when the money I've *already spent* shows up as a transaction asking to be approved (when it ought to require no further action from me), I can just see that the flag is purple and approve it.

I am particularly offended by the lack of future committed transactions because I'm pretty sure that extra programming work was required to forbid them.  Every other financial package I've seen, including every prior version of YNAB, every version of Quicken since Quicken 2.0 for DOS, and Microsoft Money before that was retired, had future dated transactions.  I conclude that programming resources were expended to create the value-subtracted feature of forbidding future committed transactions in web-based YNAB. 

TL/DR; I don't have a good workaround, and that remains a sore spot.  I have come to the conclusion that this is the way things are, and clumsily looking in many different places with significantly more manual effort than YNAB 4 required is the best I will get.

Patzer Sorry about that but thank you for taking the time to explain! I read the whole thing to make sure I understood the purpose of what exactly it is you're looking for with that feature. In YNAB, we want to prepare for the future without pretending we're already there - that's why we schedule future transactions, but they don't affect your accounts or Available amounts until the day they take place. I understand wanting those funds to appear as already spent, because they're earmarked for something else, but the reality is that they're still there. It's possible for you to spend those funds on other expenses, so showing that they've already been spent would cause your budget to be incorrect - something we want to avoid. Your Available balances and account balances would be wrong - showing what you should spend instead of what's actually available to spend. It would also cause issues with Moving Money between your categories and cast doubt on priorities (if you schedule a $20 transaction in Fun Money, but something comes up and you need funds for Groceries, that $20 would no longer show as Available even if you want to buy groceries now and worry about leisure activities later). When those emergency situations pop up, we want your budget to be there to tell you what you Can do - take money from the categories where you have it, and YNAB will prompt you to put it back before those bills come due.

I understand the extra clicks to check the inspector isn't as convenient, but putting that amount in the Available column isn't the truth we want your budget to portray. If I'm still missing something, or if you've thought of another workaround, I'm more than happy to listen or you can submit a Feature Request for it! :)

Faness Uh...you don't need to explain the YNAB method to Patzer. Patzer all but explained the YNAB method to Jesse. 

"Letting money sit?" Patzer.

"Whack a mole?" Patzer.

The equation which matches account balances to categories? Patzer. 

Most of us who really *get* this method, and can debate it at a theoretical level, have the level of understanding we have of it because at some point in time, someone passed on something to us that started with Patzer. If future dated transactions aren't something the team wants to do, that's fine. But it's not that he doesn't understand what you're trying to do. 

I, too, get what the new software is trying to do by barring future dated transactions. I happen to think it's probably better in the long run for more users. But it's not the case that people who agree with the choice to do this understand YNAB and the people who disagree somehow don't. It's a disagreement on whether the execution actually matches the goal of allowing users to rely solely on their categories, not a misunderstanding of the need to rely on categories. 

And for the record, while I think barring a commit of a transaction in the register makes sense for most new users who don't understand that YNAB is not an accrual budget, or who are trying to match a program like Every Dollar or Mint, having no insight whatsoever on the budget screen that a given category has scheduled transactions strikes me as a pretty grave oversight. It means that users have to memorize which categories might have scheduled transactions in order to even know to check the inspector, and it makes it exponentially more difficult for a couple to use the budget effectively that way. 

WordTenor I, in no way, meant to discredit Patzer. I initially asked for further explanation because I know Patzer has been using the new YNAB and wanted an opinion on making this scenario work further in the program. It's also why I asked if I was missing anything or if he had already thought of another work around.

Thank you for jumping in here and sorry if my explanation came off in such a way. I follow Patzer's activity on the forum and truly wanted his opinion for another option here. :)

Faness To be fair, Patzer doesn't need me to white knight him (sorry Patzer), and I totally am doing that out of respect for all I've learned from him directly and indirectly over the last five years. But I hope my point is clear that this disagreement about execution is not about misunderstanding the nature of reliance on categories. It's about two different definitions of what relying on categories looks like, and while the official stance is an excellent case for one side, there is an equally excellent case to be made that it runs a very real risk of causing someone ultimately to overspend a category they didn't intend to overspend. How big that risk is, well I think it varies, as my comments below show. But I think we can all agree that people using their categories correctly and overspending anyway because the budget's information is not clear is not the goal for anyone.

Faness really, no need to apologize here at all. I always appreciate your clear and concise explanations and how quickly you jump in. I often have no idea what people are trying to say here, but your explanations are always on point and a welcome relief.  

Faness I disagree with the YNAB philosophy on this point, but I understand why it is the way it is.  I just have to be a good enough budgeter to deal with it, in spite of the fact that it is the way it is.

I happen to believe that the YNAB organization is in denial on this point, and should focus on teaching people to be conservative instead of implementing features that prevent them from being conservative in the hope of preventing clueless people from hurting themselves.  I believe a better focus would be on educating clueless people so that they cease being clueless.

WordTenor Agreed. The yellow available amount is meant to prevent that overspending, but, if I'm understanding correctly, that seems to be too late of a warning - correct? I'm not saying either definition is incorrect, but since YNAB is meant to handle one of those definitions, I'm having a hard time finding a workaround for the other that isn't compromising.

budgetlover Thank you for your kind words! I'm always happy to help but worry it doesn't come across that way. If you ever need anything, please don't hesitate to tag me! :)

Patzer It's definitely okay to disagree. While we know the YNAB method is effective (and I know you know), we don't expect every aspect to work 100% for everyone. However, we Want it to work - that's why I often pry for more feedback, to see if there's a possibility for a workaround that wouldn't compromise the method. We don't want those categories to be underfunded, and that's why they turn yellow if there isn't enough for the upcoming transactions, but I understand that isn't a conservative frame of mind. 

Faness The thing many of us find baffling as long time users of the software is that suddenly there seems to be an almost aversion to putting the information someone needs to make a good decision on the budget screen. This is true with both this problem and with Stealing From the Future. 

Case in point—I pumped 23 cents more gas than I intended yesterday. My entertainment subscriptions category has $16.37. But I can’t actually move that money or that category will be overspent as soon as Audible charges me. There is nothing on the budget screen itself that gives me this information. I just have to have it memorized. I’m quite good with money and have a good memory so it’s not a huge issue, but it does mean that the budget screen doesn’t give me all the info I need to make a good decision about what to do. I actually can’t rely on that category, because if I do, it will become overspent later. It is baffling to me why it seems that there is a preference to have this obscured. That seems entirely counter to the method, not part of it. 

WordTenor First off, I'm happy to report we're taking a closer look at Stealing From The Future. We've discussed that thread and all of the feedback a number of time (support and the development team alike). I can't make any promises time wise, but we're looking into the best way to make that a clearer point in the future. :)

As for the scenario you painted, as soon as you move that 23 cents, the category will turn yellow. That's YNAB's way of telling you those funds need to be put back as soon as possible, or the overspent category needs to be covered with a different category. If you know you have more income coming before Audible is scheduled to charge you, leaving the category yellow and covering the gas transaction isn't a bad idea. However, if you don't have more income, you should put the 23 cents back and choose another category.

I don't mean to explain how the program works (I know you know that part), but the yellow category amount before the amount is budgeted (and after, if the amount is moved) is meant to be that 'in the budget logic' to make that decision.

Faness I glad the team is taking a closer look at SFTF but the problem is actually very straightforward. There needs to be a notification on the current month's budget screen that a future month is overbudget. The toolkit already figured out how to do this. 

Again to my point below; one shouldn't be using YNAB reactively very long. The move to proactive budgeting should happen quite quickly, and the software needs to support that.  

Faness I know there's an official "feature requests" place, and I guess I'll put this in there as soon as I get done typing it here and reading the rest of the thread, but would it be possible to just add a column to the budget screen of "available after upcoming"?  The software is already parsing that data for the inspector.  Could we put in in a place where we don't have to click each category to see it?

TheTabby Thank you for adding in here! The Feature request form goes directly to our development team, to share your ideas and suggestions with them, so they can give them further consideration. By all means, please submit that idea! :)

TheTabby I like the idea of having another column to show amount available after upcoming.  

Faness 

Faness said:
I don't mean to explain how the program works (I know you know that part), but the yellow category amount before the amount is budgeted (and after, if the amount is moved) is meant to be that 'in the budget logic' to make that decision.

 The "after" part is where the logic falls apart. There are use cases where you need to have the information before you make a budget or spending decision, not after. Particularly a spending decision, which are a bit less easy to reverse.

WordTenor Sorry if I’m necroposting.

I’m unbelievably new here (2 days) but while planning my first months budget I had to consider this problem.

I decided to create one or two Category Groups for Categories that contain any of those recurring subscription costs. For these—YNAB, phone bill, auto payment, etcetera—I always know they have subscriptions by virtue of being within that Category Group. If the typical renewal date is helpful info you can put it in the item title 

Using YNAB terms, these are Immediate Obligations, and you should always look elsewhere before moving funds from those Categories. You can create separate “True Expenses”-type Category/Group items for non-monthly subscriptions.

I decided on  a gradient of several Category Groups organized top-to-bottom, priority: Immediate Obligation>True Expenses>Long Term Goals. Any Category/Group items aligning most with Long Term Goals are at the bottom and pilfered from first. Only move up as the circumstances require it.

I’m just starting, but I believe this will keep everything organized so I don’t misallocate funds I *know* I’m going to spend.

WordTenor 

While still not perfect,  it is close, and it would be a HUGE improvement.  

kevman479 I would offer that for most users, the odds are quite slim that so many categories have mixed scheduled and discretionary spending that the need to see the updated category balance is in fact a major hardship. I used YNAB 4 happily for years without ever inputting a scheduled transaction early, and that was before even having this extra info about what the category balance will be. 

Having gotten a little frustrated with the discussions on the old forum, I've spent most of the last year heavily involved in other YNAB communities which are mostly populated with new users. Very few new users care about this at all, which makes me think it's not really a "Wow, you are *so* likely to mess up your budget!" kind of thing and more of a "I had this workflow going and now it's broken" kind of thing.  As opposed to credit cards or even stealing from the future, both of which new users occasionally have issues with, which indicates more of an actual problem with the way the software works. The only people I've seen upset about future transactions not affecting the budget are YNAB 4 users. Well, them, and the occasional newbie who is just upset that YNAB doesn't work the way they expect a budget to work with inputting expected income--they usually either cotton on or decide YNAB isn't for them. 

I think they could make a small change to make the existing functionality even better. But I think the population who actually need this info, and who need it so often that they can't manage to remember to check the inspector, is a very small population. 

LarryinLA Thanks for adding in here!

I know a number of users have referred to YNAB as an envelope system and it works the same way here - the funds aren't removed from the envelope until they're spent. This isn't for those stop check situations, but those planning ahead and dealing with emergencies scenarios.

For instance, let's say you plan to pay your water bill June 15th. Something happens and you don't get your paycheck on June 1st, or there's an emergency and you have to spend an unexpected amount - you now have the money budgeted for the water bill but no money for food. 

In this case, you can take the money from your water bill category. When you do, the Available amount will turn yellow because you need to put those funds back before the 15th - you know those funds need to be put back, this is just YNAB's way of reminding you. 

I understand the commitment is made when the decision is made, but we don't believe your budget should show incorrectly to reinforce that. Things change, priorities shift, and while that may sound flippant in reference to bills, it's still true. If there's an emergency, those funds are still there to use (note: I personally handle checks like cash and enter them as spent the day I hand them over).

Faness 

we don't believe your budget should show incorrectly

I think it's incorrect for my budget to show money that I've already committed to spend as "available".  It's not helpful and undermines YNAB's value as a planning tool.

If I wanted an app that merely showed the reality of my current account balances, I'd use Mint.com . The value of YNAB is that it helps you see your money in ways that may not match reality, but help you make smarter decisions:

• My money isn't actually sorted into 30 envelopes, but imagining that it is helps me realize how much I can afford to spend on various things.
• I could immediately spend the money I earn today, but imagining that it's not available until next month helps age my money and improve my financial situation.  (This was much easier to do in YNAB4, btw.)
• The purchases I've made on my credit card haven't actually been paid for yet, but choosing not to pay my credit card is a really poor financial choice (I don't like 25% interest rates.)  So I imagine that the money is gone the moment I make a purchase.  (Again, handled better in YNAB4).

In short, I disagree with a lot of what YNAB considers 'correct' in the new version.

Hi bret !

YNAB is a realistic portrayal of your accounts, outside of what you imagine to be different - just like you mentioned above.

bret said:
The purchases I've made on my credit card haven't actually been paid for yet, but choosing not to pay my credit card is a really poor financial choice (I don't like 25% interest rates.)  So I imagine that the money is gone the moment I make a purchase.

Your other categories, should be treated the same as your credit card categories. Those funds have been put aside for your credit card payment, just like your Water Bill funds are put aside for the water bill. You know those funds have a job and you shouldn't move them unless you absolutely have to (temporarily).

If you have a Utilities category, and you're afraid there won't be enough to cover all bills, you can try separating that category into individual categories (maybe Gas, Water, Electric?) so that you always know what's available for those specific upcoming expenses.

Faness I belong to the "future-dated transactions are a must" school of thought, which is one very big reason I am forced to run YNAB4 along with nYNAB. When I commit to a future payment, I *want* my budget to show that, same as when I write and mail a check. Being able to see my Cleared balance, the amount of uncleared but expected transactions, and my cleared balance is the *truest* information I can hope for.

I have an automatic transfer from checking to savings scheduled for tomorrow. It happens every month. Right now my nYNAB account is showing incorrect information because I won't allow me to post that on tomorrow's date. I have to resort to the same kinds of tedious workarounds that Patzer mentioned: Flagging a transaction as having posted on the wrong date, and remembering to correct the actual transaction when when that date passes. It's annoying and time-consuming. YNAB4 allows that transfer to show as of tomorrow's date.

I sincerely don't understand your insistence that having future-dated transactions reflected in my register is a bad thing. It is not. It's what I would do with a check. I should be able to do so with an e-payment. Makes no sense to me.

Hi JoeDid !

When considering future dated transactions, I hadn't thought about transfers at all. Is it just the account balance that's off (until the transfer goes through tomorrow to bring things up to date), or is there an issue with your category balances as well (if that account is off-budget)?

If those funds are moved in YNAB, before the transfer goes through tomorrow, the account balance would be incorrect- right? If I'm understanding things correctly, this seems to be more of an issue with funds that are more immediate (transfer for tomorrow vs. scheduled payment for next week). In those cases, since you know the funds are needed now, and YNAB will warn you if those funds are moved, is it just the possible step of moving those funds and then having to move them back because you receive the yellow Available amount Afterwards?

 JoeDid bret LarryinLA Patzer WordTenor

I asked below, but wanted to ask each of you as well - would an alert be helpful here? For instance, the Available amount shows what's available (as it does now), but if you try to move money or change the Budgeted amount, a pop up that says 'Don't do that' or 'These funds are already earmarked' - would that help your current workflows?

Faness 

Faness said:
I asked below, but wanted to ask each of you as well - would an alert be helpful here? For instance, the Available amount shows what's available (as it does now), but if you try to move money or change the Budgeted amount, a pop up that says 'Don't do that' or 'These funds are already earmarked' - would that help your current workflows?

No.  My current YNAB 4 workflow relies on easily seen information so I never get to the point of *trying* to move money that isn't really there.  My current web-YNAB workflow relies on clumsily looking in lots of different places for the same information, so I never get to the point of trying to move money that isn't there.

The hypothetical popup would be a reactive thing, warning me when YNAB thinks I've done something inappropriate.   It would only be triggered if my current workflow broke.   And to be  honest, my first reaction to any warning YNAB might pop up about inappropriate action would be to think the program has some stupid bias requiring something unnecessary or forbidding something normal.  The program's record with income for next month, walled months, stealing from the future, and credit card payment categories diverging from credit card balances for paid in full credit cards does not encourage me to trust the program to tell me what to do or not to do.  (No, you don't need to fix any of those things.  I have functional workarounds for them.  I will not be routinely pestering you with commentary on the lack of intelligence in how any of that stuff is handled.)

In a world where I might pay attention to such a warning, it's still a reactive thing.  It doesn't help me size my water budget next month without looking at the inspector.  It doesn't help me see on the budget screen whether I've remembered to schedule to schedule the gas & electric bill payment.  It doesn't help me see at a glance on the sidebar whether I've scheduled a credit card payment.  It would be just one more detail of a clumsy workaround requiring manual intervention if I happen to trigger it.  I already have enough clumsy workarounds and manual interventions to function, and I wouldn't have posted here again this week if you hadn't tagged me.

But since you asked, I'll reiterate:  I have no good workaround.  That remains a sore spot.  I continue to be offended that programming resources were expended to create the value-subtracted feature of forbidding future committed transactions.  I understand that this is the way it is, and that future committed transactions will not be coming back.  I understand that Customer Support personnel are not allowed to explicitly say that what I want won't happen.  That's okay, I got the message.  Future committed transactions aren't coming back.  I simply need to clumsily look in a lot of different places to get the same information that would be easily seen if future committed transactions existed, and in fact was easily seen in YNAB 4.  That's progress.

 Faness That might have been a bad example because that category does contain only scheduled spending. The only reason the category would turn yellow is because it contains only the scheduled transaction. What about my "shopping" category, which has a $4 NYT subscription? I have $30 in there. But technically, I can only move $26.  If I move $27, yes it turns yellow. But maybe,  if I knew,  I would chose not to touch that category at all. Maybe I am thinking, "Okay, great, I can move $20 and I'll still have $10 left" but in reality there's only $6 in that category that isn't commmitted. There's no information about that on the budget screen. 

The point is, you don't know how much you can move until you do it. There isn't any information on the budget screen that tells you that you even need to check the inspector. So basically, the current implementation makes it impossible to actually use your category balance to make decisions if there are scheduled transactions in that category. As Patzer points out, everything you are explaining is how to use the budget reactively. But a good budgeter isn't reactive, she's proactive. We're asking for YNAB the company to stop hamstringing processes that are proactive. I moved beyond reactive budgeting within two weeks of starting to use YNAB. That should be the goal. Yes, YNAB should work if you're broke. But if you use YNAB, you shouldn't stay broke very long. 

Faness 

Faness said:
I asked below, but wanted to ask each of you as well - would an alert be helpful here?

 The simplicity of YNAB is captured in the idea that spending decisions are made by checking category balances, not account balances.  Period.  So, no, a warning would not work nearly as well as the category balances reflecting the reality that the money has been spent, and I do not want to be tempted to spend it again.  The category balance does that work in YNAB.  That's what needs to be a 100% accurate reflection of the jobs my money has been assigned and the jobs my money has already left to go do.

Patzer I don't mean to irritate sore spots, but was hoping for insight to hopefully find a middle ground here. It's not that I can't say something won't happen, it's that I don't want to bite my own tongue. We're always looking for ways to improve and the online program makes that possible, so I don't want to say anything is impossible. I will say it's highly unlikely the formula for the Available amounts will be changed, so I was hoping to find another area that would help improve these scenarios. TheTabby mentioned an 'After Upcoming' column so that the information is in the budget instead of in the inspector. Suggestions aren't a requirement of any nature, I just like being able to tell our development team 'Here's the issue, here's why and here's a possible solution'. I appreciate you taking the time to share your opinions on this topic, even though it's a sore one. :)

WordTenor I understand why you'd find this information helpful - even though it's in the inspector, that isn't available at a quick glance. We want the Available amounts to represent current day balances - in case of changes, last minute occurrences, shift in priorities, etc. This isn't meant to be reactive - having those scheduled transactions and being prompted to budget for them ahead of time is proactive - but I understand the issue comes in after those categories are fully funded. If you have any suggestions or ideas, or even a second to the suggestion TheTabby made, I hope you'll submit them for further consideration! 

Faness The crux of it for me is that between now and June 23, one month away, I have a dozen scheduled ,committed, automatic transactions that are for essentials: payouts that will *not* be changed or deleted. During that same four weeks I will incur other charges, other payments needing to be made, for variable expenses over which I have control. I want to see the committed transactions as just that: committed and out of my budget, so that when it comes to deciding, say, whether to go to the fancy French place to celebrate something or to order takeout burgers, I know where I stand with those committed transactions: they are like checks I've written and mailed: they will be paid. If  still used a checkbook register, the amounts would be deducted when the check is written, no matter when it's actually paid.

The current workaround for me: entering them now on today's date, having to flag them purple so I know I have to adjust them to the real date when that passes (which I have to note in the memo field in ALL CAPS so it's visible) is absurdly inconvenient, considering the old way in YNAB4. I could and can still do this in YNAB4, which tells me it's better suited to my needs than nYNAB.

ETA: I just saw your comment about 'shift in priorities' and I need to emphasize that the transactions I need in my register are *NOT* those that will be 'shifted.' They *need* to be paid. It's payments that arise after those committed payments where I can shift priorities, based on what my budget tells me I am committed to spending.

Faness I made my suggestion four months ago. Actually, I made it about two and a half years ago. Either allow the available after upcoming to be toggled as the default, or at a minimum, provide some sort of notification (a color, italics, god knows) that there is information in the inspector that needs to be consulted. 

Do you understand that good budgeters move money *before* they spend in  another category? It seems like the only scenario in which you are able to imagine anyone ever moving money is after they've overspent. That's what we mean when we say reactive vs proactive.  Most of us now make a decision before we spend, not after.  And the information we need to make that decision isn't in the budget. 

WordTenor Thank you for those suggestions! I believe what's throwing me off on the second portion, is the reactive part. If you move money before overspending, and the category doesn't have enough to cover the upcoming transactions, then it turns yellow - prompting you to put those funds back. While this causes a few extra clicks, you're still able to fix things before spending, which I'd consider proactive. I consider moving things after (over)spending to be reactive. 

For instance, your shopping category. If you spend that $10 and then realize you're now short for your subscription, I'd consider that reactive (because you have to cover things after spending those funds). However, if you moved funds before spending, realized you shouldn't spend that $10, so put it back, I'd consider that proactive (because you didn't spend those funds, so there's nothing to cover). 

If I'm mincing the words here, please let me know!

Faness You're mincing words.  Available balances changing colors is reactive.  Proactive budgeters manage things so the Available balance never turns orange or yellow or red or whatever color the warning is.  I never see that in my budget, because the important rules are:

1.  Give Every Dollar a  Job

2.  Only  budget dollars you already have

3.  Only spend dollars you have already budgeted

It can be hard to do all of these when you're broke; but I've been using YNAB for a decade and I'm not broke.  The whole discourse of color changes warning me to budget something is foreign to how I budget.  Having a color change or a popup telling me to budget something when I enter a spending transaction would feel like having an alarm go off when I try to open a door, with no sign above the door saying "Emergency Exit Only."

I want to know that the door is for emergency exit only, and not try to open it in the first place unless the building is on fire.  And if my budget is on fire, I already know I'm going to need to look at lots of details and move money around in unusual ways.

Faness What I need to know is “Can I move $20 from this category because I want to buy a $20 gizmo.”  So I start searching my categories for a category from which I can remove $20 and which is a lower priority than the $20 gizmo. 

 I look at my shopping category, I see that there’s $30 in there.  I think ahead, I go “hmm it’s the last week of May.  $10 ought to be enough in there to see me through to the end of the month.”  So I move the 20 bucks and I buy the gizmo.  The budget is perfectly happy, because it still has plenty of money in that category to pay for the four dollar charge that’s coming up.  So it doesn’t give me any sort of warning about that lurking transaction. 

 But then Friday rolls around, the New York Times charges my card, and suddenly I only have six dollars left in my shopping category.  That wasn’t what I wanted at all, and had I known that I was only going to have six dollars in that category, not only would I not have moved the $20, I might’ve decided not to buy the gizmo at all. 

Suddenly, I’m pushed into situation in which I have to react to a bad decision that the budget helped me make.  That is not how anybody should be using YNAB. 

Herman I hadn't thought of this at all! Do you date your computer for the future so that all transactions are already taken into account? I rely on my computer settings for that information, so the idea of changing it makes me nervous. Have you found this to be the best workaround for entering your transactions?

Faness I'm hesitant to tell you, lol.   I change the date of the computer forward to cover the transactions I want to enter.  Enter the transactions,  update the amounts and change the date back.  The future dated transactions remain in the register and impact account and category balances.  If you need to edit them  before the date arrives you have to change the date again.  But works well.  And only takes about 5 minutes a month. 

Herman I am anti-judgment when it comes to budgeting, so your method is safe with me. :)

While I'm happy you've found a workaround, I'd love for there to be an easier option. I'll ask those who posted above as well, but would it help if there was an alert when dealing with categories that had upcoming transactions? For instance, the Available amount shows what's available, but if you try to move money or change the Budgeted amount, an alert to say 'Don't do that' or 'These funds are already earmarked' - would that change your current workflow?

Faness this functionality isn't as important to me as some others.  Your suggestion would be an improvement. I believe the suggestion I've heard that I like best if the option to enter them is off the table is the toggle to have the category balance reflect scheduled transactions.  I believe WordTenor suggested it.  

Herman Thank you for letting me know! We try to stay away from toggle functionality if we can, but I'll keep this in mind. You can also submit that in a Feature Request to let our development team know what you'd like to see going forward (that goes for any feature you'd like to see, not just a change to the Available amounts). :)

Faness thinking about this more the problem with an alert is you make s spending decision based on the category balance and enter the transaction after the fact.  The alert will occur too late.

Herman Hm.. Would a constant reminder on the category be better? 

 Faness I'd probably defer to some of those above that this is more critical for. I consider it a "nice to have". 

Joel  maybe you have way more transactions than I do but you can very quickly push those you don't want in the register back to scheduled by editing them after the date change back.  I'm well aware most don't like my work around but it is the only one that accomplishes what you are asking for.

Herman thinking about it a little more, the easiest improvement ynab could implement would be to expand the date range for matching imported transactions. In that case you could enter now when the funds are committed.  This doesn't help the people that want to use this for cash flow management but certainly reflects reality, stays in line with ynab philosophy and provides the necessary information to those using this for spending decisions.  

bret 

bret said:
I don't want to hijack this conversation about future-dated transactions and rat hole on credit card mechanics. But I do think the issues share an important similarity: In both cases, YNAB is inviting me to continue budgeting money that I consider already spent.

 This is exactly correct, there is a unified world view that YNAB has moved to where, as long as the money is still in your account, it is 100% available to be used however you want.  It's a huge turnaround from the revelation YNAB3 gave me when I learned about the buffer and getting off the credit card float and that having cash available didn't mean it wasn't already committed and should be treated as gone.

LarryinLA 

I suspect the reason YNAB has adopted this new view is because it's easier for new users to understand.

Considering your money to be unavailable -- because it's associated with a future-dated transaction, or a credit card purchase, or because you marked it as "income for next month" -- is an unfamiliar concept to someone who has only ever looked at their account balances to inform their spending decisions. It's probably a barrier-to-entry for many new users.

From that standpoint, these changes are completely understandable and defensible. Anything that makes the app more accessible to more people not only helps YNAB's bottom-line, but it also (probably) helps more people overall.  (Someone who is operating any budget, even just a spreadsheet, is probably going to be better-off than someone who doesn't.)

bret 

bret said:
Considering your money to be unavailable -- because it's associated with a future-dated transaction, or a credit card purchase, or because you marked it as "income for next month" -- is an unfamiliar concept to someone who has only ever looked at their account balances to inform their spending decisions. It's probably a barrier-to-entry for many new users.

 There's a fine line between accessibility and absurdity.  I'll grant that it's a tough adjustment for someone who thinks of a credit limit as money available to spend to go to thinking of *using* the credit card as being spending money.  But that doesn't mean it's not worth trying to educate that person.  I find it sad that YNAB now considers using a credit card to be "not spending" and paying the credit card to be both "spending" and optional.

I've seen several people on the old forum over the years make progress after the light bulb went off and they realized that using the credit card was the actual point of decision and act of spending. 

I can grant the point about income for next month; INM is really subtle and not totally necessary for true zero based budgeting. 

bret said:

Anything that makes the app more accessible to more people not only helps YNAB's bottom-line, but it also (probably) helps more people overall. (Someone who is operating any budget, even just a spreadsheet, is probably going to be better-off than someone who doesn't.)

 I would argue that a methodology that says, my gas & electric payment hasn't fired off yet so I'm free to use that money to whack-a-mole a night of beer and hookers is effectively not a budget.  I'm not so fried by the lack of functionality, which I can now work around thanks to the Toolkit; I'm fried by the attitude that it's okay to take funds that are committed to pay a legal obligation two weeks from now and use them for some other purpose.  The defense of the prohibition of future dated transactions is much scarier than the actual prohibition.

I could even understand the prohibition if the official reason was, "We've seen people hurt themselves doing this, so we disabled it."  Which is still like saying I need to use a butter knife on my steak because someone else cut himself with a steak knife, but at least I could understand the logic.

LarryinLA  Patzer

Pssst: I completely agree with both of you. I was just playing devils advocate and trying my best to defend (or at least) understand the new YNAB design.  

However, when I was describing money being unavailable, I meant something more than just "it's budgeted in another category."  I meant that money isn't in any other category -- it's been subtracted from my budget entirely.  I.e. I have less overall money to budget with.

That kind of unavailability is probably difficult for a new user to grok. "If the money is still in my (asset) accounts, why isn't it anywhere in my budget?"  That confusion has been eliminated in the new YNAB, because you simply can't do that anymore.  (Which is what this conversation is all about.)

It then becomes an argument about whether the trade-off is worth it: Alleviating confusion for some users vs eliminating functionality that many felt was beneficial.  I think there's a legitimate argument that YNAB could make there, but I haven't seen them make it very convincingly.

bret 

bret said:
"If the money is still in my (asset) accounts, why isn't it anywhere in my budget?" That confusion has been eliminated in the new YNAB, because you simply can't do that anymore.

 After thinking about it from many different directions, I conclude that the theory isn't all that unreasonable, but the implementation is flawed.  Get rid of Income for Next Month being hidden, and you eliminate one part of the "where's the money" puzzle.  Make credit cards effectively not part of the budget, and budget for the payment, and you eliminate the other part.   I even worked out that, in theory, what nYNAB does with credit card purchases matches what I would have told someone using YNAB 3 to do manually if they had to use a card that was carrying a balance.  (To be fair, that's about 6 steps down the sound track.  Top of the sound track is, don't use a card that's carrying a balance.)

The major implementation flaws, as I see them, are:

1.  Lack of walled months.  Get rid of the invisible Income for Next Month, sure.  Promote understanding of where the money is.  Let money flow between months with no explicit user control, bad idea.  Better idea:  Instead of directly budgeting in future months, *budget* toward TBB-Future that is automatically released as TBB next month, but can't be stolen by subsequent action in this month's budget other than deliberately reducing the amount budgeted to TBB-Future.  Release unused current month TBB into the next month when the first of the month arrives.  Don't release TBB not explicitly budgeted to TBB-Future into next month before it gets here because, after all, *IT HASN'T HAPPENED YET AND IT ISN'T REAL UNTIL THIS MONTH IS OVER.*  (Note the incredible philosophical disconnect between encouraging users to budget future months and prohibiting future dated outflows.)  Better metaphor, possibly more programming work; but nYNAB did a lot of tough programming work for questionable benefit.

2.  The collection of unexpected consequences of credit card transactions.  Overspending a category should just be overspending a category, regardless of whether a credit card or a checking account is used.  If you don't want the user to input TBB in a credit card, let the user record a direct inflow to the card categorized as the card payment category (e.g., for the cash back reward as a statement credit) that then automatically increases TBB.  Not everything is a return.  Starting balance should be automatically budgeted to the card payment category; make the user deliberately move it to recognize how much float is being used.  If my card is paid in full, the program should not let the card payment category diverge from the card balance unless I affirmatively move money out of the payment category to other categories.  *Ask* the user whether a transfer from the credit card to another account is new debt, or something to be paid with the next CC bill.  (*cough* gift card purchase *cough*)  If the user doesn't say it's new debt, put it all in the card payment category automatically.  Force the user to explicitly assume new debt, if that is what the user intends to do.

Basically nYNAB does too many things behind the scenes that aren't what a reasonable person would expect, without asking the user what is intended.  Yes, experienced users can learn all of the cases that typically apply to their budgets and compensate for them; but we shouldn't be slapping new users with those WTF results, no rational explanation why they happen, and no option to change the effect at the time of transaction entry.

Patzer The credit card functioning was rebuilt hastily right before release. It was tested for...8 days? Maybe? before soft launch happened. I remember doing a long reconcile of my budget while in Canada which means it was late October.  I’m sure if it had sat longer, many of these weird edge cases would’ve been seen and perhaps the code would’ve been rewritten. But now, it’s too little too late and the team is forced to pretend the gift card and returns behavior is purposeful. I suspect it isn’t but that fixing it would require acknowledging that. 

WordTenor 

Okay, the gift cards may be a bug because that situation wasn't considered when the programming was done.  I get that the inability to have one transaction in a credit card account go to TBB is an oversight, from not considering a cash back reward or a payment on the card from an off-budget account.  I don't get why the organization can't admit those things are bugs and fix them.  Or at least say they're in a queue to be fixed, even if they're really going to sit forever with no action.

But the creation of debt when a category is overspent has to be deliberate.  And that's beyond dumb, it facilitates poor financial results.  I totally get why the organization can't admit that one is a bad thing, because there's no way it would have happened without being a deliberately designed feature.

Okay, I get why they can't admit any of them are bugs, now.  They could have admitted some of them were bugs if they had done so soon after the bugs were discovered; but once they say the bugs are purposeful, they can't back off that position.

Scary thought:  Maybe fixing the credit card fringe cases would mess up historical budgets that fixed the cases manually?

Magenta Disk No, YNAB continues to use the reactive approach of cover overspending when it is later realized. This is in contrast to the pro-active approach of reducing the category to show they are not available.

dakinemaui Lol, well that's great. I've just upgraded from YNAB4 and realised this is a problem for me.

Magenta Disk One workaround is to Enter Now using the date those funds are committed. The category is reduced. The drawback is an import of the actual outflow more than 10 days later will not match and cause a duplicate transaction.

A second option is to pull that expense into a dedicated category, leaving the original category with a lower budget to start with. The transaction can retain the correct outflow date in the scheduler, so import isn't thrown off.

Try 2Be Kind I think you may be overthinking it. Nothing forces you to post date a transaction that you're paying today. In fact, your accounts should match reality and you should not be post dating transactions. If you're paying a bill this month, then it should be budgeted for this month.