--- title: Transactions description: How real money movements are recorded in Essential Budget. Adding, editing, and deleting transactions inside the Edit Item Event dialog, and how the app keeps the same imported line from being recorded twice. subtitle: Adding, editing, and deleting the real money movements behind your planned events. sidebar: order: 25 section: Day to day canonical_html_url: https://eb.app/learn/transactions/ --- # Transactions A *transaction* is a real movement of money: $63.41 at the supermarket, your $3,400 paycheck, the $1,800 rent autopay. Recording a transaction moves the linked account's balance immediately, in the direction set by the linked item's category type (Income adds, Expense subtracts, Transfer moves money between two of your accounts). The app does not delay the balance change until the budget period closes; the bank already moved the money in real life, and the app's number follows. 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 on individual events on the **Planner**, attached to the planned line they spent against. To work with the transactions on an event, you open the 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 mark the line paid or resolve it once the bill goes through, with no per-transaction list. The toggle and what it does are described on [Items](https://eb.app/learn/items.md). For the matching of bank-imported transactions to planned events (and the resolve-on-threshold mechanic that turns matched transactions into a closed event), see [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md). --- ## Where transactions live When an item has **Transaction Tracking** on, each event the item produces accumulates transactions until the planned amount is reached. 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 the recorded transactions have spent down. The section is only present when the item has Transaction Tracking on. For items where the toggle is off, and for Transfer items (which always settle as one event), the dialog does not show a Transactions section. There is nothing to record in those cases; you mark the event paid or resolve it whole. The same Transactions section is where bank-imported transactions show up after a match. There is no separate list for them. Once matched, a bank 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 the money already left your account in real life. The app's job is to keep its picture of your account in step with the bank, so the running balance you see is the balance that is actually there. Resolving an event is a separate step that closes the line and sends the record to History; it does not move money on its own. --- ## 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 commit 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 is the source of truth for what actually happened, 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 dedup that keeps the same imported line 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](https://eb.app/learn/history-and-undo.md). > **Why does deleting a bank-imported transaction free it up to land again?** > So you can correct a wrong match. If Match 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 dedup will then block re-import for that item. --- ## Bank-imported and uploaded transactions A transaction can land in the app 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** on the **Planner** toolbar to open it, review the suggested matches, and confirm them. Each confirmed match becomes a transaction on the event it was matched to, sitting in the same Transactions section described above. Once matched, 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 only practical difference is upstream: 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 authorisation 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, that is usually why; tap Match 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 a tracked event's matches reach the planned amount), see [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md). For Plaid setup and unlinking, see [Bank linking](https://eb.app/learn/bank-linking.md). For CSV / TSV / TXT uploads, see [File uploads](https://eb.app/learn/file-uploads.md). --- ## Why the same imported line 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 item that received the transaction. 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 line 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. Dedup is asymmetric 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 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 line 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 line 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 bring the line back as a phantom match against the closed 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 line to a different event in the meantime; see [When Undo is blocked](https://eb.app/learn/history-and-undo.md#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: - **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. - **Transfer** category: the **From Account** goes down and the **To Account** goes up by the same 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 drifts away from the bank's running balance over time, you re-anchor 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](https://eb.app/learn/accounts.md#when-the-app-and-your-bank-disagree). For the rules that govern category types, see [Categories](https://eb.app/learn/categories.md#the-three-types-and-the-sign-rule). For the broader concept of items and events that transactions sit on, see [Concepts](https://eb.app/learn/concepts.md). --- ## Who can do what Transactions follow the budget's permission model. - **Owner and Editor.** Add, edit, and delete transactions on any tracked event. Save the dialog to commit. - **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](https://eb.app/learn/sharing.md). A separate gate applies to the bulk Match Transactions flow: free editors on a Plaid-linked budget cannot Match at all. Inside the Edit Item Event dialog, that gate does not apply; an editor can still add and delete by hand on any tracked event regardless of subscription state. --- ## AI is not involved here Typing a transaction by hand, editing one, deleting one, and the import-hash dedup 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](https://eb.app/learn/subscription.md#how-ai-works-in-this-app) 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 the tracked event, 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** on the **Planner** toolbar to open the **Match Transactions** dialog. See [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md) | | Track each spend against a budget line | Open the item, turn **Transaction Tracking** on, save. See [Items](https://eb.app/learn/items.md) | | Re-match a bank line you sent to the wrong event | Delete the row from the wrong event, then run Match again. The dedup releases the hash on delete. | | Re-anchor an account whose running balance drifted from the bank | Open the account, edit **Current Balance**, save. See [Accounts](https://eb.app/learn/accounts.md#when-the-app-and-your-bank-disagree) | --- ## Related pages - [Items](https://eb.app/learn/items.md): the **Transaction Tracking** toggle is what makes the Transactions section appear on an event. - [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md): how bank-imported and uploaded transactions get matched to planned events, and how a tracked event resolves when its transactions reach the planned amount. - [Accounts](https://eb.app/learn/accounts.md): how transactions move your account balance, and how to re-anchor when the in-app number drifts away from the bank's. - [Categories](https://eb.app/learn/categories.md#the-three-types-and-the-sign-rule): the category type that drives the direction of every transaction. - [Bank linking](https://eb.app/learn/bank-linking.md): connecting an account to your bank through Plaid so Match can pull bank transactions. - [File uploads](https://eb.app/learn/file-uploads.md): adding transactions from a CSV, TSV, or TXT file. - [History and Undo](https://eb.app/learn/history-and-undo.md): 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 lines were re-matched in the meantime. - [Sharing](https://eb.app/learn/sharing.md): who can edit transactions on a shared budget. - [Subscription](https://eb.app/learn/subscription.md#how-ai-works-in-this-app): where AI is and is not used in the app. --- ## About this document This is a markdown mirror of [https://eb.app/learn/transactions/](https://eb.app/learn/transactions/). The HTML version is the canonical form. This file exists so AI/LLM tools can ingest the content without HTML parsing.