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

Intercompany elimination: counterparty lookup · case 02

Intercompany receivables are matched against the same entity payables.

Member previewVariant 2 · 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: counterparty lookup	`{"consolidated": {"ic_purchases": 600, "ic_sales": 400}, "mismatches": [["S1", "P", "ic_sales", 400], ["S2", "S1", "ic_sales", -600]]}`	`{"consolidated": {"ic_purchases": 1000, "ic_sales": 800}, "mismatches": [["S1", "P", "ic_sales", 400], ["S1", "S2", "ic_sales", -1000], ["S2", "S1", "ic_sales", 400]]}`	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.