---
title: Concepts
description: The handful of words Essential Budget uses, defined once. Item,
  event, schedule, transaction, category, and account are the only terms you
  need before reading anything else here.
subtitle: The words you need before reading anything else here.
sidebar:
  order: 10
  section: Start here
canonical_html_url: https://eb.app/learn/concepts/
---

# Concepts

This page defines the small vocabulary the rest of the guide depends on. If a word in another page is unfamiliar, you can find it here. Six terms cover almost everything: item, event, schedule, transaction, category, and account. They are introduced in italics on first use and pinned to a small running example so each one has something concrete to attach to.

You do not need to memorize them. Read the page once, and the rest of the guide will read cleanly.

---

## Item

An *item* is a template you add to your budget. Each item has a schedule that produces dated events on your planner.

Most items are recurring: rent, your paycheck, a phone bill, a streaming subscription, a weekly grocery budget. Some are one-time, useful for a planned purchase, a tax refund, or a security deposit. When you add an item, you choose between **One-Time** and **Recurring** at the top of the schedule section. A one-time item produces exactly one event and stops. A recurring item produces a new event on each scheduled date, indefinitely.

Think of an item as the template. You set the template up once, and you mostly deal with the events it produces from then on. Full treatment is on the [Items](https://eb.app/learn/items.md) page.

## Event

An *event* is one specific occurrence of an item, on one specific date. Rent due May 1st is an event. Rent due June 1st is a separate event of the same item. Your Tuesday grocery line is one event; next Tuesday's is another.

Events are what you actually see on the **Planner**. Each row in the Grid view, each entry in the Calendar view, is an event. Marking one paid, dragging one to a different date in the Calendar view, resolving one to History, all of these are operations on a single event. The three states an event can be in (Scheduled, Paid, Resolved) and how it moves between them are explained on [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md#the-three-states-of-an-event).

Each event also carries a **Payment #** that counts forward from its schedule's starting number (Payment #1, #2, #3, ...). This is useful when you are tracking a series with a known total, like a car loan or a financed purchase; see [Numbered events](https://eb.app/learn/items.md#numbered-events) on the Items page for the **First payment #** control.

## Schedule

A *schedule* is the rule on an item that decides when its events appear. It has two parts: whether the item is one-time or recurring, and (if recurring) how often it repeats. The frequency choices are **Weekly**, **Bi-weekly**, **Monthly**, **Quarterly**, **Semi-annually**, **Annually**, and a custom **Every ...** option for intervals that do not fit the standard list.

Most items have a recurring schedule (rent monthly, paychecks bi-weekly, groceries weekly). One-time schedules are useful for things like a single planned purchase or an annual fee that does not roll forward. The schedule editor, including multiple schedules per item and the per-occurrence override, is covered on [Items](https://eb.app/learn/items.md#schedules-when-the-item-happens).

## Transaction

A *transaction* is a real movement of money: $63.41 at the supermarket on Monday, your $3,400 paycheck on Friday, the $1,800 rent autopay. Transactions can land in the app three ways: you typed them in, you pulled them from a linked bank through Plaid, or you uploaded a CSV, TSV, or TXT file.

The defining thing about a transaction is that it is a fact, not a plan. As soon as a transaction is recorded against an account, that account's balance changes by the transaction amount, in the direction set by the item's category (Income adds, Expense subtracts, Transfer moves money between two of your accounts). The app updates the balance the moment the transaction lands, not at month-end or when you resolve the event; the rationale lives on [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md#the-three-paths-from-scheduled-to-resolved). You can also edit an account's **Current Balance** directly if the app's running total ever drifts away from your bank's; that is a separate re-anchoring action, not something the app does silently for you. Full treatment of the three entry paths is on [Transactions](https://eb.app/learn/transactions.md).

## Category

A *category* is the bucket an item lives in. Each category has a **Type**, which is one of three: **Income**, **Expense**, or **Transfer**. The type is what tells the app which way the money moves when a transaction lands on an item in that category.

- **Income** raises the account balance.
- **Expense** lowers it.
- **Transfer** moves money between two of your accounts. The item picks a **From Account** and a **To Account**; one balance goes down, the other goes up by the same amount.

Categories also nest. When you create a category, you can leave its **Parent Category** as **None (Top-level)** or pick another category to nest it under. So you might have **Housing** at the top with **Rent** and **Utilities** as sub-categories underneath. The nesting is a way to organize your own categories; it does not change the math. There are no built-in "Income" or "Expense" categories the app creates for you. Every category in your budget is one you created, with a type you picked.

The Categories view in the Setup tab groups your categories under three section headers (**Income**, **Transfers**, **Expenses**, in that order), one per type, so the tree you see is shaped by which type you assigned. The full set of rules around types, sign, nesting, and the cap of 250 categories per budget is on [Categories](https://eb.app/learn/categories.md#the-three-types-and-the-sign-rule).

## Account

An *account* is one place your money sits. The app's account types are **Checking** and **Savings**. If your real-world account does not fit either label exactly (a credit card, a cash envelope, an investment cash sleeve), pick whichever type feels closest; the type is mostly a label, since the direction of every balance change comes from the item's category, not the account. Each account has a starting balance, which you set when you add the account, and a running balance, which is the starting balance plus every transaction that has been recorded against it since.

Accounts can be linked to your bank through Plaid, in which case Match can pull real transactions from the bank. Or they can be kept manual, in which case you enter transactions yourself. The two can mix in the same budget: one account linked, another manual.

If the app's running balance ever drifts away from your bank's, you re-anchor by editing the account's **Current Balance**. Your bank is the source of truth; the number in the app follows it. Both behaviors (the automatic update on each transaction, and the manual re-anchor when the two diverge) are covered on [Accounts](https://eb.app/learn/accounts.md#how-the-balance-changes).

---

## A few words for related ideas

These come up in other pages and round out the vocabulary.

- ***Budget.*** A workspace that holds one set of accounts, items, categories, planner, and history. Most people only need one. Switching, creating, sharing, and deleting are covered on [Budgets](https://eb.app/learn/budgets.md).
- ***Resolved.*** An event that has been confirmed and moved off the Planner into History. An event resolves three ways: a bank transaction is matched to it, a Transaction Tracking item's transactions reach the planned amount, or you tap **Resolve item** yourself. The three paths are listed on [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md#the-three-paths-from-scheduled-to-resolved).
- ***Mark Event as Paid.*** A toolbar button that flags an event as paid for your reference. It does not move the event off the Planner and does not change a balance. Use it when you have already paid something but the bank transaction has not shown up yet. See [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md#the-three-states-of-an-event).
- ***Scheduled.*** The default state of an event: on the Planner, waiting for its date.
- ***Transaction Tracking.*** A toggle on an item. When on, the item's events accept individual transactions and accumulate against the planned amount; this is what you want for spending you build up across many small purchases (groceries, gas). When off, one matched transaction or one tap of **Resolve item** is enough to resolve the event; this is what you want for fixed bills (rent, Spotify). Detailed behavior is on [Items](https://eb.app/learn/items.md#transaction-tracking-one-transaction-or-many).
- ***Auto Pay.*** A flag on an item that says "the bank takes this on its own." It is a label for your reference, not an automation; the app does not pay anything for you. See [Items](https://eb.app/learn/items.md#auto-pay-is-a-label-not-an-automation).
- ***Match.*** Linking a real bank transaction to the planned event it represents. The toolbar button is **Match**, and the dialog it opens is **Match Transactions**. The full flow is on [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md).
- ***Resolve.*** Closing an event and sending it to History. Done by matching a transaction, by a tracked item reaching the planned amount on its own, or by tapping **Resolve item** on the toolbar.
- ***History.*** The tab where every Resolve and every Delete is recorded. Each row has an **Undo Action** button. See [History and Undo](https://eb.app/learn/history-and-undo.md).
- ***Pay period.*** A grouping the Planner can use to break events into headers, alongside week, month, quarter, and year. The default is **Pay Period Headers**, and the boundaries are derived automatically from when your income lands. Pay period is a display option; events are dated to specific days, not to a period. The full list of grouping options is on [Planner](https://eb.app/learn/planner.md#headers-and-grouping).

> **Why "Match" and "Resolve," not "Reconcile"?**
> If you have used another budgeting app, you may be looking for a "Reconcile" button. There isn't one, on purpose. In tools like YNAB, Quicken, or Mint, "reconcile" usually means "compare the app's balance against the bank's balance and adjust the gap." That is not what this app's matching does. Matching here pairs each new bank transaction with the planned event it represents, one by one; it does not adjust your balance to a target. The two ideas are different enough that they deserve different words, so the app uses **Match** for the pairing and **Resolve** for closing the event. If your app and bank balances ever drift apart, you re-anchor directly on the account's **Current Balance** instead, which is covered on [Accounts](https://eb.app/learn/accounts.md#when-the-app-and-your-bank-disagree).

> Most of these have a longer treatment on their own page. The next page worth reading is [Matching and Resolving](https://eb.app/learn/matching-and-resolving.md), where the day-to-day flow is described end to end.

---

## How the words fit together

<!-- SCREENSHOT: Annotated planner Grid view with callouts pointing to one of each: an item name, a single event row, the schedule frequency tag, a transaction nested inside an event, the category column, the account column, and the running balance column. -->

You set up an **item** with a **schedule**, which produces **events** on your **Planner**, dated against your **accounts** and sorted by **category**. Real **transactions** match against events to **resolve** them, sending the record to **History** with your account balance updated.

If you can read that sentence and have a rough picture for each bolded word, you are set.

---

## About this document

This is a markdown mirror of [https://eb.app/learn/concepts/](https://eb.app/learn/concepts/).
The HTML version is the canonical form. This file exists so AI/LLM
tools can ingest the content without HTML parsing.
