Importing your spreadsheet

Nobody starts a business on the day they start using OrderDen. There is a spreadsheet with your customers in it, a materials tab, a shelf that was counted last Sunday and invoices still out from last quarter. The importer takes all of it — ten kinds of record, one CSV file at a time — shows you what it understood, and only writes anything once you say so. One button puts a whole run back.

Open it from Import on the Clients, Items or Materials list, or from Company Settings → Your data → Import a spreadsheet.

What you can import

The wizard groups the ten kinds by what they are, and that order is also the order to do them in: each group only depends on the ones above it.

Your records

• Clients — the companies you sell to, with an email, a phone number, any further contacts, tags, payment terms, a billing address and a shipping address. One address in the file becomes their default for both; a different shipping address is saved as a second one.
• Items — your catalog: item numbers, names, descriptions, prices, costs, units, barcodes and tags.
• Materials — the wax, wicks and jars you make things out of: a code, a name, the unit it is measured in, what it costs, a category, what is on the shelf today and the level you want reordering at.
• Vendors — who you buy from: their company name, email, phone, address, your account number with them, the currency they bill in and the terms they give you.
• Price list prices — trade and retail prices for a price list you have already created, with each line's minimum and case pack.

Your shelf

• Opening stock — what is physically here, item by item, with what it cost and (if you have more than one) which shelf it is on.

Your history

• Orders — what you sold before OrderDen: one row per line, rows sharing an Order # become one order, dated as the sheet says and written as Completed (or Cancelled). Lines name a catalog item by number or SKU when they match one, or stay free text when they don't; an item number nothing matches fails the row. No stock moves — the shelf came in through Opening stock and already reflects these sales — and nothing is invoiced, so nothing counts against a plan. Source is a free-text label for where the sale came from ("Etsy", "market", "repeat"), nothing more. The reports read imported orders like any other: revenue by client, item and period all have history to show from day one.
• Invoices — your sales history: what clients still owe you and what they have already settled, with the date and method of the payment.
• Payments — money received, including one payment spread across several invoices and money paid on account before anything was invoiced.
• Expenses — the year's spend from a bank export or a bookkeeping sheet.

The four steps

1. Upload. Choose what you're loading and pick your file. Commas, semicolons and tabs are all understood, so a European export or a tab-separated file needs no conversion. Quoted fields, cells that wrap onto several lines, and the invisible marker Excel puts at the start of a file are all handled. Up to 5 MB and 5,000 rows per file — split a bigger one and import the parts.

2. Map columns. Each column in your file gets a dropdown: which OrderDen field it fills, or Ignore this column. OrderDen fills these in for you from the column headings — "Customer", "E-mail", "SKU", "Cost per item", "Transaction date", "Lineitem sku" and dozens more are recognised — so usually there is nothing to change. Columns it doesn't recognise are simply ignored.

   A file OrderDen exported needs no mapping at all. Export a list, open it in a spreadsheet, fix the forty prices that were wrong and load it back: the headings are the ones OrderDen wrote, so every column lands where it came from. Columns that are worked out rather than stored — Margin %, Balance, Days overdue, Created, Updated — are left alone on the way back in, and your own custom fields still map by their own names beside them.

3. Review. The first 20 rows exactly as OrderDen reads them, with any problem cell highlighted and explained ("Name is required", "Unit price must be an amount like 149.50"). Above them, a table of every row that matches something you already have, and what it matched on.

4. Import. Rows with problems are skipped; everything else is written. You get a summary — created, updated, skipped, rejected — with the rejected rows listed by line number so you can fix them in your spreadsheet and import those separately.

Imported records are created exactly as if you had typed them in: the same validation, the same activity trail, the same numbering. Nothing about them is second-class.

Coming from a spreadsheet

The usual shape of a move, in order. Each file is a separate run, and each one can be undone on its own.

1. Clients first, from your customer tab. Names, emails, and one address each — or two, if you bill and ship to different places.
2. Items next, from your price list. An item number or a SKU, a name and a price is enough; costs and units make the margin figures work from day one.
3. Materials, from the materials tab. This is the one with a required column: every material has to name a unit that already exists (kg, g, ml, each and the rest are there from the start; add your own under Settings → Units). A unit typed as "kgs" is refused rather than invented, because every recipe converts through it. Categories work the other way: a category you don't have yet is created.
4. Vendors, from your supplier tab. Address columns are joined into the one address block a vendor carries, so nothing needs rearranging first.
5. Opening stock, from the count you did on Sunday. Name each item by its item number or SKU (a variant by its own SKU), say what you counted, and — if you have more than one location — which shelf. Re-importing a corrected count books the difference rather than doubling the shelf, so fixing a count is just fixing the file and importing it again.
6. Invoices, from your sales history. Each row needs a client you have already imported. An unpaid one comes in already sent, so it ages on the debtors report straight away and can be chased and paid. A settled one comes in settled: put what was paid in Paid so far, when in Paid date and how in Paid with, and OrderDen records a real payment against it rather than a status somebody typed — so the invoice lands Paid, the payment is on the right date, and the money shows up where money shows up. Status covers the two a payment cannot tell you, Void and Written off. None of it appears in your revenue, because those sales happened somewhere else. Imported history never counts against the free 50 invoices either: a migration is not selling you did here, so bring in all of it on either plan, including Free. See Plans & billing.
7. Payments, when your invoices file cannot say it all. One transfer that cleared three invoices is one payment, not three: put the invoices and their shares in Allocated to (2026-0184: 620.00; 2026-0191: 380.00) and it lands as one payment against all of them. A payment naming no invoice is money on account and needs a Client; anything over what the invoices owe becomes that client's credit. Import your invoices first.
8. Expenses, from a bank export. Date, amount and a category. Categories and vendors are created as needed; a project number that doesn't match anything leaves the expense unattached rather than inventing a project.

Duplicates

Before importing, the review step tells you exactly how many rows match something you already have, what each one matched on, and what the three choices would do to this file:

• Skip them (the default) — leave the stored record untouched.
• Update them — overwrite the stored record with the columns this file provides. Columns your file doesn't have are left alone, so a price-list re-import updates prices without erasing descriptions. On clients, contacts and addresses are never touched.
• Import anyway — create a second record. Rarely what you want.

What counts as a match depends on the kind:

Rows that repeat within the same file count as duplicates too, so a sheet listing the same customer twice imports them once.

Two kinds behave differently on purpose. Invoices and Payments refuse to be rewritten: an invoice that already has a payment against it cannot have its total changed by an import (correct it with a credit note), and a payment is a fact with a date on it rather than a record to edit — remove it and import the row again, or refund it.

That matching is also what stops an invoices file and a payments file booking the same money twice: a payment the invoices file already recorded is recognised when the payments file arrives, and skipped.

Already have duplicates?

Importing is how most workspaces get them, so the Clients list has a Find duplicates panel that groups the likely pairs — by shared email first, then by the same name at the same postcode — and merges from there. See Clients.

Undo

Every import is listed under Recent imports at the bottom of the page with an Undo button, and the same button appears on the summary right after a run. Undo archives everything the import created — it never deletes, so nothing is lost and archived records can be restored one by one from their list. (Expenses and payments are the exception: neither has an archived state, and a payment left behind would leave its invoices reading as settled by money that was never received, so undoing removes those rows outright.)

Records that are already used are left exactly as they are, and the undo tells you how many it kept: an item on a quote, a vendor on a purchase, a material a recipe consumes, an invoice that has taken a payment, a payment that has been refunded. If every record an import created is already in use, the undo is refused rather than half-done.

Undo covers created records only. Rows that updated an existing record are not rewound, and an opening stock run has nothing to undo at all — it creates nothing, it sets balances, and putting a balance back is importing the count that was right.

Templates

The upload step has a template for each of the ten kinds: a CSV with the right column headings and one example row, ready to fill in.

Or export what you have. Any list you export from OrderDen loads straight back in — the column headings are the ones OrderDen wrote, so there is nothing to map. That is the quickest way to make a bulk edit: export, fix it in a spreadsheet, import with Update them. Some exports do not have a CSV importer, and the reason is always the same one: a list row is a total and the document is its lines. Those come back through the full archive instead, which restores documents whole. The whole table is in Your data.

Common export shapes are recognised column-for-column, so a Products CSV from a webstore maps itself: Handle becomes the item number, Body (HTML) the description, Variant SKU the SKU, Variant Price the price, Cost per item the cost.

Your own fields

Any custom field you have added to clients or items is offered in the mapping step like a built-in one, labelled with the field's own name — so a sheet whose header already says "Wholesale account no." maps itself. Values are validated against the field's type on the way in: a date field rejects "the fourth", and a picker only takes its own choices.

A blank cell is skipped rather than written as an empty value. A spreadsheet is mostly blank cells, and "this file has no column for that" is not the same as "clear what is there".

Reading the errors

A row is rejected as a whole; a highlighted cell tells you which value caused it. The usual causes:

• A required field is blank — Name for clients, vendors and materials; Name plus an Item # or a SKU for items; Date and Amount for expenses.
• A price, cost or quantity isn't a number. Currency symbols, thousands separators and decimal commas are all fine ("$1,299.00", "14,50"); words are not.
• A date OrderDen can't read. 2026-03-14 is never ambiguous and is worth exporting if your spreadsheet offers it; a slashed date is read month-first unless the first number is over 12.
• A unit that isn't one of yours (materials), or a location that isn't one of yours (opening stock). Each message lists the ones you do have.
• A client an invoice names, or an invoice a payment names, that isn't there yet — import clients before invoices, and invoices before payments.
• A Status, Payment terms, Paid by, Method or Item type OrderDen doesn't know — the message lists the accepted values.
• Allocated to that adds up to more than the payment.

Importing from a script

Everything the wizard does is in the public API as well: POST /imports/preview to check a file, POST /imports to run it, GET /imports for the history and POST /imports/{id}/undo to reverse a run — useful for a nightly catalog sync from another system. GET /imports also lists every kind with its fields, so a script can build a file without hard-coding column names.