---
id: ADR-COM-FUL-003
title: Evaluate current financial facts before recording event consumption
product_area: commerce
module: fulfillment
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
decision: >-
  Use event identity to select work, read current financial facts and retain the
  receipt only after processing succeeds.
constrains:
  - WF-COM-FUL-002
  - WF-COM-FUL-005
  - SVC-COM-FUL-fulfillment
  - DOM-COM-FUL-001
origin: >-
  services-commerce:docs/migrations/obligation-register/README.md#D-P4-04,
  #D-P4-13 (build decisions); Accounting's change-events contract (at least
  once, idempotent on event id)
alternatives:
  - option: Use financial amounts from the delivered event.
    why_not: >-
      An event amount can be older than the financial position at evaluation
      time.
  - option: Store the event receipt before doing its work.
    why_not: An early success receipt would suppress recovery after failed processing.
  - option: Poll financial events through a retained cursor.
    why_not: >-
      The current implementation uses event invocation and position reads rather
      than cursor polling.
consequences:
  - >-
    Duplicate event delivery can repeat evaluation while retaining one gate
    authorization.
  - >-
    Pending recovery is bounded and excludes blocked work, so it has no
    ten-minute completion guarantee.
  - >-
    The facts provider defaults to a fixture unless its deployment selects the
    live provider.
supersedes: []
evidence:
  - >-
    services-commerce at c8b66a98: modules/fulfillment/services/facts/*.ts;
    contracts/financial-facts.ts; aws/cdk/commerce.function-environment.ts.
---

# Evaluate current financial facts before recording event consumption

## Context

Financial events can arrive more than once or after later changes to the receivable position.

## Decision

Use event identity to select work, read current financial facts and retain the receipt only after processing succeeds.

## Alternatives Considered

Use financial amounts from the delivered event. An event amount can be older than the financial position at evaluation time.

Store the event receipt before doing its work. An early success receipt would suppress recovery after failed processing.

Poll financial events through a retained cursor. The current implementation uses event invocation and position reads rather than cursor polling.

## Consequences

Conditional opening prevents duplicate authorization, but earlier side effects can survive a failed event. The bounded sweep supplies partial recovery.