# Statement processing

URL: https://docs.clatri.com/en/finance/statements/

> How to import bank statements from PDF, Excel, photo or video into Clatri: a reviewable draft, duplicates, internal transfers and import instructions.

Bank statements are the most complete way to record your financial history in Clatri — richer than chat (which is good for stray day-to-day expenses) and available for every bank (unlike [open banking](https://docs.clatri.com/en/finance/open-banking/), which only covers some countries). And if you have neither a statement nor a computer at hand, just [record a video](#import-movements-with-a-video) of your banking app scrolling through the movements. The Finance Expert reads the document and leaves you an editable draft you approve before anything is recorded.

This page describes the full process: statement types, the import flow, the split of responsibilities between **what the extractor reads** and **what the accounting decides**, the smart features the system applies (duplicates, internal transfers, counterparts and projects) and the **per-entity instructions** you can write to guide the extractor.

## Statement types

| Type | When the bank issues it | What it covers |
|---|---|---|
| **Account statement** | Monthly or quarterly, depending on the bank | Movements of a checking or savings account in a period. Debit cards do NOT issue their own statements — their movements live in the statement of the account they're linked to. |
| **Credit card statement** | After each **statement-close date** | Charges, payments, and fees from the cycle between the previous close and the current one. If your card closes on the 15th, the "April" statement covers from March 16 to April 15. |

That's why it's important to correctly configure the **close date** and **payment due date** when you create the card in Clatri — the system uses them to align the statements you upload and to generate notifications.

## The extractor doesn't classify

This is the most important idea on the whole page, and the one most people assume the other way around.

The extractor **doesn't make accounting decisions**. It reads the document and reports what the document says. From each line it takes two things about the money:

- **The direction** — whether that line *adds* money to you (`income`) or *takes it away* (`expense`). That isn't an opinion: it's a fact printed on the paper, in the debit and credit columns or in the running balance.
- **The provider category** — if your bank prints its own label on the row (*"Restaurants"*, *"Grocery"*, *"ATM"*), the extractor copies it **verbatim**, in the document's language, without translating it or mapping it to anything. If the bank doesn't print one, the field simply doesn't exist.

That's it. The extractor doesn't pick which account of the **[Chart of accounts](https://docs.clatri.com/en/finance/chart-of-accounts/)** the movement goes to, because that decision isn't in the document — it's in your rules.

It helps to be very clear that in Clatri there are **three different things** people call "category", and only one of them affects your reports:

| | What it is | Does it count in the books? |
|---|---|---|
| **Accounting account** | Your [Chart of accounts](https://docs.clatri.com/en/finance/chart-of-accounts/). The accounting truth. | **Yes** — it's the line in the [Income statement](https://docs.clatri.com/en/finance/reports/) |
| **Provider category** | The label your bank put on the row | No — it's *a signal* the classifier can use |
| **Product category** | The commercial shelf of your sales catalog | No — it's a label for your store |

Your bank writing *"Restaurants"* next to a charge doesn't mean that charge is a food expense in your books. It can be a meal with a client, a team lunch, or a charge the bank itself mislabeled. The bank's label comes in as a hint, not a verdict.

## Who picks the accounting account

When a transaction comes in —from a statement, from [open banking](https://docs.clatri.com/en/finance/open-banking/) or from chat—, a **canonical classifier** that lives in the database applies **your rules**, in this order:

| Priority | The rule looks at… | Example |
|---|---|---|
| 1 | **Prepaid balance** or **source account** | Everything leaving the operations account is an operating expense |
| 2 | **Recurring payment** | The monthly hosting charge always goes to the same account |
| 3 | **Counterpart** | Everything you pay this supplier goes to the same account |
| 4 | **Bank category** | What your bank labels *"Grocery"* goes to the account you chose |
| 5 | **Description pattern** | Rows containing a certain text go to the same account |

If **no rule matches**, the transaction stays **Unclassified**. And that's fine: it's the correct default, not a failure. Clatri **never guesses** an accounting account. It would rather tell you *"I don't know where this goes"* than put it in a made-up line that later muddies your [Income statement](https://docs.clatri.com/en/finance/reports/) without you noticing.

Unclassified transactions wait for you in the queue so you can resolve them whenever you want — one by one or in bulk.

### How a rule is created

You don't write rules in a separate form. You create them **from the transaction itself**, where you have the context in front of you:

1. Open the transaction and go to **Accounting**.
2. Pick the right **Accounting account**.
3. Turn on **Use this correction in the future** and choose which criterion the rule should match: the counterpart, the recurring payment, the bank category, the source account, the description pattern.

You correct it once and from then on the classifier does it on its own. If the transaction has nothing a future rule could match, Clatri tells you instead of offering a rule that would never fire.

## The import flow

You upload the file (PDF, Excel, CSV, screenshot or [video](#import-movements-with-a-video)) to chat and the agent processes it in 5 steps:

1. **Extraction** — the LLM extractor reads the document and produces a structured list of transactions: date, amount, currency, description, direction and, if present, the bank's label. Your per-entity instructions are applied here (see below).
2. **Association resolution** — for each transaction it tries to infer the **counterpart** (which contact) and the **project** it belongs to, consulting your [contact directory](https://docs.clatri.com/en/space/people/) and your existing [Projects](https://docs.clatri.com/en/finance/).
3. **Duplicate detection** — compares each transaction against the ones you already have recorded (manual, bank integration, previous statement) using amount + date + description. Matches are flagged as duplicates.
4. **Verification** — checks what was extracted against the totals and the balance declared by the document itself. If the sum of the movements doesn't rebuild the closing balance, the system catches it before showing you anything.
5. **Staging and review** — the agent returns an interactive widget with the list of transactions: new, duplicates, technical movements, and ones that need manual review. You edit, discard, or confirm. **Nothing is recorded until you approve.**

### Reconciliation vs new registration

When executing the import you can choose between:

- **New registration** (default) — transactions are recorded and update the account's current balance. Useful for a recent statement that brings your account up to date.
- **Reconciliation** — records historical transactions without modifying the current balance. Useful when you upload past months and don't want them to recalculate a balance you already knew.

## Technical movements and the "To assign" tray

Not every line on a statement is an expense or an income. Many are **money moving from one of your pockets to another** — and treating them as an expense would count the same thing twice.

The extractor recognizes them and tags them with a movement type:

| Type | What it is |
|---|---|
| **Debt payment** | You pay the credit card from your account |
| **Internal transfer** | Leg that *arrives* from another account of yours |
| **Transfer to savings** | Leg that *leaves* toward another account or pocket of yours |
| **Loan disbursement** | The bank disburses a loan to you |
| **Own deposit** | You deposit your own cash |
| **Refund** | A return, a reversal, a chargeback |

These movements **don't go to the Income statement**. They land in **temporary control accounts** — an accounting limbo that exists precisely so money doesn't disappear or get invented while you confirm where it was really going.

That's where **[To assign](https://docs.clatri.com/en/finance/assign/)** comes in: the tray where you connect each technical movement with its real destination (which debt you paid, which account the transfer reached, which savings grew). Until you do, the movement keeps affecting your account balance —because the money did move— but stays out of your results, which is exactly where it belongs.

## Duplicate detection

When you import a statement, the system compares each new transaction against existing ones with a heuristic that combines:

- **Exact amount** (same sign, same currency)
- **Date** within a tolerance window (±2 days for statements, up to 5 days if the transaction came from a recurring payment because banks sometimes take time to process)
- **Description** with normalization (uppercase, spaces, accents stripped; fuzzy matching)
- **Account / card** — only compares against transactions from the same account

Transactions identified as duplicates appear with a special indicator in the review widget. By default they're NOT recorded, but you can force registration case by case if you decide the duplicate is actually legitimate (same amount on the same day by coincidence).

The same duplicate engine also applies to [open banking](https://docs.clatri.com/en/finance/open-banking/) — when a new transaction arrives from the bank, it first checks whether you'd already recorded it manually or by a previous statement.

## Internal transfers: pair, don't create

If you transfer money from one of your accounts to another of your accounts, that movement shows up **twice**: as an outflow on the first account's statement and as an inflow on the second's. They're two rows the bank already recorded. The money didn't change owner and nothing was created or destroyed.

Pairing them is exactly that: **connecting the two rows that already exist**. The system doesn't fabricate a third transaction, doesn't invent a new movement and doesn't touch your consolidated cash. What it does is **settle the two control accounts** each leg landed in, leaving them at zero. The result is that both your balances are right and your Income statement sees neither a phantom expense nor a phantom income.

Clatri **suggests** candidate pairs —same amount, opposite signs, close dates— with a score and the reasons behind each one. But it's a **suggestion**: nothing gets paired until you confirm it. If there are two similar candidates, Clatri doesn't choose for you; it shows you both. All of this lives in **[To assign](https://docs.clatri.com/en/finance/assign/)**.

The same applies to a credit card payment: the outflow from the account and the credit to the card balance are the two legs of a single movement.

## Automatic association to contacts and projects

During extraction, the LLM reads each transaction's description and tries to resolve:

- **Counterpart** — searches your [contact directory](https://docs.clatri.com/en/space/people/) by name or alias. If it finds a match (or your per-entity instruction gives it the hint), it pre-assigns the contact.
- **Project** — if the description matches the name of an existing [Project](https://docs.clatri.com/en/finance/), it pre-assigns it.

These are **assistive suggestions**, and the extractor is explicitly instructed to prefer leaving them out over making them up: it never proposes a contact or a project that doesn't exist in your directory, and when in doubt it proposes nothing. You confirm, change, or discard them in the review widget before executing the import.

Don't confuse this with accounting classification. The counterpart is **who** — the accounting account is **what**. They're two different questions, even though the counterpart can later serve as the criterion of a rule that does decide the account.

## Multi-currency and opening balance

If your statement is in a different currency from the account's main currency, the system asks for the exchange rate for the conversion. Transactions are stored in both currencies (original + converted) so you can see the real detail and a consistent aggregate.

Also, if the statement includes a starting / ending balance, the system uses it as an **opening balance** to align the historical balance calculation with your current balance — avoiding the drift that would happen if you only sum/subtract transactions.

## Import movements with a video

Most banking apps don't let you download your movements, and the official statement arrives a month (or a quarter) later. That's what video is for: you record your screen while scrolling through the movements in your bank, wallet or investment app, and Clatri extracts them for you. It's the simplest way to catch up without waiting for the statement.

**How to do it:**

1. Open your banking app on the movements list of the product you want to import (an account, a card, a wallet).
2. Start your phone's screen recording and scroll through the list at a steady pace, with dates and amounts visible.
3. In the Clatri chat, tap **+** → **Bank transaction video** and pick the video.
4. In the same message, say which product it is, for example: *"record these movements on my BBVA credit card"*. If you don't and Clatri can't work it out, it asks you; you don't need to upload the video again.

**Limits:** one video per message, under one minute and up to 60 MB, in MP4, MOV or WebM. For a long history, record several clips and send them in separate messages. One product per video works best: if you mix accounts in the same recording, Clatri asks you to clarify before preparing the draft.

**Credits:** before you send it, the app shows an estimate of the credits for extracting the video. It's a guide; the analysis and import that follow use credits separately. See [Pricing](https://docs.clatri.com/en/pricing/).

**What you get:** the same review draft as with a statement, with duplicate detection. Nothing is recorded until you approve. The difference is that a video is a **list of movements**, not a formal statement: it has no declared opening or closing balance, so it can't verify the closing balance. If you later upload the official statement for the same period, the movements you already imported by video show up as duplicates.

The original video is stored encrypted alongside your import.

## Receiving statements by email (automatic)

You don't have to download and upload every statement by hand. Your bank emails it to you each month — you can have it land in Clatri **on its own** and get processed without lifting a finger.

Each profile has an inbound address (something like `a1b2c3d4@inbox.clatri.com`) you can **forward** your bank's emails to. And if you set up **automatic forwarding** in Gmail or Outlook with a filter on the bank's sender, every statement that arrives goes straight into the import flow above: Clatri reads it, leaves it as a draft, and you approve.

If the PDF is password-protected, Clatri tries to open it with your national ID and available passwords. You can ask in chat to save a password for future statements; background reuse depends on the encrypted data being accessible.

The step by step — including how to set up forwarding in Gmail and Outlook — is in **[Receiving documents by email](https://docs.clatri.com/en/email/)**.

## Per-entity instructions — teaching the extractor to READ

Each entity in Clatri has a free-text field called **Statement import instructions**. You'll find it on the **Accounts** screen, in the **"+"** menu → *Statement import instructions*.

It's unstructured text, in your language, where you write the **conventions and quirks of the document** the LLM extractor can't guess on its own. It's prepended to the prompt with **maximum priority** every time you import a statement, so the agent "knows you" without you having to repeat it in every chat.

**This guides EXTRACTION, not classification.** It's the distinction that confuses people most, so it's worth saying plainly:

| You want… | Tool |
|---|---|
| The extractor to **read the document correctly** (which column is which, which rows to ignore, who is who) | **Statement import instructions** |
| A movement to **be filed under a certain accounting account** | A **rule**, created from the transaction with *Use this correction in the future* |

Writing *"maintenance fees are an administrative expense"* here does nothing: the extractor doesn't classify. That knowledge goes in a rule (see [Chart of accounts](https://docs.clatri.com/en/finance/chart-of-accounts/)).

Real use cases for this field:

```text
Any transaction to "Julia M.", "MARIA CASTRO" or "J CASTRO" is to my mom.
Associate it with the "Mom" contact.

In my bank's statements the balance appears in the second column,
not the first.

Ignore all lines containing "INTERESES CORRIENTES" — they're
bank aggregates that duplicate the actual movement.

Rows in the "Collateral" section are not part of the account balance;
the bank lists them for reference only.

Transfers to my savings account come with the description "APORTE" —
they're transfers between my own accounts, not expenses.
```

As you can see, it ranges from **contact aliases** to **document conventions** ("balances in column 2"), **filter rules** ("ignore X lines") and **routing hints** ("this is a transfer between my own accounts"). Everything that helps *read* the paper. It's the only way to encode knowledge the LLM can't have otherwise, because it depends on your life, your contacts, and your specific bank.

**Per entity, not per account**: if you have a personal entity and another for your company, you can have different conventions in each. The personal ones can talk about your family; the company ones, about specific suppliers and clients.

## What to do when something goes wrong

- **The extractor didn't read a transaction correctly** (amount, date, description) → fix it in the staging widget before approving. If the error repeats on every import from the same bank, add the convention to the **Statement import instructions** so it doesn't happen again.
- **The transaction ended up Unclassified** → it's not an error, it's the default. Open it, go to **Accounting**, pick the **Accounting account** and turn on *Use this correction in the future* if you want it to repeat on its own.
- **It landed in the wrong accounting account** → same path: you fix the account and create the rule. The correction leaves a trail; nothing is silently overwritten.
- **The extractor duplicated a transaction that is NOT a duplicate** → uncheck the duplicate flag in the widget; it'll be registered normally.
- **Two movements were paired as an internal transfer and weren't one** → you can revert the pairing; both sides go back to their control account and become available again in **[To assign](https://docs.clatri.com/en/finance/assign/)**.
- **The extractor made up data** (hallucinated) → report it in Settings → Feedback. The extractor is tuned but no LLM is perfect; knowing where it fails helps us improve the prompt.

## Retry an existing document

If a statement could not be processed, you can ask to retry with the document you already sent. A temporary download failure, an incorrect password, and an extraction failure need different solutions; you do not need to upload the file again while it remains available. See access and password-storage limits in [Receiving documents by email](https://docs.clatri.com/en/email/#password-protected-documents).

A [Schedule](https://docs.clatri.com/en/schedules/) can ask Clatri to review available information, but it does not bypass locked encrypted documents or replace review of the import draft.