Split transactions should be treated as separate transactions (2 Merged Votes)
Comments
-
I have the same question and for that reason, I agree to splitting most details (tags, category, notes, link to recurring..) but not dates.
I think the reason it comes up is because people want to fit transactions into the spending plan for specific months when it doesn't always work out that way. For example, if you pay someone every month but in April you pay them on the 30th so you just give them double to cover May as well. So then you'd want to split the transaction into 2 parts, April 30, and May 1, so that it would fit neatly into the monthly spending plan buckets.
I thought rollover would help with this but it's not so clear cut if it does or not, especially since rolling over doesn't help with surplus funds (or a deficit) from month to month.
0 -
A more typical way of handling this would be to book the payment (or part of it) as "Prepaid Expense."
For example, let's say you make a $600 payment for 6 months of insurance coverage. In this scheme, you would need an expense category for "Insurance" and an asset account for "Prepaid Expenses."
When you make the payment, you split it $100 to Insurance and $500 to Prepaid Expenses — both occurring on the same date. Then you set up a recurring payment of $100/month for Insurance to be paid out of the Prepaid Expenses account on future dates. Splits with different dates are not required.
With this method, the entire $600 comes out of your bank account on the date paid, but the expenses show up in the future at the rate of $100 per month. The downside is that you have a $500 asset in Prepaid Expenses that doesn't exist in the real world. (Or maybe it does if the insurance is refundable.)
This also seems like a lot of trouble and a source of possible user error.
DryHeat
-Quicken (1990-2020)
-Countabout (2021-2024)0 -
Agreed. So many reasons to have this feature. Almost no reasons not to. Those who say "I don't get why this is needed" just wouldn't have to use it. I hope they listen to us...
1 -
You'd need to (pretend to) pay the remaining expense, the next month, from the fake/manual account. That way the expense would be listed in the correct month and the money would be transferred out of the fake account.
I've done this sort of thing to transfer income surplus from one month to the next. It works but it's a bunch of steps and a little clumsy and you have to make sure you got it right.
0 -
@EL1234 "You'd need to (pretend to) pay the remaining expense, the next month, from the fake/manual account."
Right. That's what I tried to describe in the example I set up:
"Then you set up a recurring payment of $100/month for Insurance to be paid out of the Prepaid Expenses account on future dates."
Sorry if that wasn't clear.
And I agree that it's clumsy. It's something a bookkeeper might do. But it's more than I want to do.
DryHeat
-Quicken (1990-2020)
-Countabout (2021-2024)0 -
I see what you mean! I wouldn't set a recurring expense because you'll still need to create the actual transactions manually. So they'd be recurring if you set them each up.
I did it a few times with income but lately I haven't been using the spending plan because the data needed too much massaging in order to be useful. I hope to get back to it at some point.
0 -
I agree about the "data massaging" burden, and I try to avoid it.
I personally use the Spending Plan a lot, but in order to do so I've had to just accept it for what it is. Rather than trying to make it exactly reflect the ebb and flow in the real world, I just use it for what it can do "as is."
It keeps me up to date on how my money is being spent (or obligated), and that's really what I need.
DryHeat
-Quicken (1990-2020)
-Countabout (2021-2024)0 -
I agree with making the split transaction 2 separate transactions with a link on the backend. The combined transaction and the way it exports in the CSV is making the data unusable in excel. I spend way too much time manipulating the exported data to ensure my pivot tables are showing me all relevant data. The simplifi development team needs to fix this issue….I can't say i really care about how but the export needs to be seamless😊
0 -
Will this ever get fixed?
0 -
This feature would be good only if there is an option to set the display mode in the register as separate or combined. I understand the benefit for exporting and allowing notes for each split is a big request for me. But when reviewing my transactions and comparing to my bank, it is difficult if displayed separately in the register as I am looking for the total value. I tried Monarch and this was the primary reason I did not keep it.
It is actually not the best way to handle the issue. Most likely on their backend database they have a transaction table and a splits table. So instead of creating two transactions, really the request is can you add those fields which you want to be unique to the split, to the splits table whereas today they are only in the transaction table. Then exporting is a matter of how you format the data, on individual lines. And a setting which indicates how it's displayed, separate or combined.
1