---
id: ATS-ACC-REC-017
scope: CAP-ACC-REC-017
product_area: accounting
module: reconciliation
revision: 3
status: proposed
approved_by: null
approved_at: null
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
scenarios:
  - id: ATS-ACC-REC-017-01
    title: Daily schedules are created without overriding changes
    level: api
    proves:
      - BR-CAP-ACC-REC-017-01
    preconditions: Two workspaces include one disabled existing schedule.
    steps: Ensure schedules twice in each workspace.
    expected: Missing local-zone schedules are created once and the disabled schedule remains disabled.
    negative: false
    data_needs: No additional fixture beyond the case setup.
    bound_to:
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-schedules.integration.spec.js#creates
        the three daily schedules on the first pass
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-schedules.integration.spec.js#keeps
        the tenant’s zone on each schedule
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-schedules.integration.spec.js#creates
        nothing on a second pass
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-schedules.integration.spec.js#leaves
        a schedule a person disabled disabled
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-schedules.integration.spec.js#gives
        another tenant its own three
      - TST-ACC-REC-077
    provenance: test
    source: >-
      services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-schedules.integration.spec.js#creates
      the three daily schedules on the first pass
    category: rule
  - id: ATS-ACC-REC-017-02
    title: Overdue detection and repeat delivery
    level: api
    proves:
      - BR-CAP-ACC-REC-017-02
      - BR-CAP-ACC-REC-017-03
      - BR-CAP-ACC-REC-017-10
    preconditions: 'Items include transit, overdue, resolved and investigating cases.'
    steps: Sweep a selected day twice.
    expected: 'Only newly overdue cases raise informative blockers, and the repeat produces no duplicate problem.'
    negative: false
    data_needs: Provide sweep fixture for this case.
    bound_to:
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        the item past its grace as an open `overdue-settlement` blocker
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#titles
        the item’s exception with its amount, payment method, kind and the date it occurred, never its source
        key
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        nothing for an item in transit, resolved or already under investigation
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#leaves
        the gift in transit on 2026-10-12, raising nothing for it
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        nothing when it runs again at the same occurrence
      - >-
        services-accounting:modules/reconciliation/tests/unit/exceptions/exception-titles.spec.js#reads the
        amount, the payment method, the kind, the date and the customer
      - TST-ACC-REC-076
      - TST-ACC-REC-080
    provenance: test
    source: >-
      services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
      the item past its grace as an open `overdue-settlement` blocker
    category: invariant
  - id: ATS-ACC-REC-017-03
    title: Sweep clears settled or resolved conditions
    level: api
    proves:
      - BR-CAP-ACC-REC-017-04
    preconditions: Open overdue exceptions refer to now-finalized claims or resolved items.
    steps: Run the overdue sweep.
    expected: Both problems close with the reconciliation or resolution explanation.
    negative: false
    data_needs: No additional fixture beyond the case setup.
    bound_to:
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#clears
        the exception of an item a finalized batch now claims, naming the batch
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#clears
        the exception of an item since resolved, naming the resolution
      - TST-ACC-REC-076
    provenance: test
    source: >-
      services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#clears
      the exception of an item a finalized batch now claims, naming the batch
    category: transition
  - id: ATS-ACC-REC-017-04
    title: Payout-age boundary and clearing
    level: api
    proves:
      - BR-CAP-ACC-REC-017-05
    preconditions: 'Live deposits are four, five or six business days old alongside a voided one.'
    steps: 'Sweep, finalize an eligible old deposit and sweep again.'
    expected: 'Only beyond-five-day live deposits are raised, and finalization clears their detected problem.'
    negative: false
    data_needs: No additional fixture beyond the case setup.
    bound_to:
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        no unbalanced payout on 2026-10-12: the old payout’s fifth business day is Tuesday 10-13
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        the old payout and not the payout exactly five business days old, nor the voided one
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#clears
        the unbalanced exception of a payout now in a finalized batch
      - >-
        services-accounting:modules/reconciliation/tests/unit/exceptions/exception-titles.spec.js#titles an
        unbalanced deposit with its amount, accounting date and number
      - TST-ACC-REC-076
      - TST-ACC-REC-080
    provenance: test
    source: >-
      services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
      no unbalanced payout on 2026-10-12: the old payout’s fifth business day is Tuesday 10-13
    category: boundary
  - id: ATS-ACC-REC-017-05
    title: Drift detects without repair
    level: api
    proves:
      - BR-CAP-ACC-REC-017-06
    preconditions: A reconciliation’s maintained counters disagree with its rows.
    steps: Run drift inspection twice and inspect totals.
    expected: >-
      One drift problem identifies discrepancies, totals remain untouched and no duplicate exception is
      created.
    negative: false
    data_needs: Provide Altered counters for this case.
    bound_to:
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#checks
        every open and finalized batch, and raises the drifting one
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        `totals-drift` naming each total that differs from the rows
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#rewrites
        no total
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        nothing new when it runs again
      - TST-ACC-REC-076
    provenance: test
    source: >-
      services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#checks
      every open and finalized batch, and raises the drifting one
    category: invariant
  - id: ATS-ACC-REC-017-06
    title: Global purge preserves current keys
    level: api
    proves:
      - BR-CAP-ACC-REC-017-07
    preconditions: 'Expired completions, abandoned claims and fresh completions span workspaces.'
    steps: Run request-key purge.
    expected: Expired and abandoned records are removed while fresh completions survive.
    negative: false
    data_needs: Provide Keys of several workspaces for this case.
    bound_to:
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#removes
        every tenant’s old completions and lost claims and answers how many (at least these four; the purge is
        every tenant’s)
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#keeps
        the fresh completion
      - >-
        services-accounting:modules/reconciliation/tests/integration/db/idempotency-keys.table.integration.spec.js#let
        that transaction delete the purgeable keys and no other, rolled back here
      - TST-ACC-REC-076
      - TST-ACC-REC-031
    provenance: test
    source: >-
      services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#removes
      every tenant’s old completions and lost claims and answers how many (at least these four; the purge is
      every tenant’s)
    category: boundary
  - id: ATS-ACC-REC-017-07
    title: On-demand job grants and unit scope
    level: api
    proves:
      - BR-CAP-ACC-REC-017-08
      - BR-CAP-ACC-REC-017-09
    preconditions: Two units and a caller lacking accept are available.
    steps: 'Run every supported job, scope new overdue detection to one unit and try unauthorized or unknown jobs.'
    expected: 'Authorized jobs report their outcome, new overdue detection respects its unit and invalid calls fail.'
    negative: true
    data_needs: Configure both business units used by the case.
    bound_to:
      - >-
        services-accounting:modules/reconciliation/tests/e2e/outstanding.e2e.spec.js#runs the totals drift
        check for the tenant and answers its outcome
      - >-
        services-accounting:modules/reconciliation/tests/e2e/outstanding.e2e.spec.js#runs the overdue sweep as
        of today in the tenant’s zone
      - >-
        services-accounting:modules/reconciliation/tests/e2e/outstanding.e2e.spec.js#runs the idempotency
        purge
      - >-
        services-accounting:modules/reconciliation/tests/e2e/outstanding.e2e.spec.js#refuses a job that is not
        one of the three with 400
      - >-
        services-accounting:modules/reconciliation/tests/e2e/outstanding.e2e.spec.js#refuses a principal
        without accounting.reconciliation-exceptions.accept with 403
      - >-
        services-accounting:modules/reconciliation/tests/integration/services/scheduled/reconciliation-scheduled-work.integration.spec.js#raises
        one exception: the beta unit’s overdue item, and leaves alpha’s item alone
      - >-
        services-accounting:tests/unit/reconciliation/outstanding-api-mapper.spec.ts#keeps as_of when the body
        gives a local date
      - >-
        services-accounting:tests/unit/reconciliation/outstanding-api-mapper.spec.ts#keeps business_unit_id
        when the body names a unit
      - >-
        services-accounting:tests/unit/reconciliation/outstanding-api-mapper.spec.ts#refuses an as_of that is
        not a real date
      - TST-ACC-REC-024
      - TST-ACC-REC-076
      - TST-ACC-REC-098
    provenance: test
    source: >-
      services-accounting:modules/reconciliation/tests/e2e/outstanding.e2e.spec.js#runs the totals drift check
      for the tenant and answers its outcome
    category: permission
  - id: ATS-ACC-REC-017-08
    title: Missing-money sweep journey
    level: api
    proves:
      - AS-JNY-ACC-REC-004-02
    preconditions: An overdue item and stale deposit are recorded.
    steps: 'Sweep repeatedly, try resolution, accept or settle and sweep again.'
    expected: 'Detection is deduplicated, premature resolution fails and explained money clears its problem.'
    negative: false
    data_needs: Use the isolated reconciliation fixture unit.
    bound_to:
      - >-
        react-console:acceptance/accounting/playwright/journeys/reconciliation-close/ACT-ACC-0606.spec.ts#ACT-ACC-0606
      - TST-ACC-REC-014
    provenance: test
    source: >-
      react-console:acceptance/accounting/playwright/journeys/reconciliation-close/ACT-ACC-0606.spec.ts#ACT-ACC-0606
    category: interaction
  - id: ATS-ACC-REC-017-09
    title: Bounded scans do not establish full coverage
    level: api
    proves:
      - BR-CAP-ACC-REC-017-12
    preconditions: More than five hundred unresolved payouts include one outside the lookback.
    steps: Repeat a same-day sweep and inspect examined records and its more-work flag.
    expected: The bounded selection does not establish traversal of later or older payouts without a cursor.
    negative: true
    data_needs: Provide Isolated records for the cases described for this case.
    bound_to: []
    provenance: proposed
    source: 'services-accounting:modules/reconciliation/services/scheduled/overdue-sweep.ts'
    category: boundary
  - id: ATS-ACC-REC-017-10
    title: Detection preserves accepted work
    category: interaction
    level: api
    proves:
      - AS-JNY-ACC-REC-004-02
      - BR-CAP-ACC-REC-015-03
    interacts_with:
      - CAP-ACC-REC-015
    relies_on:
      - ATS-ACC-REC-017-08
      - ATS-ACC-REC-015-02
    preconditions: Use one isolated workspace with the financial records and caller roles required by the relied-on cases.
    steps:
      - do: 'Detect missing money, accept its concern independently and rerun the same condition.'
        expect: The raiser preserves the accepted record without creating a replacement blocker.
        provenance: proposed
        source:
          - >-
            specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-017-catch-overdue-money-stale-deposits-and-drifting-totals-every.md
          - >-
            specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-015-raise-work-and-resolve-reconciliation-problems.md
    expected: The raiser preserves the accepted record without creating a replacement blocker.
    negative: false
    data_needs: >-
      Local merchant and bank accounts, an open operational batch and distinct preparation and approval
      callers.
    bound_to: []
    provenance: proposed
    source:
      - >-
        specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-017-catch-overdue-money-stale-deposits-and-drifting-totals-every.md
      - >-
        specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-015-raise-work-and-resolve-reconciliation-problems.md
  - id: ATS-ACC-REC-017-11
    title: Assessment detects money before its sweep
    category: interaction
    level: api
    proves:
      - BR-CAP-ACC-REC-017-02
      - BR-CAP-ACC-REC-017-03
      - BR-CAP-ACC-REC-017-10
      - BR-CAP-ACC-REC-018-04
    interacts_with:
      - CAP-ACC-REC-018
    relies_on:
      - ATS-ACC-REC-017-02
      - ATS-ACC-REC-018-03
    preconditions: Use one isolated workspace with the financial records and caller roles required by the relied-on cases.
    steps:
      - do: 'Assess overdue money before the sweep, run the sweep and assess again.'
        expect: Both reads identify overdue money and the later read links the detected concern.
        provenance: proposed
        source:
          - >-
            specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-017-catch-overdue-money-stale-deposits-and-drifting-totals-every.md
          - >-
            specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-018-tell-month-end-close-what-stops-a-period-from-closing.md
    expected: Both reads identify overdue money and the later read links the detected concern.
    negative: false
    data_needs: >-
      Local merchant and bank accounts, an open operational batch and distinct preparation and approval
      callers.
    bound_to: []
    provenance: proposed
    source:
      - >-
        specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-017-catch-overdue-money-stale-deposits-and-drifting-totals-every.md
      - >-
        specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-018-tell-month-end-close-what-stops-a-period-from-closing.md
  - id: ATS-ACC-REC-017-12
    title: Publication failure rolls back detected work
    category: interaction
    level: api
    proves:
      - BR-CAP-ACC-REC-017-02
      - BR-CAP-ACC-REC-017-03
      - BR-CAP-ACC-REC-017-10
      - BR-CAP-ACC-REC-015-08
    interacts_with:
      - CAP-ACC-REC-015
    relies_on:
      - ATS-ACC-REC-017-02
      - ATS-ACC-REC-015-07
    preconditions: Use one isolated workspace with the financial records and caller roles required by the relied-on cases.
    steps:
      - do: Make enabled attention publication fail during detection and retry after restoring publication.
        expect: Failure commits no new concern; the successful repeat retains concern and attention together.
        provenance: proposed
        source:
          - >-
            specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-017-catch-overdue-money-stale-deposits-and-drifting-totals-every.md
          - >-
            specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-015-raise-work-and-resolve-reconciliation-problems.md
    expected: Failure commits no new concern; the successful repeat retains concern and attention together.
    negative: true
    data_needs: >-
      Local merchant and bank accounts, an open operational batch and distinct preparation and approval
      callers.
    bound_to: []
    provenance: proposed
    source:
      - >-
        specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-017-catch-overdue-money-stale-deposits-and-drifting-totals-every.md
      - >-
        specs/accounting/reconciliation/planning/capabilities/CAP-ACC-REC-015-raise-work-and-resolve-reconciliation-problems.md
evidence:
  - >-
    Bindings identify existing tests at the pinned revisions; proposed cases remain unbound and describe the
    proof still needed.
coverage:
  rule: covered
  transition: covered
  permission: covered
  boundary: covered
  invariant: covered
  interaction: covered
  validation: 'gap: FND-ACC-REC-062'
  edge: 'gap: FND-ACC-REC-062'
  failure: 'gap: FND-ACC-REC-062'
  concurrency: 'gap: FND-ACC-REC-062'
coverage_notes:
  design_completeness: >-
    Covered categories count specified cases, including proposed cases. Exhaustive state-transition,
    permission-key and domain-invariant traceability remains a separate proof gap.
---

# Detect reconciliation concerns through scheduled checks: Capability Test Specification

## Coverage

| Rule | Proved by |
|---|---|
| `BR-CAP-ACC-REC-017-01` | `ATS-ACC-REC-017-01` |
| `BR-CAP-ACC-REC-017-02` | `ATS-ACC-REC-017-02` |
| `BR-CAP-ACC-REC-017-03` | `ATS-ACC-REC-017-02` |
| `BR-CAP-ACC-REC-017-04` | `ATS-ACC-REC-017-03` |
| `BR-CAP-ACC-REC-017-05` | `ATS-ACC-REC-017-04` |
| `BR-CAP-ACC-REC-017-06` | `ATS-ACC-REC-017-05` |
| `BR-CAP-ACC-REC-017-07` | `ATS-ACC-REC-017-06` |
| `BR-CAP-ACC-REC-017-08` | `ATS-ACC-REC-017-07` |
| `BR-CAP-ACC-REC-017-09` | `ATS-ACC-REC-017-07` |
| `BR-CAP-ACC-REC-017-10` | `ATS-ACC-REC-017-02` |
| `BR-CAP-ACC-REC-017-12` | `ATS-ACC-REC-017-09` |

## Interactions With Related Capabilities

Missing-money sweep journey. Detection preserves accepted work. Assessment detects money before its sweep. Publication failure rolls back detected work. Proposed interaction cases require executable proof.
