Suggestions
Recurring Lump Sum expenses and income with a designated month
added context by PL staff – See note, Shawn Sansom original title: Treatment of “Yearly” expenses and income with a designated month
When PL moved to support for monthly scheduling, along with the associated pro-rating, almost everything was improved. There is one corner case, though, that I argue is counter-intuitive and should change.
For context, I’m talking about a “now” plan, which I assume is the overwhelming default since the change.
For the sake of comparison, first consider how scheduling a “once” expense is handled, especially if it is scheduled in the current year. It is currently October 2025. If I schedule an expense of $100k to happen once in Jan 2025, then the expense shows up on my cash flow, taxes for it are accounted for in 2025, but it does not impact my account balances (which is correct, as presumably the $100k was already deducted somewhere).
On the other hand, if I schedule it to occur once in Dec 2025, then it is deducted from whatever account is used to pay the expense. Again, clearly correct.
If I schedule an expense (or income) that occurs monthly, it is pro-rated as one would expect for the current year, and all the calculations are handled perfectly. Very nice.
BUT… if I create an expense that happens Yearly, things are different. If I schedule an expense (say, Christmas expenses, $6k every December, starting Dec 2025), then the expense is pro-rated for 2025 (only $500 of the expense is charged in 2025). Same for income.
I know from discord conversation that this behavior is as intended, and I respect that. However, I just got bit by it for the third time (I’m dumb, but am I THAT dumb…?). I think this is anti-intuitive, and argue that if a user schedules a yearly income or expense item to happen in a specific month, they mean they receive or pay that amount in that month, every year. In the current year, the handling of a Yearly event attached to a specific month should be the same as a Once event in the same month.
I propose that the handling of this case be massaged to make the intuitive behavior the default. I know I can work around this, but it seems like it should Just Work.
