Intercompany Reciprocity

Architecture

Key specifications

What it does for you

A development group runs as a tree of legal entities, and cash never stops moving between them: advances down the chain to fund predevelopment and overhead, repayments back up out of land sales, equity into projects. Each of those movements is booked twice, on two sets of books, by two people. The arithmetic on each set of books foots perfectly. Nothing inside any one company is out of balance. The break, when there is one, exists only in the space between two entities -- a due-from that one side carries larger than the due-to the other acknowledges, a closing balance that quietly stopped tying to the transactions that moved it, an advance funded from the capital arm when the protocol says it must come from the top parent. None of these move a single entity out of balance, so a person closing one company cannot see them; they surface only at consolidation, when the intercompany balances are supposed to eliminate to zero and instead leave a residual nobody can source, after the period is closed. These are not judgment calls. They are equalities: a due-from against a due-to, a closing against a roll-forward, a funding source against a rule -- which is what a deterministic control settles better than a controller reconciling one entity at a time.

The seeded demo runs every control over every period file⁷. The CLI generates 25 fictional period files -- one clean baseline and one carrying each planted defect -- then runs all 23 controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

A drift of one cent between the two sides⁸. A test moves a single due-to closing by one cent. The reciprocity control fires, and the pair-symmetry and roll-forward controls stay silent -- the balance is still two-sided and still ties to its own ledger, which is exactly why the drift is invisible on either entity alone and only a check spanning both finds it.

The group eliminates to zero⁹. A test sums every due-from closing and every due-to closing on the clean baseline and asserts the two totals are equal -- the property that makes the intercompany balances cancel on consolidation. It holds because every pair is reciprocal, which is the thing the registry is built to keep true.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Read-only: period files are parsed and never written back, so the engine cannot introduce the break it reports.
• Integer cents throughout, compared with exact equality; there is no tolerance band between a due-from and the due-to it faces.
• A value that should be integer cents but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced.
• Deterministic and byte-stable: same inputs produce the same findings in the same order, with no timestamps or absolute paths in any output.
• Absent evidence is never a passing control; a missing due-to schedule fails completeness rather than letting reciprocity pass unread.

Operating limits

• The engine never funds an entity, sweeps cash, or writes to a source artifact. It reports and stops.¹⁴
• It reads the six schedules the consolidation keeps. It does not connect to a bank, a general ledger or a treasury system.¹⁵
• It checks that a balance is reciprocal and rolls forward, not whether the underlying advance was commercially reasonable or on arm's-length terms. That judgment is a reviewer's.¹⁶
• It reads the funding protocol as data and tests conformance to it; whether the protocol itself is the right policy is a treasury question the engine does not answer.¹⁷
• All shipped data is fictional. The corpus demonstrates the controls; it is not a record of any real entity, group, advance or balance.¹⁸

See it run

Integration

Distribution: public repository, MIT license.