ENGINE 09

SFS-E09-CSH · CASH CONTROLS · REV 2026-07-20 · PRODUCTION

PRODUCTION = runnable end-to-end, CI-backed, full test suite passing. All data fictional and seeded.

Cash Management

Five read-only cash controls that re-derive before review

Cash Management independently re-derives five monthly cash controls: the bank-to-GL bridge, outstanding-check aging and crossfoot, wire segregation of duties, bank-register continuity, and concentration sweeps. It works in integer cents, reports findings without changing the inputs, and stops at readiness for human review. It never posts, drafts a journal entry, releases a wire, or writes back to a source system.

Cash is trusted only after the bridge, register, approvals, and sweep arithmetic can be re-derived. The public engine exposes those controls as deterministic validators and pins the behavior with an end-to-end tamper grid.

Run it Book a consultation

Architecture

functional block stack · static overview

Select a layer

Each layer is one implemented validation-only control. Select a layer for its business purpose and source-level behavior.

Key specifications

at a glance

5,290¹

Tests

the collected checks that pin this engine's behavior

5²

Controls

independent monthly cash validations

5,000 cases³

Invariant grid

constructed-to-tie inputs paired with targeted tampering

integer cents⁴

Amount model

no floating-point money arithmetic

READY FOR HUMAN REVIEW / NEEDS REVIEW⁵

Verdicts

readiness is not approval

always false⁶

Posting authority

the engine validates but cannot post

What it does for you

plain terms

Cash can appear plausible while a bridge is out of tie, a stale check is unresolved, a wire lacks segregation of duties, a running balance has drifted, or sweep legs do not foot. A controller needs each control recomputed from structured inputs and every exception carried forward without turning mechanical cleanliness into approval.

The seeded demo runs the complete monthly control set⁷. The CLI invokes all five validators on fictional data. Each reports READY FOR HUMAN REVIEW with zero findings, and the final line states that every control is read-only and nothing was posted.

A targeted tamper must trip the exact control⁸. Every point in the 5,000-case invariant grid runs once with an independently constructed tie and with at least one one-cent or one-field tamper. The wire-approval and cash-concentration grids exercise a second distinct tamper at every point. Each altered input must produce the exact finding code, so an implementation that always passes or always fails cannot satisfy the grid.

A wire cannot approve itself⁹. For an approved or scheduled wire, the engine requires a first and second approver and checks that the initiator and both approvers are three different people. Missing secondary approval, self-approval, duplicate approvers, and invalid scheduling each produce findings; the validator never releases the wire.

Functional block diagram

engineering · each block links to its source

Plain terms

Seeded Demo Inputs. fictional cash records enter five independent controls
Bank / GL Bridge. re-derives both reconciliation sides
Check Register. crossfoots status and aging
Wire Segregation. requires distinct approval roles
Register Continuity. rebuilds the running balance chain
Sweep Tie-Out. re-adds sweep legs and the roll-forward
CLI Readiness Result. prints one verdict per control and combines mechanical cleanliness into the process exit code
Human Review. a person controls approval, release, and any posting

Engineering

Seeded Demo Inputs. cash_engine.cli._run_all builds the fixed demo inputs and invokes every validator
Bank / GL Bridge. adjusted bank == adjusted book
Check Register. outstanding + stale amounts == displayed outstanding total
Wire Segregation. initiator, first approver, and second approver must be distinct
Register Continuity. opening plus signed movements == re-derived closing
Sweep Tie-Out. sub-account sweep sum == sweeps in; opening + sweeps - disbursements == close
CLI Readiness Result. all_clean is the conjunction of result.mechanical_clean; clean returns 0 and any review-required result returns 1
Human Review. every result carries manual gates and posting_authorized is always False

Instruction set

every public command

Command	Operation	Output	Exit	Artifacts
`python -m cash_engine --demo`	run all five controls on seeded fictional data	five READY FOR HUMAN REVIEW lines; findings=0; All clean.	0 for the bundled clean demo	none
`python -m cash_engine`	show the package command help	usage and --demo option	0	none
`python -m pytest -q`	run the cash engine behavior suites and invariant grid	pytest result summary	0 when the suite passes	none
`python -m pytest --collect-only -q -o addopts=`	re-derive the pinned engine test count	5290 tests collected	0	none

Benchmarks

measured demo results

Measure	Result
Engine tests¹⁰	5,290 tests collected live collection from the engine directory
Curated invariant grid¹¹	5,000 parametrized cases end-to-end clean and tampered inputs
Cases per validator¹²	1,000 grid points the grid is distributed across all five controls
Clean demo¹³	5 / 5 controls with zero findings the bundled fictional dataset exercises every control

Control characteristics

engineering

Plain terms

The engine determines mechanical readiness only. Every result carries manual gates, and posting_authorized remains False.

Engineering

Deterministic envelope. seeded fictional inputs, read-only operation, offline default mode.

Demo gate. READY FOR HUMAN REVIEW boundary

Severity	Verdict	Action
No findings	READY FOR HUMAN REVIEW	send the mechanically clean result to the documented manual gates
One or more findings	NEEDS REVIEW	retain the findings for a person; do not post, release, or write back

All five validators use integer cents and reject unsafe amount types instead of coercing them.
Each result is validation-only: posting_authorized is False and journal-entry, posting-action, and import-payload collections remain empty.
The public demo uses fixed fictional inputs, and the package declares no runtime dependencies.
The curated grid proves both sides of every control by coupling each constructed tie with at least one targeted tamper.

Operating limits

what it refuses to do

The engine never posts, drafts a journal entry, releases a wire, creates an import payload, or mutates a source system.¹⁴
READY FOR HUMAN REVIEW means the implemented mechanical checks found no findings; it is not sign-off or posting authorization.¹⁵
The public package validates generic structured inputs and does not include a bank connector, workbook adapter, or source-system writeback path.¹⁶
A nonzero bank or book error plug is not self-certifying; it remains a review finding that requires approval.¹⁷

See it run

brand animation

Cash Management diagram with a bank record tied to the general ledger above check aging, two wire approvals, and a concentration sweep — The existing Cash Management engine tile depicts the bank-to-ledger tie-out together with check aging, dual wire approvals, and concentration sweep controls.

Integration

how to run it

Distribution: public repository, MIT license.

git clone https://github.com/sophonfinance-wq/finance-automation-portfolio.git && cd finance-automation-portfolio/cash-management && python -m cash_engine --demo

python -m pytest --collect-only -q -o addopts=

Source on GitHub Engine README All tests, by engine Run in Codespaces

Substantiation

1py -3 -m pytest --collect-only -q -o addopts= (cash-management/); 5,290 tests collected on 2026-07-20 and pinned in site-datasheets/counts.json
2cash-management/README.md — The five controls
3cash-management/cash_engine/tests/test_curated_invariant_grid.py — 1,000 cases per validator x 5 validators
4cash-management/README.md — every amount is held in integer cents
5cash-management/cash_engine/* — each result.verdict returns READY FOR HUMAN REVIEW when mechanically clean, otherwise NEEDS REVIEW
6cash-management/cash_engine/* — each result.posting_authorized property returns False
7py -3 -m cash_engine --demo (cash-management/); output re-run on 2026-07-20; implementation in cash-management/cash_engine/cli.py
8cash-management/cash_engine/tests/test_curated_invariant_grid.py — module contract and five parametrized validator grids
9cash-management/cash_engine/wire_approval.py — WireApprovalValidator and WireApprovalResult
10py -3 -m pytest --collect-only -q -o addopts= (cash-management/); re-run 2026-07-20 and pinned in site-datasheets/counts.json
11cash-management/cash_engine/tests/test_curated_invariant_grid.py — 1,000 cases for each of five validators
12cash-management/cash_engine/tests/test_curated_invariant_grid.py — 1,000 cases per validator x 5 validators
13py -3 -m cash_engine --demo (cash-management/); re-run 2026-07-20
14cash-management/README.md and cash-management/cash_engine/* result types
15cash-management/README.md — Boundary; cash-management/cash_engine/* result.verdict and posting_authorized
16cash-management/cash_engine/bank_rec.py, outstanding_checks.py, wire_approval.py, bank_register.py, and cash_concentration.py — module boundaries
17cash-management/cash_engine/bank_rec.py — BANK_ERROR_REVIEW_REQUIRED and BOOK_ERROR_REVIEW_REQUIRED

Show us where the hours go.

One conversation: you describe the work that consumes your team's month; we tell you plainly what this engine can take over, what it can't, and what a scoped first phase would cost. Your people keep approval authority.

Book a free consultation