Takeaways
- Almost every failed CSV import traces to one of five causes: the file is not the encoding you assume, the delimiter is not a comma, quoting and escaping are broken, types do not match your schema, or the structure is not a clean table.
- Four of the five are invisible in Excel, because Excel silently repairs the file when it opens it. That is why 'it looks fine on my machine' is so common and so unhelpful. Open the raw file in a text editor instead.
- If every row is failing rather than a few, suspect the delimiter before you suspect the data. A comma parser does not error on a semicolon file, it returns one enormous column.
- Some errors only appear at scale: duplicates against existing records, referential failures that pass every format check, partial writes when an import dies halfway, and timeouts.
- The real cost is the error message. 'Invalid value in row 4812' produces a support ticket. Naming the column, showing the value, and suggesting the fix produces a customer who solves it themselves.
- Dromo detects encoding, delimiter, quoting and headers automatically, validates in real time against your schema, and lets users correct errors in a spreadsheet grid before anything reaches your database.
A customer says the CSV will not import. The file looks fine when they open it in Excel. Your logs say something unhelpful about an invalid column value on row 4,812. This page covers what is actually going wrong, in the order you should check, and how to stop it recurring.
The short version: almost every failed import traces back to one of five causes, and four of them are invisible in a spreadsheet program because Excel silently repairs the file when it opens it. That is why "it looks fine on my machine" is so common and so useless.
Check These Five Things, In This Order
1. The file is not the encoding you assume. This is the most common cause and the hardest to see. A file exported from a European ERP arrives as Windows-1252 or UTF-16 rather than UTF-8. Accented characters turn into question marks, or the parser rejects the file outright. Some files carry a byte order mark that shows up as an invisible character glued to your first header, so "Email" silently becomes something that matches nothing. Open the raw file in a text editor rather than Excel to see what is really there.
2. The delimiter is not a comma. Semicolon-separated files are standard across much of Europe, and tab or pipe separated files come out of older systems routinely. The failure mode is nasty: a comma parser does not error on a semicolon file, it returns one enormous column and every row looks malformed. If every row is failing rather than a few, suspect the delimiter before you suspect the data.
3. Quoting and escaping are broken. A field containing a comma has to be quoted. A quoted field containing a quote has to escape it. Automated exports get this wrong often enough that it is worth checking early, and the symptom is a row count that does not match what the customer expects, because one unescaped quote swallowed the next four rows into a single field.
4. Types do not match your schema. Dates arrive as 03/15/2026, 15/03/2026 and "March 15, 2026" in the same column. Long account numbers come through as scientific notation because Excel decided they were numbers and helpfully reformatted them. Currency arrives with symbols and thousands separators. Booleans arrive as Yes, Y, TRUE, 1 and "x". Our references on standardizing date formats, formatting numbers and trimming fields cover what each needs.
5. The structure is not a clean table. A title row above the headers. Headers spanning two rows. Blank rows in the middle. A totals row at the bottom that is not data. Extra columns that map to nothing in your schema. Merged cells from a spreadsheet that was never meant to be a data file. None of this is malformed to a human, and all of it breaks a parser expecting row one to be headers.
The Errors That Only Appear at Scale
Some failures are invisible in testing because your test file is small and clean.
Duplicates against existing records. The file is internally consistent but half the rows already exist in your database. Whether that is an update, a skip or an error is a product decision, and if you have not made it explicitly your importer has made it for you. See removing duplicates.
Referential failures. A row references an account, category or parent record that does not exist. This passes every format check and fails at the database write, which is the worst place to find it.
Partial writes. The import fails at row 8,000 of 20,000 and nobody decided in advance whether that means roll everything back or keep the good rows. Now you have a half-imported dataset and an unhappy customer. Decide this before it happens, not during.
Timeouts and memory. Everything that works at 500 rows can fail at 500,000. That is a separate problem with its own fixes, covered in large CSV file imports and handling them without crashing.
Why Error Messages Make This Worse
Most import errors reach the customer in a form they cannot act on. "Invalid value in row 4812" tells them nothing about which column, what was wrong with it, or what a correct value looks like. "Value fails regex" is worse. The customer opens a 20,000 row file, cannot find row 4,812, and emails your support team instead.
A usable error names the column, shows the offending value, explains the rule in plain language, and where possible suggests the fix. "Account ID must be two letters followed by six digits, like AB123456. This row has ab12345." The difference between those two messages is the difference between a customer who fixes it themselves and a support ticket, which is the actual cost of import errors and why onboarding friction turns into churn.
Timing matters as much as wording. Errors surfaced after a long processing run arrive when the customer has moved on. Errors surfaced while they still have the file open get fixed immediately. That is the whole argument for validating before the write rather than after, and the rules worth enforcing are listed in every validation rule you will ever need.
How to Stop Them Recurring
Fixing one file is support. Stopping the category is product.
- Give customers a template. The cheapest intervention available, and it removes a surprising share of malformed files before upload. Specifics in CSV template best practices.
- Detect rather than require. Do not ask customers to save as UTF-8 comma-delimited. Detect the encoding and delimiter yourself. Most of them do not know what those words mean.
- Match columns automatically. Do not fail because they wrote "Company Name" instead of "organization". Fuzzy and AI-assisted matching handles the long tail, covered in data mapping best practices and automated mapping.
- Let users fix errors in place. A spreadsheet-style grid with the bad cells highlighted, rather than an error log and a re-upload loop.
- Validate before writing, always. Catching a bad date in the browser is a correction. Catching it after the insert is a migration.
Where Dromo Fits
Dromo handles the five causes above before your application sees a single row. Encoding, delimiter, quoting and header detection are automatic. AI column matching aligns the customer's headers to your schema, including Excel and TSV files as well as CSV, with the approach described in AI powered column matching. Validation runs in real time against your schema, and errors appear in a spreadsheet grid the customer can fix on the spot, with suggested corrections.
Because Private Mode runs the import in your end user's browser, the file never reaches our servers, which matters for HIPAA and GDPR workloads. Pricing is published at $599 a month with 250 imports included, SOC 2 Type II and white labeling on every plan. For unattended feeds there is headless import via API and SFTP.
The fastest way to test any of this is to take the file that failed and run it through a free sandbox account. No credit card, no sales call. Or book a call and we will run it against your schema.
Further reading: the complete guide to CSV import, the best CSV importers for SaaS in 2026, framework specific options, the true cost of building in house, build versus buy, importing CSV into databases, parsing CSV in JavaScript, and our glossary of data cleaning techniques. You can also compare options on the comparison page.
Some import failures are not errors in the data at all, but limits in the stack around it. The specific numbers, each linked to the vendor that published it, are in large CSV imports: what breaks, and when.
