Importing Your Data

Nobody wants to re-type five years of history. The Import menu takes what you already have in a spreadsheet — customers, vendors, invoices, opening balances — and loads it in bulk. It’s the first thing you do at go-live, and it stays useful afterwards for the occasional batch.

The one thing to know up front: there’s no file to upload. You copy the columns out of your spreadsheet and paste them into a grid on the page. It sounds like a workaround and it isn’t — it means you can fix a value, re-paste a block, and check what you’re about to load, all before anything is written.

Take it slowly the first time. An import is not undoable, and the order you do things in matters more than anything else on this page.

Do these first, in this order#

Import validates every value against data that already exists. Load things in the wrong order and every row fails on a reference that isn’t there yet.

1. Chart of Accounts, Taxes and Currencies — every account number and currency code you paste is checked against these. Nothing else can be imported until they’re right.
2. Customers and Vendors — invoices reference them by number.
3. Services — invoice lines reference them by item number, and there is no bulk import for the catalogue. If you’re going to import invoices, the services on them have to be created first, by hand.
4. Opening balances as a General Ledger import.
5. Invoices and transactions last.

Departments and projects have to exist too, if you reference them. The General Ledger import reports an invalid Project Number; everywhere else an unrecognised department or project is quietly dropped rather than reported.

The screens#

Everything lives under Import, and each entry is the same grid with different columns:

Bank statements and card statements are also in this menu but work completely differently — see CAMT Import and Card Statements.

Permissions have a trap here. Each screen needs its own permission (import.customer and so on), but every screen also needs the General Ledger import permission to load the accounts and currencies it validates against — with only its own permission, a screen can’t validate anything and rejects every row. Committing needs a third: the permission to create that record type the normal way — Add Customer / Add Vendor, Sales Invoice / Vendor Invoice, Customer Transaction / Vendor Transaction. Only the General Ledger import stands on its import permission alone. If imports fail for one colleague and work for you, this is why — grant all three.

How the grid works#

Pick your columns, paste your rows, check, commit.

Select Columns decides what the grid shows. Required columns are always ticked and can’t be turned off. Default Columns gives you the usual set, Required Only strips it to the minimum, Select All shows everything available. Tick the columns that match your spreadsheet, in the order you want to paste them.

Then copy the matching block out of your spreadsheet and paste it into the grid. It starts with 50 empty rows; Lines to add plus Insert Rows gives you more.

Validate Data checks everything without sending anything anywhere. Bad cells are highlighted and the problems listed. This is a genuine dry run — use it as often as you like.

Import Data validates again and refuses to send if anything is still wrong. There’s no “import the good rows and skip the bad ones” — you fix the file until it’s clean, then it goes.

A column you untick isn’t validated. If you hide a column that had a problem in it, the problem stops being reported — it doesn’t stop existing.

Some shortcuts save a lot of typing. All of them use Ctrl + Shift and act on the selected cell. N and T write straight into the cell; the others open a searchable picker under the grid, and the value lands in the cell when you choose it:

Only the pickers that make sense for the screen appear — services on the invoice screens, line and payment accounts on the transaction screens.

What goes in the columns#

Required columns can’t be unticked; everything else is yours to choose.

General Ledger — required: Reference, Trans Date, Currency, Account No, Debit, Credit. Commonly used: Department, Description, Source, Memo. Also available: Notes, Exchange Rate, Project Number, Tax Account, Tax Amount.

Every line sharing a Reference becomes one journal entry, and each group must balance — debits equal credits — or validation names the reference and the difference. This is how you load opening balances: one reference, one line per account.

Customers / Vendors — required: Customer Number (or Vendor Number), Name, Currency, Start Date. Then the ordinary record fields: Contact, Street Name, Street Number, City, Zipcode, Country, Phone, Email, Terms, Discount, Credit Limit, Tax Number and more under Select All, including bank details and a second address line.

Street Name and Street Number are deliberately separate. Swiss payment standards need a structured address — the house number in its own field — for QR-bills and payment files. If your spreadsheet has “Bahnhofstrasse 12” in one column, split it before you paste, or every payment file you generate for that vendor will be missing its house number.

Sales Invoice / Vendor Invoice — required: Customer Number (or Vendor Number), Invoice Number, Invoice Date, Due Date, Currency, Account, Item Number, Item Description, Quantity, Price. Optional: Description, Tax Included, Discount, Unit, and under Select All things like Exchange Rate, Order Number and Department.

Customer / Vendor Transactions — required: Customer Number (or Vendor Number), Invoice Number, Invoice Date, Due Date, Currency, Account, Line Description, Line Amount, Line Account. Use this when the document posts straight to accounts and there’s no catalogue item involved.

A payment can be imported alongside a transaction, but only if Payment Date, Payment Amount and Payment Account are all filled in. Any one of them missing and no payment is recorded — silently.

Formats that trip people up#

• Numbers. Swiss formatting works: 1'250.00 reads as 1250. But 1.250 meaning one thousand two hundred and fifty reads as 1.25 — the last separator is treated as the decimal point. Anything unreadable becomes 0 rather than an error, which is the dangerous part. Export your spreadsheet with plain numbers.
• Dates. dd.mm.yyyy is the safe choice. Several formats are accepted, but day-first is tried before month-first, so 03/04/2026 is 3 April, not 4 March.
• Currency must be exactly three letters and must already exist. Any currency other than your base currency needs an Exchange Rate. The General Ledger import enforces this — a blank rate is a validation error while the column is shown. The invoice and transaction imports don’t check it, and a hidden column is never checked: there a blank rate silently becomes 1.0, which for a foreign currency is almost never what you want.
• Tax Included only accepts 1 or true. Anything else means “not included”.
• Umlauts and accents are fine.

Re-importing, and what can’t be undone#

Customers are matched on their number. Paste a Customer Number that already exists and that record is updated; paste a new one and a new customer is created. That makes a corrected file safe to re-import — it doesn’t pile up duplicates.

Vendors update only. The Vendors screen checks every Vendor Number against your existing vendors and rejects unknown ones at validation, so it can’t create new vendors — create them first under Vendors → Postings → Add Vendor, then use the import to fill in the rest. Re-importing an existing vendor updates it, same as a customer.

Invoices, transactions and GL entries are not matched on anything. Import the same file twice and you get two of everything. If an import half-worked, check what actually landed before running it again.

There is no undo. No rollback, no “reverse this import”. Correcting a bad import means deleting the records one by one — which the period lock and your deletion settings may not even allow. See Closing the Books.

So: import a handful of rows first. Look at what they produced — open one customer, look at one invoice in the GL Journal. Then paste the rest.

When something fails#

If every row succeeds, the grid clears and you’re told it worked.

If anything fails, the grid keeps your rows so you can correct them, and you’re told how many succeeded, how many failed, and why each one failed. (One exception: a General Ledger import in which every entry fails reports only a general error and greys out Import Data — run Validate Data to see the individual problems.) The rows that succeeded are already saved — so fix the failures and re-send only those. For customers and vendors, re-sending the whole file is safe too, since existing numbers update rather than duplicate.

Rows are processed one at a time rather than all-or-nothing, so a partial import is a normal outcome, not a broken state. Large files are handled in one request, so break a very large history into a few thousand rows at a time rather than pasting everything at once.