Importing your book

DixonDesk reads your existing spreadsheet by looking for tabs named Purchases, Sales, Returns, or Operating Costs (only the ones you have — none are required), then tries to recognize your columns automatically. Common column names are matched without you doing anything; anything it can’t confidently match, you get to review and correct before a single row is actually written. Nothing is committed until you click “Import for real” — the whole first pass is just a preview.

The single most useful habit: import once, look at the preview closely, fix anything it flagged in your spreadsheet, and import again. Re-importing the same corrected file is completely safe — it replaces the earlier version of that data rather than creating duplicates.

Naming your tabs

Name each tab something DixonDesk will recognize on its own:

Matching isn’t case-sensitive, and a tab named “Purchases 2024” or “Sales - eBay” still matches, since it starts with the recognized word. You only need the tabs for the kind of data you actually have — a book that’s only ever tracked purchases and sales doesn’t need empty Returns or Operating Costs tabs.

What each tab needs

For each type, here’s what genuinely matters — the columns it truly needs to make sense of a row, and the ones worth including if you track them, since they carry real information forward instead of leaving it blank.

Formatting that just works — and what to watch for

Currency symbols and commas in numbers are fine. “$1,234.56” reads correctly without any cleanup — no need to strip formatting before importing.

Dates: keep them as real date-formatted cells, not typed text, whenever possible. Genuine Excel dates always read correctly. Typed text also works for common formats (2026-01-05, 01/05/2026, Jan 5, 2026, and a few others), but anything outside a realistic range gets rejected as unreadable rather than imported wrong — this is what catches the occasional Excel glitch where a date cell somehow becomes the year 1900 or similar. A rejected date doesn’t stop the row from importing; it just comes through with no date, flagged in the preview so it’s easy to find and fix.

Keep your header row as the actual first row of data, without a title or notes row above it. DixonDesk looks for the first row with at least three filled-in cells and treats that as the header row — a stray note or title above your real headers can get mistaken for them.

Multi-item orders: the one thing worth getting right

If a single order ever included more than one item, DixonDesk groups those rows back into one purchase — the same way it would look in the app if you’d entered it by hand — but only if those rows share both the same vendor name and the same order number. If a multi-item order’s rows are missing an order number, or the vendor name is spelled slightly differently between rows that should be the same order, each row imports as its own separate, single-item purchase instead of one grouped order. Worth a quick check before importing if your book has multi-item orders: same order number, same exact vendor spelling, on every row of that order.

Reading the preview

Every import runs as a preview first — nothing is written until you choose to commit it. The preview shows what it’s about to do: a count of what would be imported, the actual date range it found (a good way to confirm it read the file you think it did), and a “Rows needing attention” section listing anything it skipped or flagged, grouped by reason with a count for each.

This section is the actual point of the preview — it’s not just a progress report, it’s the tool for catching data issues before they become part of your real ledger. If something shows up there in real numbers (not just one or two edge cases), it’s worth closing the import, fixing the spreadsheet, and running the preview again rather than committing with known gaps.

If it’s not matching your columns

If your spreadsheet uses column names DixonDesk doesn’t recognize, it still makes its best guess using text similarity — “Product Name” gets matched to “Product” even though it’s not an exact hit. When it genuinely can’t find a reasonable match, you’ll be shown a mapping screen before anything imports, where you tell it directly which of your actual columns means what. This mapping is remembered for that exact set of columns, so it won’t ask again for the same file structure next time.

Fixing a mistake after importing

If you find an issue after importing — a wrong vendor name across the board, a batch of bad dates — the straightforward fix is usually to correct it in the original spreadsheet and import again. Re-importing the same file replaces the data that came from that book, rather than creating duplicate entries alongside it. Anything you’ve added by hand inside DixonDesk since then is untouched — this only replaces what came from the book itself.