Bank Reconciliation

Use Bank Reconciliation to compare a downloaded bank statement with one Actual account. Use it to audit a period or resolve missing, duplicate, or incorrect transactions. It does not replace normal transaction entry or bank sync.

Open it from Financial Management → Bank Reconciliation (/reconciliation).

Budget impact: Your decisions stay in the session until you Apply. Bank Reconciliation does not directly change transaction categories. A transformation can use an existing category as a condition, but it does not modify that category. Actual rules can categorize new transactions when they are created.

Before opening this workspace, save or discard pending entity or budget edits from other pages. Bench shows an entry screen until those edits are resolved, with Save, Discard, Undo and Redo available in the temporarily expanded changes panel. The workspace’s own review/save actions remain separate. Once the workspace opens, its global pending-changes panel is hidden again. If you then create a global draft through Quick Create or Redo, the relevant panel opens without closing your current editor. Resolve the global draft there; local work stays in place. Re-entering the page or switching budgets checks pending drafts again.

The Guide button at the top right of the session list opens an illustrated walk-through of the whole feature, from importing a statement to applying safely, with navigation between sections, without leaving the page.

Before you start

You need a statement file and the Actual account to compare it with. Supported files are CSV, TSV, OFX, QFX, QIF, and text-based PDF statements. OFX and QIF are detected from their contents, so an OFX export saved as .txt still imports as OFX.

Each session covers one account. It is stored in Actual Bench, so you can close the tab and return later. No bank connection, bank credentials, or separate setup is required.

The workflow

1. Start a session and select the Actual account. Add a tag if it will help you find the session later.
2. Import the statement. For CSV or TSV, confirm the date, amount, payee, and notes columns. For a PDF, review and correct the extracted transactions before importing them.
3. Review automatic matches and decide what to do with every difference.
4. Check the planned changes on Review.
5. Select Apply to write the approved changes. Actual Bench checks affected transactions again before it writes.

Open a session to continue where you left off. Tags, account, date, and status filters help you find it. An applied session remains available as an audit record.

Start and import

Select New reconciliation, choose the account, and optionally add a tag such as July close or after the refund. This tag labels the reconciliation session only; it does not add a tag to budget transactions. You cannot change the account after the session starts.

Credit cards. When the account is a card you have added in Credit Cards, you can tick Also enter this card’s bank statement figures. After Start, Card statement figures opens: choose the statement at the top (each one shows its period, balance and whether its figures are entered or verified), then enter or check its figures and Save figures, or Skip straight to the import. The reconciliation remembers the statement and shows it in its header, marked different period? if the imported file looks like another statement. Select it there to edit the figures again at any step, or Enter card statement figures if you skipped. Once you apply, select Review statement to open that statement’s review in Credit Cards and match its transactions. A credit-card account that is not added in Credit Cards shows the option disabled.

Paste a statement or upload a file. The import screen shows the parsed rows before you continue. For CSV and TSV files, correct the mapping if needed. For example, map separate debit and credit columns when the bank does not supply one signed amount column. Check the date format and sign convention before matching.

Import a PDF statement

Select a PDF to read it in your browser. Actual Bench uses PDF.js locally. It does not upload or store the PDF. If the file has a password, enter it when prompted; the password remains in memory only.

The workbench has two steps, Check detection and Review transactions. It opens on review when the initial result is mostly usable, and on detection when more than half of the proposed transactions are rejected or a saved layout needs checking. The bar above both steps summarizes the statement: its transaction count and date range, a track showing how the rows divide into Ready, Review, and Fix with each part named beside its colour, the money in and out, the net, and how many pages held transactions. The track is a composition, so it shows progress as rows are resolved rather than only naming the worst problem left.

Select Use transactions only after every row is ready. The rows then use the same import preview, matching, review, and Apply steps as other statement formats. Select Review PDF import on the import page to reopen the workbench before continuing.

Check detection

This step shows the positioned PDF text, transaction areas, and column boundaries, each mapped column in its own colour with a role label and examples taken from inside its current boundary. Include or ignore an area, select a missed one, change a column role, or drag its boundaries.

The panel beside the page holds everything that decides how the statement is read: the Statement Layout in use, Statement Interpretation for the account type, currency, statement period, date or number format, import date, printed sign, unsigned amount direction and pages to ignore, and the Column Mapping. Each setting has an (i) that says what it changes and whether it is saved with the layout, and the book icon on Statement Interpretation opens this guide.

What needs attention, above those settings, is the one place messages appear. Each item says what happened and where, then offers one action named for what it does: Set period, Choose a rule, Set currency, Confirm, Change, or Show, which opens the page with the row selected (with several rows, it steps through them). Items waiting on you come first, in amber; notes that are only worth knowing follow, muted. The setting an item points at, and the Statement Interpretation section itself, are outlined in amber until it is answered.

The mapping list is always in the order the statement prints its columns, left to right, so it never disagrees with the page. Drag a column’s label to move the whole column, or its edges to change one boundary; the arrow keys do the same from the keyboard. The + on a mapping adds a column between it and the one to its right, for a column the detection missed, and the up and down arrows swap a mapping with its neighbour, moving it left or right on the page.

Preview updated transactions compares the current result with the proposed one: how many transactions there would be, how many are ready to import, and how the net change moves, each with the difference stated. Underneath it summarizes the row changes - added, removed, amounts, dates, descriptions - and warns when a change would leave transactions unreadable. Apply changes and review then reuses the extracted file and preserves your row corrections. These actions, with Reset detection and Save layout, stay at the top of the settings column, and the preview opens directly under them.

Review transactions

This step shows the extracted rows. Negative amounts are money out and positive amounts are money in. Edit a date, description, or amount directly. Select the sign to reverse one row, or select several rows to set their direction, mark valid warnings as reviewed, merge them, or ignore them. Actions for selected rows appear in the fixed footer.

Each row is Ready, Review, or Fix. Ready can continue, Review needs confirmation, and Fix is missing a required value. A row that is not ready states underneath its description the most serious thing it is waiting on, so a repeated reason can be spotted down the column. A status with a chevron opens the row’s full notes, on hover or selection, separating what needs attention from how a value was read; ready rows carry the second part only. Select a field’s eye icon to see its source text in the PDF. Select Mark reviewed only after checking a row against the statement. Correcting a required field removes that error as soon as the row is valid, and a row cannot be marked reviewed while a required field is still invalid.

Use All, Needs review, and Ready above the table to change the view; Needs review shows non-empty structural, date, amount, direction, balance, reconciliation, and duplicate filters. Direct edits change one row, and after an eligible edit the footer can offer the same correction to a stated number of similar rows or all remaining rows. Marking several selected rows reviewed at once first names the warnings that action would accept without resolving, such as a balance that does not reconcile.

Possible duplicates remain included and are marked reviewed straight away, since the same charge twice on a day is ordinary: mark both reviewed when they are separate transactions, or ignore the repeated row.

Add transaction, beside the search box, adds a transaction the statement does not show. It goes at the end of the list, empty and marked Fix until its date, description, and amount are filled in, and it counts in the totals and statement checks like any other row. It has no source on the PDF, and undo removes it again. Ignored rows can be restored from Check detection. A dated row inside a transaction table stays available for correction even when its amount cannot be read.

Export, beside the search box, saves the transactions to CSV exactly as the table shows them - the same rows in the same order, with the corrections made so far, each row’s status, and any outstanding notes. A filtered or searched view exports what is on screen.

The PDF viewer

The viewer opens at 80%, which keeps a full statement page in view. Its +, −, and fit-width controls stack down the left of the page and zoom between 60% and 160%; with the page focused, +, -, and 0 do the same. Paging sits above the viewer, and a statement of more than five pages replaces the page label with a box you can type a page number into. The zoom level is kept as you move between pages and workbench sections. Selecting a field’s eye icon opens the page containing its source and scrolls to the highlighted text. In Check detection, the columns button under the zoom controls shows or hides the mappings drawn over the page and stays lit while they are shown; selecting a mapping centers that column in the viewer.

Statement layouts

A layout stores how to read a bank’s table and nothing about any one statement: column roles as fractions of the page width, the date, number and amount-direction settings, and the masked shape of the table’s header row. It does not store the statement period, the transaction areas, the PDF, or transaction text - a period moves every month, and areas are numbered by page, which shifts as soon as a statement runs longer. Recognition is by the table’s header, so correcting a layout’s mapping never makes it harder to recognize next month.

Layouts are grouped by bank and shared across budgets and accounts, so HSBC Bank can have separate Credit card and Checking layouts. The bank name organizes the list; Actual does not identify which bank owns an account. Selecting a layout applies it to the current statement only; select Use for the account to save that assignment.

An assigned layout is applied to that account’s statements. Where the statement’s table has drifted from the saved one it is still applied and the difference is stated, because a layout withheld leaves you mapping the statement by hand for reasons you cannot see. When either table header is not detected, the layout is applied without template verification if the page aspect ratio and rotation are compatible; check its column mapping and detection settings. When both headers are missing, the notice says no table header was available to verify the layout and asks you to check the column mapping; it does not claim that the table changed. Corrected columns are never compared with fresh detection to reject a headerless layout. Conflicting detected headers or incompatible headerless page shapes keep the layout unapplied. A layout carrying amount-direction settings says so when it is applied, so you can confirm those against the statement.

To save one, apply the detection changes and select Save layout, in the actions at the top of the settings column or on the confirmation that follows. Enter the bank and layout names, and assign it to the account if you want it used automatically. Layouts are not versioned, so a name that is already taken asks whether to replace that layout’s settings or keep it and save under a different name, and a layout can only be saved when it has no rejected transactions. Select Manage to change an assignment, rename a bank or layout, or delete one; removing an assignment returns the account to automatic detection.

When the settings in force no longer match the layout they came from, a Layout not saved control appears in the workbench header and opens the save dialog. It counts only changes a layout can hold - column mappings and the reading settings - so adjusting a transaction area, which belongs to one statement, does not ask to be saved.

How the statement is read

The parser has no bank-specific templates. It reads the statement’s own structure, and anything it cannot settle from the statement stays in review rather than being guessed at.

Columns and rows. Automatic mapping identifies the transaction table first, using the table’s printed header where there is one, so account details, credit limits, payment summaries, balances, and totals elsewhere on the page do not create mappings. An uncertain role stays unmapped for you to set. Where extraction returns several values as one piece of text (two dates and a description, say) the words are divided between the columns that cover them, so each column reports its own value.

A valid date in the mapped date column starts a transaction, and the lines above it join the transaction they belong to rather than the one they sit nearest: a description printed above its own date stays with it, and a fee, VAT, original-amount, or total line stays with the transaction it belongs to unless its own amount and balance show it moved the account. Where a statement prints a date once for several transactions, the later rows inherit it and are marked for review. Only running balances are used for reconciliation; available and periodic balances are not ledger movements.

Dates. A date cell takes whatever the statement prints - 15 Jun 19, 15/06/2019, 2019-06-15 - reads it through the Date format setting, and stores the date it means; a value it cannot read stays on screen and is marked. Unambiguous dates establish whether the rest use day/month or month/day order, and the statement period supplies missing years across December and January. The period is read from the first two pages, including a label printed on one line with its dates on the next. A date printed without a year, on a statement whose period cannot be found, is not guessed: those rows ask for the statement period, and set once, it supplies every year. A label such as Date before a numeric date does not prevent it being read. Named-month dates require a recognised month name, and may be printed without separators, as 06JUL or 06JUL2019; ambiguous date order and invalid calendar dates still need review. Transaction date is the default import date, marked by the check in its column header. Posting and value dates are optional and stay separate; removing one of their mappings stops it being validated.

Amounts and direction. The parser reads signed, parenthesized, and trailing-minus amounts, mixed-case DR and CR markers, separate debit and credit columns, explicit debit and credit sections, and one Amount column where a suffix such as 113.61CR marks money in. When some amounts are marked CR and the rest are bare, the bare ones are not assumed to be money out: Amount direction says Auto-detect (unmarked amounts need a rule) and those rows wait until you choose. The choice is saved with the layout, so each bank asks once. When direction is proven, the setting says by what - the Debit and Credit columns, printed signs, the balance column, or section headings. Common US, European, space-grouped, Indian, Swiss, Arabic-digit, and East Asian number layouts are supported.

Money in and money out are never guessed from the account type alone. Printed directions decide first. Where a statement prints no direction at all, a running balance can supply one, but only once the parser knows which way that balance moves - from printed directions that already agree with it, or from an account type you have confirmed. A heading that is ambiguous, or that disagrees with the printed directions, leaves the balance column unused and those rows unresolved.

Pages to ignore. Ignore first / last N pages treats that many pages at each end as carrying no transactions - a cover page, terms at the back - counted from each end so it holds however long next month’s statement is. Those pages are still read for the period, currency, account type, and balances, and still shown; only their transaction areas are switched off (shown as Ignored by the layout, and you can include one for a single statement). It is saved with the layout. Rules that would ignore every page are not applied.

Printed sign means states whose side the printed sign takes: a bank account prints a minus for money out, while a card or loan issuer prints a minus for a payment that reduces what is owed. Until that convention is confirmed on a card or loan statement, rows that take their direction from a printed sign stay in review. The account type behind it is read from the statement heading, never from transaction descriptions, so a checking statement that pays a credit card is not classified by those payments; a type read from the heading alone resolves directions but keeps them in review until you confirm it in Statement Interpretation.

Currency and precision. The amount column states the statement’s currency in its header, and when it cannot be read it is asked for once in Statement Interpretation rather than on every row. Currency is a statement-level reading: Actual holds one currency per budget file and the import carries no currency code, so what it decides here is how many decimal places an amount may have. A row printing a different currency is flagged, because it usually means the original amount was read instead of the amount charged to the account. Actual transactions use two decimal places, and import is blocked when converting would lose a meaningful digit, so correct the amount to the value that should be stored in Actual.

Parser details, warnings, and limits

Select Parser details for how the statement was read - the account type, currency, date and number formats, which date is imported, how unmarked amounts and printed signs were treated, what the balance column was taken to mean, and which pages held transactions - each labelled with where it came from: the parser’s own reading, your setting, or a saved layout. Underneath, the reasons rows are not ready are counted, and selecting one shows those rows. It also holds saved-layout validation and technical diagnostics, which contain aggregate events, counts, and page numbers, not statement text or source IDs. The panel opens beside the workbench rather than replacing it. Parsing warnings are not kept here; they appear in What needs attention, beside the settings that answer them.

A page that has no readable text layer, or that could not be read at all, is reported above the transaction table, and import stays disabled until you confirm that you checked those pages: their transactions are missing from the statement. The page is named once, in What needs attention, and again beside the import button, and I checked these pages at either place settles it. A page the layout’s Ignore first / last N pages setting leaves out is not reported. A row inside a transaction area that prints an amount but did not become a transaction is reported in What needs attention with its page, and Show takes you to it, so you can mark it in Check detection instead of losing it silently. Lines of text alone - a translated label, a heading on its own line, a disclaimer - cannot be transactions and are not reported.

Scanned or image-only PDFs have no usable text layer, and OCR is not included. A damaged page is reported instead of being silently ignored. Large files are limited by file size, page count, text item count, and processing time so they cannot keep the browser busy indefinitely. Use CSV, OFX, QFX, or QIF when the bank can provide a structured export.

Changes to PDF reading

How statements are read changes between releases. Parser details says which version read a statement, and copied diagnostics include it.

• Next release
  • PDF.js 6, with its character maps, fonts and image decoders served by Actual Bench: statements whose fonts rely on predefined character maps (common in Chinese, Japanese and Korean PDFs) are now read, and previews show the right fonts and images.
  • Ignore first / last N pages, saved with the layout.
  • The statement period is read from the first two pages, including a label with its dates on the next line; a period printed as “STATEMENT PERIOD 12 Feb 2026 TO 11 Mar 2026” no longer loses its first date.
  • A date without a year asks for the statement period instead of reading as unreadable.
  • Amount direction only applies what the statement proves, and says what that was.
  • What needs attention is the one place for messages, each with a named action; only rows that print an amount are reported as not read.
  • The review no longer closes on a click outside it. Esc, the close button, and Cancel ask before discarding corrections or detection changes, and the browser warns before leaving the page while there are any.

Choose how missing rows are created

Choose how transactions that are missing from Actual should be created:

• Use the statement payee, which resolves or creates an Actual payee; or leave the payee for Actual rules to set.
• Keep the bank memo, the statement payee, both, or neither in notes. For CSV and TSV, the mapped Notes column is the source of notes.

You can change these options later in Re-run → When a row isn’t in Actual. Notes you edited or changed with a transformation keep their staged value; the new choice affects only untouched rows.

The two text channels

The statement payee and memo are separate fields. The statement payee is recorded as Actual’s imported payee. The memo is a source for notes on new transactions; whether it is written depends on your new-row choices. For CSV and TSV, the mapped Notes column is the notes source instead. This preserves the bank’s original text while leaving your curated Actual payee and category intact.

This distinction matters: Imported payee records what the bank called the transaction, while Notes records its extra text. The imported payee can be used to resolve an Actual payee, but it does not replace your curated payee.

If you import the same statement again, Actual Bench warns you and identifies the earlier session. You can still continue. Re-importing can be useful after a partial apply or after correcting a column mapping; matching always compares the statement with the current state of Actual.

Reconciliation profiles

For CSV and other structured files, save an account-specific reconciliation profile to keep the column mapping, date and amount conventions, payee and memo choices, and matching options. PDF statement layouts are separate: they are global, grouped by bank, and configured in Check detection as described above.

Import details

For CSV and TSV, Actual Bench detects delimiters from a consistent column layout, recognises header rows, and suggests a column mapping. The date column is required. You can leave the description column unmapped when it is really a memo; in that case no imported payee is recorded and matching uses notes instead.

For OFX, QFX, and QIF, the format supplies the field structure. You can use a memo as a fallback when a payee is empty, or swap a bank’s payee and memo fields when it put them in the wrong places. When a memo is used as the fallback payee, it is not also available as notes for that row. QIF and CSV dates may be ambiguous. Check the preview and select the intended date convention before you continue.

OFX transaction IDs (FITID) are stored as statement metadata and can support matching. They are not written to Actual’s imported_id; Actual Bench uses its own deterministic marker to make retries safe.

Statement field	Actual field	Purpose
Merchant, description, NAME, or P	Imported payee	The bank’s merchant text and a candidate for payee resolution
Memo, details, or MEMO / M	Notes	The bank’s extra transaction text

Match and decide

Automatic matching requires an exact signed amount. Dates and text rank candidates with the same amount; they do not create a match by themselves. If the statement uses positive numbers for spending, correct the sign convention. Re-run inverted is offered only when no rows matched and reversing the signs would explain the mismatch.

Use the workbench to review matches, find rows that need attention, and make decisions.

Choose what the text is compared against

Under Matching, choose where Actual keeps merchant text: Payee, Imported payee, Notes, or All, best match. The statement payee is compared, with the memo used only when the bank did not provide a payee. Payee and imported-payee comparisons use name similarity; notes use containment so the bank text can sit within a longer note.

Best match compares every enabled field and uses the strongest result. Priority first checks fields in your chosen order and uses the first one that reaches the threshold. You can set priorities and weights in Advanced matching. Settings are saved in the reconciliation profile and take effect only when you select Re-run.

For each difference, you can:

• accept the suggested match or select another candidate;
• say two rows are not the same transaction;
• create a transaction that is missing from Actual;
• delete a duplicate transaction;
• correct an existing amount;
• keep an existing transaction that is not on the statement; or
• leave the row undecided. Apply does not change undecided rows.

Actual amounts with a staged correction appear in amber in the matching table.

Resolve competing matches together

When several bank rows share Actual candidates, open a row and select the highlighted Resolve group button in its panel header. Bank rows run down the matrix and Actual transactions run across it. Each row and column header shows a bold amount above the date and merchant. Each eligible cell states the amount and date difference. Actual column headers include a single-line notes preview, and same-day candidates stay highlighted while you select other cells. Selecting a cell opens its comparison in the right panel; select Use this match to confirm it. The panel states any amount correction that accepting the pair will stage.

Confirming a pair closes the panel. Paired shows both transactions using the reconciliation table layout, including their dates, amounts, payee, notes, and decision. Select a paired row to reopen its details. The group title is on the left, with navigation on the right. After the last confirmation, the completion message appears beside Paired and Back to all rows is highlighted. The paired table stays visible so you can review it or use Undo last pairing before returning.

A confirmed transaction disappears from the other candidate lists. Columns that no remaining bank row can use are hidden; these Actual transactions remain available in the main reconciliation table. The last remaining pair still needs your confirmation. Undo last pairing restores the previous relationships, including any released Actual rows. An unrelated edit clears that undo. It is available during this visit only.

None of these leaves the bank row undecided and keeps released Actual transactions available for their usual keep/delete decisions. Use Back to all rows to handle those remaining decisions. Selecting cells does not fetch data or write to Actual.

Read the match details

The matching table header keeps its bottom divider visible while scrolling. The right panel shows the current result or confidence in its fixed header, with supporting evidence below. Comparison, Bank, and Actual share one header row, and differences show their size beside the Actual value. Decision buttons stay visible in a gray footer while details, candidate choices, and resulting fields scroll above it. Payee and notes edits are grouped separately from decisions; category remains read-only. Candidate comparisons show Use this match before exposing the editor.

Use the bank’s date

On an accepted match with different dates, Use statement date beside the date comparison stages the bank date on the existing Actual transaction. It does not change the date merely because the rows matched. The resulting transaction shows the staged date and Undo date removes that proposal. Review includes the date change before Apply. Existing protections still apply.

When amounts disagree

To correct several rows together, select them and choose Use the statement amount. Each eligible row is recorded as decided, with its correction staged for Review and Apply. Undo that restores the previous decisions and staged edits until another edit is made. Rows with several candidates need a chosen match first. Bulk decisions apply only to eligible selected rows currently visible in the table. Shared Actual candidates must be paired individually in Resolve group before bulk amount corrections or deletion.

When a matched amount differs from the statement, accepting the pairing stages the statement amount on the existing transaction. Actual Bench will not change the amount of a reconciled transaction, a split parent, or one leg of a transfer. You can still record the match, but Review reports the remaining difference. When allowed, the correction updates the same transaction rather than replacing it, so its ID, payee, notes, category, schedule, and transfer link remain.

If the two rows are different transactions, choose Not the same transaction. The statement row then remains available to create, and the Actual transaction remains available to keep or delete.

You can continue to Review with unresolved rows. Apply does not create an unresolved statement row or change an unresolved Actual transaction.

Transactions outside the statement period are loaded to help match rows near the start and end of the period. They start as kept and are not included in the decision count. You can still choose to delete one if that is appropriate.

When no automatic match works

Rows that are too ambiguous are not matched automatically. Use Possible pair to review a likely pair, or select two rows yourself and confirm that they are the same transaction. This also stages the statement amount on the selected Actual transaction.

Possible pairs are review hints, not automatic candidates. They can have different amounts, so they require an explicit confirmation and never lower the automatic-match threshold.

The workbench shows statement coverage and Actual-account coverage separately. It also keeps rows outside the statement period visible, because they can explain a match near the date boundary. They are kept by default and do not count as undecided work.

Transform transactions

Use transformations to preview and stage a payee change or note changes across several rows. Already-applied rows are excluded from the preview and changes. Set a payee, or use note actions to add, remove, move, or replace tags and text. Conditions can use a payee, category, or tag. Transformations do not write any change until Apply, and do not overwrite a hand-edited value unless you choose to do so.

The If and Then controls sit together in a rule section, with the manual-edit override beneath them. The preview shows payee names in Now and After, and a date beside each row’s description helps distinguish repeated merchants. An unset payee shows No payee; if its name cannot be found, the preview shows Unavailable payee. The preview explains when matching rows already have the requested values or were left unchanged by protections or manual edits. The header and action buttons remain visible while you scroll through the preview.

Selecting Change N rows adds the changes to this reconciliation for review. Your Actual budget is updated only when you select Apply.

For text, you can prepend, append, or replace an exact value. You can also extend a merchant name in an existing note to the longer statement description. If Actual Bench cannot identify the bank text inside the note, it leaves that row unchanged and explains why.

When a row has several candidates, select the candidate before you correct, delete, or match it. Actual Bench protects reconciled transactions, split parents, and transfer legs from changes that would make the budget inconsistent. It explains the restriction and leaves the row available for a safe decision.

See How Matching Works for match scoring, text targets, safeguards, foreign-currency matching, and every matching setting.

Review the plan

Select Review when you have finished deciding rows. If possible pairs or undecided rows remain, Actual Bench warns you first. In particular, an undecided statement row is a bank transaction that will not be added to your budget if you apply; an undecided Actual-only row is left alone. You can return to the workbench or continue to Review.

The Review page lists each planned create, update, delete, and imported-payee write, plus the effect on the account balance.

Check these choices before you apply:

• Mark as cleared: leave transactions unchanged, mark only new transactions cleared, or mark every statement-confirmed transaction cleared. The last option also writes the cleared status to matched transactions that otherwise need no update.
• Save the statement’s text as imported payee: save the statement’s description as the imported payee on new rows only, or on matching rows as well. This changes imported_payee, not the curated payee, notes, or category.

New transactions always record the statement payee when the statement provides one. Their payee and notes follow the options you set during Import.

Matched transactions keep their existing payee and notes unless you explicitly stage a transformation or another reviewed edit. Bank Reconciliation does not directly change categories: matched transactions keep their category, while Actual rules can set the payee or category of new transactions.

Transactions already reconciled in Actual are skipped. A matched transaction also needs no imported-payee write when it already has the same bank text.

What actually gets written

Field	On a new transaction	On a matched transaction
Imported payee	The statement payee, when present	Written only when Save the statement’s text as imported payee includes matched rows
Payee	Resolved from the statement, or set by Actual rules	Kept unless you stage a payee change
Notes	Follow the Import choice	Kept unless you stage a note change
Category	Set only by Actual rules	Kept as it is

The Review page identifies imported-payee writes separately from curated-data changes. It also shows the previous value when an existing imported payee would be replaced.

Apply safely

Decision saves finish before Apply checks the budget. A failed save must be retried before writing; bulk decisions save together. If a staged date already matches Actual, it needs no further write. If Actual has a different third date, that row is held for review.

If a new Actual transaction could match a row marked Create, the row returns to undecided with the new candidate available for review. It cannot be created until you resolve that choice. Accepting a match or correcting its amount removes that Actual transaction from competing rows; Apply also refuses conflicting decisions about the same transaction.

Select Apply only after reviewing the plan. Immediately before writing, Actual Bench re-reads every affected transaction. It writes rows that are still safe and holds back conflicts or changes it cannot combine safely.

For example, it preserves an amount or date corrected in Actual after the session began, and tries to replay a staged note change onto a newer note. If it cannot do that safely, it reports the row instead of overwriting it.

Applied creates use deterministic markers. Retrying a partial run does not create the same transaction twice. The result identifies successful, skipped, and failed actions, and Retry what failed attempts only unfinished work. After writing, Actual Bench reads the account again to verify the result.

If an Apply was interrupted, return to the session and choose Recover interrupted Apply only after the original tab has stopped. Recovery reads Actual to confirm outcomes; it does not repeat writes. Confirmed rows stay fixed, and unconfirmed work remains available for review and retry. A session that was only partly applied can still be used to decide its remaining rows.

When every row is decided and no writes are needed, select Finish to close the session. Finish checks the saved decisions too. If another tab has changed them, reopen the session to review the current choices before finishing.

An applied session cannot be re-matched because it is an audit record of its decisions and writes. Its Review page remains readable, but its write choices are locked to the options that were used. To reconcile the account again, start a new session.

Sessions and limits

The session list shows one row per reconciliation: the account, its tag, the statement’s format and file name, the period, the number of statement rows, and where it has got to. Group by account gathers an account’s sessions under one heading, and is off by default because most accounts have a single session. Opening a session goes to the step its work is at - a draft opens on Import, an applied one on its result, and everything else on the workbench.

Opening a saved session fetches current Actual transactions; a Direct connection syncs first. Your saved decisions and staged edits remain. Editing and Apply wait for that read to succeed, with Retry reading Actual available after a failure. Saved snapshots are used for conflict checks and historical results, rather than as current Actual data.

The Year filter starts on the current year when there are sessions in it; Clear filters widens it back out. A draft has no statement period yet, so it is always listed whatever the year. A statement period that runs across a year answers to both, so a December-to-January cycle is found under either.

Sessions are stored in the Actual Bench metadata database on the server, not in the budget file. They contain the imported statement rows, your decisions, matching options, and apply result. Statement contents therefore leave your browser and remain in Actual Bench metadata until you delete the session. Delete a session from the session list when you no longer need it; deletion removes that session data only and never changes your budget. Applied changes remain applied.

Bank Reconciliation has these limits:

• One account per session.
• Split children are read-only. A split transaction can be matched, but its individual lines cannot be edited here.
• Automatic matches require an exact signed amount. Amount differences and ambiguous pairs require review.
• Manually linking rows is limited to transactions loaded for the session’s date range.

Related pages

• How Matching Works — matching algorithm and configuration
• Bank Sync — run Actual’s existing bank sync on a schedule