The quick answer
Download the completed job's CSV response and reconcile successful and failed rows. Group failed lines by the transaction-level External ID used by this import, search for existing orders with that same identifier, and retry only confirmed-missing transactions. In the new Add import, map the customer and required transaction fields, map numeric item values to Sales Order Items: Item with reference type Internal ID, then reconcile the retry response and inspect every created order.
A partial import needs a recovery process, not a blind rerun. A failed response row does not always prove that no transaction was created, and one sales order can span several CSV rows. The example below starts with five successful orders and three failed order identities across four item rows. Spreadsheet preparation happened before the walkthrough and is described where needed. The screenshots use sample data and fictional person and operating-company names.
Before you start
Sales Orders must be enabled. Use a role that can perform CSV imports, view CSV Import Status and response files, search and create sales orders, and view the item fields needed for validation. Confirm access to the relevant customers, items, subsidiaries, locations, currencies, custom forms, classifications, and custom fields. The selected form must expose the fields the import needs. In OneWorld accounts, role and subsidiary restrictions can change which records you can see or use.
Keep the original import, its response file, and the source file available for reconciliation. If the failure cause is unclear, test the corrected mapping with a small controlled subset first.
01. Review the failed rows
Open Setup → Import/Export → View CSV Import Status and find the completed Sales Order job. Read its success count and open the CSV Response. Percent complete describes processing progress; the response and success or error counts describe the outcome.
In this example, the response retains four failed item rows for REC-6406, REC-6407, and REC-6408. Reconcile them with the successful source rows before creating the retry set. Keep the two rows for REC-6406 together because they belong to one order. If some lines for one source order succeeded while others failed, inspect the created transaction before deciding whether an Add retry is appropriate.
02. Confirm the orders are missing
Open the Sales Orders list and search the Sales Order record type for each exact External ID. In this import, the source key is deliberately mapped to the sales order's External ID; use the identifier actually populated by your original mapping. Continue with an Add import only when the expected order is absent and there is no evidence it committed under another identifier.
This check reduces duplicate risk, but it is a point-in-time check. Another user, import, script, or integration can still create an order after you search. If you find an existing order, inspect it and reconcile the original response before deciding what to do next.
03. Verify item Internal IDs
Open Lists → Accounting → Items and inspect each referenced item's name, Internal ID, inactive status, type, and subsidiary assignment. Also confirm the item is valid for the order's location, units, customer, form, and other account rules.
The prepared reconciliation workbook keeps Item Lookup and Item Export in two sheets along the bottom of one window. The export is the source of the target account's IDs; the lookup sheet shows the prepared exact-match formula and results. In this example, Cable Assembly resolves to 2841, Mounting Bracket to 2857, and Junction Cover to 2862. An exact lookup such as =VLOOKUP(A2,ItemTable,2,FALSE) can match a name to an ID, but it does not prove that the item is eligible for the transaction. Resolve unmatched names and validate the business rules before accepting an ID.
04. Map and run the retry
Prepare a new CSV containing only orders confirmed absent. Repeat one unique transaction-level External ID on all rows for the same order, use a different key for each order, retain every required line, and omit the response file's Error column. Do not reuse a key from an earlier retry unless you are deliberately performing an update.
In Import CSV Records, choose Transactions and Sales Order, upload the reviewed file, and select Add. Map External ID to the transaction External ID. Map Customer using a reliable customer Internal ID or External ID and set its reference type to match the file. Map Date, Subsidiary, Location, Status, classifications, custom mandatory fields, and the item-line Quantity and Rate where the account requires them. Check that blank source columns are not mapped unintentionally.
Map the numeric item column to Sales Order Items: Item, open that mapping's edit control, and set Reference Type to Internal ID. Confirm that customer and item values resolve in the target account and subsidiary. The item Internal ID identifies an item record; it is not the new sales order's transaction Internal ID. Accounts may also require currency, tax, approval, transaction-form, or other fields.
Review all mandatory fields and defaults, then save and run the import. When the job completes, compare the intended transaction count, successful transaction count, failed rows, response errors, source External IDs, and created transaction identifiers. Recheck order existence before making another attempt if any errors remain.
05. Verify the created orders
Return to the Sales Orders list and search for each original External ID. The intended result for this example is one new order for each of REC-6406, REC-6407, and REC-6408.
Open the orders and confirm their customer, External ID, status, location, line count, items, quantities, rates, and totals. For the illustrated data and account configuration, REC-6406 contains two lines totaling 352.00; REC-6407 and REC-6408 total 266.00 and 506.00. Pricing, discounts, tax, shipping, currency, and rounding can change totals in another account. Matching counts alone are not enough to prove that the imported transaction data is correct.
Common questions
How do I identify only the sales orders that need to be recovered?
Reconcile the original source rows with the import response. Group failed lines by the transaction External ID used in the original mapping, search for each exact ID, and retry only orders confirmed missing.
Can a failed response row still leave a created sales order?
Yes. Some failures can happen after a transaction is committed, and response granularity can differ from business-order granularity. Search for the exact Sales Order External ID and inspect any match before retrying.
Why do numeric item IDs still cause an invalid reference error?
The item mapping must use Reference Type: Internal ID. A valid ID can still fail when the item is inactive, unavailable to the subsidiary or location, the wrong item type, or blocked by account-specific validation.
How do I preserve a sales order with several item lines?
Keep every line for the order in the retry file and repeat the same transaction grouping key, commonly the External ID, on each row. Different orders need different keys.
Does checking External IDs prevent duplicate orders?
It lowers the risk, but it does not lock the account. Another import, integration, script, or user can create the order after your check. Reconcile the completed retry immediately and use any account-specific duplicate controls available to your process.
Which fields should the retry import map?
Map External ID to the transaction External ID, map Customer with a reference type that matches its source values, and map every required transaction body field. Map ItemInternalID to Sales Order Items: Item with Reference Type: Internal ID, plus the required quantity, rate, location, tax, classification, and custom fields for the account.
How do I confirm that recovery is complete?
Compare the intended transaction count, retry success count, failed rows, response errors, source keys, and created identifiers. Then open every created sales order and verify its body fields, item lines, quantities, rates, taxes, and totals.