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.

  1. 1
    Your 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.

  2. 2
    The partnerOwn company

    A transfer between two accounts of the same company, or a type bound to a specific partner.

  3. 3
    The 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.

  4. 4
    A personMarked manually

    Marks or undoes on the transaction's page. The decision becomes an example for the AI.

Any mark can be taken back on the transaction page:Undo: mark as unmatched

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

  1. 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.
  2. 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.
  3. 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.
  4. 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".

Edit transaction type

System default. Its name is shown in the workspace's language automatically. Rename it to set a custom name.

Describe what transactions belong to this type. This text is shown to the AI when classifying transactions.

Inactive types are excluded from AI matching and the manual selection dropdown

When on, these movements get a partner automatically. Either the account's bank, or one specific partner.

The party is the account's own bank. Set each account's bank (name + tax ID) under Master Data → Bank accounts.

Patterns

Match transactions where any pattern applies (case-insensitive):

42 existing transactions in this workspace would match these patterns.

Editing the Bank Fee type. The numbers match the list below. The patterns and counts are examples.

  1. Description: the AI reads it to decide which transactions belong to the type.
  2. Set the partner from this type, here with Bank selected.
  3. The patterns: a field, a match mode and a value.
  4. 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:

TypePurpose
Bank FeeAccount maintenance charges, transfer fees
InterestInterest credited or debited by the bank
Internal Bank AdjustmentBank-initiated corrections and adjustments
Card Reserve / AuthorizationPre-authorisation holds on cards
VAT / Tax PaymentPayments to the tax authority
PayrollSalary and payroll runs
Cash withdrawalATM and cash withdrawals from the account
Internal transferMoving money between your own bank accounts (see below)
Loan / financing movementLoan disbursements, repayments and other financing movements
Card acquirer settlementPayouts 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

  1. Click + New Type, or Edit on a type's row.
  2. Enter a Name.
  3. 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.
  4. Leave Active ticked.
  5. Set a partner if the type has one (see below).
  6. Add one or more patterns with + Add pattern.
  7. 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:

FieldWhat it checks
DescriptionThe transaction's free-text description from the bank
Partner nameThe other party's name as it appears on the bank line
ReferenceThe payment reference
ModeBehaviour
ContainsThe field contains the value anywhere
Starts withThe field begins with the value
ExactThe 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:

ModeThe party is…Use it for
BankThe bank that runs the account, taken from the account itselfBank fees, interest, cash withdrawals, card reserves
Specific partnerOne verified partner you pickA 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

PatternsExamples
Where they come fromYou write themCaptured from your marks and undos, or added by hand
What they doA hard rule: a match is marked at once, no AI involvedA hint the AI weighs with everything else about the transaction
If one is wrongTransactions are marked wrongThe AI can still decide against it
Can say "this does need an invoice"NoYes

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

ColumnMeaning
PartnerThe partner the example is about
DescriptionText the transaction contains
VerdictNo invoice needed (with the type) or Needs an invoice
Transaction typeThe type to apply; blank for a Needs an invoice example
SourceAuto-learned (from your mark) or Manual (you added it)
Times seenHow 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…:

  1. Pick a transaction type, or No specific type if none fits.
  2. 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:

LabelMeaning
No invoiceMarked No invoice needed, by a type or by a person
MatchedMatched to an invoice
UnmatchedStill waiting for an invoice or a decision
DuplicateDetected as a duplicate of another transaction
Bank feedImported from a live bank connection
StatementImported 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.