The load starts, processes some rows, and stops — often with an error that names a process rather than a row.
Six steps, and the order is not negotiable
Template, CSV, zip, upload, interface, import. The useful thing about that chain is that upload and import are separate: between them your data sits in interface tables where you can look at it, before anything has been committed to the application. No invoice exists yet, no supplier exists yet, nothing has happened to the business. It is also why the process reporting the failure is frequently not the one that failed — work backwards and read the output of each, not only the last.
Most likely causes
- Nothing reached the interface table at all. Usually the zip: it must contain the CSV named exactly as the interface expects. An empty interface table is the discriminator and separates this from everything below in one look.
- Part of the file landed and part did not. That is the normal case rather than the exception. Read the import log's three counts — rows read, rows imported, rows rejected — because a run that completes having imported nothing is still a completed run, and the status alone will not say so.
- 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. Templates are versioned against releases and change without announcement, so a stale one gives either a rejection naming a column, or a load where everything after the changed column is one position out.
- Dates or numbers mangled before you touched them. A spreadsheet reformats dates, drops leading zeros and mangles long numbers — silently, on open. A code of 000451 becomes 451 and then matches nothing or duplicates; a sixteen-digit account becomes 1.23457E+15, which loads as a wrong number and does not look wrong on screen; and 03/04 is March the fourth or the third of April depending on the machine, so both are valid and nothing errors. The remedy is a habit, not a format: generate the CSV from the template rather than Save As, import it as text rather than opening it, and check the result in a text editor, where you see the actual bytes rather than a rendering.
The failure that is not in any count
A failure is visible — it is in the reject count and it names an error. A row that succeeded into the wrong place is in no count at all: imported cleanly into the wrong business unit, period or supplier, because a column you left empty was defaulted or a code matched something you did not intend. Nothing in the import output will mention it. The only route to it is reading what was created against what you sent, at a total and then at three individual records. Treating a clean log as proof of a correct load is the commonest false pass in conversion work, and it survives every review that does not open the resulting records.
What to check
- The import log's three counts, before anything else and every time.
- The rejection report or error table, which names the row — read knowing the message names a column rather than a cause.
- Whether the template matches your current release, taken from Oracle's file-based data import reference for your release rather than a shared drive or the last project. The check is that the reference page names the release. Keep that exact file with the load: six months later, which template was this has no other source of truth.
- What already landed, before you reload a corrected file. Eight thousand rows imported, two thousand rejected, fix the file, reload all ten thousand — and eight thousand records now exist twice. Count what is in the application for that batch, reload only the rows that are absent, then count again against the source.
- Whether a single row of the same file loads in an environment you are allowed to break. One row exercises the whole chain and fails on a stale template loudly rather than subtly. The ladder is one row, then ten, then the batch, and it belongs before you prepare the full file — afterwards the correction is ten thousand rows in a spreadsheet somebody has already reformatted.
If none of the above explains it, raise a ticket and include what you checked. Reading this article cost you no hours.