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

Intercompany elimination: zero balance filter · case 04

Fully eliminated accounts appear in the consolidation with zero totals.

Member previewVariant 4 · 3 implementations · 7 checks per implementation

Case contract

x = [[entity, account, counterparty or None, amount]]. Rows with no counterparty, the entity itself as counterparty, or an account outside the pairs (ic_receivable/ic_payable, ic_sales/ic_purchases) are consolidated as-is. For each (entity, counterparty, pair) the left balance of entity toward counterparty is matched against the right balance of counterparty toward entity; min(left, right) is eliminated from both, residuals are consolidated and a mismatch [entity, counterparty, left account, left - right] is reported when they differ. Return {'consolidated': nonzero account totals, 'mismatches': in sorted key order}.

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: zero balance filter	`{"consolidated": {"ic_loan": 1000, "ic_payable": 400, "ic_receivable": 0, "ic_sales": 400, "sales": -400}, "mismatches": [["P", "S1", "ic_receivable", -400], ["S1", "S2", "ic_receivable", 1000]]}`	`{"consolidated": {"ic_loan": 1000, "ic_payable": 400, "ic_sales": 400, "sales": -400}, "mismatches": [["P", "S1", "ic_receivable", -400], ["S1", "S2", "ic_receivable", 1000]]}`	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.