Learn - Transactions

Recording individual purchases and deposits when Transaction Tracking is on.

Transactions

A transaction in Essential Budget is an individual purchase, charge, or deposit saved inside an event whose item has Transaction Tracking turned on. Transactions are optional. You use them when you want to track several purchases or deposits against one planned amount, such as groceries, gas, dining, tips, or commissions.

This page covers how transactions are added, edited, and deleted in the app. Two things to know up front:

Transactions are not a top-level tab. They live inside individual events on the Planner. To work with the transactions on an event, you open that event.
Transactions only attach to events whose item has Transaction Tracking turned on. For items where the toggle is off (rent, Spotify, the gym), you resolve the whole event once the payment, deposit, or transfer appears in your bank account. There is no per-transaction list for those events. The toggle and what it does are described on Items.

For matching bank or uploaded payments, deposits, and transfers to planned events, including the way an event with Transaction Tracking on resolves when its transaction total reaches the planned amount, see Matching and Resolving.

Where transactions live

When an item has Transaction Tracking on, each event the item produces can collect transactions during that event’s period. The transactions for an event live inside the Edit Item Event dialog: open the Planner, tap an event row to select it, then tap Edit Event on the toolbar (or double-tap the row).

The dialog has a Transactions section near the bottom, with a progress bar showing how much of the planned amount has been recorded. The section is only present when the item has Transaction Tracking on. For items where the toggle is off, and for Transfer items, the dialog does not show a Transactions section. Those events resolve as whole events instead.

The same Transactions section is where bank-imported or file-uploaded rows show up after they are matched to an event whose item has Transaction Tracking on. There is no separate list for imported ones. Once matched to that kind of event, a bank or file transaction sits in the event’s transaction list alongside any you typed by hand, and the running total at the top of the section adds them all together.

Adding a transaction by hand

Open the event. In the Transactions section header, tap the Plus button (aria label Add transaction). An inline form opens with three fields:

Date. Defaults to today. The app does not block future dates, so a same-day-as-tomorrow purchase you want to pre-record is allowed.
Amount. What the transaction was. Must be greater than zero. You can enter 5 or 5.00; the app stores the same value either way.
Description (optional). Free text up to 100 characters. What you type here is what appears in the transaction’s row and in History after the event resolves.

Tap Save transaction (the floppy-disk icon in the top-right of the form). The transaction is added to the list, the running total at the top of the section updates, and the linked account’s balance moves by the transaction’s amount as soon as you save the dialog. Tap Cancel (the X icon next to it) to discard the in-progress entry without recording it. Pressing Enter while the form is focused saves; pressing Escape cancels.

Each event holds up to 500 transactions. Past that, the Add transaction button is disabled and the section shows the message Maximum transaction limit reached (500). The cap is per event, not per item or per account; it resets the moment the event resolves into History and the next event takes over. In practice this only matters for accounts with very heavy weekly volume; most events finish a period with a handful of transactions or fewer.

Why does the balance move now and not when the event resolves? Because a saved transaction is used when the purchase, charge, or deposit has already happened. The app updates the account balance when you save the transaction so the running balance keeps up with your bank. Resolving the event later files the event to History; it does not move the same transaction a second time.

Editing a transaction

Two ways to start an edit: double-tap the transaction’s row, or tap the pencil icon (aria label Edit transaction) on the row. Either opens the same inline form, pre-filled with the transaction’s existing values. Edit the field you want, tap Save transaction, and the row updates with the new values. Save the dialog to save the change.

This applies whether the transaction was typed in by hand or arrived from a bank match. Inside this dialog the two are recorded the same way and edited the same way.

Why is a bank-imported transaction editable here at all? Because the description the bank sends is sometimes the merchant’s terminal code rather than the name you would recognize (“SQ* MAINSTREET PIZZA” instead of “Mainstreet Pizza”), and you may want to clean it up so History reads cleanly later. Editing the amount or the date is also possible, but treat that as a last resort: your bank’s record is the one to trust, and an edit here makes the app’s record disagree with the bank’s. The next bank pull will not overwrite your edit, because the duplicate check that keeps the same imported transaction from landing twice (described below) is keyed by the original bank values, not by what is on the row right now.

Deleting a transaction

Tap the trash icon on the transaction’s row (aria label Delete transaction). The row is replaced by an inline confirmation that asks Delete {amount} transaction? with a Cancel and a Delete button. The delete only fires when you tap Delete; tapping Cancel restores the row.

After you confirm and save the dialog, the transaction is removed, the running total drops by the deleted amount, and the linked account’s balance reverses by the same amount.

If the deletion makes the running total fall below the planned amount on an event that had already resolved, the event stays in History. To bring it back to the Planner for further work, open the History tab and use Undo Action on its row. The full picture of Undo and what can fail is on History and Undo.

Why does deleting a bank-imported transaction free it up to land again? So you can correct a wrong match. If Match Transactions dropped a $63.41 charge onto Groceries when it should have been on Dining, you delete it from Groceries and the next pull (or the next file upload) sees that hash as untaken on Groceries and offers it as a match again, this time so you can route it correctly. If you don’t want it to come back, route it where it belongs first; the duplicate check will then block re-import for that item.

Bank-imported and uploaded transactions

Bank exports and Plaid call each bank row a transaction. In Essential Budget, that row becomes a saved transaction only when it is matched to an event whose item has Transaction Tracking on. When it is matched to an item with Transaction Tracking off, it resolves that whole event instead and does not appear in a Transactions section.

A saved transaction can enter an event with Transaction Tracking on three ways: you typed it in by hand, you pulled it from a linked bank through Plaid, or you uploaded it from a CSV, TSV, or TXT file. The first is described above. The other two flow through the Match Transactions dialog: tap Match Transactions on the Planner toolbar to open it, review the suggested matches, and confirm them.

Once matched to an event with Transaction Tracking on, a bank-imported transaction is indistinguishable in the dialog from one you typed in. It uses the same row, the same edit gesture, the same delete gesture, and the same place in the running total. The practical difference is that the bank set the amount and date, so editing those values puts the app out of step with the bank’s record. The description is the safest field to change.

Pending bank charges (a Costco swipe that has not posted yet, an Amazon authorization hold) are skipped on the way in. The app waits for the bank to post the charge before pulling it. If you can see something in your bank’s mobile app but not in Match Transactions, that is usually why; tap Match Transactions again the day after it posts.

For the bulk-matching flow itself (how the app suggests matches, how to deselect a wrong one, what happens when an event with Transaction Tracking on reaches the planned amount), see Matching and Resolving. For Plaid setup and unlinking, see Bank Linking. For CSV / TSV / TXT uploads, see File Uploads.

Why the same imported transaction cannot be recorded twice on one item

Every transaction the app receives from a bank pull or a file upload carries an import hash before it is matched. Plaid transactions are hashed from the cleaned-up date, description, and signed amount. File uploads use an existing hash column when the file has one; otherwise the app hashes date, description, amount, and balance when a balance column is present.

After you confirm a match, the hash is stored on the matched item. On the next bank pull or file upload, a transaction with the same hash is skipped for that same item. Re-uploading the same CSV (because you were not sure if the first one went through) does not add the same imported transaction to the same item again. A repeated Plaid pull over the same date range also does not add it again.

The check is per item, not per budget or per account. If you matched the same imported transaction to the wrong item, delete it from that event and match (or add) it where it belongs. The hash is removed from the wrong item when you delete and registered on the right item when you match again, and from then on neither item will pick up a duplicate.

Manual transactions (the ones you typed in) carry no hash. The app does not treat two identical-looking $5 cash purchases as duplicates; it lets you record both. The duplicate check works this way on purpose: bank and file imports get the safety net because banks and files can be pulled more than once; manual entries do not, because two real cash purchases that look identical are a normal thing to record.

Why use an import hash? Because banks and files can be pulled more than once. The hash makes re-uploads and repeated bank pulls safe in the common case while still letting you correct a wrong match deliberately.

What edits to a bank-imported transaction saved inside an event with Transaction Tracking on do, and do not, do to the hash:

Editing the description, amount, or date on a bank-imported row inside this dialog updates the row, but the original import hash stays attached. The next bank pull will still skip the same imported transaction for that item, even though the row’s current values no longer match what the bank reported. Your edit “wins” until you delete the row.
Deleting the row removes the hash too, so the same bank transaction can be re-imported on the next pull.
Resolving the event keeps the hash registered, so a re-pull of the same date range does not offer the same transaction against the resolved event.
Deleting the whole event from the planner removes the hashes for its bank-imported transactions, freeing them to be matched against a different event next time. If you change your mind, Undo Action on the deleted row in History restores the hashes. Undo can fail if you matched the same bank transaction to a different event in the meantime; see When Undo is blocked for the full failure catalog.

How transactions move your balance

The amount field on a transaction is unsigned. The direction the linked account moves is set by the item’s category type. Transactions in the Transactions section are for Income and Expense items; Transfer items do not use Transaction Tracking and resolve as whole events.

Income category: the linked account’s balance goes up by the transaction’s amount.
Expense category: the linked account’s balance goes down by the transaction’s amount.

This is the same rule whether the transaction came from your hand, from a bank match, or from a file upload. The category and the linked account live on the item, not on the individual transaction; you change them by editing the item, not the event. The category cell inside the Edit Item Event dialog shows a small lock icon to make this explicit.

If the running balance in the app stops matching the bank’s running balance over time, reset it by editing the account’s Current Balance directly. The app does not silently change the balance for you, because that could mask a transaction the app missed. Both paths are described on Accounts.

For the rules that govern category types, see Categories. For the broader concept of items and events that transactions sit on, see Concepts.

Who can do what

Transactions follow the budget’s permission model.

Owner and Editor. Add, edit, and delete transactions on any event whose item has Transaction Tracking on. Save the dialog to finish.
Viewer. The Edit Item Event dialog opens with the title View Item Event. The transaction list is visible, but the Add button, the pencil icon, and the trash icon are all hidden, and double-tapping a row does nothing. To make changes, ask the budget owner to grant edit access; see Sharing.

The larger Match Transactions flow has a separate rule: free editors on a Plaid-linked budget cannot use Match Transactions at all. Inside the Edit Item Event dialog, that rule does not apply; an editor can still add and delete by hand on any event whose item has Transaction Tracking on regardless of subscription state.

AI is not involved here

Typing a transaction by hand, editing one, deleting one, and the import-hash duplicate check are all run locally and on the app’s own backend. No AI model is called and no transaction text is sent anywhere except the app’s database. The AI features that exist live one layer up, inside the Match Transactions flow, where you can opt into Integrated AI assistance for matching. See Subscription for the full breakdown of where AI is used in the app and what data is sent.

Quick reference

If you want to	Do this
Add a manual transaction	Open an event whose item has Transaction Tracking on, tap the Add transaction button in the Transactions section, fill in Date and Amount (and optional Description), tap Save transaction, save the dialog
Edit a transaction (manual or bank-imported)	Open the event, double-tap the row or tap the pencil icon, edit in the inline form, tap Save transaction, save the dialog
Delete a transaction	Open the event, tap the trash icon on the row, tap Delete in the inline confirmation, save the dialog
Match bank or uploaded transactions to events	Tap Match Transactions on the Planner toolbar to open the Match Transactions dialog. See Matching and Resolving
Track each purchase against a planned amount	Open the item, turn Transaction Tracking on, save. See Items
Re-match a bank transaction you sent to the wrong event	Delete the row from the wrong event, then run Match Transactions again. The duplicate check releases the hash on delete.
Reset an account whose running balance stopped matching the bank	Open the account, edit Current Balance, save. See Accounts

Items: the Transaction Tracking toggle is what makes the Transactions section appear on an event.
Matching and Resolving: how bank-imported and uploaded transactions get matched to planned events, and how an event with Transaction Tracking on resolves when its transactions reach the planned amount.
Accounts: how transactions move your account balance, and how to reset Current Balance when the in-app number stops matching the bank’s.
Categories: the category type that drives the direction of every transaction.
Bank Linking: connecting an account to your bank through Plaid so you can pull bank transactions with Match Transactions.
File Uploads: adding transactions from a CSV, TSV, or TXT file.
History and Undo: where resolved events with their transactions go, how to bring one back to the Planner, and what can fail when you Undo a deleted event whose bank transactions were re-matched in the meantime.
Sharing: who can edit transactions on a shared budget.
Subscription: where AI is and is not used in the app.