Getting off spreadsheets without losing a year of history

The spreadsheet is not the problem. The problem is that three years of orders, customers and supplier prices live in it, and every tool that would replace it starts you at zero.

So the real question is not "is the new thing better", it is "what does moving cost me, and what do I lose".

What can move, and what cannot

Four things import from CSV: orders (with their line items), customers, expenses and pantry items (ingredients and supplies in one file, separated by a type column on each row).

Your history and your ingredient list import from CSV; the catalog is built once in the product builder, so costs and allergens roll up properly. A product in ibakepro is a bill of materials pointing at components pointing at pantry ingredients, and a flat row cannot express that without a dozen decisions per product that a spreadsheet column cannot record.

That is the shape of the job, one file at a time, up to 2,500 rows per import.

Before you touch a CSV

Download the reference data. It is an Excel file with a sheet each for your time slots, product variants, suppliers, payment methods, expense categories and event categories, each with the id the import expects. Orders referencing a time slot or a catalog variant need those ids, and guessing them is the most common way to spend an afternoon fixing rows.

Decide what "historical" means. An order imported with a past event date is classified as past and excluded from future automated messages. One with a future date is treated as still in flight and is eligible for them. That distinction is what stops your customers getting a payment reminder for a cake they ate in March.

Nothing fires unless you say so

Every automation toggle on the import screen is off by default, and each sits behind a separate acknowledgement checkbox you have to tick before the toggle is even enabled. Customer, payment and stock automations: all three, off, twice. Imported customers are stamped so their automations are skipped entirely unless you opted in, and imported past orders are skipped the same way.

Get this right on day one. A bad import that lands quietly is a Tuesday afternoon. A bad import that emails four hundred people is a different kind of week.

How columns get matched

You do not have to rename your columns to match a template, though you can download one if you would rather work that way.

Your file is tidied up before anything tries to read it. Whichever separator it uses is worked out for you, a banner above the real header row is skipped and blank padding rows are dropped. A line break inside a quoted cell counts as content rather than the end of a row, which is what shreds Notes columns exported from other systems.

Then the obvious columns are matched with no AI involved at all. Customer First Name, first-name, FirstName and customer.firstname all land on the same field, with nothing left to interpret. Only the leftovers go to Choux, and it sees a small sample of rows rather than your file.

What it does not see: free-text and custom-field columns never leave, and in what remains, email addresses, phone numbers and long runs of digits are taken out. Names and addresses are not, because their shape is what identifies the column. A one-time consent screen says so before the first file is sent, and Smart Import does not draw on your AI credit balance.

Each mapping comes back scored high, medium or low confidence and you review them before anything is written. A source column can fan out to two fields, which is how one "Billing Name" column becomes a first and last name.

Rows it cannot read

They do not stop the import.

At preview, every row is checked against what each field will accept, and failures are grouped by error rather than listed one by one, so "date is not YYYY-MM-DD" appears once with a count rather than four hundred times. Each group gets a plain statement of what is wrong and a separate line on how to fix it. You can fix a group, or explicitly leave it alone and move past it.

Choux can propose fixes for broken rows, accepted only when the model is confident enough and the fixed row then passes the same checks as every other row. A confident suggestion that still does not validate is shown as an error.

One check worth knowing about: if every date in a column could be read as either day-month or month-day, that ambiguity is raised rather than resolved by assumption. Quietly picking a convention would move half your history.

When the write runs, each row is handled independently. A row that fails records an error against its row number and the rest keep going. You get back total, created, skipped and errors. Partial success is the normal outcome, by design, because the alternative is one bad row in two thousand rolling back the whole file.

Duplicates, and what "skipped" means

Imports are create-only. Customers are matched on email and external id, pantry items on name or external id, expenses on external id. A match is skipped. Re-running a file after fixing rows adds the missing ones rather than duplicating what landed. It also means you cannot use an import to bulk-edit what you already have.

What an orders CSV has to look like

Orders are one line item per row, with rows sharing an order_number grouped into a single order. The first row carries the order-level fields; the rest only need item details. A customer email with no match creates a customer. Prices are in whole currency units, not minor units. Do not send cents.

If your CSV states a total, it is compared against the total computed from the lines, fees, tax and discount, allowing for the other system's rounding. A real disagreement is reported rather than absorbed, which is how you find the export that dropped a delivery fee.

Pantry rows take units in either system: kilograms and grams, pounds and ounces, litres and millilitres, count units like each or dozen. Where a row gives an item one unit and its stock another, the preview requires both to be in the same family. Kilograms with grams is fine, and so is kilograms with pounds. Kilograms with litres is an error rather than a guess.

How long this takes

Longer than you want, shorter than rebuilding by hand. The variable is almost entirely your file rather than the importer, so rather than trust anybody else's number, get your own before you commit an evening to it.

Take one file, run it as far as the preview and stop there. Nothing is written until you go past that point, and the preview has already validated every row and grouped the failures by cause, so it will tell you how many distinct problems your export has and how many rows each one touches. That is your estimate. A short list of groups is a file you can fix in place. A long one is a file to fix in the spreadsheet first, where one find-and-replace corrects a whole column at once.

The causes that generate the most rework are predictable, and every one of them is cheaper to fix at the source than row by row: more than one date format in the same column, one row per order where the importer wants one per line item, customers with no email address to match on and a stated total that disagrees with its own lines because the original export dropped a fee. Budget for the catalog separately. That is hand work in the builder and no amount of tidying shortens it.

The order that works: pantry, customers, orders, expenses. Build the catalog once the pantry is in, so costs are real from the first product you make and what you charge is built on figures rather than memory.