Connected applications can reduce re-keying and accelerate workflows, but they also create financial control points. A timeout does not always mean a transaction failed. The receiving system may have completed the work while the sending system lost the response. An automatic retry can then create a duplicate payment, order, invoice or journal entry.
Stripe’s API documentation describes idempotency keys as a way to retry a request without accidentally performing the same operation twice. Microsoft’s Retry pattern guidance similarly warns that retries of non-idempotent operations can create unintended side effects. AWS recommends timeouts, bounded retries, backoff and jitter so transient failures do not amplify pressure on a struggling service.
Design the control before the interface
Start with the business event, not the API endpoint. For each order, payment, invoice or journal transfer, define a durable business reference that remains the same across every retry. The receiving system should use that reference to recognize that a request has already been processed.
A practical control design has five parts:
- Unique transaction identity. Assign one stable reference before transmission. Do not generate a new business reference for each retry.
- Idempotent processing. If the same request arrives again, return the earlier outcome or safely complete the unfinished work without creating a second record.
- Bounded retry policy. Retry only failures judged transient, use delays that increase between attempts and stop after an agreed limit.
- Reconciliation. Compare counts, values and statuses between the source and destination at an appropriate frequency.
- Exception ownership. Route unresolved items to a named role with enough evidence to decide whether to repair, reverse or escalate.
Reconcile value, not only volume
A count can match while the dollars do not. Consider an illustrative daily transfer from an order system to accounting:
- Source: 486 completed orders totalling $72,640
- Destination: 486 sales records totalling $72,415
- Difference: $225
The matching count might suggest success, but the value difference signals an issue such as a tax, discount, currency or rounding rule. A useful reconciliation therefore compares record count, gross value, tax, discounts, net value and status totals. The example is illustrative, not a client result.
Make the exception queue operational
An exception queue should answer four questions: what failed, what business value is affected, what has already been attempted and who owns the next action. Include the source reference, destination reference, timestamps, error category, retry count and current financial exposure.
Separate exceptions into categories such as:
- safe to retry automatically;
- requires data correction before retry;
- requires business approval or reversal;
- duplicate suspected and held for review; and
- permanent rejection requiring process redesign.
This prevents a generic “failed” status from becoming a growing backlog with no decision path.
Measure control effectiveness
Useful measures include duplicate attempts prevented, unreconciled value, exceptions older than the agreed service level, recovery time and manual touches per 1,000 transactions. Track both the initial failure and the final business outcome. A technically successful retry is not a complete result if the accounting record remains unmatched.
A practical review sequence
- Map the business events and financial postings across systems.
- Identify where timeouts, retries or replay can create duplicate effects.
- Confirm stable identifiers and idempotent behaviour.
- Define reconciliation fields, timing, tolerance and owner.
- Test partial failure, delayed response, duplicate delivery and recovery.
- Review exceptions after release and adjust rules using observed evidence.
Advancement Advisors supports application development and integration planning, business analysis, quality assurance, data controls and delivery governance from Regina, Saskatchewan. A focused review can connect interface design to financial control, testing and operational ownership.
Discuss an integration control review ↗
Explore application development and systems integration, business analysis and quality assurance, data and decision support and risk-based testing.