Reconciliation rules

Categorisation rules for Estonian bank transactions: match repeating payments like bank fees or phone bills once, and they skip the review queue for good.

Some transactions never need judgement. Telia is always the phone bill, the bank's monthly service charge is always a bank fee, and deciding this afresh every month is not a good use of anyone's time. A rule captures the pattern once — a condition matched against incoming transactions, plus the category to apply — and from then on those transactions are categorised the moment they arrive, skipping the review queue entirely.

Rules live under Banking → Rules, where you can see every rule, what it matches and where it posts.

The anatomy of a rule

Part	What it does
Rule name	A label for the list, e.g. "Telia phone bill"
Match field	Which part of the transaction to look at: the description, the paid to/from name, the payment reference or the counterparty IBAN (compared without spaces, however the bank prints it)
Match type	Contains, exact match or starts with — all case-insensitive
Match value	The text to look for, e.g. "TELIA"
Category	The income or expense category to apply, which determines the account the transaction is posted to
Priority	The rule's place in the queue — lower numbers are checked first
Active	Only active rules are applied; unticking pauses a rule without deleting it

Creating a rule

Start a new rule

Go to Banking → Rules and select New Rule. It helps to have the transaction you're targeting open in All Transactions at the same time, so you can copy the exact text the bank uses.

Describe what to match

Pick the field and the text. The paid to/from name is usually the steadiest choice — counterparty names rarely change, while descriptions and references often vary from one payment to the next. The IBAN is steadier still, when the same account is always involved.

Choose where it posts

Select the category, give the rule a priority and leave it active. Save, and the rule applies to matching transactions from the next import onwards.

Creating a rule while you categorise

You can also make a rule from a payment you're categorising. In Reconciliation, choose Bank fee / simple charge, pick the category and tick Always categorise payments to and from … this way. The rule matches the counterparty's IBAN when the payment has one, and otherwise its name. It books the category's account, and as soon as it's saved it categorises the other payments in Needs review that it matches; the confirmation says how many. A payment with neither an IBAN nor a counterparty name doesn't offer the option, since a rule on its description would match only that one payment.

How rules are applied

Rules run automatically whenever transactions arrive — on every bank sync and every CSV import, before auto-matching has its turn. Active rules are checked in priority order, lowest number first, and the first rule that matches wins, so two rules can never fight over the same transaction. A matched transaction gets its category, is marked as done and never appears in Reconciliation.

Rules only ever touch transactions that are still in Needs review. Anything already matched, categorised or excluded is left alone, so a new rule cannot rewrite history.

A rule to an income category other than Sales Revenue, such as Other Income, asks whether the money it books is for goods or services you sold, since that's where payment processor payouts often go. A rule that books sales — to Sales Revenue, or one you answered yes for — leaves them in Needs review while your company is VAT registered on their date, and refunds of them too (a rule matches money out as well as in): one booked from a bank line carries no VAT and wouldn't reach your VAT return, so match each sale to its sales invoice and each refund to its credit note as a Client Refund instead. While the company isn't registered, the rule books them, but they aren't counted towards the €40,000 VAT registration threshold (see Other income).

💡Leave gaps in your priorities

Numbering rules 10, 20, 30 rather than 1, 2, 3 leaves room to slot a specific rule above a general one later — for instance, an exact-IBAN rule at 10 catching one supplier before a broad "description contains" rule at 20 sweeps up the rest.

Seeing what a rule has done

There is no separate per-rule activity log; the place to check a rule's work is All Transactions. Filter to Matched and search for the counterparty — transactions the rule handled show as Done with the rule's category in the category column. If one was caught wrongly, Undo Categorise on the row sends it back to Needs review, and the rule itself can be adjusted or deleted from its row menu on the Rules page — or paused by unticking Active.

Once in a while a rule's booking can't be confirmed — the connection drops just as it is posted. Rather than risk booking the transaction twice, Arvello keeps it out of Needs review, and the sync, import or retry that ran the rule tells you how many it kept. You'll find them under Matched in All Transactions: check each one, and use the undo in its row menu if the booking needs redoing. Auto-matching does the same with a match it can't confirm.

A rule that matches too eagerly usually has a match value that's too short, or a "contains" that wanted to be "exact"; tightening the value or switching to the counterparty IBAN narrows it down.

Suggestions for money out

For a payment out with no invoice match, a Suggested banner above the grid can say how to book it. Its button opens the form pre-filled; nothing is booked until you confirm there.

From your own history. When the earlier payments to the same IBAN (or, without one, the same name) were mostly booked one way, the banner says so: for example "3 earlier payments to Zone Media OÜ were recorded as expenses from Zone Media OÜ". Record expense opens the expense form with that supplier and the expense account its expenses used; Categorise as … opens the Bank fee form with that category. If the earlier payments were categorised straight from the bank to a category that has VAT, such as software, the banner suggests recording this one as an expense instead, so its VAT can be claimed.
From AI, for a payee you've never paid. Where the history has nothing, Arvello can ask an AI model (TypeSafe's Jev, listed in the privacy policy) which expense category the payment looks like, and marks the suggestion as AI's. A category with VAT, such as software, is suggested as an expense to record with the supplier's invoice, so its VAT can be claimed; only a VAT-free one, such as bank fees or insurance, is suggested for categorising straight from the bank. The model is sent the amount, that it's money out, and the payee: a company's name when it carries a legal form such as OÜ or AS, otherwise only a web address or the prefix a platform such as Google or Apple puts on card payments. It is never sent an IBAN, a reference, an e-mail address or anything else from your books. A payment to someone named as a person, or to a sole trader (FIE), gets no AI suggestion; a card payment's web address can still occasionally be a sole trader's own.

A rule, or a recurring expense?

Both deal with costs that repeat, from opposite ends:

A rule is bookkeeping after the fact. It categorises what the bank statement already shows; nothing exists in Arvello until the money has moved. It fits charges where the statement line is the whole story — bank fees, card charges, small subscriptions without a meaningful invoice.
A recurring expense template works ahead of the bank. It creates the expense record itself on schedule, with the supplier and VAT details attached, and the bank transaction is then matched against that expense during reconciliation. It fits proper monthly supplier invoices, where there's VAT to track and a document behind the payment — see Recurring expenses.

A reasonable test: if you'd never ask the supplier for an invoice, a rule does the job; if there's an invoice with VAT on it, a recurring expense keeps the paper trail intact.