# Bank data ingestion: camt file import

> From the Zendrea manual for AI assistants, generated 2026-10-31 from the knowledge of Zendrea's built-in assistant. All topics: https://www.zendrea.ch/llms.txt; all of them in one file: https://www.zendrea.ch/llms-full.txt. Screen names are quoted in English, account numbers are those of the standard Swiss chart, and nothing here is tax or legal advice.

Bank transactions get into the app exactly ONE way: the camt file import described below. They land in the Bank Transactions table and drive reconciliation. Reconciliation has a durable state per movement — "reconciled" (abgeglichen) is a persisted fact, not a live guess.

The leftmost column of each bank row is a PASSIVE STATUS ICON — it says what the movement is and is never clickable. Whatever the user can DO about it sits in separate buttons immediately to its right (confirm, record payment, undo), each with its own tooltip. Colour is a severity ramp: GREEN = reconciled (the only green in the table), AMBER = a suggestion to confirm, ORANGE = verify, RED = missing or wrong, GREY = no action needed. The statuses:
- SOLID GREEN check: RECONCILED — this movement is settled against one specific booking. It got there either automatically or because the user confirmed a suggestion; the tooltip names the booking and says which. A movement reconciles ITSELF only on an exact key the bank itself supplied, never on a guess, and there are exactly two such keys: (a) the creditor/QR REFERENCE plus the amount, both agreeing unambiguously; or (b) the counterparty ACCOUNT (IBAN) — the recipient's account as the statement reports it equals the account the booking's counterparty is known to hold, with amount and direction equal and the dates within ten days. Key (b) is what reconciles SALARIES and recurring SUPPLIER payments (rent, leasing), which carry no reference of the booking's own: it needs the employee's IBAN on their master record (Employees panel), or the supplier's IBAN saved in the supplier dialog (Suppliers panel) with the payment booked to that supplier's K-… account (a payment of a bill on the collective 2000/2004 names no supplier, so it has no key (b)). A statement line that carries a reference is normally left to key (a) — except when it is the supplier's saved FIXED reference (e.g. rent paid to a QR-IBAN), which then counts as part of key (b). Key (b) deliberately stays silent when two equal payments to the same account fall in one window — that is the double-payment shape, which the user must see. Both keys run at import time and again the moment a matching payment is booked, or an employee's or supplier's IBAN is entered. A small undo arrow next to the marker takes the reconciliation back.
- AMBER check: a SUGGESTION — reference+amount agree but not unambiguously, or same amount + direction with a booking date within a few days (fees etc. carry no bank-side reference, and a salary or supplier payment whose IBAN is not captured on the employee or supplier, so they can only match this way). Suggestions are inferences: the user confirms one with the double-check button beside the marker, ROW BY ROW — there is currently no bulk "confirm all" button. Confirming turns it into the green persisted state — green is reserved for reconciled facts.
- GREY SLASH with NO buttons next to it: UNIDENTIFIED — the app declines to reconcile this movement at all, shown greyed with no suggestion, no automatic clearing and no action, because every action would assert something the app cannot stand behind:
  - UNIDENTIFIED: the statement never said which account the movement belongs to (no IBAN in the file), so attributing it would be a guess. The remedy is on the bank's side — statements that identify the account by IBAN; there is nothing to click in the app.
  - ORANGE X (rejected payment): the bank SENT A PAYMENT BACK — it declared the entry a reversal. BOTH legs are marked: the returned movement and the original payment it cancels. The booking those legs were attached to is therefore NOT paid, and the app says so by releasing it — the original movement's reconciliation is withdrawn, so the booking is open again. What the user must do is OUTSIDE this panel: send the payment again from e-banking with corrected details (a wrong IBAN is the usual cause). The corrected payment arrives in the next statement and reconciles against that same booking automatically — no re-booking needed, and it is NOT reported as a double payment. The rejected pair itself is never reconciled and carries no buttons; the two legs cancel each other in the account balance. If instead the user prefers to drop the whole thing, they delete the payment booking.
- GREY SLASH with an undo arrow: HIDDEN. **There is no longer a "hide" button** — it was removed in September 2026 once every case it served was handled at the source (pending entries are not imported; unattributable rows and returned payments are shown unreconcilable). A movement cannot be written off by hand any more, deliberately: a real movement always moves the balance, so hiding one would let the books drift from the bank with nothing to catch it. Rows in this state exist only from before the removal or from an imported archive; they keep their undo arrow, which restores them. Never tell a user to hide a movement — if one has no booking, the answer is to book it, or to correct/delete the booking that was wrong.
- GREY SIGMA (sum symbol Σ): the row equals the SUM of several same-day booking lines that belong to different bookings (a split booking paid as one transfer) — effectively matched, nothing to do, which is what the grey says. It deliberately does NOT wear a check: a one-movement-to-several-bookings reconciliation cannot be stored yet, so there is nothing to confirm either.
- ORANGE circle alert: verify the amounts — the reference matches but the amount differs (under/overpayment), or a single close-but-not-equal amount candidate exists.
- RED cross (X): NOT IN THE BOOKS — no payment booking explains this movement. Two shapes: nothing related was found at all (e.g. bank fees never booked; fix: create the booking), or the movement carries the reference of a known invoice that is NOT marked paid in the app — money arrived, the payment booking is missing. In the second case a payment-arrow ACTION button sits next to the status icon and records the payment on that invoice in one click.
- RED warning triangle: likely a DOUBLE PAYMENT — a second movement carrying a reference whose payment is already accounted for (including one already reconciled). Investigate before booking anything.
**PENDING movements are not imported at all.** Only entries the bank has actually BOOKED become bank movements in the app; pending, information-only and future-dated entries (which intraday camt.052 files carry) are skipped on import, because a movement that has not hit the account balance cannot be booked and would sit in the panel forever. When the bank books it, it arrives as a normal movement. So if a user asks why a payment they made today is not in the list yet, the answer is that the bank has not booked it yet — not that the import failed. A statement entry whose status the bank left empty IS imported: an empty status means unknown, not pending.
A payment booked together with its difference line — or lines: a Skonto books a net reduction plus a VAT-correction line — (VAT, AHV, bills, invoices) reconciles as ONE movement: the app nets that booking's lines on the account (the bank only ever saw the net), and every member line carries the marker.
The panel currently shows NO summary line above the table and no bulk-confirm button — both are hidden for the time being, so per-row markers are the whole story; do not tell a user to look for counts or a "confirm all" button. Reconciled state maintains itself: editing a reconciled booking so its bank amount no longer agrees re-opens the movement automatically (an edit that leaves the bank leg untouched keeps it), deleting the booking re-opens it, and re-booking it correctly reconciles it again without any clicking. On the first open after this feature arrived, unambiguous reference matches across existing data were reconciled automatically.
Discrepancies are marked on BOTH tables: the paired booking row in the left (bookings) table carries the same marker (green check on every leg of a reconciled booking, orange circle for amount deviations), so an issue is findable from either side. A booking with no bank counterpart whose date falls INSIDE the period covered by the imported bank data gets a RED cross ("no bank movement found ... within the imported period") — a booked movement the bank never saw; investigate. A booking with NO marker at all lies outside the imported coverage — the bank data simply doesn't extend to its date.
The assistant has NO tool that reads bank movements or their reconciliation state: it can explain how all of this works and where to click, but it cannot list a company's open or reconciled movements — those live on the Bank Account report's screen (the bank rows are also scoped to the selected account and fiscal period there).
The ingestion path:

**Manual camt file import (no bank contract needed).** The **Bank Account** report header has an "Import bank flows" button that accepts a camt.053/.052/.054 XML file — or a ZIP of several — as downloaded from any Swiss e-banking portal (at PostFinance: Documents → Account statements; the ISO-20022 statement format usually has to be activated once with the bank first). CSV and MT940 files are NOT supported — only camt XML. A file whose account IBAN belongs to a different company in the app is rejected to protect against mixing books — unless the IBAN is also configured as the current company's own bank account (cloned/demo companies legitimately share IBANs); in a rejection, adding the IBAN under the company's bank accounts in Settings and re-importing resolves it. Re-importing the same or overlapping statements is safe: duplicates are skipped automatically.

**There is NO direct bank connection (EBICS) in this build.** The app cannot fetch anything from a bank by itself: there is no connection wizard, no EBICS settings tab, and no fetch buttons on the Bank Account report. Do not describe one, do not route a user to one, and do not treat a missing connection as something the user failed to set up — it is simply not part of the app right now. A direct bank connection is intended as a future Premium feature; no date is announced. If a user asks for automatic or daily fetching, say exactly that and point them at the file import, which is the whole answer today.

Nothing is lost by its absence. Reconciliation, automatic invoice payment matching, the double-payment checks and every marker described above run on file-imported transactions exactly as they would on fetched ones. The bank-movements panel of the Bank Account report appears as soon as any bank data exists; a chevron in the panel's top-right corner hides it, and a slim chevron strip at the report's right edge brings it back.

**There is no manual assignment workbench.** The app proposes matches on its own (reference, or amount+date) as amber-check suggestions the user confirms — but an unmatched transaction has no "assign to an arbitrary booking" or "book from transaction" action (unlike DATEV/Lexware-style bank reconciliation). An unmatched movement means the corresponding booking doesn't exist yet (or carries a different reference) — the fix is to book the movement through the normal forms; the suggestion then appears by itself, and an unambiguous reference match even reconciles automatically. The one exception: an incoming payment the matcher ties to an open customer invoice (QR reference, or the original amount of a foreign-currency payment) carries an action icon next to its red cross that opens that invoice's payment dialog pre-filled from the line (date, amount, bank account); see the topic [bank-file-import](https://www.zendrea.ch/docs/bank-file-import.md).