# What is Compensating Transaction?

Also called compensating action, semantic undo.

A compensating transaction is an operation that semantically reverses the effect of a previously committed step, used when a multi-step process fails partway and a true rollback is impossible. Rather than erasing history, it applies a counteracting change: a refund offsets a charge, a cancellation offsets a booking, a correction notice offsets a sent message.

The pattern arises because a workflow spanning several independent systems cannot hold a single database transaction across all of them. Each step commits locally and becomes visible immediately. When step four fails, steps one through three are already durable and observed, so the only available recovery is to issue further operations that bring the world back toward its prior state.

Compensation is approximate by nature. A refunded charge leaves both entries on a statement. A cancelled booking may have already displaced another customer. A retracted message may have been read. This is why compensations are described as semantic rather than exact: they restore business intent, not the previous byte-level state, and any downstream observer who acted on the intermediate state is not automatically corrected.

Implementation requires each forward step to declare its compensating counterpart and requires those counterparts to be safely repeatable, since compensation itself can fail and be retried. Ordering is typically the reverse of the forward sequence. Steps that genuinely cannot be compensated, such as disclosing information to a third party, should be sequenced last so that all revocable work commits before the irrevocable step.

For agent systems, compensation is what makes broad autonomy tolerable. An agent that creates records, notifies people, and updates external systems needs a defined undo for each action class, and the absence of one is itself a design signal: an action with no compensation is a candidate for human approval before execution rather than after failure.

## Key points

- Reverses a committed step semantically when rollback is impossible
- Needed when a workflow spans independent systems
- Restores business intent, not the exact prior state
- Compensations must themselves be repeatable and ordered in reverse
- Actions with no compensation belong behind human approval

## In practice

An onboarding workflow creates a workspace, provisions a seat with a billing provider, and sends a welcome email. Provisioning succeeds but a downstream directory sync fails permanently. The workflow runs compensations in reverse: it voids the seat with the billing provider, marks the workspace as withdrawn, and queues a short correction message. The charge and its void both remain visible on the account history.

## Related terms

- [Durable Execution](/en/glossary/durable-execution)
- [Workflow](/en/glossary/workflow)
- [Rollback](/en/glossary/rollback)
- [Orchestration Engine](/en/glossary/orchestration-engine)
- [Blast Radius](/en/glossary/blast-radius)

[Back to the AI Glossary](/en/glossary)