nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

"Yearly" Totals Incorrect (Bills & Income > All Recurring)

Ed_G

Within "All Recurring" transactions, I'm seeing that the Yearly column for Monthly expenses inconsistently calculates the Yearly value. Some of the monthly transactions are being multiplied by 10 and others by 12 to calculate the Yearly total. Attached image shows first two rows x 10 and then third row x 12. ?

Find more posts tagged with

Recurring

Comments

Coach Kristina

Hello @Ed_G,

Thank you for letting us know about this issue. When did you first notice it? Is there any pattern to which bills are showing 10 months instead of 12? Is it always calculating based on 10 months when it's incorrect? Is this happening only with monthly bills, or are there other intervals that also don't add up as expected?

I look forward to your reply!

Ed_G

Hi @Coach Kristina - Responses to your questions:

1 - I just signed up for Simplifi last week; long time Quicken user.
2 - No pattern that I can see. Impacts transactions whether checking, savings, or credit card.
3 - I see it impacting Income, Bills and Subscriptions (Monthly, Twice a month)
4 - The yearly multiplier can range from 9 to 10 to 12 for Monthly intervals.
5 - I saw that "Twice a month" for Income is also not calculating the Yearly column correctly

I also noticed issues with Spending Plans missing transactions and another issue with modifying Recurring transactions. I'll detail in a separate post.

Ed

DryHeat

@Ed_G

I'm seeing something similar. A subscription that costs $3.25/month shows $42.25/yearly (so x13). I haven't bothered to check all the others, but I've seen at least a couple more that are multiplying by 13.

I thought maybe an an "extra transaction" might be included, like maybe the Dec bill was paid in Jan. But that's not the case. There have only been 3 transactions this year (Jan 30, Feb 28, Mar 29), so everything is on schedule.

(A tiny transaction like this doesn't affect anything, of course, but it's another data point showing the problem.)

Coach Natalie

@Ed_G & @DryHeat, thanks for the information!

This is not a bug. The 'Yearly' amount in the Recurring section does not use simple multiplication. Here is the official answer from our product team:

https://community.simplifimoney.com/discussion/comment/38997#Comment_38997

We are working on adding this information to our Help Center. Otherwise, if you'd like to see a change made to the current design, you can create an Idea post so other users can vote on it!

https://community.simplifimoney.com/discussion/998/creating-and-voting-for-ideas-in-the-community

I hope this helps!

RobWilk

We addressed this in the past, it's not a simple multiply by 12 things for monthly charges. It's based on prior matched transactions and future upcoming transactions for the current year.

DryHeat

@RobWilk + @Coach Natalie

" Total of past transactions + total of future scheduled transactions" would be a fine way of doing it. But that's not what's happening.

As I said in my earlier post, this recurring bill has seen 3 transactions so far this year (Jan, Feb, Mar). The series history shows that:

The transactions are scheduled for the last day of the month, and the next one is set for April, so there are 9 remaining transactions in the year (Apr-Dec). The series recurrence panel shows that:

All the transactions are the same amount. According to the product team, the Yearly amount should be 3 x that amount (for the past transactions) plus 9 x that amount (for the future transactions). The expected Yearly value is thus 12 x that amount.

BUT… The Yearly value shown is actually 13 x that amount.

So, as far as I can tell, it's not working they way the product team says is should.

RobWilk

IF it's scheduled for the last day of the month, is it possible the december one CLEARED in january (changing the date), thereby "adding an extra month"?

DryHeat

@RobWilk "is it possible the december one CLEARED in january (changing the date)"

Good thought. But no… that didn't happen.

The date for the December transaction is December 30, 2024 in QS and December 29, 2024 on the credit card statement.

Coach Natalie

@DryHeat, I think the formula is a little more complex than "Total of past transactions + total of future scheduled transactions". The user in the thread I shared above was also seeing x13, and it was escalated and subsequently closed as not a bug. I'd suggest creating an Idea post for a simpler calculation, such as simply taking the recurring amount and multiplying it by the number of occurrences in the year. I think that would be a great way to get this in front of the product team and rally feedback from other users! I'd add my vote!

RobWilk

I might agree, as since it says "yearly" and not 'this year', it implies it's the amount every year, which should be a simple recurring amount times number of occurences per year - of course, this is complicated when it comes to every 2-3+ year transactions (I have at least 2 or 3 of those, such as car registration and web hosting renewals).

-rob

DryHeat

@Coach Natalie "I think the formula is a little more complex than 'Total of past transactions + total of future scheduled transactions.'"

The team's version is wordier but no more complex than my shorthand rendition, which is functionally equivalent. At least where, as I said above, all transactions are of equal size. (The team's version is vague about whether it handles past transactions of varying size.)

Here's the team's version: "For the yearly calculation, we … calculate the amount based on how many posted transactions exist for the recurrence + the amount of future scheduled transactions for the rest of the calendar year multiplied by the amount."

You can see the equivalence by applying both formulae to my scheduled recurrence. There have been 3 monthly transactions so far, and there are 9 left to go. For simplicity, let's assume the transaction amount was $100. The yearly amount should be 12 x $100 = $1200.

First factor (past) = $300 under either formula

ME: "Total of past transactions"

Using my version, the 3 past transactions (Jan, Feb, Mar) of $100 each total $300.

TEAM: "calculate the amount based on how many posted transactions exist for the recurrence"

Using the TEAM version, there are 3 posted transactions with an amount of $100 each, again totaling $300.

Second factor (future) = $900 under either formula

ME: "total of future scheduled transactions"

Using my version, the 9 future scheduled transactions (Apr-Dec) of $100 each total $900.

TEAM: "amount of future scheduled transactions for the rest of the calendar year multiplied by the amount"

Using the TEAM version, there are 9 future scheduled transactions, the amount is $100 each, and 9 x $100 again totals $900.

Result:

Either description results in $300+$900 = $1200, which is 12 x the monthly amount, which is what you would expect for the year.

But, like others, I am seeing a resulting yearly total of 13 x the monthly amount. The team's formula doesn't explain that.

Ed_G

@Coach Natalie , @DryHeat @RobWilk - Thank you for the responses. I have to chuckle though because the name of this product is "Simplifi", but this calculation is anything but simple. I think it's safe to say that the average user is going to assume that the Yearly total represents the Monthly number x 12, but without an info icon to explain otherwise it's only going to cause confusion. Maybe we keep it simple and just multiple by 12. : ) I'll submit an Idea Post. Thanks again everyone.

DryHeat

@Coach Natalie

It seems several of my monthly fixed amount recurring bills show a yearly total of 13 times the monthly amount. Here's an example:

This recurring bill has 3 existing posted transactions (Jan-Mar) and is scheduled for 9 future transactions for the rest of the calendar year (Apr-Dec). All are for the same $21.73 amount.

In the real world, there will be 12 transactions this year totaling $260.76. Applying the product team's formula also returns $260.76.

But the yearly amount shown by QS is $282.49… 13 times the monthly amount.

It doesn't seem right to close this as "not a bug" when the displayed yearly amount matches neither what the user would expect nor what the product team's "formula" would calculate.

Coach Natalie

@DryHeat, the issue you are describing was already escalated and deemed not a bug. We will not be able to do anything further from our end except suggest that you create an Idea post. Our product team reviews Idea posts, so doing so will shed new light on the behavior.

Thanks!

DryHeat

@Coach Natalie "the issue you are describing was already escalated and deemed not a bug."

Sigh…

I get that you can't do anything about it. But the word "deemed" does a lot of work here.

The product team said this wasn't a bug because they use a different method to calculate the yearly totals. But the yearly totals don't match the method they claim to be using. If that's not a bug, well… never mind.

Thanks for looking at this.

(BTW, it may not be obvious, but the "more complex" formula is nothing more than payments so far + remaining planned payments. That's actually a good plan, as it correctly handles payments that start in the middle of the year. But they just haven't coded it correctly.)