Reconciling a Partial Asset Import Before Retrying the Batch
Reconcile accepted and rejected asset rows before retrying an import, using run IDs and separate checks for duplicate records and financial postings.
How do you retry a partly successful asset import without creating duplicates?
Establish which source rows were accepted, rejected or left uncertain in each import attempt before retrying. Preserve run identifiers and compare the resulting records and financial postings separately. Use the system’s documented retry mechanism only after testing its behaviour; a timeout does not prove that no records were created.
An asset upload stops halfway through, and the operator is tempted to press import again. Some systems roll back the whole batch; others retain successful rows. Without a row-level outcome report, a second attempt can create ghost records for assets already loaded. The immediate control is a reconciliation of attempts, not a general cleanup of similar-looking asset descriptions.
Reconstruct Each Import Attempt
Preserve the original source file and assign it a batch reference. Give each source row a stable identifier that survives sorting and correction. For every attempt, record the system run ID, start time, submitted population and reported result. Retain error messages and any downloaded accepted or rejected row reports before starting another attempt.
Classify rows as accepted, rejected or uncertain based on saved-state evidence. An accepted response should lead to an identifiable destination record. A rejected row should have a reason. If the interface timed out after submission, inspect the resulting records or obtain a supported run-status report before deciding what remains. Do not assume the displayed error describes the outcome of every row.
Choose a Controlled Retry
Ask the system owner whether retrying the original request is supported and how repeat requests are recognised. Idempotency means a repeated operation avoids additional side effects; the AWS Builders’ Library explains this principle for APIs. It does not establish that your asset import implements it. Obtain product-specific evidence through documentation and a controlled test.
Where the workflow requires a corrected file containing rejected rows only, retain the connection to their original source-row IDs. Record changed values and the new run ID. Where a documented request token must be reused for an unchanged retry, follow that contract. Do not reuse a token for changed contents without knowing how the system handles a different request intent.
Reconcile Records and Postings Separately
Build a final row bridge across all attempts: original source row, accepted run, destination asset ID and final outcome. Confirm that each intended asset has the expected single record, with approved exceptions listed separately. Use physical identifiers as a supporting check, but keep the import history central to determining whether a retry created an extra record.
Then reconcile financial effects independently. A duplicate asset row may not have generated a duplicate posting, and a repeated interface message may affect the ledger without adding another visible register row. Finance should review any proposed correction. Retain before-and-after counts, relevant amounts and approved adjustments, then test the corrected retry process before using it for another production batch.
Practical Example
Illustrative example: run A submits 100 source rows, accepts eighty and rejects twenty. Run B contains the corrected twenty, but its response times out. A status check confirms that eighteen were accepted and two rejected. Run C submits only the final two after correction. The row bridge identifies 100 accepted source rows across three runs. A separate posting reconciliation confirms the financial outcome instead of inferring it from the asset count.
Action Checklist
- 1.Preserve the source batch, stable row identifiers and every import run ID.
- 2.Reconcile accepted, rejected and uncertain rows before submitting another attempt.
- 3.Test the documented retry or idempotency behaviour in an authorised environment.
- 4.Map corrected retry rows back to their original source references and accepted destination IDs.
- 5.Reconcile asset records and financial postings separately before closing the batch.
For a reconciled recovery from partial asset imports, explore Fixed Asset Register Reconciliation.