Learn - Items

The things you set up once, like rent, paychecks, and the gym.

Items

An item is the template for something you plan: rent, your paycheck, a phone bill, a streaming subscription, a weekly grocery budget. You write the rule once (“Rent, $1,800, on the 1st of every month, from Checking”) and the app produces a sequence of dated events on your Planner.

Items live as a segment of the Setup tab, alongside Accounts and Categories. Open the Setup tab and tap Items in the segment at the top to see the list. Tap the add button on the toolbar to open the Add Item dialog. Tap any item in the list to open it for editing or, if you have view-only access, for reading.

When you change an item, the change applies to every future event the item produces. Past events that have already been resolved into History are kept as-is, with their own snapshot of the name, amount, account, and category at the moment they were resolved. Renaming Spotify to Streaming services later does not rewrite the older History rows.

If you only want to change one specific occurrence (rent went up only this month, your paycheck arrived a day late), open the event in the planner and edit it there instead. The dialog you land in is Edit Item Event, and your change applies just to that one occurrence; the rest of the schedule keeps running as before.

A budget can hold up to 250 items. The cap is the same on the free tier and on Premium. When you reach it, the toolbar shows “Item limit reached (250/250 per budget).” and the add button stops opening the dialog; delete an item you no longer need to make room.

What’s on an item

The form has these fields, in order. They are the same whether you are creating a new item or editing an existing one.

Item Name. A short label that appears in the planner, the Reports tab, and History. Up to 50 characters.
Bank Transaction Merchant Name. Optional text that helps the app match bank transactions to this item. Up to 50 characters.
Category. Pick from the categories you set up. The category’s Type (Income, Expense, or Transfer) is what tells the app which way the money moves.
Account. The account the money lands in (for income) or comes out of (for expenses). For a Transfer category, the field splits into From Account and To Account instead, and the two cannot be the same account.
Auto Pay. A label, not an automation. See below.
Transaction Tracking. An optional toggle for items where you want to record each purchase or deposit inside the event. Hidden for Transfer items. See below.
Notes (optional). Free-form text for anything else. Up to 1,000 characters.
Schedules. One or more rules for when the item produces events. Most items have a single schedule.

Why is Bank Transaction Merchant Name a separate field from the item name? Your bank’s merchant string is rarely what you want to call the item. “AMZN MKTP USB5K2L9X”* on the statement is “Amazon” in your head. Keeping the two apart means you name the item naturally and the matcher still has the bank’s exact string to work with when a transaction comes in. If you have not linked a bank account, the field is just a typing hint you can fill in to help future imports match faster.

Once any account in this budget is linked through Plaid, the Bank Transaction Merchant Name field becomes display-only across every item, even items whose own account is not the linked one. The value is filled in for matched items from the linked bank’s recurring-stream merchant data, and stays where it was for the rest. To go back to typing your own hint, the budget would need to have no Plaid linkage on any account.

Schedules: when the item happens

A schedule is the rule that produces events. Each item has at least one schedule, displayed inside an accordion at the bottom of the Add Item dialog. To add another, tap Add Schedule beneath the existing schedules. To remove one, tap the trash icon on its accordion header.

At the top of a schedule, choose One-Time or Recurring.

A One-Time schedule produces a single event. You set the Amount and the On Date. If Transaction Tracking is on, you also set an End Date so the app knows the period that event covers. Useful for a planned one-off like an annual fee, a tax payment, or a single deposit.

A Recurring schedule produces a new event on a repeating cadence. You set:

Amount. What you expect each occurrence to cost (or pay).
Frequency. One of Weekly, Bi-weekly, Monthly, Quarterly, Semi-annually, Annually, or Every … for an interval that does not fit the standard list. Custom intervals run from 1 to 99 weeks or months.
On the dates (monthly cadences) or On weekdays (weekly cadences). For monthly, pick one or more days from 1st through 31st, plus a special Last entry that resolves to the actual last day of each month (so February still works). For weekly, pick one or more weekdays.
Start date. When the schedule’s first event lands.
End date. Optional. When set, the schedule stops producing events after this date.
First payment #. Optional. The number the schedule’s first event is labeled with. Defaults to 1; set higher when you are picking up a sequence that started outside the app (a car loan you are five payments into, a mortgage, a treatment plan).

A few examples that map to common patterns:

Pattern	Schedule settings
Rent on the 1st, every month	Recurring, Monthly, On the dates 1st
Paycheck every other Friday	Recurring, Bi-weekly, On weekdays Fri
A fee on the last day of each month	Recurring, Monthly, On the dates Last
Twice a month, the 1st and the 15th	Recurring, Monthly, On the dates 1st and 15th
Weekly groceries every Tuesday	Recurring, Weekly, On weekdays Tue
A single deposit on June 15th	One-Time, On Date 2026-06-15

Events appear on the planner as far ahead as the planner’s forecast horizon reaches. The default horizon is one year and is adjustable from the planner toolbar. See Planner for the control.

Numbered events

Every recurring schedule numbers the events it produces, sequentially. The first event opens as Payment #1 (or Payment #2, #3, and so on if you set First payment # to a higher starting value); each subsequent event counts up by one. The number appears at the top of the Edit Item Event dialog, which is useful when you are tracking a series with a known total: a car loan, a mortgage, a financed purchase, a course of treatments. The label is Payment # regardless of whether the item is income or expense.

Each schedule on an item keeps its own counter, so a second schedule on the same item starts again from its own First payment #. To stop the numbering at a specific count, set the schedule’s End date so it produces events through the date of the final payment.

More than one schedule on an item

Most items have a single schedule. Some don’t, and the app supports multiple schedules on the same item:

A paycheck whose timing changed mid-year. The original schedule was every other Friday, which you cap with an end date. The new schedule is every other Wednesday starting on a later date. Two schedules, one item, the History stays unified under the same name.
A bill that lands twice a month on different patterns that don’t fit a single schedule.

To add another, save the first schedule, then tap Add Schedule at the bottom of the Schedules section. To remove one, tap the trash icon on its accordion header.

Editing a single occurrence on the planner

Schedule rules are templates, not commitments. To change just one event (rent went up this month, your paycheck arrived a day late, you only need a half-amount this week), tap the row in the planner instead of opening the item template. The dialog that opens, Edit Item Event, lets you override the amount, date, account, category, or notes for that one occurrence. The rest of the schedule keeps producing events at the original values.

The override is tied to the schedule’s position. If you later change the parent schedule’s timing (frequency, dates, weekdays, start, or end), the per-event override is cleared along with everything else attached to that schedule. The form warns you with a yellow note before you save the timing change, so you can step back if you want to keep the override.

Changing the parent item’s name, category, account, or amount does not touch your per-event overrides. Those flow forward only.

Transaction Tracking: one transaction or many?

Transaction Tracking is optional. Turn it on only for items where you want to record individual purchases or deposits inside each event. The toggle lives on the item, so it covers every event the item produces, current and future. Transfer items do not have it.

Why is Transaction Tracking off by default? Most fixed bills do not need transaction-by-transaction tracking. Rent, a subscription, or a fixed paycheck can be resolved as one whole event once the payment or deposit appears in your bank account. Transaction Tracking is for categories where the planned amount is a budget you spend down or build up across several smaller purchases or deposits. Starting it off keeps the simple case simple.

When Transaction Tracking is off

Each event is handled as a whole. A matched payment, deposit, or transfer from a bank pull or file upload can resolve it, or you can tap Resolve Event on the planner toolbar.
The full planned amount is the unit when you resolve by hand: Resolve Event applies the planned amount and moves the event to History.
Best for fixed bills, like rent, your phone bill, Netflix, or the gym.

When Transaction Tracking is on

Each event accepts multiple transactions, accumulating against the planned amount. You can add them by hand inside the Edit Item Event dialog, by matching a linked-bank pull, or by uploading a CSV/TSV/TXT file.
During a Match Transactions session, an event resolves on its own once the running total reaches the planned amount. If the total stays under the planned amount when the period ends, the event stays on the planner until you resolve it yourself.
Best for spending you build up across many purchases, like groceries, gas, or dining out.

For the matching rules, see Matching and Resolving.

What happens when you turn Transaction Tracking on

With Transaction Tracking on, one event covers one continuous period. Two events in the same period would make a purchase ambiguous (which event does today’s $43 grocery purchase count toward?), so the schedule is reduced to a single occurrence per period when you flip the toggle on.

If the schedule was monthly on the 1st and the 15th, turning Transaction Tracking on collapses it to monthly on the 1st: the rest of the dates are dropped from the schedule. The same happens for weekly schedules with multiple weekdays selected: the schedule keeps the first selected weekday and drops the rest. The collapse runs across every schedule on the item.

If you want both halves of the period to have their own event with Transaction Tracking on, create a second schedule explicitly. The collapse only happens to a single schedule’s date or day list.

Turning the toggle back off does not restore the dropped dates. The schedule keeps the single occurrence it was reduced to; if you want the full pattern back, edit the schedule’s date or weekday list yourself.

Transfer items: two accounts, one record

Picking a category whose Type is Transfer changes the form: the single Account field splits into From Account and To Account, and the Transaction Tracking toggle disappears. A transfer resolves as one event that moves money out of the From Account and into the To Account at the same time.

The two accounts cannot be the same account; the form blocks save if they match. The reason for keeping a transfer as one record with two sides is covered in Categories: why is Transfer a separate type rather than two transactions.

Why does deleting either account remove the whole Transfer item? A Transfer item only makes sense with both sides intact: one balance going down, the other balance going up by the same amount. If the destination account were removed but the From side were left in place, the recurring transfer would have nowhere to send money. The same logic applies in reverse. Removing the item entirely is cleaner than leaving a one-sided Transfer that cannot do its job.

So if you delete either the From Account or the To Account, the Transfer item goes with it. You see this in the Delete Account dialog’s count of items that will be removed: a Transfer item that touches the account you are deleting is included even when its other side is an account you are keeping. Past History rows for the Transfer are preserved with their snapshots of the From and To account names; only the future events disappear.

If you want a recurring transfer to continue against a different destination, recreate the Transfer item against the new account before or after you delete the old one.

Auto Pay is a label, not an automation

The Auto Pay toggle is a flag that shows up as an icon on the planner row. It does not change how an event resolves, does not connect to your bank, and does not move money. The app does not pay anything for you, regardless of which Auto Pay state the item is in.

Use it to remind yourself which bills the bank pays automatically (rent autopay, your subscriptions, autopay-on-due-date utilities) and which ones you have to actively send (rent paid by hand, a transfer to your roommate). Resolving the event works the same either way: a bank payment, deposit, or transfer appears and is matched, or you tap Resolve Event yourself.

Why is Auto Pay just a label? Real autopay is a setting on your bank or biller’s website; the app cannot enable or disable it on your behalf. Marking it here is a memory aid, not a control. Treating it as a control would imply the app can stop or start your bank’s autopay, and that promise would be wrong.

Editing an item

Tap an item in the list, then Edit Item. You can change anything: name, category, account, the schedules, the toggles. Save.

The change applies to every future event the item produces from that point forward. Past events already in History are kept at the values they had when they were resolved, with their own snapshots of the name, amount, account, and category. Renaming an item or changing its category does not rewrite the older History rows.

Changing a schedule’s timing (frequency, dates, weekdays, start, or end) is a stronger edit. It discards any per-event customizations you made on that schedule (a one-month change to a single event’s amount, for instance) and any pending transactions that were attached to the affected events. The form warns you when this is about to happen and tells you how many records will be cleared. The history of already-resolved events is preserved.

Pending transactions that were attached to an event whose schedule timing you change are removed by the save, but the balance change those transactions already made to your account stays in place. The warning calls this out so you can update the Current Balance on the affected account by hand if you want it back to the bank’s number. See Accounts for resetting the balance.

If two people on a shared budget edit the same item at the same moment, the second save is rejected with a brief notice and the second editor is asked to refresh and try again. See History and Undo for the broader conflict-resolution flow.

If you want the item to stop producing future events but you don’t want to delete the item or its history, set an End date on each of its schedules. That stops new events from the end date forward and leaves everything else in place.

Deleting an item

Open the item, tap Delete Item at the bottom of the dialog, and confirm in the Delete Item dialog. Anyone with editor or owner access on the budget can delete an item.

The dialog tells you what will go away: the item, its schedules, and all future, unresolved events the schedules would have produced. Any pending event customizations on the item (per-event amount overrides, date adjustments, attached transactions that have not yet resolved) are removed too.

Your payment history is preserved. Resolved and deleted events from the item stay on the History tab as their own snapshots, with the name, amount, category, and account they had at the time. They no longer link back to the item, though. Undo Action on a History row from a deleted item will fail and tell you so; the row stays in History but cannot be returned to the planner.

If you want the item to stop producing new events without losing the option to undo a recent resolve, set an End date on its schedules instead of deleting the item. That keeps the item, the schedules, and the link from past History rows intact.

Quick reference

If you want to	Do this
Add an item	Setup tab, Items segment, add button. Fill in name, category, account, and at least one schedule. Save.
Change an item’s amount	Open the item, change the schedule’s amount. Save. The change applies to future events.
Edit just one specific occurrence	Tap the event in the planner, change it inside the Edit Item Event dialog, save.
Stop an item from producing future events	Open the item, set an End date on each of its schedules. Past History stays intact.
Track each transaction against the budget	Open the item, turn Transaction Tracking on. Save.
Mark an item as autopay (label only)	Open the item, turn Auto Pay on. Save.
Add a second schedule pattern	Open the item, tap Add Schedule, fill in the new pattern. Save.
Delete a schedule from an item	Open the item, tap the trash icon on the schedule’s accordion header. Save.
Delete an item entirely	Open the item, tap Delete Item, confirm. Future events disappear; History is preserved.
Move a recurring transfer to a different destination account	Recreate the Transfer item against the new account; the old item is removed when the original destination account is deleted.
Add more than 250 items	Not possible; the cap is 250 per budget on every tier.

Behind the scenes

Skim past this section on a first read; it explains a few details you can sometimes feel without needing to know them.

Schedule edge cases for short months and odd days. When a monthly schedule is set to the 31st, the calculator clamps each occurrence to the actual last day of that month, so February resolves to the 28th (or 29th in a leap year), April resolves to the 30th, and so on. The Last sentinel uses the same mechanism explicitly. Annual schedules behave the same way for Feb 29: a yearly schedule on the 29th lands on Feb 29 in leap years and Feb 28 the rest of the time. The app never silently skips a month or rolls an event into the next month when the chosen day does not exist.

Schedule dates are anchored at noon UTC. Daylight saving transitions and timezone shifts cannot move a scheduled event off its day. A monthly-on-the-1st schedule lands on the 1st in your local view regardless of where you are travelling.

Item color comes from the category, which gets it from the theme. You pick the icon when you create the item’s category, but the color an item shows on the planner is chosen from the active theme palette and the parent category’s position in the tree. Switching themes restyles every item at once. See Categories: behind the scenes for the full rule.

The Items segment does not call AI. AI Budget Generation creates items at budget-creation time (covered on Subscription and Getting Started); AI Match Review reads each item’s category Type and Bank Transaction Merchant Name during a Match Transactions session (Matching and Resolving); the Plaid recurring-stream import populates items when you link a bank (Bank Linking). Once those flows have finished, the items are normal items you can edit, retitle, or delete, and the Items segment itself never calls back out to AI.

Two editors on the same item. If two collaborators on a shared budget save changes to the same item in the same moment, the second save is rejected with a brief notice that asks the second editor to refresh and try again. The app uses a per-record version number to detect the collision; the first save wins and the second editor sees the refreshed state with the first save’s changes already applied. See History and Undo for the version-conflict flow.

Categories: every item lives in a category, and the category’s Type drives whether the item adds money to an account, takes it out, or moves it between two accounts.
Accounts: items are linked to one account, or two for transfers; what happens when an account they reference is deleted.
Planner: where the events your items produce show up, and where the forecast horizon for upcoming events is set.
Matching and Resolving: how events resolve, how Transaction Tracking changes that, and how to match bank transactions to planned events.
Bank Linking: how Plaid populates items from your linked bank’s recurring streams.
History and Undo: what survives when you delete an item, and the conflict-resolution flow when two editors save at once.
Shopping Lists: lists you check off as you shop, priced from the receipts behind your grocery items.
Recipes: meals you save, what each costs to make at your own prices, and turning one into a shopping list.