Importing a price list from CSV

When you're bringing in 100+ items from a previous system, hand-entry isn't practical. Suprata's CSV import handles bulk loads, but the parsing rules and tax-category mapping have a learning curve. Here's the safe pattern.

Importing a price list from CSV

Hand-entering 800 items takes a week and produces inconsistencies. The CSV import takes 30 minutes once you know the rules, and produces a clean catalog. This article covers the import flow, the column conventions, common parsing errors, and the staged approach that keeps you from corrupting your live catalog on a bad import.

For one-by-one item entry, see Adding items to the price list.

When you'd use this

  • Migrating from a previous system. You exported your old catalog and need to bring it in.
  • Initial setup for a service business with hundreds of SKUs. Plumbing, HVAC, electrical — any trade with a sizable parts catalog.
  • Bulk update of existing items. Re-importing with updated pricing or tax categories on many items at once.
  • Periodic refresh from a vendor's catalog. Some vendors publish updated pricing as CSVs; importing once a quarter keeps your sellable pricelist aligned.
  • Restoring a backup or reapplying a known-good catalog after a misconfiguration.

When NOT to import

  • You only have 20 items. Hand-entry is faster than fighting CSV format issues.
  • Your current catalog is messy. Importing on top of a messy catalog usually multiplies the mess. Clean (or wipe) first.
  • You haven't yet set up tax categories. Items reference tax categories by name; without categories in place, the items either fail to import or land with broken tax tagging.

The import screen

The pricelist import lives in the import area:

The pricelist import screen

Treat this screen as a load step, not a workflow tool. You upload, you confirm, and the items come in. Editing happens after the fact in the regular pricelist screen.

What the CSV looks like

Suprata expects a header row and one data row per item. The exact column names depend on your version, but typical columns are:

  • Name (required) — what shows on invoices.
  • Description — optional longer text.
  • Price (required) — unit price as a number, no currency symbol (125.00, not $125.00).
  • Cost — your cost; blank or 0 is OK.
  • Tax Category — must match the exact name of an existing tax category in your account.
  • Item Category — your internal taxonomy. Will be auto-created if it doesn't exist (or will fail to import, depending on configuration).
  • Item Type — Service, Product, etc.
  • Active1 for active, 0 for inactive.
  • SKU or Internal Code — your part number, optional.
  • QB Income Account — if QB-syncing.

Always download the system's blank template before building your CSV. The exact column names and order matter; making your own column layout from memory leads to import failures.

The pre-import checklist

Before you upload, verify these:

  1. Tax categories exist in Suprata for every category name referenced in your CSV. Spelling and capitalization must match. If your CSV has Taxable goods but Suprata has Taxable Goods, every row with that mismatch either fails or lands with the wrong category.
  2. Prices are numbers, not text. 125, 125.00, and 125.5 are all OK. $125, 125.00 USD, and one hundred twenty-five are not.
  3. Names are unique within the file. The system may allow duplicate names but you'll regret them; clean duplicates in the spreadsheet before import.
  4. No empty required fields. A missing Name or Price kills the row.
  5. CSV encoding is UTF-8. Excel sometimes saves as Windows-1252 by default, which mangles special characters (em-dashes, ™ symbols, accented letters). Save explicitly as UTF-8 if you have any non-ASCII content.
  6. Field separator is a comma, with quoted fields if the content contains commas. Some non-US locales default to semicolon — check your CSV in a text editor before uploading.

The staged import — the safe pattern

Don't upload 800 rows on the first try. Stage it:

Stage 1: import 5 rows

Create a tiny CSV with 5 representative items — different tax categories, different item types, a service item, a parts item, an item with a description, an item with no cost. Upload that. Verify:

  • All 5 rows landed.
  • The names are correct.
  • The tax categories are correct.
  • Prices are correct.
  • Item categories are correct.
  • Active flag is correct.

If any of those are wrong, the issue is in your column conventions, not the data. Fix the template before going wider.

Stage 2: import 50 rows

Once 5 rows worked, try 50. Same checks, but with more rows you'll spot patterns:

  • Are special characters surviving (apostrophes in names, em-dashes in descriptions)?
  • Are large prices correct (no decimal-comma confusion)?
  • Did anything fail silently?

Stage 3: import the rest

When 50 worked, import the full file. The system will report how many rows succeeded, how many failed, and (usually) why each failure happened.

This staged pattern saves you from the worst-case scenario: 800 items uploaded with the wrong tax category, and now you have to rebuild or re-tag 800 items. A 5-row test catches the bug.

What the import does and doesn't do

It does:

  • Create new items by name (or by SKU if your config matches on SKU).
  • Update existing items if the name (or SKU) matches an existing one.
  • Auto-create item categories that don't exist (in some configurations).
  • Resolve tax categories by name and link them.

It does not:

  • Auto-create tax categories. They must exist already.
  • Delete existing items not in the CSV. The import is additive/upsert, not a full sync. To remove old items, you inactivate them manually.
  • Validate prices against any external source. If your CSV has $1 where it should be $100, the import accepts the bad data.
  • Sync to QuickBooks during the import. QB sync happens on the next QB sync cycle after import.

Handling update vs. insert

If you're re-importing to update existing items, the system matches incoming rows against existing items by name (or SKU) and updates them in place. This is convenient — but it also means a typo in the name creates a new item alongside the old one rather than updating. After re-importing, scan for unexpected new items.

A safer pattern for bulk updates: export your current catalog, edit the export, reimport. Names and identifiers stay aligned because they came from the system in the first place.

Common parsing errors

These show up on most first-time imports:

  • "Tax category not found" — the tax category name in the CSV doesn't match any in the system. Usually a capitalization or spelling difference. Fix the CSV or fix the category name in Suprata.
  • "Invalid price" — non-numeric value in the price column. Most often $ or , characters in the number, or a stray space.
  • "Required field missing" — a row with no name or no price. Usually a blank line in the CSV, or a row that lost its key data during spreadsheet editing.
  • "Duplicate item" — a row whose name (or SKU) already exists, and the system isn't configured to update on duplicate. Either remove duplicates from the CSV or change the import config to update.
  • Encoding garbage in special characters (e.g., Caf┬® instead of Café) — CSV saved as the wrong encoding. Re-save as UTF-8 and re-upload.
  • Half the file imported, the other half didn't — usually an unquoted comma in a description field broke CSV parsing on that row. Quote text fields that contain commas: "Diagnostic, including tools".

After the import — verification

Don't trust "import complete" without spot-checking:

  1. Sort the new items by date created and look at the first 10 — do they look right?
  2. Try creating a test invoice and pulling 5–10 of the new items as line items. Do they price correctly? Tax correctly?
  3. Run a report grouped by item category — does the count per category match your expectations?
  4. If QB-connected, watch the QB sync log over the next hour to confirm items flowed cleanly.

If anything is off, fix in bulk if possible (re-import with corrections) or one-by-one if not. Catch issues now, not when a customer's invoice is wrong.

Updating prices via re-import

When you raise prices across the catalog, the cleanest approach is:

  1. Export your current catalog.
  2. Edit the export — bump the prices.
  3. Re-import.

The system updates existing items in place; names stay the same; only the price changes. Historical invoices retain their old prices (line item prices are captured to the invoice at the time of creation, not re-read from the catalog).

For partial price changes (one item line, not the whole catalog), edit the items individually — re-importing for one change is overkill.

Common mistakes

  • Skipping the staged test. 5 rows first, then 50, then the rest. Always.
  • Importing before tax categories exist. Create the categories first, then import items.
  • Not downloading the template. Your hand-built CSV will have subtle column mismatches. Use the system's template.
  • Mixing encoding (Windows-1252 + UTF-8). Special characters break. Save as UTF-8.
  • Letting Excel reformat numbers. "0001234" becomes "1234", "01/02/2026" gets turned into a date. Format columns as Text in Excel before pasting numbers.
  • Treating the import as a one-way sync. It's not — it adds and updates, but doesn't delete. Old items stay until you manually inactivate them.
  • Importing into a catalog with existing duplicates. The duplicates make matching ambiguous. Clean first.
  • Forgetting that imports don't trigger QB sync immediately. Wait for the next QB sync run, then check.
  • Bulk-importing tax categories that should be different per row. If half your items are exempt and half taxable, make sure the CSV has the right category per row — don't import everything as one category and plan to re-tag later. Re-tagging 800 items is much harder than getting it right at import.

Related articles