Imports — bank statements and CSV
Being builtPartly works today — the limits are below.
Countbean imports a bank export by mapping each row to two accounts — the account the money moved through and the category it belongs to — so every imported transaction balances before it is written.
What works today
Hand the agent a file — CSV, OFX, QFX, a PDF statement — and it reads the rows,
maps them to accounts, and writes balanced transactions. Anything it cannot
classify confidently is flagged ! and left pending rather than guessed.
This works because the model reads the file. There is no deterministic importer behind it yet, which has three consequences worth knowing:
- Column mapping is re-derived on every run, so two imports of the same statement can differ on an ambiguous column.
- Duplicate detection is not systematic. Re-importing an overlapping export can double-book.
- The Telegram bot accepts a statement file and reaches the same result, but by the same route — the model reads it. The chat is deliberately at parity with the plugin here rather than ahead of it.
What is being built
A server-side importer with the column mapping returned in the response, explicit handling for the three amount-column shapes, and a stable per-row key so a re-import cannot double-book. Tracked as #515.
The three shapes an amount column comes in
| Shape | Looks like | The trap |
|---|---|---|
| Signed amount | -42.00 | Some banks sign from their side |
| Split debit/credit | Debit: 42.00, Credit: | Empty string, not zero |
| Running balance | Balance: 4,182.00 | The amount is a difference between rows, so row order is load-bearing |
What there is not
No bank feeds. No direct connection to any bank, and none planned. You export a file — which is also why every bank in every country works on your first day, with no integration list to be missing from.
Something here wrong or missing? Put it on the board — it is public, and the reply is in the thread.