# Retry an Excel task without importing the same document twice

A native Excel checkpoint experiment stops after saving an input, then resumes without another append. Download the workbook, exact script and recovery results.

Published 2026-11-15T07:30:00Z by Renaissance Superintelligence Corporation (RSI).

Inspect the saved workbook before retrying an interrupted import. Our prepared test stopped after saving one synthetic document but before refreshing its query. Recovery found the same document and payload, skipped the append, then produced 481 clean documents and a $686,501 report with one witness record.

## The first attempt had already changed the file

The expense fixture began with 483 raw rows and 480 clean documents. The script appended SEO-RETRY-ONE, a synthetic October document for $1, and saved the workbook. It wrote a checkpoint marker and deliberately raised an error before refreshing the Actuals query.

At that point the saved raw table contained 484 rows, while the cleaned query still contained 480 documents. Both observations were valid descriptions of different stages. Starting over from the instruction “append the document” would ignore the state already committed to the file.

This experiment creates the interruption at a known boundary. It does not reproduce every failure an agent may encounter, and it does not establish exactly-once processing across simultaneous clients. Its narrower question is whether an inspected retry can recognize its own saved input.

## A matching ID is only the first check

On recovery, the script counted the exact document identifier in the raw table. More than one match would stop the test. Zero matches would permit the initial append. One match required comparison of all six expected fields: identifier, posting date, department code, category, amount and description.

That payload comparison matters. An existing identifier with a different amount is a conflict to investigate, not permission to continue. In this fixture the fields matched, so appended was false and the raw count stayed at 484.

Only then did the script refresh the named query and recalculate. The clean count rose to 481, the report became $686,501, and the cleaned identifier appeared once. The recovered file reconciled the intended change without another raw append.

Saved state across the deliberate interruption

Measure | Interrupted attempt | Recovery

Raw rows | 484 | 484

Clean documents | 480 | 481

New append during recovery | — | False

Report total after recovery | Not accepted | $686,501

Clean witness count | Not checked | 1

## Keep a checkpoint useful for diagnosis

The marker in this test records that the source-save stage was reached. It is not an atomic transaction spanning the workbook and a separate file. The recovery therefore inspects the workbook itself; it does not use the marker as proof that the expected payload is present.

For a longer close, record the input file identities, task-specific document IDs, accepted source totals and the last completed stage. After an uncertain command, inspect files and the Office window before resubmitting it. A timeout describes what the controller observed; it need not describe every side effect in the application.

Keep append, refresh, validation and delivery as explicit stages. A recovered source does not authorize sending the output until the downstream query, formulas, pivots and presentation checks pass. Our experiment accepts the source/query/report checks only; it does not claim a fully validated management deck.

## Run the interruption and recovery deliberately

Download the [recovered workbook](/research/native-office-2026-11-15/retry-workbook.xlsx), [result record](/research/native-office-2026-11-15/retry-checkpoint.json) and [script](/research/native-office-2026-11-15/native-retry-checkpoint.ps1). Put the synthetic [expense workbook](/examples/excel-to-powerpoint/October%20close.xlsx) in a new directory as expense-original.xlsx. The first invocation deliberately fails after saving its own copy; inspect that copy before the second invocation.

Never use this failure-injection script on an existing customer workbook. It writes a known synthetic row and uses a local marker to select the test stage. Adapt the reconciliation contract to your data before using the pattern in a real process.

Use the [Panes command docs](/docs#commands) for execution and the [duplicate-document guard](/blog/power-query-duplicate-document-guard) for conflicting or blank identifiers. The guard and the retry solve related problems at different points: input acceptance and recovery after a committed edit.

## Evidence

Prepared scripted execution on one retained 4-vCPU, 16-GB Windows research computer, November 15, 2026. Excel 16.0 build 20527. A deliberate first-attempt error followed a source save; its API time was 3.634 seconds. Recovery reached its saved result in 4.507 seconds before finally-block cleanup, API time was 5.263 seconds and controller wall time 5.352 seconds. This was not an injected network failure or a test of arbitrary concurrent retries. One observed run, not an autonomous-agent or fleet benchmark. Per-task operating cost is unmeasured. Public Office copies have author metadata redacted; all other ZIP members are identical to the native outputs. They were reopened read-only in Office without changing their bytes.

## Sources

- [Exact native recovery record](https://usepanes.com/research/native-office-2026-11-15/retry-checkpoint.json)

- [Full interruption and recovery script](https://usepanes.com/research/native-office-2026-11-15/native-retry-checkpoint.ps1)

- [Public-file identity and native reopen](https://usepanes.com/research/native-office-2026-11-15/publication-manifest.json)