---
id: TST-ACC-REC-097
title: Reconciliation permissions and assigned policies
kind: unit
product_area: accounting
module: reconciliation
revision: 1
status: draft
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
repository: services-accounting
files:
  - tests/unit/reconciliation-permissions.spec.ts
implements:
  - ATS-ACC-REC-020-01
  - ATS-ACC-REC-020-02
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: Suite-owned workspace fixtures and deterministic records removed by suite cleanup.
evidence:
  - 'services-accounting:tests/unit/reconciliation-permissions.spec.ts'
bindings:
  - scenario: ATS-ACC-REC-020-01
    assertions:
      - >-
        services-accounting:tests/unit/reconciliation-permissions.spec.ts#publishes exactly the reconciliation
        keys of the architecture, no bulk among them
      - >-
        services-accounting:tests/unit/reconciliation-permissions.spec.ts#makes each read tier read, so the
        Read Only policy carries it
      - >-
        services-accounting:tests/unit/reconciliation-permissions.spec.ts#makes the ordinary writes tier user:
        reconciliation’s records are records, not configuration
      - >-
        services-accounting:tests/unit/reconciliation-permissions.spec.ts#makes every approval tier admin and
        sensitive
  - scenario: ATS-ACC-REC-020-02
    assertions:
      - >-
        services-accounting:tests/unit/reconciliation-permissions.spec.ts#lets the preparer record payouts and
        prepare reconciliations, and approve nothing
      - >-
        services-accounting:tests/unit/reconciliation-permissions.spec.ts#lets the approver do what the
        preparer does and the four approvals
      - >-
        services-accounting:tests/unit/reconciliation-permissions.spec.ts#files both policies under the
        accounting application
---

# Reconciliation permissions and assigned policies

## Verification Boundary

This suite evaluates the production rules or declarations with controlled inputs. It does not perform a complete financial workflow.

## What This Suite Proves

The executable assertions identified in the binding records supply the registered scenario observations. When a scenario names several suites, this suite supplies its listed assertions and does not independently establish every clause.

## What It Does Not Prove

Database enforcement, API authorization, console behavior and deployed workflow completion require separate suites.

## Real Dependencies and Test Doubles

Production rules and declarations are real; fixtures supply literal amounts, dates and permission sets. No live database or deployed service participates.

## Must Not Be Doubled

The rule or declaration under examination remains production code; expected results remain independent literal observations.