Learn - History and Undo

Every resolve and delete is recorded, and almost every one can be reversed.

History and Undo

History is the fourth tab in the budget tracker, alongside Setup, Planner, and Reports. It lists every event you have resolved or deleted, with the controls to look up details, search, export, and reverse a single row at a time.

A row appears in History only when an event leaves the planner: when you resolve it (closing the event and posting its impact, see Matching and Resolving), or when you delete it from the planner toolbar. Tapping Mark Event as Paid on the planner does not create a History row, because Paid is a status flag on a still-scheduled event; flip it back to Scheduled in the planner if you change your mind.

What’s in a row

Each row is a snapshot of a single event at the moment it left the planner. The Item, Category, and Account names are recorded as they were on the day the row was created; rename the parent item later, and old rows keep the original name.

The columns are:

Action. Either Resolved (the event closed and moved here) or Deleted (it was removed from the planner).
Item. The name on the event when it was recorded.
Category and Account. The category and account on the event when it was recorded.
Amount. The amount that was applied. For an item with Transaction Tracking on, this is the sum of the transactions filed against the event. For an item with Transaction Tracking off, this is the planned amount the event closed at. For more on Transaction Tracking, see Items.
Due. The date the event was scheduled for.
Paid. Whether the event had been Marked Paid before it was resolved.
Action Date. When the row was created (when you resolved or deleted the event).

Rows are grouped by Action Date, most recent first. The grid loads more rows as you scroll.

Why are the names a snapshot rather than the current names? So your old History stays accurate to what actually happened. If you rename the Streaming category to Subscriptions this year, the Netflix rows from last year still read Streaming, because that is the category they were filed against at the time. The View dialog has a separate Item tab if you want to see what the parent looks like today.

The toolbar runs across the top of the page.

Filter by Status. Opens a small dialog titled Filter by Status with two options: Resolved and Deleted. Both are on by default. At least one must stay selected. Your choice persists across sessions on this device.

View History Item. Opens the Event History dialog for the selected row. The dialog has two segments: Event shows the snapshot recorded when the row was created (the historical name, amount, account, category, and the transactions filed against it). Item shows the parent item as it stands today, in case you want to compare. The Event tab is read-only; to change anything, undo the row first, edit the event in the planner, then resolve again. If the row is one of the few that cannot be reversed, the Event tab shows a short note starting Cannot undo: that explains the reason.

Export to Excel or CSV. Downloads the visible rows in either format. The visible-columns choice you set in Grid Settings carries over to the exported file, and any active Filter by Status or search applies as well, so the export contains exactly the rows you can see. The filename is your budget name plus the current date, for example MyBudget_history_2026-05-08.xlsx.

Grid Settings. Lets you hide and reorder columns.

Undo Action. Reverses the selected row. Sits on the right of the toolbar by itself. The button is enabled only when a row is selected and the row is reversible (see When Undo is blocked below).

Searching History

A Search field sits in the app’s top bar above every page in the budget tracker, and on the History tab it searches the rows server-side. It looks across the item name, the description or notes, the category and account names recorded on the row, the amount in any of its written forms (125, 125.00, $125.00), the due date and paid date as they were captured, and the status word Resolved or Deleted. The match is non-case-sensitive.

The Action Date is not part of search; the app filters on it directly through the date columns instead. Searching for “yesterday” or a calendar date string of the Action Date will not find rows, but searching for the formatted Due date (the value shown in the Due column) will.

The current Filter by Status setting still applies while you search: turn off Deleted and the search returns only Resolved matches. Clear the Search field to return to the full filtered list.

Undoing a row

Tap a row to select it, then tap Undo Action. A confirmation dialog opens, titled either Undo Resolution of or Undo Deletion of , depending on the row.

The dialog summarizes two outcomes:

Restore to Planner. The event will return to your planner, with its date, transactions, and any per-event edits intact.
A balance line, whose contents depend on what kind of row you are undoing.

What that means in practice: the event leaves History and reappears in the Planner in the same date slot it occupied before, the change record (notes, per-event amount or date overrides) is restored to active, any transactions filed against it become active again, and for a row that came from a deleted event, the bank-import hashes that were freed when you deleted are re-registered to that item so future bank pulls treat them as already known. The History row itself is removed from the History tab.

The balance line takes one of three shapes.

A resolved row with no transactions filed against it

The event was resolved without any transactions attached, so the resolve itself was the moment your account balance moved. The dialog shows a Reverse Balance Change toggle, on by default.

Leave it on (the default) and the undo restores the event and reverses the account balance change the resolve made. Turn it off if your bank already settled the difference some other way and you do not want a second adjustment. The balance you started the dialog with is what stays on the account.

Why is Reverse Balance Change on by default? Because for an event resolved with no transactions on it, the resolve itself was the balance-moving step (the app posted the planned amount to your account when you closed the line). Undoing that resolve undoes the only balance change the event ever made, so flipping the balance back is the natural pair. The toggle is there for the rare case where you already corrected the balance some other way.

A resolved row with transactions filed against it

The event resolved with transactions on it, and those transactions had already moved your balance the moment they were added (not at resolve time). The dialog shows no toggle. Instead, a single Account Balance line explains that the balance will not be adjusted; the transactions are restored as active and keep their original effect.

Why no toggle here? With transactions on the event, the resolve never moved the balance: the transactions did, when they were first added. Undoing the row brings the transactions back as active, and they keep doing the same work. A “reverse” toggle on top of that would subtract the same amount a second time. The dialog hides the toggle so the math stays right.

A deleted row

You deleted an event. Undo brings it back to the planner. The dialog shows no toggle. The Account Balance line notes that nothing about the balance changes, because deleting an event never moved the balance in the first place.

When Undo is blocked

In a few situations, the Undo Action button is disabled even with a row selected, or the dialog opens but the action fails on confirm. The row stays in History in every case; nothing is damaged. The View History Item dialog spells out the reason for any blocked row, in a line beginning Cannot undo:, so you can see which case applies before you act.

The button is disabled

The button stays disabled when one of the following is true. The cause is the same: the data needed to put the event back in the planner is no longer available.

The original item was deleted. With the parent item gone, the planner has nothing to attach the event to.
The original schedule was deleted, or its timing was changed. Resolving an event records the schedule’s exact timing at that moment. If the schedule has since been removed or its frequency, dates, or start or end dates were changed, the event no longer maps cleanly back into the schedule.
The original account was deleted, or the original category was deleted. The event needs both to be restored.
The row predates undo support. A few older rows from earlier app versions do not carry the data the planner needs to reverse them. New rows you create today are always reversible by these checks.

If you want one of these rows back, the only path is to recreate the event manually in the planner.

The button is enabled but the undo fails

There is one more case, which the button cannot detect ahead of time. It applies only to deleted rows whose bank-imported transactions were re-matched to a different event.

Here is the scenario. You delete an event whose bank-imported transactions were filed against it. Deleting an event releases the bank-import hashes for those lines so that future pulls can match them somewhere else (see Why the same imported line cannot be recorded twice on one item on the Transactions page). You then run Match again, and the same real-world transactions now match a different event in your budget. Later, you change your mind and want the original event back. The undo fails when you confirm, with a message saying the bank transactions have been matched to other events and asking you to remove those matches first. The History row stays put.

To resolve this, open the other event (the one that now holds those bank transactions), remove the conflicting transactions there, then come back to History and try the undo again.

Why does the app refuse to pick a side? The same real-world transaction cannot belong to two events at once: that would double-count it everywhere. The deleted event was the original home; another event has since claimed the transactions. Either choice can be the right answer, so the app waits for you to remove the wrong side rather than overwriting a deliberate match.

Who can undo

History is visible to anyone who can open the budget. Anyone with edit access (the budget owner or someone the owner shared the budget with as an editor) can undo a row. Viewers can browse, filter, search, and export, but the Undo Action button has no effect for them. To grant edit access, the budget owner uses Sharing; see Sharing.

How long History keeps your rows

History keeps every row for the current calendar year plus the previous five full years. Rows older than that are deleted automatically each time a new row is created. The cleanup is by age, not by count.

Once a row is purged, it is gone for good. Undo only works on rows that are still in History; there is no path to recover a row past the cutoff. In practice, the cutoff is far enough back that you will almost never see a row drop off naturally.

Why apply the same five-year window on every plan? Because History is a record-keeping feature, not a tier differentiator. Five years plus the current year is long enough to cover taxes, year-over-year comparisons, and any audit you would want to run from inside the app, and the cleanup keeps the History grid fast no matter how active your budget is. The rule is the same whether you are on the free plan or Premium, and it is the same on shared budgets too.

Quick reference

If you want to…	Do this
See everything you’ve resolved or deleted	Open the History tab.
Look up an event’s details	Tap the row, then View History Item.
Show only resolved rows or only deleted rows	Tap Filter by Status and toggle.
Find a specific row	Type into the Search field in the top bar.
Reverse a resolve	Tap the row, then Undo Action. Confirm the dialog.
Reverse a delete	Tap the row, then Undo Action. Confirm the dialog.
Reverse a resolve without changing the account balance	Turn the Reverse Balance Change toggle off in the dialog before confirming.
Restore an event whose bank transactions are now on another event	Open the other event, remove the conflicting transactions, then retry the undo.
See why a row cannot be undone	Open it with View History Item and read the Cannot undo: line.
Save your History to a file	Tap Export to Excel or CSV on the toolbar.
Hide a column you do not use	Tap Grid Settings.

Behind the scenes

This section describes how a few of the mechanics work in more detail. None of it is something you need to know to use History, but it answers questions that come up.

Snapshots vs. current. The Item, Category, Account, Amount, Due, and Paid values on a row are captured at the moment the row was created and never change after that. Renaming a category, deleting an account that was used on a closed event, or editing the parent item’s name has no effect on existing History rows. The View History Item dialog’s Item tab is the one place that shows the current parent item, so you can compare what the row recorded against what the item looks like today.

There is no per-row delete. The History page has no control to remove a single row by hand. The only deletion that happens is the age-based cleanup described above. Filtering, hiding columns, and exporting do not remove anything; they only change what you see.

Search uses a single index built per row. When a row is created, the app builds one searchable string from the row’s values (name, description, category, account, amount in several written forms, due and paid dates, and the Resolved or Deleted word) and stores it on the row. Searching is then a single full-text lookup against that index, which is why search returns even on a long History without delay. The Action Date is intentionally left out of the index: it depends on your timezone, and including it would make searches behave differently after a timezone change.

Undo of a transfer reverses two account balances. A transfer event has both a From and a To account, and the resolve moved both balances at once. Undoing a resolved transfer with no transactions on it (the Reverse Balance Change toggle on) reverses the move on both accounts in the same step. With transactions on the transfer, the transactions are restored as active and keep their effect, just like any other tracked event.

AI is not involved. Nothing about History or Undo calls an AI model. The grid, the search, the filter, the export, and the undo flow are all run on the app’s own backend against your budget’s data. The only AI feature elsewhere in the app is the optional Integrated AI assistance inside the Match Transactions flow on the planner; see Subscription for the full breakdown.

Undoing an undo. There is no second-level undo. If you reversed a row by mistake, you can resolve it or delete it again from the planner, which puts it back in History as a new row.

Matching and Resolving: the lifecycle that fills History.
Planner: where Undo restores events to.
Items: how Transaction Tracking decides which Amount lands in History.
Transactions: how bank-import hashes interact with deleting and undoing events.
Sharing: who can undo on a shared budget.
Subscription: where AI is and is not used in the app.