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; } } }

SOLVED: Issue when generating Transaction Reports that include split transactions

Bobbymacd

I just spent 90 minutes on a support session with an agent and then a supervisor and I'm a bit peeved.

The problem is that when generating a Transaction Report that includes split transactions, the report excludes certain items depending on the order of the items in the split window.

Example:

I have two years of monthly transactions for Ajax Apartments at $1000 per month. These are split into four categories:

1. Rent at $700

2. Parking at $200

3. Utilities at $75

4. Trash at $25.

In creating a Transaction Report for just Rent and Parking, I check the box for Ajax as the Payee and I select only the two boxes "Rent" and "Parking" as the categories. The resulting report only includes 18 of the 24 months because, in the other 6 months, the order of the split transactions was different, i.e., Trash was listed first; followed by Rent, Parking, and Utilities.

I think this is kind of a big deal, but Quicken support insisted that it's a normal FEATURE of Transaction Reports, not a bug. They insist on this narrative despite the fact that (a) for other types of Reports, such as Cash Flow, the order of the splits does not matter and all split items are included, and (b) there is NO DOCUMENTATION anywhere for this particular "feature" of the Transaction Report.

I've been using Quicken for 37 years and have never come across this issue before, but the wizards at Tech Support insist this is just how the software works. So now I'm questioning the accuracy of all my other Transaction Reports over the years.

I refuse to believe this is anything other than a bug. And no, it's not a corrupted data file since it passed the File Validation check.

The Support Supervisor suggested I post here under the heading of "New Ideas" for the product.

Is anyone else aware of this undocumented and heretofore unknown "FEATURE" of Transaction Reports?

Find more posts tagged with

Known Issues

Transactions

Comments

pablomiller

Boiling your well-justified displeasure into an actionable request, Copilot suggests the following:

Requested Fix

Please update the Transaction Report engine so that:

A transaction is included if any split line matches the selected categories
Split-line order has no effect on inclusion
Behavior is consistent with Cash Flow, Itemized Categories, and Spending reports
Users receive accurate, complete results regardless of split ordering

If the legacy report engine cannot be corrected, Quicken should:

Document the limitation clearly, and
Provide a modern replacement report type that handles splits correctly

NotACPA

Your assertion that the order of split lines makes a difference in a Transaction report can't be supported by my experiment, just now.

Bobbymacd

Thank you Pablo. Having spent part of my career managing customer support call centers - and having used Quicken since 1989 - this experience was triggering to say the least. You know the old saying - "don't blank down my back and tell me it's raining?"

I trust your reply will serve as a more constructive response to the Quicken team (assuming they don't delete the post entirely.)

Bobbymacd

Thank you NOTACPA. My gut also tells me that it's a data corruption issue of some type, but the Supervisor insisted that it was (1) a known issue and (2) that it's not an issue at all, just a normal limitation of Transaction Reports.

Not sure I buy any of that, especially considering that I've never experience this issue before. Maybe it's a combination of my particular data file (which has 37 years of transactions) and the latest version of Quicken?

Jim_Harman

This is an interesting bug. I tried a very simple test with just 2 transactions and 4-way splits, arranged as you describe, with the Payee and the first 2 Categories of the first transaction selected for the report.

What I see is that with the Show splits box on the Display customization tab not checked, the report only shows the first transaction and it shows the total of all the splits in that transaction, $1,000. If I check the Show splits box, the report works correctly, showing both transactions and just the two selected Categories, totaling $1,800.

I suppose what is happening is that with the Show Splits box un-checked, the report is just filtering on the Payee and the first line of the split. If the transaction matches those criteria, the whole transaction is included in the report, not just the split Categories. I seem to remember there was a similar issue with the transactions to include on the Spending tab.

BTW I think this should be treated as a bug, not an Idea. If you don't mind, I will ask a Moderator to change it.

Although the OP asked to have it deleted because their immediate problem is resolved, I think it is a bug. I think with a split transaction where not all the split Categories are selected, the report should include all the transactions that contain one or more of the selected split lines and the total should be the total of the selected Categories, not the full amount of the transaction, regardless of whether "Show splits" is selected

Bobbymacd

Jim

Mystery solved! The "show splits" transaction box was unchecked.

This renewed my faith in the software even if it completely undermined any faith in the support team since - despite sharing my screen - it never occurred to them to look at that section of the screen. Scary.

I will delete this thread since I don't want to mislead anyone about this - the correct fix would be a popup warning box if the "show splits" box is unchecked.

Chris_QPW

https://community.quicken.com/discussion/comment/20544017#Comment_20544017

Unfortunately, only the moderators can delete comments/threads.

pablomiller

Quicken’s Reports module has become so overloaded with decades of user‑requested options and interacting filters that even small mis‑configurations can silently distort the output. The result is a system where reports look authoritative but often behave unpredictably because category filters, transfers, splits, tags, and account‑level settings all override one another in inconsistent ways. Unfortunately, there's probably no way back from the current state of affairs.

Bobbymacd

Since I can't delete the post I changed the title to reflect that the issue is RESOLVED. I agree with Pablo about the risk of too many changes. We legacy users should be concerned that our saved reports may become inaccurate over time.

A greater fear is that they kill the program entirely in which case I'll have bigger problems.