The load starts, processes some rows, and stops — often with an error that names a process rather than a row.
How to find the actual cause
These loads run as several chained processes. The one that reports the failure is frequently not the one that failed. Work backwards through the chain and read the output of each, not only the last.
Most likely causes
- One bad row rejected the batch. Many loads are all-or-nothing per batch; a single invalid reference stops the rest.
- A reference that does not exist yet. Loading transactions before their master data is the most common version of this.
- A column shifted. Inserting or deleting a spreadsheet column silently changes what every later column means, and the error will point at a value that looks fine.
- Dates or numbers in a local format. These load without complaint and land wrong, which is worse than failing.
What to check
- The rejection report or error table for the load, which names the row.
- Whether the template matches your current release. An old template is a common cause of shifted columns.
- Whether a smaller extract of the same file loads. If ten rows work and a thousand do not, look for a bad row rather than a configuration problem.
If none of the above explains it, raise a ticket and include what you checked. Reading this article cost you no hours.