Compensating Transactions for ERP Integration

TL;DR

• Bottom line: ERPs cannot participate in distributed transactions (2PC), so every multi-system workflow must use compensating transactions — new operations that semantically undo prior committed work — instead of database rollbacks.
• Key limit: Some ERP operations are non-compensable (emails sent, checks printed, goods shipped). Design your saga steps so non-compensable actions execute last.
• Watch out for: Compensation failures — if the compensating transaction itself fails, you need a dead letter queue and manual reconciliation process, not recursive compensation.
• Best for: Multi-ERP workflows (order-to-cash, procure-to-pay, hire-to-retire) where a failure at step N requires undoing steps 1 through N-1 across system boundaries.
• Pattern choice: Use saga orchestration (not choreography) when compensation logic is complex; use Temporal or AWS Step Functions as the orchestrator for durable execution guarantees.

System Profile

This is a cross-system architecture pattern card covering compensating transaction design across major ERP platforms. It applies to any integration where two or more ERPs participate in a multi-step business process and true distributed transaction support (2PC/XA) is unavailable — which is virtually every cloud ERP integration scenario.

Per-ERP Compensation Capabilities

What Can and Cannot Be Reversed

Understanding each ERP's reversal capabilities is the foundation of compensation design. Every ERP handles "undo" differently, and some operations simply cannot be reversed via API. [src4, src5, src6, src8]

Compensation Design Patterns

Forward Recovery vs Backward Recovery

There are two fundamental approaches to handling saga step failures. [src1, src3]

Backward recovery (compensating transactions): Undo completed steps in reverse order. Use when operations are reversible and the business process can be abandoned.

Forward recovery (retry + continue): Retry the failed step until it succeeds. Use when the process must complete (e.g., payroll initiated, goods shipped).

BACKWARD RECOVERY (Compensating Transactions)
Step 1: Create Salesforce Opportunity    OK Committed
Step 2: Create SAP Sales Order           OK Committed
Step 3: Create NetSuite Invoice          FAILED
  -> Compensate Step 2: Cancel SAP Sales Order
  -> Compensate Step 1: Revert SF Opportunity to "Open"

FORWARD RECOVERY (Retry + Continue)
Step 1: Create Salesforce Opportunity    OK Committed
Step 2: Create SAP Sales Order           OK Committed
Step 3: Create NetSuite Invoice          FAILED
  -> Retry Step 3 with exponential backoff
  -> If retries exhausted: human escalation, do NOT undo Steps 1-2

Decision rule: If the process involves irrevocable side effects (payment captured, goods shipped, regulatory filing submitted), use forward recovery for steps after the irrevocable point. Use backward recovery for steps before it.

Saga Orchestration for ERP Workflows

Orchestration is strongly preferred over choreography for ERP compensation because: (1) ERP APIs have inconsistent event models, (2) compensation ordering requires centralized state, and (3) debugging cross-ERP failures requires a single audit trail. [src2, src3, src7]

SAGA ORCHESTRATOR FLOW
Orchestrator
  |
  +-- Step 1: CreateSalesforceOrder()
  |     +-- onSuccess: record SF Order ID, register compensateStep1()
  |     +-- onFailure: ABORT (nothing to compensate)
  |
  +-- Step 2: CreateSAPSalesOrder(sfOrderId)
  |     +-- onSuccess: record SAP SO number, register compensateStep2()
  |     +-- onFailure: COMPENSATE [Step 1]
  |
  +-- Step 3: CreateNetSuiteInvoice(sapSONumber)
  |     +-- onSuccess: record NS Invoice ID, register compensateStep3()
  |     +-- onFailure: COMPENSATE [Step 2, Step 1]
  |
  +-- Step 4: CapturePayment(nsInvoiceId)     NON-COMPENSABLE
        +-- onSuccess: SAGA COMPLETE
        +-- onFailure: COMPENSATE [Step 3, Step 2, Step 1]

Integration Pattern Decision Tree

START — User needs to handle failures in multi-ERP workflows
+-- Is the failed operation within a single ERP?
|   +-- YES -> Use the ERP's native rollback (SAP LUW, SF trigger rollback)
|   +-- NO -> Distributed workflow, continue
+-- How many systems have already committed?
|   +-- 0 -> No compensation needed — just fail and retry
|   +-- 1 -> Simple bilateral compensation — reverse the one committed op
|   +-- 2+ -> Full saga with compensation registry
+-- Are all committed operations reversible via API?
|   +-- YES -> Backward recovery (compensating transactions)
|   |   +-- < 5 steps? -> Inline compensation logic
|   |   +-- >= 5 steps? -> Use Temporal or Step Functions orchestrator
|   +-- PARTIALLY -> Hybrid approach
|   |   +-- Order steps: compensable first, non-compensable last
|   |   +-- For compensable steps -> backward recovery
|   |   +-- For non-compensable steps -> forward recovery (retry)
|   +-- NO -> Forward recovery only (retry failed step until success)
+-- What if compensation itself fails?
|   +-- Financial/regulated -> Dead letter queue + manual reconciliation
|   +-- Best-effort -> Log failure + alert + scheduled retry
|   +-- Can retry indefinitely -> Temporal durable execution
+-- Orchestration tool?
    +-- Need durability guarantees -> Temporal (code-first, replay-safe)
    +-- AWS-native -> Step Functions (state machine)
    +-- iPaaS-based -> MuleSoft/Boomi/Workato with error handlers
    +-- Simple (< 3 steps) -> Custom code with compensation array

Quick Reference

Compensating Actions Per ERP Per Operation Type

Step-by-Step Integration Guide

1. Design your compensation registry

Before writing any saga code, map every step to its compensating action. Register the compensation BEFORE executing the step — this prevents orphaned state when an activity times out mid-execution. [src2]

// Compensation registry pattern — register BEFORE execute
interface SagaStep<T> {
  name: string;
  execute: () => Promise<T>;
  compensate: (result: T) => Promise<void>;
}

class CompensationRegistry {
  private completedSteps: Array<{
    name: string;
    compensate: () => Promise<void>;
  }> = [];

  async executeStep<T>(step: SagaStep<T>): Promise<T> {
    const placeholder = { name: step.name, compensate: async () => {} };
    this.completedSteps.unshift(placeholder);
    const result = await step.execute();
    placeholder.compensate = () => step.compensate(result);
    return result;
  }

  async compensateAll(): Promise<CompensationReport> {
    const report: CompensationReport = { succeeded: [], failed: [] };
    for (const step of this.completedSteps) {
      try {
        await step.compensate();
        report.succeeded.push(step.name);
      } catch (err) {
        report.failed.push({ name: step.name, error: err });
      }
    }
    return report;
  }
}

Verify: The registry should contain entries in reverse execution order.

2. Define per-ERP compensating actions

Each ERP has different API semantics for undoing operations. Define typed compensating action factories for each ERP. [src4, src5, src6, src8]

// Salesforce compensation actions
const salesforceCompensations = {
  deleteRecord: (objectType: string, recordId: string) => async () => {
    await sfClient.delete(`/sobjects/${objectType}/${recordId}`);
  },
  undeleteRecord: (recordId: string) => async () => {
    await sfClient.soap('undelete', { ids: [recordId] });
  },
};

// SAP S/4HANA compensation actions
const sapCompensations = {
  reverseDocument: (companyCode, docNumber, fiscalYear, reasonCode) => async () => {
    await sapClient.call('BAPI_ACC_DOCUMENT_REV_POST', {
      OBJECTKEY: docNumber, BUKRS: companyCode,
      GJAHR: fiscalYear, REASON_REV: reasonCode,
    });
  },
  reverseGoodsMovement: (materialDoc, year) => async () => {
    await sapClient.post('/API_GOODSMVT_2/GoodsMovement', {
      GoodsMovementType: '102', MaterialDocument: materialDoc,
      MaterialDocumentYear: year,
    });
  },
};

// NetSuite compensation actions
const netsuiteCompensations = {
  voidTransaction: (transactionId, tranType) => async () => {
    await nsClient.post('/transaction/void', {
      id: transactionId, type: tranType,
    });
  },
};

// Dynamics 365 Finance compensation actions
const d365Compensations = {
  reverseJournal: (journalBatchNumber) => async () => {
    await d365Client.post('/GeneralJournalEntries/reverse', {
      JournalBatchNumber: journalBatchNumber,
    });
  },
};

Verify: Each compensating action should be independently testable.

3. Wire the saga orchestrator

Connect your steps and compensations in an orchestrator. [src2, src7]

async function orderToPaySaga(order: OrderRequest): Promise<SagaResult> {
  const registry = new CompensationRegistry();
  try {
    const sfOppId = await registry.executeStep({
      name: 'createSalesforceOpportunity',
      execute: () => sfClient.createOpportunity(order),
      compensate: (oppId) => salesforceCompensations.revertStatus(
        'Opportunity', oppId, 'Prospecting')(),
    });
    const sapSONumber = await registry.executeStep({
      name: 'createSAPSalesOrder',
      execute: () => sapClient.createSalesOrder(order, sfOppId),
      compensate: (soNumber) => sapCompensations.reverseDocument(
        order.companyCode, soNumber, currentFiscalYear(), '01')(),
    });
    // Step 3, Step 4 (non-compensable last)...
    return { status: 'completed', sfOppId, sapSONumber };
  } catch (error) {
    const report = await registry.compensateAll();
    if (report.failed.length > 0) {
      await deadLetterQueue.publish({ sagaId: order.sagaId, compensationFailures: report.failed });
    }
    throw new SagaCompensationError(error, report);
  }
}

Verify: Test by injecting a failure at each step and confirming all prior steps are compensated.

4. Handle compensation failures

When a compensating transaction itself fails, route to a dead letter queue — do not recurse. [src1, src2]

class CompensationFailureHandler {
  private maxRetries = 3;
  async handleFailedCompensation(
    sagaId: string, failedStep: string,
    compensateAction: () => Promise<void>, attempt = 1
  ): Promise<void> {
    try {
      await compensateAction();
    } catch (error) {
      if (attempt < this.maxRetries) {
        await sleep(Math.pow(2, attempt) * 1000);
        return this.handleFailedCompensation(sagaId, failedStep, compensateAction, attempt + 1);
      }
      // Exhausted retries — dead letter queue
      await this.dlq.publish({ sagaId, failedStep, attempts: attempt,
        error: error.message, requiresManualIntervention: true });
    }
  }
}

Verify: Confirm DLQ receives messages for steps that fail compensation after max retries.

Code Examples

Python: Saga Orchestrator with Compensation Registry

# Input:  List of saga steps with execute/compensate callables
# Output: SagaResult with status and compensation report

import asyncio
from dataclasses import dataclass, field
from typing import Any, Callable, Awaitable

@dataclass
class SagaStep:
    name: str
    execute: Callable[[], Awaitable[Any]]
    compensate: Callable[[Any], Awaitable[None]]

class SagaOrchestrator:
    def __init__(self):
        self._completed = []

    async def run(self, steps):
        results = {}
        try:
            for step in steps:
                result = await step.execute()
                self._completed.insert(0, (step.name, lambda r=result, s=step: s.compensate(r)))
                results[step.name] = result
            return {"status": "completed", "results": results}
        except Exception as e:
            report = await self._compensate_all()
            return {"status": "compensated", "error": str(e), "report": report}

    async def _compensate_all(self):
        succeeded, failed = [], []
        for name, comp_fn in self._completed:
            try:
                await comp_fn()
                succeeded.append(name)
            except Exception as e:
                failed.append({"step": name, "error": str(e)})
        return {"succeeded": succeeded, "failed": failed}

JavaScript/Node.js: Temporal Workflow with Compensation

// Input:  Order details from upstream system
// Output: Completed saga or compensated state with audit trail

import { proxyActivities } from '@temporalio/workflow';

const { createSFOpportunity, cancelSFOpportunity,
        createSAPSalesOrder, reverseSAPDocument,
        createNSInvoice, voidNSTransaction } = proxyActivities({
  startToCloseTimeout: '30s',
  retry: { maximumAttempts: 3 },
});

export async function orderToPayWorkflow(order) {
  const compensations = [];
  try {
    compensations.unshift(() => cancelSFOpportunity(sfOppId));
    const sfOppId = await createSFOpportunity(order);

    compensations.unshift(() => reverseSAPDocument(sapSONum));
    const sapSONum = await createSAPSalesOrder(order, sfOppId);

    compensations.unshift(() => voidNSTransaction(nsInvId));
    const nsInvId = await createNSInvoice(order, sapSONum);

    return { status: 'completed', sfOppId, sapSONum, nsInvId };
  } catch (err) {
    for (const compensate of compensations) {
      try { await compensate(); }
      catch (compErr) { console.error('Compensation failed:', compErr.message); }
    }
    throw err;
  }
}

Error Handling & Failure Points

Common Error Scenarios

Failure Points in Production

• Compensation ordering matters: If Step 3 depends on Step 2's data, compensating Step 2 before Step 3 may fail. Always compensate in reverse execution order. [src1]
• SAP period-end blocking: Reversal documents require open posting periods. Fix: Post to current period with reason code indicating cross-period reversal. [src4]
• NetSuite preference conflict: transaction.void() throws an error if "Void Using Reversing Journals" is enabled. Fix: Create a reversing journal entry manually via SuiteScript. [src5]
• Salesforce governor limits during compensation: A saga compensating 200+ records hits DML limits. Fix: Batch compensations into groups of 150 or use Bulk API. [src8]
• D365 settlement reversal dependency: Cannot reverse a vendor payment until settlement is first reversed. Fix: Always unapply settlements before reversing payments. [src6]
• Temporal workflow timeout kills compensation: If workflow timeout is too short, compensation may be interrupted. Fix: Set workflow timeouts generously or use child workflows for compensation. [src2]

Anti-Patterns

Wrong: Ignoring compensation — assuming failures are rare

// BAD — no compensation logic, relies on "it usually works"
async function naiveOrderFlow(order) {
  const sfId = await createSalesforceOpp(order);
  const sapSO = await createSAPOrder(order, sfId);     // What if this fails?
  const nsInv = await createNetSuiteInvoice(order, sapSO); // sfId is orphaned
  return { sfId, sapSO, nsInv };
}
// Result: Salesforce has an Opportunity with no matching SAP order

Correct: Every step has a registered compensation

// GOOD — every step has a compensating action
async function compensatedOrderFlow(order) {
  const registry = new CompensationRegistry();
  try {
    const sfId = await registry.executeStep({
      name: 'sf_opp', execute: () => createSalesforceOpp(order),
      compensate: (id) => deleteSalesforceOpp(id),
    });
    // ... remaining steps with compensation
    return { sfId };
  } catch (e) {
    await registry.compensateAll();
    throw e;
  }
}

Wrong: Assuming ERP API operations are idempotent

// BAD — retrying compensation without idempotency key
async function retryCompensation(action) {
  for (let i = 0; i < 3; i++) {
    try { await action(); return; }
    catch (e) { /* retry */ }
  }
}
// Result: SAP creates 3 reversal documents for 1 original

Correct: Idempotent compensation with tracking

// GOOD — idempotency key prevents duplicate compensations
async function idempotentCompensation(sagaId, stepName, action) {
  const key = `${sagaId}:${stepName}:compensate`;
  const existing = await compensationLog.find(key);
  if (existing?.status === 'completed') return;
  await compensationLog.upsert(key, { status: 'in_progress' });
  try {
    await action();
    await compensationLog.upsert(key, { status: 'completed' });
  } catch (error) {
    await compensationLog.upsert(key, { status: 'failed', error: error.message });
    throw error;
  }
}

Wrong: Non-compensable steps early in the saga

// BAD — payment captured at Step 2, but Step 3 can fail
async function badStepOrdering(order) {
  const sfId = await createSalesforceOpp(order);
  const paymentId = await capturePayment(order);         // NON-COMPENSABLE
  const sapSO = await createSAPOrder(order, sfId);       // If this fails...
  // ...payment already captured but no SAP order. Refund takes 5-10 days.
}

Correct: Non-compensable steps execute last

// GOOD — non-compensable payment capture is the final step
async function correctStepOrdering(order) {
  const sfId = await createSalesforceOpp(order);         // compensable
  const sapSO = await createSAPOrder(order, sfId);       // compensable
  const nsInv = await createNetSuiteInvoice(order, sapSO); // compensable
  const paymentId = await capturePayment(order);         // NON-COMPENSABLE (last)
}

Common Pitfalls

• Audit trail for compensated transactions: Compensated transactions must leave a complete audit trail. SOX/IFRS mandate reversed financial transactions remain visible. Fix: Log every compensation action with original transaction ID, timestamp, reason, and compensating transaction ID. [src1]
• Assuming void and reverse are the same: In NetSuite, voiding removes GL impact entirely; reversing creates an offsetting journal. SOX compliance requires reversal, not void. Fix: Use reversing journals for financial transactions in regulated environments. [src5]
• Compensation timing assumptions: SAP reversals require open posting periods. If fiscal period closes between original posting and compensation, reversal is blocked. Fix: Check period status before SAP reversals; if closed, post to current period with cross-period reason code. [src4]
• Ignoring concurrent modifications: Between original operation and compensation, another user may have modified the record. Fix: Use conditional updates (ETags, version fields, SystemModstamp) to detect concurrent modifications. [src1]
• Not testing compensation paths: Teams test the happy path exhaustively but never test compensations. Fix: Include compensation testing in CI — inject failures at each saga step. [src2]
• Recursive compensation: When compensation fails, some teams try to "compensate the compensation." Fix: Cap at one compensation attempt per step. If compensation fails after retries, route to DLQ. [src1, src7]

Diagnostic Commands

# Check SAP posting period status (must be open for reversals)
curl -X GET "$SAP_BASE_URL/API_FISCALYEARPERIOD_SRV/FiscalYearPeriods?\
$filter=FiscalYear eq '2026' and FiscalPeriod eq '03'" \
  -H "Authorization: Bearer $SAP_TOKEN"

# Salesforce: check if record is in Recycle Bin (available for undelete)
curl "$SF_INSTANCE/services/data/v62.0/queryAll/?q=\
SELECT+Id,IsDeleted+FROM+Opportunity+WHERE+Id='$OPP_ID'" \
  -H "Authorization: Bearer $SF_TOKEN"

# D365 Finance: check if journal can be reversed
curl -X GET "$D365_BASE_URL/data/GeneralJournalEntries?\
\$filter=JournalBatchNumber eq '$JOURNAL_BATCH'" \
  -H "Authorization: Bearer $D365_TOKEN"

# Check dead letter queue for failed compensations (AWS SQS example)
aws sqs get-queue-attributes \
  --queue-url "$DLQ_URL" \
  --attribute-names ApproximateNumberOfMessages

# Temporal: check workflow compensation status
tctl workflow show -w "$SAGA_WORKFLOW_ID" -r "$RUN_ID"

When to Use / When Not to Use

Cross-System Comparison

Important Caveats

• ERPs update their reversal APIs with each release. SAP's API_GOODSMVT_2 replaced older BAPIs in 2023; always verify the current recommended API for your S/4HANA version.
• NetSuite's transaction.void() behavior fundamentally changes based on a single account-level preference. Test in sandbox with the same preference settings as production.
• Salesforce Recycle Bin has a 15-day retention limit and a 25x storage limit. High-volume orgs may hit the Recycle Bin limit, making undelete impossible.
• Financial compensations in regulated industries (SOX, IFRS, GAAP) require specific reversal documentation. A simple API delete is not compliant — you must create offsetting entries with audit-linkable references.
• Temporal and Step Functions provide durable execution guarantees, but they do not make ERP APIs themselves more reliable. The ERP is still the bottleneck.
• Compensation timing is critical: the longer the delay between original operation and compensation, the higher the risk of concurrent modifications, period closings, and dependent downstream processes.