Feature Request: Allow variable/editable payment amounts for subscriptions (e.g., utility bills)
First of all, thank you for Wallos — it's been a fantastic tool for tracking my subscriptions, and the Hungarian localization is excellent!
The Problem
I have several recurring payments where the amount varies each month, most notably utility bills (electricity, gas, water). Currently, Wallos requires a fixed amount for every subscription, and the field cannot be left empty.
This means I have to either:
Enter a rough average (which makes my monthly statistics inaccurate)
Edit the subscription every month after receiving the actual bill (which is tedious and loses the payment history)
Proposed Solution
I would love to see one or more of the following features implemented:
Option A: "Actual Payment" field
Add a secondary "Actual Payment" field that can be filled in when marking a subscription as "paid". This would:
Keep the original estimated amount for budgeting purposes
Record the real amount paid for accurate statistics
Preserve a history of actual payments over time
Option B: Payment history log
Allow each subscription to have a payment history log, where each payment instance records:This would be especially useful for annual statistics and tracking spending trends on variable-cost services.
Date paid
Actual amount paid (editable)
Optional note
Option C: Optional amount field
Make the amount field optional for certain subscription types, with a toggle like "Variable amount" or "Bill-based payment". When enabled, the user is prompted to enter the amount each time they mark it as paid.
Why This Matters
For many households, utility bills represent a significant portion of monthly recurring expenses. Having inaccurate amounts in the tracker undermines the value of the statistics and budget features.
Additional Context
I'm currently using the workaround of entering an average and editing it monthly, but this overwrites the previous month's data and makes year-over-year comparisons impossible.
Thank you for considering this request! I'm happy to provide more details or test any beta implementation.
tsilver
Feature Request: Allow variable/editable payment amounts for subscriptions (e.g., utility bills)
First of all, thank you for Wallos — it's been a fantastic tool for tracking my subscriptions, and the Hungarian localization is excellent!
The Problem
I have several recurring payments where the amount varies each month, most notably utility bills (electricity, gas, water). Currently, Wallos requires a fixed amount for every subscription, and the field cannot be left empty.
This means I have to either:
Enter a rough average (which makes my monthly statistics inaccurate)
Edit the subscription every month after receiving the actual bill (which is tedious and loses the payment history)
Proposed Solution
I would love to see one or more of the following features implemented:
Option A: "Actual Payment" field
Add a secondary "Actual Payment" field that can be filled in when marking a subscription as "paid". This would:
Keep the original estimated amount for budgeting purposes
Record the real amount paid for accurate statistics
Preserve a history of actual payments over time
Option B: Payment history log
Allow each subscription to have a payment history log, where each payment instance records:This would be especially useful for annual statistics and tracking spending trends on variable-cost services.
Date paid
Actual amount paid (editable)
Optional note
Option C: Optional amount field
Make the amount field optional for certain subscription types, with a toggle like "Variable amount" or "Bill-based payment". When enabled, the user is prompted to enter the amount each time they mark it as paid.
Why This Matters
For many households, utility bills represent a significant portion of monthly recurring expenses. Having inaccurate amounts in the tracker undermines the value of the statistics and budget features.
Additional Context
I'm currently using the workaround of entering an average and editing it monthly, but this overwrites the previous month's data and makes year-over-year comparisons impossible.
Thank you for considering this request! I'm happy to provide more details or test any beta implementation.
tsilver