github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-21 06:31:58 -05:00
Code Issues 2.1k Packages Projects Releases 57 Wiki Activity

[GH-ISSUE #4481] [Feature] Add proper installment handling #8844

New Issue
Closed
opened 2026-04-10 19:08:21 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-10 19:08:21 -05:00
Owner
Copy Link

Originally created by @morags on GitHub (Feb 28, 2025).
Original GitHub issue: https://github.com/actualbudget/actual/issues/4481

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?

As far as I can tell, Actual does not currently have a proper mechanism for handling installments, which are a series of payments that are part of a single transaction. Actual does have a mechanism for scheduling, but that I assume is meant for recurring, separate transactions. In the former case, the number of payments and their total value is known in advance, while in the latter it is not.

Describe your ideal solution to this problem

To have proper handling of installments, Actual should have the following workflow:

  1. From the account view, click "add new".
  2. Fill in all of the transaction details, including any category splits.
  3. Under "payment", click "installments" and input the relevant number.
  4. Click on "add". Actual will now add to the account a series of linked, partial payments, timed by default for consecutive months, that share the same account, payee and categories.
  5. Changing the sum of any of the payments (except for the original transaction) would pop-up a reconciliation dialogue, similar to the one displayed when changing the sum of a split transaction ("distribute" / "add split").
  6. For the purpose of envelope budgeting, the total sum of the transaction would be considered. For example, if one makes a purchase worth $300 in three monthly installments, the budget would immediately consider it as $300 deficit. For the purpose of a tracking budget, this may work differently.

This workflow has the following benefits:

  1. Installments are logically connected, making it clearer where payments are derived from, which is not the case if one inputs installments as separate future transactions.
  2. One only needs to input the payment category (or split) once. If one inputs a category split, then there's no need for them to manually calculate how the categories add up in subsequent payments - the program can do it on its own based on the proportions of the original transaction. For example, if that $300 purchase from before is split between three categories at a ratio of 225:45:30, then the program will automatically split the three installments by the same proportions (75:15:10).
  3. Installments are easier to set up than schedules and rules, which also means that they're usable in scenarios where one wouldn't otherwise bother - like small, day-to-day payments. You might set up a schedule and rules for a multi-year mortgage, but you probably won't bother for that weekend grocery hop that you decided to split to two.
  4. This is essentially how credit statements work - showing both the concrete payments, what transaction they are derived from, and what the total sum is expected to be - which makes it both more intuitive, and easier to process.

Teaching and learning

Since this tracks closely with how credit statements work, it should be relatively easy to understand and explain (for example in the "Managing Credit Cards" page); and since it replicates current GUI elements, it should also be easy to comprehends visually.

Originally created by @morags on GitHub (Feb 28, 2025). Original GitHub issue: https://github.com/actualbudget/actual/issues/4481 ### Verified feature request does not already exist? - [x] I have searched and found no existing issue ### 💻 - [ ] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? As far as I can tell, Actual does not currently have a proper mechanism for handling installments, which are a series of payments that are part of a _single_ transaction. Actual does have a mechanism for scheduling, but that I assume is meant for recurring, _separate_ transactions. In the former case, the number of payments and their total value is known in advance, while in the latter it is not. ### Describe your ideal solution to this problem To have proper handling of installments, Actual should have the following workflow: 1. From the account view, click "add new". 2. Fill in all of the transaction details, including any category splits. 3. Under "payment", click "installments" and input the relevant number. 4. Click on "add". Actual will now add to the account a series of linked, partial payments, timed by default for consecutive months, that share the same account, payee and categories. 5. Changing the sum of any of the payments (except for the original transaction) would pop-up a reconciliation dialogue, similar to the one displayed when changing the sum of a split transaction ("distribute" / "add split"). 6. For the purpose of envelope budgeting, the total sum of the transaction would be considered. For example, if one makes a purchase worth $300 in three monthly installments, the budget would immediately consider it as $300 deficit. For the purpose of a tracking budget, this may work differently. This workflow has the following benefits: 1. Installments are logically connected, making it clearer where payments are derived from, which is not the case if one inputs installments as separate future transactions. 2. One only needs to input the payment category (or split) _once_. If one inputs a category split, then there's no need for them to manually calculate how the categories add up in subsequent payments - the program can do it on its own based on the proportions of the original transaction. For example, if that $300 purchase from before is split between three categories at a ratio of 225:45:30, then the program will automatically split the three installments by the same proportions (75:15:10). 3. Installments are easier to set up than schedules and rules, which also means that they're usable in scenarios where one wouldn't otherwise bother - like small, day-to-day payments. You might set up a schedule and rules for a multi-year mortgage, but you probably won't bother for that weekend grocery hop that you decided to split to two. 4. This is essentially how credit statements work - showing both the concrete payments, what transaction they are derived from, and what the total sum is expected to be - which makes it both more intuitive, and easier to process. ### Teaching and learning Since this tracks closely with how credit statements work, it should be relatively easy to understand and explain (for example in the "[Managing Credit Cards](https://actualbudget.org/docs/budgeting/credit-cards/)" page); and since it replicates current GUI elements, it should also be easy to comprehends visually.
GiteaMirror added the needs votesfeature labels 2026-04-10 19:08:22 -05:00
GiteaMirror commented 2026-04-10 19:08:23 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 28, 2025):

✨ Thanks for sharing your idea! ✨

This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make 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:2691383888 --> @github-actions[bot] commented on GitHub (Feb 28, 2025): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make 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
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#8844
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?