Transaction Types & No Invoice Needed
Some bank transactions will never have an invoice: bank fees, interest, payroll, tax payments, transfers between your own accounts. Transaction types recognise these transactions and mark them No invoice needed, so they stop waiting for a document and stay out of the unmatched work.
- 1Your patternsMatched by pattern rule
Every unmatched transaction is checked against the patterns of your active types when it arrives. A match marks it at once.
- 2The partnerOwn company
A transfer between two accounts of the same company, or a type bound to a specific partner.
- 3The AIMatched by AI · Confidence: Medium (0.72)
Reads the transaction, your type descriptions and examples, and marks it when it is at least 60% sure. Once per transaction.
- 4A personMarked manually
Marks or undoes on the transaction's page. The decision becomes an example for the AI.
How a bank transaction gets its type: your patterns first, then the partner, then the AI, and a person can always mark or undo.
How a transaction gets its type
- Your patterns. When a statement is uploaded or a new bank-feed transaction arrives, AI Finance Team checks every unmatched transaction against the patterns of your active types. A match marks it No invoice needed with that type straight away.
- The partner. A transfer between two accounts of the same company is always an internal transfer (see below), and a type bound to a specific partner applies whenever the transaction's partner is that partner.
- The AI. For what is still unmarked, the AI reads the transaction, your type descriptions and the examples you taught it. When it is at least 60% sure, it marks the transaction itself. It looks at each transaction once; below that confidence it leaves the transaction alone.
- A person can mark or undo any time on the transaction's page.
The transaction's page says which of these marked it: Matched by pattern rule (also shown for a partner-bound type or a transfer between your own accounts), Matched by AI with the confidence, or Marked manually.
Setting up transaction types
Open Master data, then Bank Transaction Types. The page has two tabs, Types and Examples. Members of the accounting firm can open it; creating and changing types needs the permission "Edit master data".
Editing the Bank Fee type. The numbers match the list below. The patterns and counts are examples.
- Description: the AI reads it to decide which transactions belong to the type.
- Set the partner from this type, here with Bank selected.
- The patterns: a field, a match mode and a value.
- The live preview: how many existing transactions the patterns match.
Default types
A new workspace starts with ten types, or with your accounting firm's own template if it has one:
| Type | Purpose |
|---|---|
| Bank Fee | Account maintenance charges, transfer fees |
| Interest | Interest credited or debited by the bank |
| Internal Bank Adjustment | Bank-initiated corrections and adjustments |
| Card Reserve / Authorization | Pre-authorisation holds on cards |
| VAT / Tax Payment | Payments to the tax authority |
| Payroll | Salary and payroll runs |
| Cash withdrawal | ATM and cash withdrawals from the account |
| Internal transfer | Moving money between your own bank accounts (see below) |
| Loan / financing movement | Loan disbursements, repayments and other financing movements |
| Card acquirer settlement | Payouts from a card acquirer |
The default types come with patterns for typical bank wording, such as BANK FEE, JUTALÉK, PROVISION and HAVI DÍJ for bank fees. Their names are shown in the workspace's language; once you rename one, it keeps your name. You can edit, extend or deactivate any of them.
Creating and editing a type
- Click + New Type, or Edit on a type's row.
- Enter a Name.
- Write a Description. This is not a private note: the AI reads it to decide which transactions belong to the type, so describe them plainly.
- Leave Active ticked.
- Set a partner if the type has one (see below).
- Add one or more patterns with + Add pattern.
- Click Create type, or Save changes for an existing type. Saving replaces all the patterns of the type.
Deactivate on a row switches a type off without losing it: an inactive type is shown dimmed, its patterns are not applied, the AI does not use it, and it is not offered when you mark a transaction. Activate switches it back on.
Patterns
A transaction matches a type if any of its patterns match. A pattern is a field, a match mode and a value:
| Field | What it checks |
|---|---|
| Description | The transaction's free-text description from the bank |
| Partner name | The other party's name as it appears on the bank line |
| Reference | The payment reference |
| Mode | Behaviour |
|---|---|
| Contains | The field contains the value anywhere |
| Starts with | The field begins with the value |
| Exact | The field is exactly the value |
Patterns ignore upper and lower case and accents, so fizetés also matches FIZETES.
As you type, the editor shows how many existing transactions the patterns match. The count includes transactions that are already matched or marked, and adds up the patterns one by one, so treat it as an upper limit: it tells you whether a pattern is far too broad or catches nothing at all.
Partner binding: who the transaction is with
Bank fees, interest, tax payments and card-acquirer payouts have a real party: the bank that runs the account, the tax authority or the payment provider. A type can set that party, so these transactions reach the exports with the right party instead of a name scraped from the statement.
In the editor, tick Set the partner from this type and pick a mode:
| Mode | The party is… | Use it for |
|---|---|---|
| Bank | The bank that runs the account, taken from the account itself | Bank fees, interest, cash withdrawals, card reserves |
| Specific partner | One verified partner you pick | A tax authority, or a card acquirer: always the same party |
With the box unticked, the type sets no partner and the partner comes from the transaction itself. If the partner you need does not exist yet, + Create partner creates it right in the editor.
Bank: set each account's bank
A Bank type takes its party from the bank account. Set it under Master data → Bank accounts: open the account with Edit (or when adding one) and fill in Bank and Bank tax ID, so bank charges always export with a party.
Specific partner: the rule fires on identity
A Specific partner type applies when the transaction's partner is the partner you picked, never because the text merely looks similar, and it marks a transaction that is still unmatched No invoice needed. Its patterns are not used. For example, a type bound to a card acquirer classifies that acquirer's payouts, but the rule leaves a look-alike from another company untouched, because that is a different party that may well need an invoice. Create one type per partner: one for the VAT account of the tax authority and a separate one for personal income tax, because tax sub-accounts are not the same party.
The rule itself only looks at the partner. The AI also sees the type's name and description and can suggest it for other transactions, so name the partner in the description. The steps do not always run in the order above; whichever marks the transaction first wins, and a later step never replaces the type.
The category belongs to the partner. To book a partner's transactions to a fixed category, set Fixed transaction category on the partner's Rules tab (see Managing Partners). It only sets the category; whether a transaction needs an invoice is decided here.
Internal transfers between your own accounts
When you move money between two of your own bank accounts, most often converting EUR to HUF or topping one account up from another, there is no invoice.
AI Finance Team recognises these by the account number, not by the wording. When the other account on a transaction belongs to one of your companies:
- the transaction is linked to that company instead of a partner, shown with an Own company badge;
- between two accounts of the same company, it also gets the Internal transfer type and is marked No invoice needed;
- between two different companies of yours, only the company is linked; the transaction is not marked, because a payment between two companies can have an invoice behind it.
Keep each company's bank accounts up to date under Master data → Companies so transfers are caught reliably. A transaction whose description only mentions a transfer word (e.g. "átvezetés") can still get the Internal transfer type from a pattern, but it is not linked to one of your companies.
Teaching AI Finance Team which transactions need an invoice
Patterns are not the only way to teach. When you mark a transaction No invoice needed with a type, or undo such a mark, AI Finance Team remembers the decision as an example and shows it to the AI the next time something similar arrives. A mark with No specific type teaches nothing, because it says nothing about which type applies.
Examples live on the Examples tab of Bank Transaction Types.
Examples are not rules
| Patterns | Examples | |
|---|---|---|
| Where they come from | You write them | Captured from your marks and undos, or added by hand |
| What they do | A hard rule: a match is marked at once, no AI involved | A hint the AI weighs with everything else about the transaction |
| If one is wrong | Transactions are marked wrong | The AI can still decide against it |
| Can say "this does need an invoice" | No | Yes |
Use a pattern when you know the exact bank wording and want it handled every time. Use examples for everything else; your day-to-day decisions build them up on their own.
Teaching the opposite: "this needs an invoice"
When you undo a No invoice needed mark, AI Finance Team records a Needs an invoice example, and the AI then leaves similar transactions alone even when the wording looks invoice-free.
If a pattern made the wrong mark, undoing it is not enough: the pattern marks the transaction again on the next run, because patterns run before the AI. Fix the pattern instead. Hungarian bank text is full of near misses: a pattern for fizetés (payroll) also catches kifizetés (a payout), and adó appears inside plenty of company names. Make such a pattern more specific, for example with Starts with or a longer value.
What each example shows
| Column | Meaning |
|---|---|
| Partner | The partner the example is about |
| Description | Text the transaction contains |
| Verdict | No invoice needed (with the type) or Needs an invoice |
| Transaction type | The type to apply; blank for a Needs an invoice example |
| Source | Auto-learned (from your mark) or Manual (you added it) |
| Times seen | How many transactions you have decided this way; an example you add by hand starts at 3 |
Repeated decisions about the same partner collapse into one example with a rising Times seen count. + Add example teaches something before AI Finance Team has seen it, which helps when you take on a client whose recurring items you already know. Your most recent decision wins, and a new or changed example affects transactions from then on; it does not revisit transactions already processed.
AI learning, under Settings on the tab, is a slider for how many learned examples AI Finance Team shows the AI, from Low to High (30 by default); Off stops using them. It is one setting for the whole workspace, shared with the category examples. Changing it needs the permission "Edit workspace settings". Examples belong to one client workspace and are never shared between clients.
Marking a transaction by hand
Open the transaction from Bank transactions. On an unmatched transaction, the Matching & payment card has a menu, Mark as: no invoice needed…:
- Pick a transaction type, or No specific type if none fits.
- The transaction is marked No invoice needed at once.
To take it back, click Undo: mark as unmatched. The transaction returns to unmatched and waits for a document again. Marking and undoing need the permission "Edit bank transactions"; client users see the mark but cannot change it. The menu appears only when the workspace has at least one active type.
Labels and filters on the transaction list
A row on the Bank transactions page can carry these labels:
| Label | Meaning |
|---|---|
| No invoice | Marked No invoice needed, by a type or by a person |
| Matched | Matched to an invoice |
| Unmatched | Still waiting for an invoice or a decision |
| Duplicate | Detected as a duplicate of another transaction |
| Bank feed | Imported from a live bank connection |
| Statement | Imported from an uploaded bank statement |
The pills above the list filter by the same states: Bank feed, Statement, Duplicate, Unmatched, Matched and No invoice, plus Custom category missing. Several pills can be on at once. The list itself, its columns and its search are described in Bank Transactions.
Exports
A transaction marked No invoice needed still needs a transaction category with a Code; without one the RLB export warns, and the ledger account stays empty. Transactions of a Bank type export with the bank name and tax ID from the bank account.