2026.08.23.1

New features

Pending-survivor match refusal (MSG_SURVIVOR_PENDING) and two-step Enter-then-Match ergonomics for underpaid bills (KAN-1872)

Settling a bill you paid for a different amount than usual is now a one-step task. When a payment that doesn’t match a bill’s usual amount shows up in your account, the Enter button offers to settle the bill against that payment directly — one confirmation, no duplicate entry to clean up afterward. You can also now match a payment that’s still processing at your bank to an entry you typed in yourself: a new “Match” option on the processing payment combines the two into one, keeping your notes and category, after you confirm it’s really the same payment. The confirmation message when entering a bill with a payment still processing has been corrected too — it previously warned that entering would create a second entry to clean up, when in fact the app combines them cleanly. These conveniences never act on their own; every combination happens only when you confirm it, and your automatic matching stays exactly as careful as before.

Fixes

bills.next_payment_date NULL-fallback divergence across ten read call sites, two incompatible semantics (KAN-1744)

Your bill balance forecast now lines up correctly with your other reports. Previously, the “actual balance” line on the Bills forecast could read differently than the same days shown on your Net Worth and Cash Flow reports, and a recently connected account’s older history could be partly left out of that line. Both are now fixed, so the balance you see for past days on your bill forecast always matches what your other reports show, and every connected account’s full history is counted correctly. Today’s balance and any future projections are unaffected — this only corrects how past days are calculated. We also added extra safety checks behind the scenes to keep your account balances accurate and prevent certain transfer payments from being counted twice.

25 Plaid pending rows frozen 19+ days on two accounts — they can never settle, and each one duplicates when its charge posts under a new id (KAN-1801)

Some pending card charges were getting stuck: they stayed marked as pending for weeks, never cleared on their own, and when the real charge finally arrived it showed up as a second copy — so the same purchase could appear twice and balances looked off. The app now double-checks older pending charges against your bank and automatically clears out any hold your bank no longer reports, so stale pending items no longer linger or create duplicates. If a cleared hold later turns into a real charge, it simply reappears in its place with any edits you made intact — nothing is lost. We also added a behind-the-scenes health check that shows us any account where pending charges are stuck, so problems like this can be spotted and resolved quickly. Existing stuck items on affected accounts will clear automatically the next time those accounts refresh with the bank.

enterBill.ts and skipBill.ts floor a NULL bills.next_payment_date cursor at ‘today’ via settlementFloorIso, so a legacy bill with no settle history cannot have a genuinely-overdue PAST occurrence entered or skipped (KAN-1833)

Previously, if you had an older recurring bill that had never been recorded as paid, trying to mark one of its past due dates as paid or skipped would fail. Now you can enter or skip that overdue payment right from the Bills screen, and it will be recorded on its actual due date. Doing this only affects the one payment you choose — it won’t pull in every missed payment from that bill’s history at once, so your account totals and spending outlook change by just that one amount. If a matching transaction already exists for that date, you’ll be shown that a match was found instead of creating a duplicate. This makes it possible to finally clean up long-standing bills that could never be settled before.

Plaid bill settlement anchors its date window on the settle-through cursor instead of the outstanding occurrence — every recurring bill stops auto-settling after its first payment (KAN-1863)

Previously, when a recurring bill was paid automatically from a linked bank account, only the very next payment would be matched and marked as paid — every payment after that stayed unmatched, even though the money had already gone out. This showed up most often right after connecting a bank account for the first time, when several months of a recurring bill’s payment history come in at once: only the first one would get marked paid, and the rest were left looking overdue or unpaid. Now, every outstanding payment for a recurring bill is matched and marked as paid as soon as its payment history comes in, not just the first one. This means your bills and account balances stay accurate without you needing to go in and mark past payments as paid by hand. A small number of very tightly spaced duplicate charges may still need a quick manual confirmation, but this is rare and does not affect normal monthly or weekly bills.

matchEngine.ts Pass 3 carries the identical cursor-anchored window defect on the import-commit path (KAN-1870)

We fixed several issues in how the app matches your bank transactions to your recurring bills and scheduled payments. Previously, one unusually large past payment could occasionally cause the app to accept too wide a range of amounts as a match going forward, which could let the wrong transaction get linked to a bill. We also fixed a case where, during a single automatic sync, a bill could be counted as paid a second time for a payment it had already matched, and a case where importing bank transactions from a file could link a payment to the wrong upcoming due date on a bill’s schedule. With these fixes, the app now consistently identifies the correct amount and the correct due date when matching your transactions to your bills. No action is needed — these corrections apply automatically going forward.

computeLearnedRange’s outlier band blow-out at small n (KAN-1871)

When a bill had only a few recorded payments, a single unusually large or small payment could cause the app’s automatic matching to become too permissive, potentially matching unrelated transactions to that bill during bank sync or file import. This happened because the tolerance range the app used to decide whether a transaction belonged to a bill would widen dramatically when one payment looked very different from the others in a short history. The matching tolerance is now capped so that it can never stretch beyond a reasonable range of the bill’s expected amount, regardless of how few payments exist or how unusual one of them was. Bills with consistent payment histories are unaffected. The fix only narrows the range the app considers, so no transaction that was previously refused will start matching incorrectly.

Regression from PR #711: the in-run re-settlement guard its PR body documents (lastSettledOccurrence) was never implemented — a short-period bill can settle a not-yet-due occurrence (KAN-1875)

When the app automatically matched bank transactions to a recurring bill with a short payment cycle, such as a weekly or biweekly bill, it could sometimes mark a future payment as settled before it was actually due. This happened when multiple qualifying transactions arrived from your bank during the same update. After matching one transaction to the current payment, a second transaction dated just a few days later could incorrectly settle the following week’s payment early, advancing your bill schedule past a date that had not yet arrived. The app now tracks which payment was most recently matched for each bill during a single bank update and prevents a subsequent transaction from settling a future occurrence too soon. Only transactions that fall within the correct window around each payment date can now match to that payment.

Improvements

Mobile Accounts: native Plaid relink / re-auth repair (update mode) (KAN-754)

When a bank connection stops working, the Tovari mobile app now lets you fix it right where you are. Before, tapping Fix on an account that needed attention only showed a message telling you to sign in on the web, so you had to put your phone down and start again on a computer. Now tapping Fix opens your bank’s sign-in inside the app, and as soon as you finish, the account goes back to normal on its own — no restarting, and no duplicate copy of the account left behind. You can do the same thing from an account’s edit screen, whether you opened it from your account list or from that account’s transactions. If your bank sends you out to its own website or app and you can’t find your way back, Tovari says so plainly and still offers the web option as a backup.

iOS Plaid OAuth continuation blocker (KAN-754 follow-up) (KAN-861)

Connecting a bank account that uses secure sign-in (such as Chase or Capital One) now opens the bank’s login page directly within the iOS app. Previously, these connections redirected to Safari, which could leave you stranded outside the app with no clear way back. The in-app flow keeps you in context throughout the entire linking process, so you return to your accounts automatically after signing in with your bank. This improvement applies to both new bank connections and reconnections when a bank asks you to re-authorize. The change was verified against production before going live, and the app falls back gracefully to the previous browser-based flow if anything unexpected occurs.