---
id: TST-ACC-BAT-131
title: Batch rules recurring batch rules
kind: unit
product_area: accounting
module: batches
revision: 1
status: draft
product_intent: proposed
implementation_evidence: observed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
repository: services-accounting
files:
  - modules/batches/tests/unit/rules/recurring-batch-rules.spec.js
implements:
  - ATS-ACC-BAT-009-04
  - ATS-ACC-BAT-010-01
environment: mock
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: Each case owns its supplied rule inputs and test doubles.
assertion_sources:
  - scenario: ATS-ACC-BAT-009-04
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/unit/rules/recurring-batch-rules.spec.js#refuse
      Rhythm 1.0’s Handlebars helper, naming the field
  - scenario: ATS-ACC-BAT-010-01
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/unit/rules/recurring-batch-rules.spec.js#is
      the local date in the schedule’s zone when the UTC date is already the
      next day
  - scenario: ATS-ACC-BAT-010-01
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/unit/rules/recurring-batch-rules.spec.js#render
      the batch date with Liquid’s date filter, never moved across midnight
evidence:
  - provenance: observed
    source: >-
      services-accounting:modules/batches/tests/unit/rules/recurring-batch-rules.spec.js
    note: >-
      The executable file is inspected at the pinned revision; duration is an
      unmeasured planning estimate.
  - provenance: documented
    source: >-
      services-accounting:modules/batches/tests/unit/rules/recurring-batch-rules.spec.js#suite
      header
    note: 'Real: the rules and the shared Liquid renderer. Doubled: nothing.'
unbound_scope: null
---

# Batch rules recurring batch rules

## Verification Boundary

This suite exercises the named rule functions with controlled inputs. Its boundary ends before persistent accounting and deployed execution.

## What This Suite Proves

The assertions exercise batch rules recurring batch rules with controlled case inputs and compare permitted outcomes with their recorded refusals. The assertion anchors identify the supported portions of the bound scenarios.

## What It Does Not Prove

These checks do not prove transport authorization, transactional storage, scheduling delivery or the whole feature workflow.

## Real Dependencies and Test Doubles

The rule inputs and dependency callbacks are controlled by the case. Database, API dispatch and workflow delivery are outside this boundary.

## Must Not Be Doubled

Qualifying transactional integrity requires real storage and accounting execution beyond this rule-only suite.