Bulk Import is built to be transparent: every row of your CSV either lands in your account or doesn't, and the preview screen tells you which way each one will go before anything is written.
A quick reminder up front: Bulk Import is a Premium feature, and the entry point is the Bulk Import button in the top-right of the Add Purchase form rather than a dedicated nav item.
First, figure out which kind of "didn't land" you're dealing with
Before doing anything else, work out which of the following best describes the situation. The fix is different for each.
The file wouldn't upload at all. You tried to drop the CSV onto the upload page and it was rejected outright — wrong format, too large, or an error message instead of a preview screen.
The file uploaded but the preview was full of errors. You reached the preview screen, but most or all of your rows were flagged with red error messages.
The import "succeeded" but the data looks wrong. Every row imported, but the resulting transactions have the wrong dates, wrong products, wrong prices, or otherwise don't match the CSV's content.
The import was blocked by a transaction limit. You hit your tier's transaction cap mid-import, and the rows past that point didn't land.
Each of those gets its own section below.
The file wouldn't upload at all
If the upload step itself bounced your file, the issue is almost always with the file rather than your account.
Check the file extension. Bulk Import expects a .csv file. Spreadsheets saved as .xlsx or .xls won't be accepted — open them in Excel, Google Sheets, or Numbers and re-save explicitly as CSV.
Check the file size. Very large files (thousands of rows) can hit upload limits. If you're trying to import an enormous historical backlog at once, splitting the CSV into smaller batches usually works.
Check the file's encoding. CSV files in unusual encodings (UTF-16, certain non-UTF-8 variants) sometimes fail to parse. Re-saving the file as UTF-8 from your spreadsheet tool resolves this.
Check the column structure. If the first row of the CSV doesn't match the expected column headers, the upload may fail to parse before it gets to preview. See Preparing your CSV for the canonical column list.
A workable file accepted on a fresh upload attempt will land on the preview screen — that's the signal that the upload step itself is past.
The preview surfaced errors and nothing imported
This is the most common outcome of an import that "failed," and it's the easiest one to handle.
The preview screen shows every row from your CSV with a green or red indicator. Red rows have a specific reason listed — missing required field, unrecognized product, malformed date, out-of-range value, that kind of thing. If you don't proceed past the preview, nothing in red is written and nothing in green is either.
The fix:
Stay on the preview screen, or note down what was flagged before you leave it.
Open the CSV, find each flagged row, and apply the correction. The full diagnostic per error type is in Fixing common CSV errors.
Re-upload the corrected file. The preview will re-run and most or all of the rows should now be green.
Once the preview is clean, proceed with the import.
The import "succeeded" but the data looks wrong
If every row landed but the resulting transactions don't match what you expected, the issue is usually in the CSV itself rather than in the import process.
The usual suspects:
Date format. If the column expected ISO dates (YYYY-MM-DD) and your file had US-style (MM/DD/YYYY) or UK-style (DD/MM/YYYY), some dates may have been parsed in the wrong order — turning a March 5 purchase into a May 3 purchase. Check the date column on a few imported transactions against what was in the CSV.
Currency in the wrong unit. Prices, premiums, spot, and shipping are expected in USD on every row, regardless of your display currency. If your CSV had figures in EUR or GBP and didn't convert them, the transactions will be off by the relevant exchange rate. The CSV format expects USD-only monetary columns as a deliberate choice.
Wrong product key. If a product column referenced a key that maps to a different catalog product than you intended, the transactions will be for that other product. Spot-check a few transactions against the corresponding CSV rows.
Quantity misread. Trailing whitespace, formatting characters, or commas in number fields can occasionally cause a quantity to be misread. Inspect a representative transaction against its CSV row.
If the resulting transactions are wrong in a way that's salvageable with an edit, Editing a transaction after the fact is the path.
If a large batch is unrecoverably wrong, the cleanest fix is to delete the affected transactions (which removes their associated inventory items — see Deleting a buy transaction), correct the CSV, and re-import.
The import was blocked by a transaction limit
Each plan has a cap on the total number of transactions an account can hold — see The three plans compared for the current numbers. If a bulk import would push you past your plan's cap, the import is constrained to what fits and the remaining rows don't land.
The full read on how this interacts with imports is in Bulk upload and your transaction limit. The short version:
The portion of the CSV that fit within your remaining headroom will have imported.
Rows beyond that point will not have imported, and you'll see a message on the import flow explaining the cap was hit.
The fix is to either upgrade to a plan with more headroom (see Upgrading your subscription), consolidate older transactions if that's appropriate, or import in smaller batches that stay within the cap.
A consolidated set of unrecorded transactions is easier to manage than a half-imported file, so deciding the headroom strategy before the next import attempt is usually worth the few minutes.
What you don't need to do
A few reflexes that don't help:
Don't re-upload the whole CSV without removing the rows that already landed. That would create duplicate transactions for everything in the file. Trim the CSV to only the rows that didn't import.
Don't manually edit the existing imported rows to "match" what was supposed to come in. If the originals are wrong, delete them and re-import the corrected versions. Editing each one by hand is slower and more error-prone than fixing the CSV and running it again.
Don't clear cache, sign out, or refresh the page mid-import. The import is a single operation on our side once you confirm it. Interrupting the browser session won't pause or rewind it, and may make it harder to see the result.
When to contact support
If you've worked through the right section above and still can't account for what happened — rows that don't appear in the preview at all, an import that says it succeeded but produced no transactions, or an error message that doesn't match anything in Fixing common CSV errors — that's worth flagging.
[Contact support] is the path. The most useful things to include are:
The CSV file you tried to upload (or a representative subset, with anything sensitive redacted).
A description of what you expected to happen and what actually happened.
Roughly when the import ran, so we can correlate against logs if needed.
The vast majority of bulk-import surprises resolve within the preview-fix-re-upload loop. Real platform-side bugs are rare, but they exist, and we'd rather hear about them than not.
Where to go next
Bulk import overview: The high-level read on what Bulk Import does and doesn't do.
Preparing your CSV: The canonical column schema and what each field expects.
Uploading and reviewing your CSV: Walkthrough of the upload and preview steps.
Fixing common CSV errors: The error-by-error diagnostic guide.
Bulk upload and your transaction limit: How tier caps interact with imports.
Editing a transaction after the fact: Fix for individually wrong imported transactions.
Deleting a buy transaction: What happens when a batch needs to be removed and re-imported.
Upgrading your subscription: The path if you've hit your plan's transaction cap.