FA-58207 / Double-entry ledger accounting / Member archive

Journal void and reversal linkage: reversal id collision · case 02

A void overwrites an existing entry that shares the reversal id.

Member previewVariant 2 · 3 implementations · 7 checks per implementation

Case contract

x = [['post', id, amount] | ['void', target_id, reversal_id] | other]. Posting an existing id is an error 'duplicate'. Voiding needs a known target ('unknown'), whose status is 'posted' ('not_voidable' for voided entries and reversals) and an unused reversal id ('duplicate'), checked in that order. A void marks the target 'voided' and creates a 'reversal' entry with the negated amount. Other commands give 'bad_command'. Return {'status', 'balance': sum of all amounts, 'errors': [[index, reason]]}.

Why this case matters

Ledger software must keep debits equal to credits and apply normal-balance, period and cutoff rules exactly; small sign or boundary slips silently misstate financial statements.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
regression: reversal id collision	`{"balance": -80, "errors": [[1, "unknown"], [4, "unknown"], [5, "unknown"]], "status": {"A": "posted", "B": "voided", "D": "posted", "R1": "reversal"}}`	`{"balance": 130, "errors": [[1, "unknown"], [4, "unknown"], [5, "unknown"], [7, "duplicate"]], "status": {"A": "posted", "B": "posted", "D": "posted", "R1": "posted"}}`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.