github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 07:04:23 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #7683] [Feature] Allow grouping in transaction log #72903

New Issue
Closed
opened 2026-05-16 13:49:30 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-05-16 13:49:30 -05:00
Owner
Copy Link

Originally created by @wiktor-jurek on GitHub (May 2, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7683

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

Pitch: what problem are you trying to solve?

The transaction view currently supports sorting and filtering, but not grouping. When you have hundreds of transactions, sorting by category or date only puts similar rows next to each other; you still have to scroll through every one of them to find what you want or to get a sense of the totals.

What I'm after is the ability to collapse transactions into groups, the same way a spreadsheet pivot or the macOS Finder's "Group By" option works. Pick a field (date, category, payee, account, cleared status), and the table reorganises into collapsible sections with a header row showing the group name, count, and sum. This is particularly useful by grouping transactions by day, so you can reconcile it with what you can see in your bank balance.

A few concrete cases where this would help:

  • Reviewing a month: group by day to see daily spending at a glance, expand a day to see the detail
  • Reconciling: group by payee to spot duplicate or fraudulent charges
  • Auditing categories: group by category to confirm transactions are sitting where I expect them
  • Big-picture: group by category group to see roughly where money went without leaving the transaction view

Right now the only way to get any of this is to flip over to the Reports view, but that takes me out of the transaction list and I lose the ability to click into and edit individual rows.

Describe your ideal solution to this problem

A "Group by" control in the transaction view header (next to or near the existing Sort and Filter controls) with options:

  • None (current default)
  • Date (Day / Week / Month / Year)
  • Category
  • Category group
  • Payee
  • Account (relevant in All Accounts view)
  • Cleared status

Each group renders as a collapsible header row containing:

  • Group label (e.g. "Groceries" or "12 March 2026")
  • Transaction count in that group
  • Sum of amounts in that group (with running balance behaviour disabled or recalculated per group)

Other behaviours worth defining:

  • Expand/collapse all from the three-dot menu
  • Group state persists with saved filters
  • Sorting still works inside each group
  • Filtering still works across groups (groups with no remaining matches are hidden)
  • Selection across groups behaves the same as today

Describe alternatives you've considered

  • Sorting by the field I want to group on. Works partially but doesn't give totals or collapse, and a long category still produces a wall of rows.
  • Using the Reports view (custom report, split by category/payee). Gives totals but is read-only, separate from the transaction list, and breaks the editing workflow.
  • Filtering down to one category at a time. Tedious for a monthly review across 20+ categories.
  • A "Group" column for export only (#4538). Useful for spreadsheets but doesn't help inside the app.

Implementation note: ActualQL already supports groupBy on the query layer (used in the reports), so the data side is largely there. The work would be mostly UI: a group-by selector, the grouped renderer, and the expand/collapse state.

Teaching and learning

The "Group by" control should sit alongside the existing Filter and Sort controls in the transaction view header, not buried in the three-dot menu. Showing the current state in the label ("Group by: None" / "Group by: Category") makes it self-evident at rest. Putting it anywhere less prominent would mean most users never find it.

Documentation

  • A new subsection in the Transactions docs, parallel to the existing Filtering and Sorting sections.
  • An entry in Tips & Tricks, particularly noting any interactions with running balance (which already has a "only available under certain conditions" caveat).
  • A short demo GIF in the release notes for the version that ships it. Most users find new features through the changelog rather than reading docs end-to-end.

Things that could trip users up (and need a deliberate decision)

  • Group totals with active filters. The sum in a group header should reflect the filtered subset, not the whole underlying group. Worth stating explicitly so users don't think the totals are wrong.
  • Select all across collapsed groups. Selecting "all" should include rows inside collapsed groups, but with a visual cue so users don't accidentally bulk-edit transactions they can't see.
  • Editing a row that changes its group. If a user edits a transaction's category while grouped by category, the row shouldn't immediately jump to a different section: that's disorienting. Leave it in place until the view is refreshed or the user re-applies grouping, similar to how editing with filters currently works.
  • Saved filters. Group state should save with named filters, the same way sort does, otherwise users will lose their setup constantly.
  • Mobile. The mobile transaction view is laid out very differently. Grouping might need a separate design pass, or could ship desktop-only first with a note in the docs.
Originally created by @wiktor-jurek on GitHub (May 2, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/7683 ### Verified feature request does not already exist? - [x] I have searched and found no existing issue ### 💻 - [x] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? ## Pitch: what problem are you trying to solve? The transaction view currently supports sorting and filtering, but not grouping. When you have hundreds of transactions, sorting by category or date only puts similar rows next to each other; you still have to scroll through every one of them to find what you want or to get a sense of the totals. What I'm after is the ability to collapse transactions into groups, the same way a spreadsheet pivot or the macOS Finder's "Group By" option works. Pick a field (date, category, payee, account, cleared status), and the table reorganises into collapsible sections with a header row showing the group name, count, and sum. This is particularly useful by grouping transactions by day, so you can reconcile it with what you can see in your bank balance. A few concrete cases where this would help: - Reviewing a month: group by day to see daily spending at a glance, expand a day to see the detail - Reconciling: group by payee to spot duplicate or fraudulent charges - Auditing categories: group by category to confirm transactions are sitting where I expect them - Big-picture: group by category group to see roughly where money went without leaving the transaction view Right now the only way to get any of this is to flip over to the Reports view, but that takes me out of the transaction list and I lose the ability to click into and edit individual rows. ### Describe your ideal solution to this problem A "Group by" control in the transaction view header (next to or near the existing Sort and Filter controls) with options: - None (current default) - Date (Day / Week / Month / Year) - Category - Category group - Payee - Account (relevant in All Accounts view) - Cleared status Each group renders as a collapsible header row containing: - Group label (e.g. "Groceries" or "12 March 2026") - Transaction count in that group - Sum of amounts in that group (with running balance behaviour disabled or recalculated per group) Other behaviours worth defining: - Expand/collapse all from the three-dot menu - Group state persists with saved filters - Sorting still works inside each group - Filtering still works across groups (groups with no remaining matches are hidden) - Selection across groups behaves the same as today ## Describe alternatives you've considered - Sorting by the field I want to group on. Works partially but doesn't give totals or collapse, and a long category still produces a wall of rows. - Using the Reports view (custom report, split by category/payee). Gives totals but is read-only, separate from the transaction list, and breaks the editing workflow. - Filtering down to one category at a time. Tedious for a monthly review across 20+ categories. - A "Group" column for export only (#4538). Useful for spreadsheets but doesn't help inside the app. Implementation note: ActualQL already supports `groupBy` on the query layer (used in the reports), so the data side is largely there. The work would be mostly UI: a group-by selector, the grouped renderer, and the expand/collapse state. ### Teaching and learning The "Group by" control should sit alongside the existing Filter and Sort controls in the transaction view header, not buried in the three-dot menu. Showing the current state in the label ("Group by: None" / "Group by: Category") makes it self-evident at rest. Putting it anywhere less prominent would mean most users never find it. **Documentation** - A new subsection in the Transactions docs, parallel to the existing Filtering and Sorting sections. - An entry in Tips & Tricks, particularly noting any interactions with running balance (which already has a "only available under certain conditions" caveat). - A short demo GIF in the release notes for the version that ships it. Most users find new features through the changelog rather than reading docs end-to-end. **Things that could trip users up (and need a deliberate decision)** - **Group totals with active filters.** The sum in a group header should reflect the filtered subset, not the whole underlying group. Worth stating explicitly so users don't think the totals are wrong. - **Select all across collapsed groups.** Selecting "all" should include rows inside collapsed groups, but with a visual cue so users don't accidentally bulk-edit transactions they can't see. - **Editing a row that changes its group.** If a user edits a transaction's category while grouped by category, the row shouldn't immediately jump to a different section: that's disorienting. Leave it in place until the view is refreshed or the user re-applies grouping, similar to how editing with filters currently works. - **Saved filters.** Group state should save with named filters, the same way sort does, otherwise users will lose their setup constantly. - **Mobile.** The mobile transaction view is laid out very differently. Grouping might need a separate design pass, or could ship desktop-only first with a note in the docs.
GiteaMirror added the needs votesfeature labels 2026-05-16 13:49:31 -05:00
GiteaMirror commented 2026-05-16 13:49:33 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 2, 2026):

✨ Thanks for sharing your idea! ✨

This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don't forget to upvote the top comment with 👍!

<!-- gh-comment-id:4364585325 --> @github-actions[bot] commented on GitHub (May 2, 2026): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don't forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature needs votes
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#72903
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?