Rows That Were Skipped: Reading the Error Report

An import that reports skipped rows has not gone wrong. Every row is judged on its own, and the ones that could not be landed safely are set aside with a reason rather than guessed at.

Getting the Report

Open the import from Imports and use Download error report. You get a CSV with the row number, how serious it was, the reason in plain words, and the identifying columns from the original row so you can find it in your file.

What the Common Reasons Mean

• Missing name / missing email. The row carried neither of the things that identify a person. Usually a blank line or a subtotal row from the bottom of a report.
• Could not match the person. On Notes, Check-ins and Giving, a row names somebody who is not in Studio. Import your People file first, then run this one again. Nothing is duplicated by doing so.
• Missing amount / missing date. A gift needs both. Check whether the column mapped: an amount column full of $1,250.00 is fine, but one full of - or n/a is not.
• Missing invoice number. Every invoice line needs one, because it is what collects lines onto a single invoice.
• Invoice already exists and has been paid. Studio found an invoice with that number that it did not import and that carries money. It is left exactly as it is. If the numbers genuinely collided between two systems, renumber the incoming ones in your file.
• Not a client name / report footer. A row whose name is punctuation, or the timestamp line at the bottom of an accounting report. Correctly skipped.
• Duplicate transaction ID. The gift is already in Studio, from an earlier run of the same file. This one is a success, not a failure.

Fixing and Re-Running

Studio can cut the failed rows out of your original file for you, so you do not have to rebuild anything by hand:

1. On the finished import, use Retry failed rows. Studio downloads a file containing only the rows that failed, with your original header row and every column exactly as you uploaded it, including the ones the mapping ignored.
2. Fix whatever the error report called out, in that file.
3. Upload it back. The mapping you already chose is carried over, so there is nothing to map again.

Only the failed rows are walked, so the ones that already landed are not touched a second time. The retry stays linked to the original import, and each screen links to the other.

If you would rather work from the whole file, Original file on the same screen gives you back exactly what you uploaded. You do not need to revert first either way: rows that already landed are matched and updated rather than duplicated, so re-running the entire file is safe, just slower.

When Most of the File Failed

That is a mapping problem, not a data problem. Revert the import, go back to the mapping step, and check the preview table on the review step before running it again. A single column mapped to the wrong field can fail every row in the file.

If the Import Itself Failed

A whole import that ends in failed rather than complete usually means the file could not be read: a CSV saved in an unusual encoding, or an Excel file that was renamed rather than exported. Save the sheet again as CSV UTF-8 and re-upload. If it happens twice on a file you are confident in, contact support with the import number rather than trying a third time.

Related

• The Review Step, which catches most of this before it happens.
• Reverting an Import.