Bugs

On the Budget page in beta, the 'Pad your budget' tooltip for income categories is showing recurring income as a negative value. It should be positive.

On the Suggested Recurring page, or when managing the suggest recurring item directly from a transaction, clicking on "This is not a recurring item" initiates an endless spinning loading state on all three buttons. Note that the suggested recurring item does get deleted (the item disappears after refreshing the page and is no longer associated with the transactions). There are also reports of the same behavior with the "merge with existing" action.

On the Transactions page, updating the Payee name of a transaction that is associated with a suggested recurring item, will lead to the Payee name only updating in the 'Transaction Details' panel. The payee name in the Transactions table cell will remain with the original value. If the suggested recurring is marked as "This is not a recurring item", the payee name in the table will then reflect correctly. On the other hand, if the suggested recurring is accepted, it will lock the listing with the two different payee names.

Plaid changed the way synced transactions with the TRANSACTIONS_REMOVED webhook should be handled. This needs to be updated in Lunch Money to ensure removed transactions are also properly removed in the app.

The "Available to Spend" does not seem to be calculating properly like it did in the regular version. For Example, in a specific category, with a budget of $100, there is a projected spend of $80, but it is still saying I have $100 available to spend. It should be saying $20. In some cases, positive values in the 'Available' column of the Budget Breakdown also appear in red, instead of green, and vice-versa.

On the Transactions page, the categories dropdown and the expanded payee name on hover, will be cut off at the bottom of the table when viewed in a narrower screen width. It displays correctly in a fully expanded browser.

When using 'Create from Recurring' on the Transactions page, transactions associated with Recurring Items that have their anchor date set to day 30 or 31st will end up getting created in the following month if the day doesn't exist (February, April, June, September, and November). If the anchor date's day does not exist in the current month, the recurring item should be created on the last day of that month (e.g., February 28th for February 2025, April 30th for April 2025), as per the billing day that displays when viewing the Recurring Items page. Steps to Reproduce: Create a Recurring Item with an anchor date of January 31, 2025. Use the "Create from Recurring" option in February 2025 to create the transaction. The item is incorrectly created on March 3, 2025, instead of February 28, 2025. Similarly, for an anchor date of April 30, 2025, the item gets created on May 1, 2025, instead of April 30, 2025.

Previously reported as "Disappearing recurring items" Update (July 11, 2024): Another user reported incorrect totals on the Overview page under the Spending Breakdown. This was associated with a recurring income item, but in this case the recurring item was displaying on the Recurring page for the current month. Simply deleting the recurring rule resolved the issue and the totals then displayed correctly. Update (July 3, 2024): When a recurring item has an end date, it will only display on the Recurring items page up until that end date. With that said, the recurring rule continues to exist on the Rules page past that end date, and therefore will continue linking new transactions that match the recurring item criteria. Since these transactions are linked to a past recurring item, they cause incorrect totals on the Transactions and Overview page, and click to edit the recurring item from the recurring transaction will lead to a blank page (broken link). Two different errors were reported when the blank page occurs (the one in the attached image, and the one below): Uncaught TypeError: Cannot read properties of null (reading 'billing_date') at EditModal.tsx:135:187 at Ll (react-dom.production.min.js:262:359) at t.unstable_runWithPriority (scheduler.production.min.js:18:343) at Ur (react-dom.production.min.js:122:325) at Nl (react-dom.production.min.js:261:308) at Ie (react-dom.production.min.js:292:141) at Kt (react-dom.production.min.js:73:323) at HTMLBodyElement.a (helpers.js:91:17)

During CSV / PDF import, the 'Fix Dates' feature only works correctly when the date format is entered in uppercase letters, eg. 'DD/MM/YYYY'. It doesn't work as expected when entered as 'dd/mm/yyyy'.

When a transaction is split (eg. in 3 ways), it will immediately display all 3 split transactions in the table, yet they will actually be treated individually (not associated with one another). If the page is refreshed, they are then treated as expected... but if actions are done to them without refreshing the page, it means that an individual split transaction can be deleted by itself. The delete dialog doesn't mention the need to split it first as part of the deletion process. If deleted, that individual split transaction goes into a "void" and cannot be seen or accessed, but remains in the database. The remaining two split transactions in this example will still display in the table. If the page is refreshed, the two split transactions will then correctly display as associated with one another, and can be unsplit or deleted. If unsplit, the original value returns (including that of the deleted transaction), but if it's deleted, then only the two are deleted, and the third remains in the "void". Adding the same transaction through CSV prompt a warning saying it's a duplicate transaction, as it's comparing it with the transaction in the "void". Also, selecting the transactions immediately after creating them, fails to display the selected amount under 'Selected Transactions' (see screenshot).