Import & export

Svodly works with standard formats — CSV, JSON and XLSX. Load your history from a bank, export data to Excel, move a book to another device without the cloud — all through ordinary files.

Importing transactions

If you are moving from a spreadsheet or a bank statement, the import will immediately pick up the columns by their Russian and English headers and suggest a mapping.

Supported formats

• CSV — comma, semicolon or tab as the separator. The encoding is detected automatically (UTF-8, Windows-1251, OEM-866).
• XLSX — an Excel file, the first sheet. Headers in the first row. Exports of the supported apps (ZenMoney, 1Money, Elba, Alzex, the template) are parsed on the phone via the migration tiles; import an arbitrary XLSX spreadsheet on a computer or on the web — the transactions reach the phone via the cloud.
• JSON — a transaction export from this same app. Like CSV, it adds transactions to the current book. To move a book as a whole — with its accounts, budgets, rules and attachments — you need the ZIP archive from “Moving a book as a whole”, not this import.
• Bank statement (1CClientBankExchange) — a kl_to_1c.txt file from your online bank. Recognized automatically — see “Importing a bank statement” below.

Steps

1. On the Transactions tab open the Import and export menu — the arrow-into-tray icon to the right of the filters — and pick Import. On the phone — the import icon in the Transactions screen header.
2. Drag a file into the window or tap “Choose a file”.
3. Check the column mapping: date, amount, category, counterparty, note. Svodly fills in the mapping itself, but you can change everything.
4. Choose the default account — the transactions whose account is not set in the file go there. If the file has a “Transaction account” column, map it and the default account is not needed.
5. Review the preview — a table of the transactions to come (the first 50 rows are shown, the import handles them all). Amounts in it use the familiar format and the currency the transactions will land in: “−250.00 ₽”, “30,000.00 ₽”. If something is off — go back and change the mapping.
6. Confirm the import.

The last source you picked is remembered on the device — the next import suggests the same tile. The column mapping of a universal file is worked out anew from the headers: a statement from the same bank has the same headers, so the layout will match.

Unsigned amounts: the “Transaction type” column

Many banks (T‑Bank, for one) export the amount without a sign and keep the direction of money in a separate column — “Transaction type” or “Operation type” with the values “Debit” (money out) and “Credit” (money in). Such a file is imported in a single pass: map that column to the “Transaction type (income / expense)” field — Svodly usually recognizes it by the header (“Тип операции”, “Дебет/Кредит”, Type, Debit/Credit, Dr/Cr) — and the sign of the amount comes from it: debit, expense, withdrawal, payment → expense; credit, income, deposit, refund → income. Both Russian and English words are understood, case does not matter.

There is no need to split income and expenses into two files. When the type column carries an off-beat header — “Операция”, “Движение”, “Вид расчёта” — Svodly looks at the values themselves: a column whose every value reads as a direction (“Расход”, “Доход”, “Списание”, “Зачисление”…) is picked up automatically. You can check it on the mapping step — such a column will show “Transaction type (income / expense)” in its “Field” select. And when no direction can be found in the file at all — every amount unsigned and no type column — the wizard says so with a banner above the table instead of silently importing everything as income.

• If the amount already has a sign, the type column wins: “Credit” next to “−200.00” gives an income.
• An empty cell and values that name no direction — “Перевод” (transfer), “Коррекция” (adjustment), “Инвестиции” (investment) — leave the sign as is: for those it already sits in the “Сумма” column. That is why the app’s own journal export (the “Тип” column = Доход / Расход / Перевод / Коррекция / Инвестиции) imports back without losses.
• A row with an unknown value (“Bonus”, “Other”) is marked in the preview as “Not recognized: transaction type “Bonus”” and skipped — the sign is never guessed silently. Fix the value in the file or unmap the column.
• If the file has two amount columns — “Debit” and “Credit” (Sber and 1C export this way) — they are mapped as “Expense amount” and “Income amount”; no type column is needed.
• A file that goes one way as a whole (only expenses or only income) with unsigned amounts — map its single amount column to “Expense amount” or “Income amount”. A second column is not required for that.

On the phone the columns are mapped automatically — the rule is the same.

Undo an import

Each import is saved as a separate batch and goes into the log: Settings → General → “Import and export”. The table shows the date, the file name and how many transactions the import created — a transfer counts as one transaction, and rejected file rows are not counted. On the web at phone width the same history — “History · N imports” — sits right under the source tiles of the import wizard.

To undo it, press “×” in the row of that import and confirm “Delete”. The confirmation says how many of the import's transactions are still in the book — they are all marked deleted in one action, and the account balance returns to its state before the import. Categories and counterparties the import created along the way stay where they are.

You can also undo older batches — for example, change your mind a week later. Undoing does not touch other transactions added manually between the import and the undo. On the desktop the app takes a book snapshot before the rollback, so you can change your mind afterwards too: an undone row gets a restore-from-backup button in the log. The web version has no backups, so an undo there is final — the only way to get the transactions back is to import the same file again. An undone row stays in the log marked “data deleted”.

Duplicates

Svodly recognizes a repeat only in a 1C-format bank statement: every payment document in the statement has its own key, and a document that is already in the book (or appears twice in one file) is simply skipped on import. Such rows are not marked in the preview, and the app asks nothing — you only see them in the result: on the computer and on the web the banner after the import says “duplicates skipped: N”, on the phone the final “N of M” shows fewer imported transactions than recognized ones.

CSV/XLSX tables and exports from other apps are not checked for repeats: load the same file twice and the transactions are doubled. An extra import is removed as a whole with a rollback.

Moving from another bookkeeping app

Moving from another app — ZenMoney, CoinKeeper, 1Money, Elba, Alzex Finance or a regular Excel spreadsheet? For popular apps there are step-by-step guides for moving your history without loss — see the “Migrating from other apps” section.

A service tile understands only that service's export. If the file turns out to be something else, the wizard on the computer and on the web says so — the file doesn’t look like a ZenMoney export — and offers Open as universal CSV/XLSX: the same file opens straight at the column-mapping step, with no need to pick it again.

Transactions arrive already labelled: the category and counterparty from the export are put on every row, not merely created in the references. A category from the file outranks your rules, the counterparty's history and the built-in dictionary — you get your own labelling, not one guessed from scratch. If a category in the file does not match the direction of the transaction (an expense category on an income), it is not applied, and the row can still be picked up by the rules.

A transfer between your own accounts in the Svodly template is written as a single row: the account money leaves goes in the “Account” column, the account it arrives in goes in “Account to”. Such a row arrives as a real transfer with the built-in “Transfer between accounts” category: the money leaves one account and arrives in another, but it counts as neither income nor an expense. In exports from other apps transfers still arrive as an “expense + income” pair, and those have no category — only a counterparty.

In Svodly’s own transaction export a transfer is written as two rows — one per account, exactly how it looks in “Transactions”. Importing such a file back joins both rows into a single transfer: the book gets as many transfers as it had, and the money moves the same way.

Importing a bank statement (1C format)

Besides spreadsheets, Svodly accepts a bank statement in the 1CClientBankExchange format (a kl_to_1c.txt file) — a universal Russian standard that almost any bank exports: Sberbank, T‑Bank, Alfa-Bank, VTB and others. In the import wizard, on the “Where are you moving from?” step, pick the “Bank statement · 1C format” tile and choose the file.

• Svodly recognizes income and expenses, creates and matches counterparties by INN.
• Auto-categorization by your own rules, by counterparty history and by the built-in payment-purpose dictionary: payments to a familiar recipient land in the same category as before. Your rules take precedence over both history and the dictionary — the fastest way to sort a large statement.
• The built-in dictionary recognizes insurance contributions, taxes (tax, VAT, personal income tax, USN, patent), acquiring and bank fees, rent and payroll in the purpose — and sets a category only if the book has a starter-set category with the same name and direction. The dictionary looks for the names of the Russian starter set: in a business book “Страховые взносы ИП”, “Налог по режиму”, “Эквайринг”, “Аренда помещения”, “Зарплата сотрудникам”, in a personal one “Налоги”, “Комиссии”, “Аренда / Ипотека”. If you renamed such a category, create a rule for it, otherwise the row arrives without a category. The “НДС не облагается” and “Без НДС” notes (no VAT) don’t count as a tax. Telecom, subscriptions, supplies and other payments are not sorted by the dictionary.
• Repeats: a payment document that is already in the book is silently skipped on import — loading the same statement again does not double the transactions (see “Duplicates”).

The preview shows how many transactions were recognized and how many counterparties are created/matched by INN; you can confirm the import or open the file as a regular CSV/XLSX. Statement import works on desktop, on the web and on the phone — the Windows-1251 encoding from an online bank is read right on the device.

Ready-made parsers for specific banks (PDF statements from Sber, T‑Bank, Alfa) are not available yet — that's post-v1.0 work. If your bank can't export the 1C format, save the statement as CSV or Excel: Svodly parses the column mapping automatically.

Exporting data

Export is useful in two scenarios: a backup (save the state of a book to a file) and an export for analysis (open in Excel or hand to an accountant).

Two different exports

Don't mix them up — these are different buttons for different jobs:

• The whole book in one file — Settings → Move the whole book → “Export the whole book”. You get a ZIP archive with everything the book holds. This is the backup and the way to move.
• The transaction log — on the Transactions tab apply the filters (period, category, account), then the Import and export menu (the arrow-into-tray icon to the right of the filters) → Export. Formats: CSV, XLSX, JSON. This is an export for analysis — it does not turn into a book archive.

What goes into the book archive

Everything you have put into the book: accounts with their initial balances, transactions with splits, tags and attachment files, transfers, counterparties, projects, budgets, recurring payments, auto-category and cashback rules, investment cards and trades, IIS deductions, business book documents. Inside the archive there is a data.json file in the open documented format and an attachments folder with the original receipts.

An attachment that is not on this device (you added a receipt from the phone and are exporting from a laptop) the app will try to download from the cloud. If that does not work out, such files do not make it into the archive, and the app honestly says how many there are.

Transaction export formats

• CSV — a flat list of transactions with Russian headers: “;” as the separator, UTF-8 with BOM — Excel and Google Sheets open it without any setup. Suitable for analysis.
• XLSX — the same transactions on the “Операции” sheet: the header row is frozen, the amount is numeric. If the exported transactions include FNS receipts, the file gets a second sheet, “Детализация”: the same transactions, but every receipt is expanded into one row per line item.
• JSON — the same list of transactions in a machine-readable form; the category comes as the leaf name category_name plus the path from the root category_path, and a transaction with an FNS receipt carries its line items in the receipt_items array.

In CSV and XLSX the category takes two columns: “Категория” — the top-level category of the transaction, “Подкатегория” — everything below it (“Coffee” inside “Food”; empty for a transaction filed under the top-level category itself). An Excel pivot “Category → Subcategory” therefore matches the groups in Analytics. The last column, “QR чека”, holds the fiscal receipt string for transactions with an FNS receipt — the one the “Проверка чеков ФНС” app scans. Such an export can be imported back, and the category hierarchy is restored.

The “Детализация” sheet: receipt line items

The sheet is for when the purchase total is not enough: you want to see how much went on milk or household chemicals, or hand your accountant the expenses with a breakdown. It holds every exported transaction: a transaction without a receipt takes one row, just like on the “Операции” sheet, while a transaction with an FNS receipt takes one row per line item, with the columns “Наименование” (name), “Кол-во” (quantity), “Цена” (price) and “Сумма” (amount). The result is one flat table — a ready base for an Excel pivot.

• “№ операции” — the transaction's sequence number on the “Операции” sheet (transaction No. 1 sits in the second row there, right under the header). It groups the items of one purchase.
• Item category — the one you assigned when splitting the receipt across categories; an unassigned item takes the category of the transaction itself. A split receipt therefore lands in the same categories as in Analytics.
• Item amounts carry the sign of the transaction: negative for an expense. If the items do not add up to the transaction amount (a discount, loyalty points, rounding, an amount edited by hand), a separate row “Разница с суммой операции” (difference from the transaction amount) holds the gap. The sheet total always matches the total of the “Операции” sheet.

If the export contains no receipts with line items, the file stays single-sheet. CSV does not carry receipt items — it is one flat table of transactions; a per-item CSV is available on the “Receipts” screen. Importing the file back reads only the first sheet, so the second one does not get in the way.

Exporting the book regularly is a simple way to play it safe. You can put the archive next to your photo album or upload it to any cloud of your own by hand.

Moving a book between devices and accounts

This works without the cloud, and between two different Svodly accounts as well — for example when you have changed your email and want to take your books over to the new account:

1. On the old device: Settings → Move the whole book → “Export the whole book”.
2. Send the ZIP file to the new device (a messenger, AirDrop, a flash drive, a cloud disk).
3. On the new device: Settings → Move the whole book → “Import a book from a file”, choose the archive.

The import creates a new book next to the existing ones and overwrites nothing. The same file can be imported several times — every time you get a separate independent copy. If you already have a book with that name, the new one gets the import date added to its name — say, “Personal finances from 27.09.2026”, and a second import on the same day also gets a number: “… (2)”. That way the two books don't get mixed up in the list; the new one can be renamed as usual. If the book had transfers into another book, they arrive as ordinary transactions: the second book was not part of the file.

The import cannot merge two books into one. If merging is exactly what you need, export the transactions to CSV and load them into the target book — a CSV import adds transactions rather than replacing them.

Where to go next

• Sync — if there are a lot of moves between devices.
• Shared access — if a book is kept by several people.
• Security — where the book file lives and who can see it.