# Lose the Xero response after the test invoice is created

Reproduce an unknown outcome in a safe organisation. The integration should recover the original result rather than create another invoice automatically.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Use an isolated test document

Use the appropriate Xero test or demo setup and a clearly synthetic document under the organisation's testing procedure. Avoid live customer or accounting effects.

Save the local operation and request identity before sending. Arrange a controlled transport interruption after the provider has accepted the request but before the application records the response.

Confirm the test actually reached that boundary. A failure before send tests a different and easier recovery case.

## Inspect the local state

The operation should remain identifiable as uncertain, with the target organisation and intended request preserved. It should not be marked definitively absent solely because the client timed out.

Check that automated retries follow the documented idempotency rules and do not create a new business operation identity on every attempt.

Keep the test's provider resource identity available through a controlled observation path for independent verification.

## Exercise delayed recovery

Resume once within the supported retry window and separately test recovery after that window no longer protects the request. The latter needs the integration's durable reconciliation procedure.

Do not assume that reusing an old key forever guarantees deduplication. Provider retention and application operation history solve different parts of the problem.

Verify that matching does not rely only on amount or contact name. Create another synthetic document with similar values to expose ambiguous lookup logic.

## Check the final mapping and count

Confirm that the intended provider document exists once, the local operation points to it and the application can read its current state.

If the outcome cannot be determined unambiguously, verify the held-review path and the information available to the authorised operator. The test should not force automatic success at the expense of duplicate risk.

Record cleanup of synthetic documents according to the test environment's supported process. Preserve the operation timeline and assertions as regression evidence for future client or retry changes.

## Sources

- [Xero: idempotent requests](https://developer.xero.com/documentation/guides/idempotent-requests/idempotency/)