Income and Expense are single entries on one account.

Transfer is money moving between two of your own accounts. It is two entries, one on each account, shown in the table as a single row reading From → To. A transfer changes both balances but is not counted as income or expense anywhere — it is not new money, just money in a different place.

You cannot switch an existing transaction between income and expense. That choice is made when you create it.

Every transaction has a date. Some also have an actual period.

The date is when the money moved. It drives your balances, Cashflow, the payment calendar, and the exchange rate used for conversion.

The actual period is what the money was for. It is a range — a start and an end — and it drives the Profit and Loss report only.

This is what lets P&L answer a different question from Cashflow.

Payroll of 10,000 paid on 10 January for December's work, with an actual period covering December:

An annual invoice of 12,000 paid on 15 January, covering the whole year:

Cashflow shows all 12,000 in January. P&L spreads it evenly per day across the 365 days — about 32.88 a day, so a 31-day month gets 1,019.18 and February gets 920.55. Because the split is per day rather than per month, no month shows exactly 1,000, and the twelve rounded months can add up to a cent more than the total.

The actual period is optional and never filled in automatically. Bank and wallet imports do not set one. When a transaction has no actual period, P&L uses its date instead — so for anything you have not annotated, P&L and Cashflow will agree.

To remove an actual period, open its date picker — in the table cell or in the transaction window — and choose Clear. P&L then uses the transaction's date again.

Transfers have no actual period at all.

Three ways: your bank or wallet sends them, you enter them by hand, or they come from a scheduled or recurring template.

On a synced transaction, the financial facts belong to the bank and cannot be edited: amount, currency, date and account. Everything you add yourself is yours to change — description, category, counterparty, custom attributes and the actual period.

When the bank sends an update for a transaction you have already annotated, your category, counterparty, actual period, attributes and splits are kept.

A synced transaction cannot be deleted. It is the bank's record of what happened.

A new transaction dated in the future on a manual account is created as planned. It shows a Planned chip in the table.

Planned means not yet approved, whatever the date. Nothing happens automatically when the date arrives: a planned transaction stays planned until someone chooses Approve, and overdue ones simply sit there. Changing a transaction's date never changes its status.

Approve is available for planned income and expense on manual accounts. Planned transfers can't be approved yet, and planned transactions on bank and wallet accounts can't be approved at all — see below.

Approving keeps the planned date and time if that day has already come. Approve a 1 March payment on 5 March and it stays on 1 March. If the planned date is still in the future, approving moves it to the current moment, and the confirmation tells you so.

There is no partial settlement. If you planned 1,000 and 700 arrived, you cannot close 700 and leave 300 open. Two things you can do instead:

An approved transaction always counts in balances and reports, even when its date is in the future. Planned transactions count only with Show planned data on. Then every unapproved occurrence in the period counts, overdue ones included.

To turn an approved manual transaction back into a planned one, select just that row and choose Actions → Convert to planned. Its date, split and other fields stay as they are. This isn't available for bank and wallet transactions, transfers or pending holds, or when more than one row is selected.

You can plan up to the end of the year five years from now.

You can plan on a connected bank or wallet account too — an expected client payment, a card subscription. Everything you create on such an account is planned, whatever its date: actual transactions there come only from the bank or wallet.

A recurring template repeats daily, weekly on chosen weekdays, monthly on chosen days of the month, or yearly on chosen dates.

A monthly template set to the 31st skips months that have no 31st. It does not fall back to the 30th.

There is no end date — a series runs indefinitely until you stop it.

Templates live on the Recurring transactions page in the sidebar.

Editing a template changes every occurrence that has not been approved yet, including overdue ones. Occurrences you have already approved are independent copies and keep what they had.

To change a single occurrence without touching the rest, use Edit this occurrence. When you save, that date is removed from the template and the occurrence becomes a standalone transaction. It stays planned and keeps the template's split, if there is one. This is permanent. Closing the editor without saving leaves the series as it was.

If the template has an actual period, each occurrence gets that period shifted to its own date. So does the transaction you get by approving or editing that occurrence.

To stop a series, use Delete all future from an occurrence. That cannot be undone and the series cannot be restarted.

A bank has no way to know that two transactions are the same move, so a transfer between your own accounts arrives as an expense on one account and an income on the other. Until you join them, they are counted as real income and a real expense.

Joining is manual. Select exactly two rows — one income, one expense, on different accounts — and choose Change to transfer. In the same currency, the amounts must match. Planned and pending transactions, and existing transfers, can't be used.

The two originals are not destroyed. Revert, or deleting the transfer, brings them back exactly as they were.

To create a transfer from scratch, use the Transfer form. It offers manual accounts only; to make a transfer out of bank or wallet transactions, join two existing rows instead.

Between currencies, each side holds its own amount and you enter either the amount received or a rate.

A split divides one transaction between several categories, counterparties or attribute values — one payment covering three projects, say.

The parts must add up to exactly the transaction's amount, and there must be at least two.

Splitting does not change your balance, and while a split exists the transaction's amount and currency are locked. On an account in a currency other than your workspace's, a new date can't be saved either, because it would change the converted amount. Remove the split to change them.

Two things to know about where splits count:

Only the P&L report reads the parts. Cashflow, the payment calendar and custom widgets use the transaction as a whole.

Filters match the transaction, not its parts. Filtering by category will not find a transaction whose parts carry that category — it matches the transaction's own category, which is hidden once you split it.

Planned and recurring transactions can be split, and occurrences inherit it.

Transfers cannot be split.

Rates come in once a day and there is never a rate for today.

Each transaction is converted using the rate for its own date, and that figure is stored with the transaction. It does not move afterwards, even if the rate provider later revises the day.

Account balances are different: they are converted at the latest rate each time you look at them. This is why a balance and a report can drift apart — they are answering different questions with different rates.

If there is no rate for a currency on a transaction's date, the transaction cannot be saved. Choose another date or currency.

Your workspace's main currency cannot be changed after the workspace is created. Everything is stored converted into it.

Select rows to get the bulk bar. It shows separate income, expense and transfer totals for the selection. It offers Duplicate and Delete, plus Change to transfer for exactly two eligible rows. With exactly one row selected it also offers Actions: for a planned row, the same actions as the row's own menu; for an approved manual income or expense, Convert to planned.

Transactions that came from a bank or wallet cannot be duplicated or deleted, so those actions are unavailable when the selection includes one. Planned transactions you created on those accounts can be.

Duplicate and Delete cannot be undone.

There is no trash and no restore. A deleted transaction is gone, and recovering it is not something you can do from the app.

Deleting a transfer removes both sides. Deleting a split transaction removes its parts with it.

Deleting an account permanently deletes its transactions. If a transfer had one side on that account, the surviving side becomes an ordinary income or expense.

Ordinary transactions are deleted from the bulk bar after selecting them, not from the row menu.

Every transaction carries a category and a counterparty, and any custom attributes you have defined. Categories and counterparties support sub-options, which reports can roll up or show separately.

See the custom attributes article for how to set these up.