Transaction Types & No Invoice Needed
Some bank transactions will never have a matching invoice — bank fees, interest charges, payroll runs, VAT payments, and similar recurring items. Transaction types let you define rules for these transactions so they are automatically recognised and excluded from the Missing Documents list, keeping your inbox focused on genuinely unmatched items.
How it works
When new transactions arrive (via bank statement upload or bank feed), AI Finance Team runs your transaction type rules against every unmatched transaction. Any transaction whose description, partner name, or reference matches a rule is immediately marked No invoice needed with that transaction type attached. No manual review required.
For transactions that don't match a rule exactly, the AI can also suggest a type based on the content of the transaction — you will see the confidence level in the transaction detail.
Setting up transaction types
Transaction types are managed under Master data → Transaction Types. This page is only visible to users with the Accountant or Accountant admin role.
Default types
Every new workspace comes with eight pre-seeded transaction types to get you started:
| Type | Purpose |
|---|---|
| Bank Fee | Monthly 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 | Direct tax authority payments |
| Payroll | Salary and payroll runs |
| Cash withdrawal | ATM / cash withdrawals from the account |
| Internal transfer | Moving money between your own bank accounts (see below) |
These types already include common patterns based on typical bank descriptions (such as BANK FEE and COMMISSION for bank fees). You can edit, extend, or deactivate any of them.
Internal transfers between your own accounts
When you move money between two of your own bank accounts — most commonly converting EUR to HUF, or topping up one account from another — there is no invoice, because both sides are the same company.
AI Finance Team recognises these automatically and does not rely on the description wording alone. When the other account on a transaction is one of your own entity's bank accounts (matched by IBAN or account number against your entities' bank accounts), the transaction is:
- given the Internal transfer type,
- marked No invoice needed, and
- linked to a special Own entity partner rather than a junk supplier record (see Managing Partners).
Because this is based on your saved account numbers — not forgeable text — keep each entity's bank accounts up to date under Master data → Entities so transfers are caught reliably. A transaction whose description merely mentions a transfer word (e.g. "átvezetés") but whose other account you don't own is still flagged No invoice needed with the Internal transfer type, but it is not linked to an own entity.
Creating a new type
- Click + New Type in the top-right corner.
- Enter a Name — this is what accountants and the AI will see.
- Optionally add a Description for internal reference.
- Add one or more patterns (see below).
- Click Save.
Editing a type
Click the Edit button on any row in the table. The same form opens with the current settings pre-filled. Saving replaces all patterns for that type.
Activating and deactivating types
Click Deactivate (or Activate) on any row. Inactive types are greyed out and their patterns are not applied during matching. Use this to temporarily disable a type without losing its configuration.
Partner binding — who the transaction is with
Bank fees, interest, tax payments and card-acquirer settlements don't just need No invoice needed — they also have a real party: the bank that runs the account, the tax authority, or the payment provider. A transaction type can resolve that party automatically, so these movements carry a proper party into the ledger and exports instead of a junk record scraped from the statement text.
In a type's editor, turn on Set the partner from this type and pick one of two modes:
| 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 — it differs per account, but is always "that account's bank" |
| Specific partner | One verified partner you pick | A tax authority (e.g. NAV VAT), or a card acquirer like Teya — always the same party |
Leaving the toggle off means the type doesn't set a party — the partner comes from the transaction itself, as usual.
For a Specific partner type you can also set a Fixed category: the transaction is booked to it automatically (only when it doesn't already have one). If the partner doesn't exist yet, use + Create partner right in the editor — no need to leave the page first.
Bank: set each account's bank
A Bank type takes its party from the account itself — the bank is not a separate partner. (You have no running balance / folyószámla with your bank for fees; the balance you hold with the bank is the account's own cash balance.) Set it under Master data → Bank accounts: open a bank account with Edit (or when adding one) and fill in the Bank and Bank tax ID fields, next to the account's IBAN and currency, so bank charges always export with a party.
Specific partner: fires on identity, never look-alikes
A Specific partner type only applies when the transaction's partner actually resolves to the partner you picked — never because the text merely looks similar. For example, a type fixed to Teya classifies Teya's card settlements but leaves a look-alike Wolt settlement untouched, because Wolt is a different party (and may well need an invoice). You decide which partners get a rule at all.
Moved here: transaction rules that used to live on the Partner detail page now live here as Specific partner types. Create one type per partner — for example one for NAV VAT and a separate one for NAV Personal income tax, because tax sub-accounts are never the same party.
Patterns
Each transaction type can have one or more patterns. A transaction matches the type if any of its patterns match (case-insensitive OR logic).
Pattern structure
Every pattern is a combination of three fields:
| Field | What it checks |
|---|---|
| Description | The transaction's free-text description from the bank |
| Partner name | The name of the other party on the transaction |
| Reference | The payment reference / communication field |
Combined with a match mode:
| Mode | Behaviour |
|---|---|
| Contains | The field contains the value anywhere (most flexible) |
| Starts with | The field begins with the value |
| Exact | The field matches the value exactly |
Example: A pattern with Field = Description, Mode = Contains, Value = BANK FEE will match any transaction whose description contains the words "BANK FEE", regardless of what comes before or after it.
Live match preview
As you type a pattern value, AI Finance Team shows you a count of how many existing transactions in the workspace would match that pattern. Use this to check whether a pattern is too broad or too narrow before saving.
Teaching AIFT which transactions need an invoice
Patterns are not the only way AIFT learns. Every time you mark a transaction No invoice needed — or undo that mark — it remembers the decision as an example, and shows it to the AI the next time something similar arrives. You don't have to do anything to build this up; it accumulates as you work.
Examples live under Master data → Transaction types → Examples.
Examples are not rules
This is the important distinction, and it is worth getting right before you reach for either one:
| Patterns | Examples | |
|---|---|---|
| Where they come from | You write them | Captured automatically from your own marks and undos |
| What they do | A hard rule — a match is filed immediately, no AI involved | A hint the AI weighs alongside everything else about the transaction |
| If one is wrong | Transactions are silently filed 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 deterministically — and check the live match preview before saving, because a broad pattern will catch things you didn't intend. Use examples for everything else: they are what your day-to-day corrections build up on their own.
Teaching the opposite: "this needs an invoice"
When you undo a No invoice needed mark, AIFT records that as a Needs an invoice example — a veto. The AI will then leave similar transactions alone even when the wording looks invoice-free.
This is the fix for the near-miss cases. Hungarian bank text is full of them: a rule written for fizetés (payroll) also reads kifizetés (a payout), and adó appears inside plenty of ordinary company names. Rather than trying to word a pattern around every one of those, undo the wrong mark once and AIFT learns the exception.
What each example shows
| Column | Meaning |
|---|---|
| Partner | The partner the example matches on |
| Description | Text the transaction should contain |
| Verdict | No invoice needed (with the type below) 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've ruled on this way |
Repeated decisions about the same partner collapse into one example with a rising Times seen count, rather than one row per transaction — so the list stays readable even after a few hundred bank fees.
Adding an example by hand
Use + Add example to teach AIFT something before it has seen it organically — useful when onboarding a client whose recurring items you already know. Pick No invoice needed and a type, or Needs an invoice for a veto.
Your most recent decision wins. If you mark a pattern invoice-free and later undo it, the example flips — it doesn't keep both answers.
Changes apply going forward. A new or edited example affects the next classification run; it does not revisit transactions AIFT has already processed.
Examples are per client, never shared between clients, and are visible to accountants only.
Labels on the transaction list
Each transaction row in the Transactions page can show one or more labels:
| Label | Meaning |
|---|---|
| No invoice | Matched by a transaction type rule or manually marked by an accountant |
| Duplicate | This transaction was detected as a duplicate of another |
| Bank feed | Imported via a live GoCardless bank feed connection |
| Statement | Imported from an uploaded PDF bank statement |
A transaction can carry multiple labels at once — for example, a statement import that is also a duplicate will show both Statement and Duplicate.
Filtering by label
Below the main filter bar on the Transactions page, there is a row of toggleable pill filters. Click any pill to activate it; click again to deactivate. Multiple pills can be active at the same time — the results show transactions matching any of the active pills in each group.
Available filter pills: Bank feed, Statement, Duplicate, Unmatched, Matched, No invoice needed.
Manually marking a transaction
Even without a matching pattern, an accountant can mark any unmatched transaction as no invoice needed directly from the transaction detail panel:
- Click on the transaction row to open the detail panel.
- In the Match section, choose a transaction type from the dropdown — or select No specific type if none applies.
- The transaction is immediately marked as No invoice needed.
To undo this, click Undo — mark as unmatched in the No invoice needed section. The transaction returns to unmatched and will reappear in the Missing Documents list.
Both the mark and the undo are remembered — see Teaching AIFT which transactions need an invoice above. Marking a few of the same kind is usually enough for AIFT to handle the rest on its own.
Only Accountant and Accountant admin users can mark or unmark transactions. Clients can see the label but cannot change it.