FAILURE MAP
← Case archive

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

Journal void and reversal linkage: voidable status · case 02

A reversal entry can itself be voided, reinstating the original silently.

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 fixtureActualExpectedOutcome
regression: voidable status{"balance": 170, "errors": [[1, "duplicate"], [3, "duplicate"], [7, "not_voidable"]], "status": {"A": "posted", "B": "voided", "C": "posted", "R1": "voided", "R3": "reversal"}}{"balance": 210, "errors": [[1, "duplicate"], [3, "duplicate"], [5, "not_voidable"], [7, "not_voidable"]], "status": {"A": "posted", "B": "voided", "C": "posted", "R1": "reversal"}}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.

Sign in to the archive ↗