---
id: ADR-ACC-CLS-013
title: Execution Uses System Authority after Request Acceptance
product_area: accounting
module: close
revision: 1
status: proposed
design_intent: open
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Submission checks the acting caller’s grant, while later job evaluation uses
  system authority and does not resolve the original requester’s current grant.
constrains:
  - WF-ACC-CLS-001
  - WF-ACC-CLS-002
  - WF-ACC-CLS-003
  - DOM-ACC-CLS-002
origin: >-
  OQ-ACC-CLS-001 (open); FND-ACC-CLS-016;
  services-accounting:docs/migrations/fiscal-close/README.md (FC2-4 decisions
  and departures)
alternatives:
  - option: Resolve the requester’s live authority during revalidation.
    why_not: >-
      The existing product question recommends this, but a supported Platform
      lookup must be designed.
  - option: Also resolve original-requester authority during recovery.
    why_not: >-
      The recovery caller already needs the action grant; whether the original
      requester also needs it remains a separate policy choice.
consequences:
  - >-
    The present job context passes the authorization readiness check as the
    system.
  - >-
    Recovery authority comes from the acting recovery caller rather than
    automatically from the requester.
supersedes: []
evidence:
  - >-
    services-accounting at f47cb263:
    modules/fiscal-close/services/jobs/fiscal-close-jobs.ts (submitPermission);
    services/readiness/close-authorization.ts.
---

# Execution Uses System Authority after Request Acceptance

## Context

Execution can begin or resume after the original person’s authority has changed. Product must choose whether saved submission authority remains sufficient.

## Decision

Record the implemented system-authority mechanism and keep its future policy open. Retry and cancellation independently check the person performing recovery.

## Alternatives Considered

Resolve the requester’s live authority during revalidation. The existing product question recommends this, but a supported Platform lookup must be designed.

Also resolve original-requester authority during recovery. The recovery caller already needs the action grant; whether the original requester also needs it remains a separate policy choice.

## Consequences

The present job context passes the authorization readiness check as the system. Recovery authority comes from the acting recovery caller rather than automatically from the requester.