2026.08.11.1

New features

Mobile nav rework: Reports tab restored, Alerts moved to menu, dashboard indicator cleanup, root-screen menu icon (KAN-1209)

Reports is back in its usual spot at the bottom of the mobile app, so you can jump straight to it from any screen without hunting for it. Alerts now lives in the new menu, which you open with the three-line button at the top left of the Home, Accounts, Budget and Reports screens — and a small amber count on that button still tells you at a glance how many items are waiting for you. The menu also gets you to your bills and schedule, settings and help from anywhere, and opening Alerts from it gives you a back button to return to whatever you were doing. On the Home screen, the small circle with your initial has been replaced by that menu button. The “Updated a moment ago” note and the “Needs Attention” tag under your Safe to Spend amount are gone, since the amount already turns red and tells you how far short you are when money is tight; the “Healthy” and “Getting tight” labels still appear as before.

Mobile: Unify screen headers into a shared ScreenHeader (chrome + band contract) (KAN-1290)

The app’s main screens now share one consistent look at the top: the same colors, the same centered title, and the same controls in the same places, so nothing shifts or changes as you move between tabs. Bills now has its own spot in the bottom navigation bar, so your bill schedule is always one tap away instead of tucked inside the home screen. Adding something new now happens from a plus button at the top of each screen — including a new one on your home screen — replacing the old raised button in the middle of the bottom bar. The Reports section gains a new Income vs Expenses report that lays out what came in and what went out month by month, with a breakdown showing exactly where the gap between them came from. Searching your bills now lives inside the filter panel alongside your other choices, and the filter button shows a small dot whenever a search or filter is narrowing what you see.

Fixes

Review Center’s “Safe to Spend drops to $X” disagrees with the dashboard hero for any household not on window 1 (KAN-1072)

You can tell the app how far ahead to plan when it works out what’s safe to spend, and that setting now applies everywhere that figure appears. Until now the review area — where you confirm the recurring bills and payments the app has spotted — quietly ignored your choice and always planned just one paycheck ahead, so the amount it showed you could differ from the amount on your dashboard. Both places now look at the same setting, so the two figures agree and change together whenever you adjust how far ahead you want to plan. If the app ever can’t read your preference, both places fall back to the same sensible default instead of drifting apart. Your saved setting is unchanged, and each household’s figure is based only on its own choice.

KAN-982 shipped PRIMARY-level PFC matching where its own binding ruling required DETAILED — re-opens the false-link class (KAN-1163)

When money left one of your accounts and a similar amount arrived somewhere else around the same time, the app could occasionally treat the two as a transfer between your own accounts even when they were unrelated — for example, a bill payment matched against a deposit that happened to be the same size. Because transfers are kept out of your spending and income totals, those amounts could quietly disappear from your budget, your reports, and your safe-to-spend number without anything looking wrong. The app is now much stricter about connecting two items on its own: it only links them automatically when your bank’s own information clearly identifies both sides as a transfer. When the match is less certain, the app shows you the pair as a suggestion so you can confirm or dismiss it yourself instead of deciding for you. Everything you have already entered or approved stays exactly as it is.

payee_mappings read path and the orphan sweep still yield dead-payee ids — KAN-1116 fixed only the merge write path (KAN-1164)

After you merged two payees together or deleted one, the app could still quietly match newly imported transactions to the payee that no longer exists, so those transactions came in attached to a name you had already cleaned up — and the old spelling variations it had learned stayed behind even after the payee was gone. Imports now always match to a payee that is still in your list, so a merge or a delete really is the last time you have to think about that name. Cleaning up an unused payee now also clears the spelling variations it had learned, instead of leaving them behind where they could resurface later. Deleting a payee that is still attached to a bill continues to stop and ask you first, and the counts the app reports back after a merge or delete are unchanged. The rest of this release is behind-the-scenes tidying, with no change to how anything looks or behaves.

Improvements

Enforce idempotency keys on all write endpoints (KAN-26)

If a save was interrupted — a dropped connection, a slow response, or a second tap on a button — the app could quietly apply the same change twice, leaving a duplicate payee, a repeated bill edit, or a transfer confirmed more than once. Saving now recognizes a repeated attempt as the same action and returns the original result instead of doing the work again, so a retry can no longer double up your data. This covers your accounts, bills, payees, transfers, and the transaction register, including reconciling an account and saving your register view. When a save is retried, the numbers you see back — such as how many transactions were reconciled — are the ones from the original save rather than freshly recalculated figures that could look wrong. And if an attempt fails partway through, nothing is left half-applied, so simply trying again works cleanly.

Deleting a Plaid-settled transaction leaves the bill cursor/history stranded (KAN-438)

When you deleted a transaction that had been used to mark a bill as paid, the bill stayed marked as paid and moved on to its next due date, with no way to put it back — the payment you removed also quietly skewed the app’s sense of what that bill normally costs. Deleting such a transaction now returns the bill to the date it was due and removes the payment from its history, so the bill shows up as unpaid again exactly as you would expect. This works the same whether you entered the payment yourself, brought it in from a file, or the app matched it to your bank automatically, and it also works when the payment was part of a transfer between two of your accounts. If your bank later withdraws a transaction that was paying a bill, the app now leaves it in your register with its usual undo option instead of removing it behind your back. Separately, entering a bill whose payee has since been removed now posts the payment with the payee left blank rather than attaching a name you no longer use, and an import containing one of these bills still brings in every other transaction as normal.

No persisted Google-identity linkage (google_sub) — blast radius grew with native client (KAN-876)

Signing in with Google is now more dependable. The app now remembers your actual Google account, not just its email address, so if you ever change the email on your Google account you will still land in your own Tovari account instead of being turned away or mixed up with someone else. If you try to sign in with a Google or Apple account whose email is already tied to a different sign-in identity, you now get a clear explanation of what happened and what to do, instead of a vague failure message. When you ask us to erase your account, we now also disconnect Sign in with Apple on your behalf, so the app no longer appears in your Apple settings afterward. We also fixed a rare timing glitch where signing out at just the wrong moment could leave the app appearing signed in. Finally, sign-in error messages are now announced immediately to people using screen readers.