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 is automated — the built-in matcher settles clean payments at import time, and rules you write handle the recurring rest — but the page also gives you full manual control when you need it, including handing an outgoing card payment straight to an employee as an expense.

Navigate to Cockpit → Bank Matching to open the page (requires the bank-transactions permission).

Filters and action bar#

The page opens showing lines from all your bank accounts; pick a Bank Account at the top to narrow to one. Next to it, the search box matches anywhere on a line — description, counterparty, IBAN, vendor, references, amounts, dates, bank and codes, including the raw additional info. It supports wildcards: * matches any sequence, ? matches one character — e.g. *4242* finds anything containing 4242.

The Filters button expands further filters, with a Clear all button to reset them:

Top action buttons:

• Export to Excel / PDF — exports the rows loaded for the active tab. The Bank Account, date and Type filters apply to the export; the search box and the Amount, Counterparty and Bank Code filters do not.
• 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.

The three tabs#

The tabs split the list by status:

• Unmatched — bank lines that haven’t been tied to anything yet. These rows have a checkbox so you can select them for batch actions.
• Pending expense — outgoing payments that have been assigned to an employee as an expense. These lines are locked until the expense is decided — see Turning a payment into an expense.
• Matched — lines that have been matched to one or more ledger entries. They show a green check; the only action left on them is Unmatch.

Columns worth knowing#

Each row shows the Booking Date, Bank, Description, References, Amount, Counterparty, Vendor, and Bank Code, plus an Actions menu. Most are self-evident; these are the ones that aren’t:

How automated matching works#

When you import a CAMT statement (or transactions arrive from a connected bank or a card statement), neoo 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, the counterparty IBAN isn’t on any vendor or customer, and the name doesn’t resolve to exactly one customer or vendor with an open item of exactly that amount — or, for a Skonto payment, of exactly that discounted amount.
• A bank 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).
• The counterparty name is ambiguous (it fits more than one customer or vendor) or the open amount isn’t an exact match — partial settlements are never made on a name alone; the Match dialog shows the candidates instead.
• The payment looks like a Skonto payment but the invoice cannot take the discount automatically — it carries more than one VAT rate, its date falls in a closed period or a different year, it is in a foreign currency, it is managed by an integration, or the dataset uses the flat-rate (Saldo) VAT method. The line is left unmatched rather than short-paid, so you can settle it yourself.

Same amount twice is not one of these cases: when several open invoices for the counterparty share the same amount and currency, the matcher settles the oldest one. Check the Matched tab if a payment cleared a different invoice than you expected.

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 or AP posting — or an expense assignment — created from the bank line. See Matching rules below.

Matching a transaction manually#

When the booking date on a row is shown in blue, the line can still be matched. Click it to open the Match Transactions dialog, which searches for candidates — it may also come up empty.

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.

If the right invoice isn’t offered, click Include Other Transactions to widen the candidate list beyond the recognised counterparty. A selection can only combine transactions of one counterparty in one currency.

Handling uneven amounts#

If you match a single candidate and part of the bank amount is left over, neoo asks how to handle the difference before posting. A Handle remaining amount dialog appears with three options:

When the bank line and the invoice are in different currencies, the dialog is titled Handle currency difference instead and offers Settle against FX exchange account, GL Transaction, and — for overpayments — Debit/Credit note.

Turning a payment into an expense#

Some outgoing payments — typically company-card spend — are best explained by the person who made them. Instead of matching the line yourself, hand it over: choose Create Expense on an unmatched money-out row and pick the user. The expense is created and assigned, and it lands in that person’s Needs information queue on My Expenses with the bank details (counterparty, reference) attached, so they know exactly which payment to justify. All they add is the receipt and a description (and a category, if the AI shouldn’t pick one).

While the expense owns the bank line, the row carries an Expense entry chip (“Locked by expense #… — manage it on the Expenses page”) and sits in the Pending expense tab. It can’t be matched, re-booked, or edited there — approving the expense books it and moves the line to Matched; deleting the expense releases the line again.

If a receipt was matched to the wrong payment — or the import found none — correct it from the row menu: Unmatch expense detaches the current one (the receipt goes back to waiting, the line becomes unmatched again), Change assigned expense swaps in another waiting receipt, and Match pending expense assigns one to an unmatched money-out line. The same corrections are available on Manage Expenses.

To hand several payments over at once, select the rows and use Assign expense — see Working with selected rows. And rules can do this automatically for recurring cases — for example, assigning every payment made with one card to its holder. See the Expense entry template type under Matching rules.

Working with selected rows#

Tick one or more unmatched rows and action buttons appear above the table. Each button shows only when every selected row qualifies for it:

• Create — every selected row is still new (Transition). Opens the Template Builder pre-filled with details from the selected lines so you can post a fresh transaction directly from the bank data.
• Assign expense — every selected row is a money-out line that can still become an expense. One dialog assigns all selected payments: pick the Assigned User (required) and optionally a Category and a note applied to all. If any row fails, the dialog lists what went wrong and retrying retries only those.
• 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 bank file included, including raw additional info).
• Match Transactions — opens the match dialog (same as clicking the booking date).
• Create Expense — on unmatched money-out rows; assigns the payment to a user as an expense (see above).
• 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.
• Unmatch — on matched rows; undoes the match and returns the line to the Unmatched tab (see below).

Unmatching a transaction#

A wrong match is undone from the row’s three-dot menu with Unmatch (desktop and mobile). Before anything changes, a dialog lists exactly what will happen for this particular line, and the Unmatch button only becomes available when every step is allowed. Depending on how the line was matched, the list contains entries such as:

• Remove the payment of … from Customer/Vendor invoice … — the payment the match posted is taken off the invoice; the caption shows the payment date and the amount that will be open again afterwards.
• Delete … (created by rule …) / Delete the overpayment credit … / Delete the pending Vendor invoice … posted for the expense — a document the match itself created (a vendor invoice booked by an Account Payable rule, the credit note for an overpayment, or the draft vendor invoice behind a pending expense) is deleted, because removing only its payment would leave an empty document behind.
• Delete GL entry … — a booking made by a rule/template, or a GL entry that was posted from this bank line by hand.
• Bank payment for … goes back to status … — a Bank Payments entry the match had marked Completed returns to the status it had before (Created, Exported or Uploaded).
• Detach expense #… — a card expense assigned to the line is detached: a pending expense returns to the pending card expenses, an approved one stays approved and is marked unpaid.
• Reverse the … skonto — an early-payment discount the automatic match booked on the invoice is reversed.
• Book the bank transaction back to the transition account … — the holding entry on the transition account is re-created so the money is back where a fresh import puts it. If the holding entry still exists (for example after Mark As Processed), it is simply kept.
• The bank transaction moves to the Unmatched tab — module, rule link and processing flags on the line are cleared.

Unmatch also copes with a match that was already partly undone by hand — for instance when the payment was deleted on the invoice, which left the line stuck in the Matched tab with 0.00 matched: leftover links are removed and the holding entry is rebuilt.

The action is refused, with the reason shown in the dialog, when any of the affected dates falls in a closed period (the bank booking date, the payment date, the document date or the date of a rule-booked GL entry), when a linked GL entry is locked (accrual or expense), when the document is managed by an integration, when an expense on the line is still being processed by the AI, when no transition account is configured, or when the payment lines on the document cannot be told apart from another payment on the same day. In the last case, remove the payment on the document itself.

After unmatching, the line can be matched again like any other unmatched transaction.

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 its Active / Inactive status, plus:

• Edit to reopen the rule and adjust its conditions or template — this is also where you enable or disable a rule, by ticking or unticking Active.
• 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 → Create New Rule.

A rule has three parts:

1. Rule Name and Bank. 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 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 when it fires. Pick a type — General Ledger, Account Payable, or Expense entry — then fill in the fields for that type (see Template Builder below).

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 of the selected bank account (or of all accounts when none is picked). Clean matches become 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 when you define a rule’s output. It builds the shape of what the bank line becomes. The field set you see depends on the Template Type you pick:

• General Ledger — a Description and Notes, optional Department and Project, the Account to post to, an optional Tax Account, and a Reverse Tax option.
• Account Payable — the Vendor, Description and Notes, optional Department and Project, a Record Account, and the line’s Line Item Account, Tax Account and Line Description.
• Expense entry — pick the Assigned User. Every transaction the rule matches is created as an expense for that user — the way to route, say, one card’s payments to its holder automatically. The booking then happens through the normal expense approval. Tick Card payment and enter the card’s last 4 digits to let that user file receipts before the payment arrives: when the transaction is imported it is matched to the waiting receipt instead of creating a second expense (same user and card, amount within 50 rappen, receipt dated up to ten days before or two days after the booking; a receipt in a foreign currency is matched against the original amount the bank quotes on the debit, or failing that at the day’s exchange rate).

Account Payable and Expense entry are only offered for outgoing (money-out) lines, and the Expense entry type is available when defining a rule or working from a single row — not when creating from a bulk selection. Description, Notes, and Line Description fields all accept the {{ }} variables described above.

Where bank lines come from#

Lines arrive in this table from three places:

• CAMT import — uploaded statements via CAMT Import.
• Bank integration — with Amnis, Konfipay or Revolut connected, transactions arrive here by themselves, with no file to upload. You can also pull in a date range on demand. See Bank Integrations.
• Card statement import — every card transaction on an imported credit-card statement becomes a bank line here (and, optionally, an expense for the cardholder). See Card Statements.

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.

And to verify that a bank account and your books actually agree over a period — statement balance against ledger balance — run a reconciliation.