Bank Matching #

Bank Matching is where bank statement lines meet your ledger. Every credit and debit imported from your bank gets matched to the invoice, payment, or GL posting that explains it. Most of this can be automated — by rules you write, or by the AI when you drop a supporting PDF on the row — but the page also gives you full manual control when you need it.

Navigate to Stations → Bank Transactions to open the page.

Filters and action bar #

Choose a Bank Account at the top of the page to load its transactions. The other filters narrow what you see:

Top action buttons:

• Export to Excel / PDF — exports the current filtered view.
• Manage Rules — opens the rule manager.
• Apply Rules to All — runs every active rule against every unmatched line in one pass.

The next row of buttons appears only when you’ve ticked one or more rows in the table. See Working with selected rows below.

Unmatched vs Matched tabs #

The two tabs split the list by status:

• Unmatched — bank lines that haven’t been tied to anything yet (based_on = transition).
• Matched — lines that have been matched to one or more ledger entries.

Unmatched rows have a checkbox so you can select them for batch actions. Matched rows show a green check instead — they’re informational only.

Columns worth knowing #

Most columns are self-evident (date, description, amount, bank code, transaction ID). These are the ones that aren’t:

Matched rows are visually de-emphasised (greyed out) so the unmatched work in front of you stands out.

How automated matching works #

When you import a CAMT statement (or sync transactions from a connected bank), Neo-Ledger tries to settle each line against an open invoice before it ever reaches your screen. Anything it finds with high confidence is posted as a payment immediately and labelled auto_matched on the Bank Matching page. Anything it can’t resolve falls through to the Unmatched tab for you to handle.

What it looks at, in order #

The matcher works through these data points top-to-bottom. The first signal that produces a clean hit wins; if none does, the line stays unmatched.

When auto-matching falls through to manual #

A line stays on the Unmatched tab when any of the following is true:

• No reference on the bank line, and the counterparty IBAN isn’t on any vendor or customer.
• The reference matched something, but the currency is different from the invoice’s.
• The IBAN matched a vendor or customer, but the amount doesn’t match any of their open invoices (or there’s nothing open).
• Multiple invoices on the same counterparty share the same amount — the matcher won’t pick one ambiguously, it asks you to.
• The counterparty appears in the remittance text only by name — names are too noisy to auto-post against, so name-only signals are surfaced in the manual Match dialog instead, never auto-applied.

When the line lands unmatched, the Match dialog (below) still uses the same signals to rank candidates for you — it just shows you the options instead of acting on them.

Auto-matched vs rule-matched #

Both are forms of automated matching, but they come from different places:

• auto_matched — the built-in matcher matched a bank line to an existing open invoice using the signals above. This happens at import time, automatically.
• rule_matched — one of your rules matched. Rules can also fire automatically at import, or on demand via Apply Rules to All. Use rules when no invoice exists yet and you want a templated GL/AP/AR posting created from the bank line — see Matching rules below.

Matching a transaction manually #

When the booking date on a row is blue and underlined, it means Neo-Ledger has potential matches for you to choose from. Click it to open the Match Transactions dialog.

Inside the dialog:

1. The top half shows the bank line you’re matching.
2. The lower table lists candidate AR / AP / GL transactions, pre-sorted by best fit — the most properties matched first (amount, counterparty, date), then closest amount, then oldest.
3. Tick one or more candidates. The system distributes the bank amount across them automatically, but you can edit the Distributed amount on each row to split it yourself.
4. If the bank line is in a different currency from the candidates, an Exchange Rate field appears.
5. Click Post to confirm the match.

Handling uneven amounts #

If your distributed total doesn’t equal the bank amount, Neo-Ledger asks how to handle the difference before posting. A Handle remaining amount dialog appears with three options:

Dropping a document on a row #

Every unmatched row has a Drop or click zone in the Document column. Drag a PDF, image, or Word file onto the zone (or click to browse). What happens next depends on whether the document corresponds to a transaction Neo-Ledger already has:

• If the bank line settles an existing invoice — Neo-Ledger reads the document, finds the matching AR or AP transaction, and ties the bank line to it. The document is attached as a reference along the way.
• If there is no existing transaction yet — Neo-Ledger creates one directly from the document and the bank line. The transaction is posted as already paid (no separate payment step is needed) and routed to the Receipt workstation for sign-off on the Approvals page.

This second behaviour is the receipts flow — see Receipts flow — payment first on the Cockpit overview. It’s especially useful for credit-card statements, direct debits, and any spend where the bank line shows up before the receipt does. Drop the receipt on the row, approve on the Receipt station, done.

While the file uploads, the zone shows a spinner. Once queued for processing, the zone turns green with a “Queued” check.

The drop zone only appears on unmatched rows. Once a row is matched, the document column shows a dash.

Working with selected rows #

Tick one or more unmatched rows and three buttons appear above the table:

• Create — only enabled when every selected row is still in transition state (i.e. truly new). Opens the Template Builder pre-filled with details from the selected lines so you can post a fresh GL, AP, or AR transaction directly from the bank data.
• Edit — only enabled when every selected row is rule_matched. Lets you tweak the template that the rule applied before posting.
• Mark As Processed — flags the selected rows as resolved without creating a ledger entry. Use this for the rare bank lines that genuinely need no ledger match (e.g. internal transfers between bank accounts where the other side is also imported).

Per-row actions menu #

The three-dot menu on each row offers:

• View Details — full transaction detail dialog (everything the CAMT file included, including raw additional info).
• Edit — only on matched rows that have a reference; lets you reopen the related ledger transaction.
• Match Transactions — opens the match dialog (same as clicking the booking date).
• View Applied Rule — only on rows matched by a rule; shows the rule’s conditions and template, read-only.
• Create Rule — start a new matching rule pre-filled from this row’s data.
• Mark As Processed — same as the bulk button, but for a single row.

Matching rules #

Rules are the headline feature here. They turn repetitive manual matching into a one-click pass — write a rule once and every future statement line that fits gets matched automatically.

Manage Rules dialog #

Click Manage Rules in the action bar. The dialog lists every rule on the dataset with:

• Toggle to enable or disable the rule.
• Edit to reopen the rule and adjust its conditions or template.
• Delete to remove it.

Creating a rule #

The fastest way to create a rule is from a row that already has the right shape: open its three-dot menu → Create Rule. The dialog opens with the bank account, conditions, and a starter template pre-filled from that row. You can also create one from scratch via Manage Rules → New.

A rule has three parts:

1. Name and bank account. Both required. The bank account scopes the rule — it won’t run on lines from other accounts.

2. Conditions (up to 10). Each condition is a Field, an Operator, and a Value. The first condition is the bank account itself and can’t be removed. Add more conditions to narrow the match. All conditions are AND-ed together.

Available fields:

Operators for text fields: Equals, Contains, Starts with, Ends with. Operators for amount: Equals, Less than, Greater than, Less than or equal, Greater than or equal.

3. Template. Defines what the rule should create or match against when it fires. Pick a type — General Ledger or Account Payable — then fill in the accounts, vendor (for AP), and a description.

Variables inside a template #

In the Template’s Description, Notes, and Line Description fields, click a variable chip to insert a placeholder. Placeholders use {{ variable }} syntax and are replaced with values from the actual bank line each time the rule fires:

This lets a single rule generate clearly-labelled postings — for example, a description of Salary {{ counterparty_name }} {{ booking_date }} produces Salary Mary Smith 2025-04-30 on the actual GL entry.

Apply Rules to All #

Click this button to run every enabled rule against every unmatched line in your filter. Matches at 100% confidence flip from transition to rule_matched and move to the Matched tab. Anything ambiguous stays unmatched for you to handle.

Template Builder #

The Template Builder is the dialog that opens when you click Create (on selected unmatched rows) or use Create Rule to define a rule’s output. It builds the shape of the resulting AP, AR, or GL transaction. The same component is reused, so the field set you see depends on the Template Type you pick:

• General Ledger — account, tax, line description.
• Account Payable — vendor, expense account, record account, tax account, line description.
• Account Receivable — customer-side equivalents.

Description, Notes, and Line Description fields all accept the {{ }} variables described above.

Where bank lines come from #

Lines arrive in this table from one of two places:

• CAMT import — uploaded statements via CAMT Import.
• Bank integration — for connected providers (Revolut, Konfipay), transactions can be polled directly. For connection options, contact Support.

After matching, outgoing payments that go through Payments will appear here on the next statement and can be matched back to the originating vendor invoice, closing the loop.