Finance acknowledges ADR-0038 with recognition, correction-period, and reconciliation requirements
Finance acknowledges ADR-0038 and accepts Option A. Delivery should own the guarded operator workflow and effective lesson outcome. Revenue should own the append-only credit and recognition correction. The original lesson lifecycle facts, terminal reservation state, credit-ledger rows, and recognition rows remain immutable.
Finance also accepts Revenue's durable correction identity, preview-state, balance, active-reservation, and service-recovery guardrails in 2026-07-29-revenue-adr-0038-guardrails-and-api-commitment. Those refinements strengthen the chosen option and do not change Finance's acknowledgment.
Recognition treatment
The signed customer-credit delta and the recognition adjustment are separate facts. Revenue must derive recognition from the difference between the policy treatment of the previous effective outcome and the policy treatment of the corrected effective outcome. Revenue must not infer recognition from the sign of net_credit_delta.
For cash-backed sold credits, a correction that removes an earned disposition posts append-only contra recognition linked to the original recognition fact. A correction that creates an earned disposition posts append-only gross recognition linked to the correction, reservation, lesson, and source credit facts. A net-zero correction that changes only financial classification has zero profit-and-loss impact. It needs an auditable reclassification record, but it must not inflate both gross and contra recognition when the recognized amount is unchanged.
For non-cash-backed service-recovery credits, ADR-finance-003 remains controlling. Consumption, forfeiture, release, reversal, or reclassification of those credits produces no gross recognition and no contra recognition. A data correction does not convert a goodwill credit into cash-backed consideration.
Outcome correction is not a payment or refund. Positive, negative, and net-zero corrections therefore create no cash receipt or cash-refund row. Any deferred-revenue movement must follow the cash-backed credit provenance actually affected by the correction, not the raw customer credit balance.
The correcting financial facts belong to the correction period identified by corrected_at or the Revenue correction occurred_at. They do not silently rewrite a previously served reporting period. If a material closed-period error ever requires retrospective restatement, that is a separate Finance decision and not an automatic behavior of this endpoint.
Used benefits
Finance confirms that automatic clawback of an already-used customer benefit must remain blocked. Revenue's current inability to allocate later debits to a specific service-recovery credit lot means an unreversed lesson-linked service-recovery grant cannot be proved unused. Until Revenue has explicit use provenance, automatic revocation must block and route to manager and Revenue review. Aggregate balance is not sufficient evidence of use or non-use.
Reconciliation and silver requirements
Finance reads warehouse silver and will not reconstruct corrections from Delivery or Revenue bronze. Before contract promotion, the conforming Revenue silver surface must make each correction reconstructible through stable fields for correction id, organization, lesson, reservation, signed credit delta, previous and effective financial classification, correction timestamp, linked credit-ledger entry ids, linked recognition or contra-recognition row ids, and the source recognition row being reversed or reclassified when applicable.
The correction API and silver surface must distinguish:
- customer-credit balance movement;
- recognized-revenue movement;
- non-profit-and-loss classification change;
- non-cash-backed benefit state; and
- cash movement, which is always zero for this workflow.
Those distinctions let Finance preserve zero-tolerance tie-back to Revenue's authoritative ledger without treating a net-zero reclassification as no audit event, or treating a positive credit return as automatically contra revenue.
The proposed lesson.outcome.corrected payload is sufficient as the Delivery-side effective-outcome signal when it carries the stable Revenue correction reference, signed credit delta, and effective financial classification. Finance's monetary tie-back remains the Revenue correction, credit-ledger, and recognition silver facts. The event must not become a substitute financial ledger.
Analytics questions
- What recognized-revenue amount changed because of corrections in the reporting period? The linked Revenue recognition and contra-recognition rows, correction id, and correction timestamp answer this.
- Which corrections changed customer credits but had no profit-and-loss or cash effect? The signed credit delta, effective financial classification, recognition-row linkage, and zero cash classification answer this.
- Do correction-driven finance-mart figures reconcile to Revenue's immutable source facts at zero tolerance? The correction-to-ledger and correction-to-recognition references answer this without reading bronze.
Position
These requirements are normative for Finance's acknowledgment and should land in the accepted ADR or the promoted credit-reservation-lock correction sub-spec. They are refinements to Option A, not objections. Finance has no operational write or event-producer commitment in this workflow. Once the Revenue and Platform silver shapes satisfy the reconstructability requirements, the existing finance-mart composition should inherit the correcting facts without a new Finance-owned source-of-record path.
References
- ADR-0038:
adrs/ADR-0038-guarded-lesson-outcome-corrections.md - Delivery proposal:
2026-07-29-delivery-guarded-lesson-outcome-corrections-proposal - Revenue guardrails:
2026-07-29-revenue-adr-0038-guardrails-and-api-commitment - Finance recognition policy:
adrs/finance/003-non-cash-backed-credit-recognition-policy.md - Finance mart recognition manifest:
contracts/finance-mart/revenue-recognition-rollup.md - Finance mart reconciliation manifest:
contracts/finance-mart/reconciliation.md