aiolabs/libra

Fork 1

Settlement flow doesn't net related expense + income entries (links + postings incomplete) #33

New issue

Open

opened 2026-06-06 18:06:29 +00:00 by padreug · 2 comments

padreug commented

2026-06-06 18:06:29 +00:00

Owner

Surfaced during aio-demo end-to-end testing of the split-ledger refactor (#28 / #29 / PR #32). Not related to the refactor — the bug is in the manual cash-settlement flow.

What we saw

User nancy has two open entries against the org:

Expense ^exp-bbfe35fcb4cf4a0e — drill from Home Depot, 50 EUR. Org owes nancy.

Expenses:Equipment:Tools           +50.00 EUR
Liabilities:Payable:User-4fe66163  -50.00 EUR

Income ^inc-23dbe0fd230d4be0 — 100 EUR collected on org's behalf. Nancy owes org.

Assets:Receivable:User-4fe66163   +100.00 EUR
Income:Other                      -100.00 EUR

Net obligation: nancy owes org 50 EUR (100 receivable - 50 payable).

She makes a single 50 EUR cash payment to clear the net. The expectation was that this settlement reconciles both entries (expense + income), so it should:

Link to both source entries: ^exp-bbfe35fcb4cf4a0e AND ^inc-23dbe0fd230d4be0
Touch all the user-side accounts: zero out Liabilities:Payable AND Assets:Receivable

What actually got written

2026-06-06 * "Cash payment from nancy" #cash-payment #settlement ^MANUAL-4fe66163 ^exp-bbfe35fcb4cf4a0e
  user-id: "4fe66163"
  source: "cash_settlement"
  payment-method: "cash"
  settled-by: "890debf13d4848a8b173a3b3f2095b9f"
  Assets:Cash                            +50.00 EUR @ 1650.12 SATS
  Assets:Receivable:User-4fe66163        -50.00 EUR @ 1650.12 SATS

Two problems:

1. Income entry link is missing

Settlement links: ^MANUAL-4fe66163, ^exp-bbfe35fcb4cf4a0e. The expense is linked but ^inc-23dbe0fd230d4be0 is not. A reader scanning the settlement entry can't tell from links alone that the income entry was also reconciled by this payment.

2. Postings are 2-leg, leaving both per-user accounts open

The expected bookkeeping-complete form for "single cash payment nets both directions" is three legs:

Assets:Cash                            +50.00 EUR    ; cash actually received
Liabilities:Payable:User-4fe66163      +50.00 EUR    ; org's debt to nancy zeroed
Assets:Receivable:User-4fe66163       -100.00 EUR    ; nancy's debt to org zeroed

After the actual 2-leg entry, per-account balances look like:

Account	Before	After (actual)	After (expected)
Assets:Receivable:User-4fe66163	+100 EUR	+50 EUR	0
Liabilities:Payable:User-4fe66163	-50 EUR	-50 EUR	0
Assets:Cash	x	x + 50	x + 50

Both forms net to the right total obligation for nancy (zero), but the actual form leaves both per-user accounts showing non-zero balances — so a balance-sheet view per user would mislead: it would suggest nancy still owes the org 50 EUR AND the org still owes nancy 50 EUR.

Suggested direction

The settle-receivable endpoint (probably POST /api/v1/settle-receivable per docs) needs to:

Accept a list of entry IDs to reconcile (or auto-detect open entries for the user_id and ask the operator which to include)
Compute the net obligation across those entries
Generate a transaction with one leg per affected account: Cash for the actual payment direction, then one Liabilities:Payable leg and/or one Assets:Receivable leg matching the gross amounts being zeroed
Append a link for each settled entry's ^exp-... / ^inc-... reference

Acceptance

Settlement entry links every source entry it reconciles
Settlement postings zero out the actual per-user account balances, not just the net
bean-query "SELECT account, sum(position) WHERE 'User-4fe66163' in account" returns zero rows (or near-zero) after a complete settlement, not partial open balances on each account

Out of scope for this issue

The cosmetic ordering / always-append-at-end behavior (already fixed in PR #32)
The cost-basis-rate consistency across legs (operator currently manages this manually; could be a future helper)

Reference: see the actual on-disk entries in aio-demo:/var/lib/fava/transactions.beancount lines 7, 14, 21 as of 2026-06-06 18:00 UTC for the live example.

Surfaced during aio-demo end-to-end testing of the split-ledger refactor (#28 / #29 / PR #32). Not related to the refactor — the bug is in the manual cash-settlement flow. ## What we saw User nancy has two open entries against the org: 1. **Expense** `^exp-bbfe35fcb4cf4a0e` — drill from Home Depot, 50 EUR. Org owes nancy. ``` Expenses:Equipment:Tools +50.00 EUR Liabilities:Payable:User-4fe66163 -50.00 EUR ``` 2. **Income** `^inc-23dbe0fd230d4be0` — 100 EUR collected on org's behalf. Nancy owes org. ``` Assets:Receivable:User-4fe66163 +100.00 EUR Income:Other -100.00 EUR ``` Net obligation: nancy owes org 50 EUR (100 receivable - 50 payable). She makes a single 50 EUR cash payment to clear the net. The expectation was that this settlement reconciles **both** entries (expense + income), so it should: - **Link to both source entries**: `^exp-bbfe35fcb4cf4a0e` AND `^inc-23dbe0fd230d4be0` - **Touch all the user-side accounts**: zero out Liabilities:Payable AND Assets:Receivable ## What actually got written ```beancount 2026-06-06 * "Cash payment from nancy" #cash-payment #settlement ^MANUAL-4fe66163 ^exp-bbfe35fcb4cf4a0e user-id: "4fe66163" source: "cash_settlement" payment-method: "cash" settled-by: "890debf13d4848a8b173a3b3f2095b9f" Assets:Cash +50.00 EUR @ 1650.12 SATS Assets:Receivable:User-4fe66163 -50.00 EUR @ 1650.12 SATS ``` Two problems: ### 1. Income entry link is missing Settlement links: `^MANUAL-4fe66163`, `^exp-bbfe35fcb4cf4a0e`. The expense is linked but `^inc-23dbe0fd230d4be0` is not. A reader scanning the settlement entry can't tell from links alone that the income entry was also reconciled by this payment. ### 2. Postings are 2-leg, leaving both per-user accounts open The expected bookkeeping-complete form for "single cash payment nets both directions" is three legs: ```beancount Assets:Cash +50.00 EUR ; cash actually received Liabilities:Payable:User-4fe66163 +50.00 EUR ; org's debt to nancy zeroed Assets:Receivable:User-4fe66163 -100.00 EUR ; nancy's debt to org zeroed ``` After the actual 2-leg entry, per-account balances look like: | Account | Before | After (actual) | After (expected) | |---|---|---|---| | Assets:Receivable:User-4fe66163 | +100 EUR | +50 EUR | 0 | | Liabilities:Payable:User-4fe66163 | -50 EUR | -50 EUR | 0 | | Assets:Cash | x | x + 50 | x + 50 | Both forms net to the right total obligation for nancy (zero), but the actual form leaves both per-user accounts showing non-zero balances — so a balance-sheet view per user would mislead: it would suggest nancy still owes the org 50 EUR AND the org still owes nancy 50 EUR. ## Suggested direction The settle-receivable endpoint (probably `POST /api/v1/settle-receivable` per docs) needs to: - Accept a list of entry IDs to reconcile (or auto-detect open entries for the user_id and ask the operator which to include) - Compute the net obligation across those entries - Generate a transaction with one leg per affected account: Cash for the actual payment direction, then one Liabilities:Payable leg and/or one Assets:Receivable leg matching the gross amounts being zeroed - Append a link for each settled entry's `^exp-...` / `^inc-...` reference ## Acceptance - [ ] Settlement entry links every source entry it reconciles - [ ] Settlement postings zero out the actual per-user account balances, not just the net - [ ] `bean-query "SELECT account, sum(position) WHERE 'User-4fe66163' in account"` returns zero rows (or near-zero) after a complete settlement, not partial open balances on each account ## Out of scope for this issue - The cosmetic ordering / always-append-at-end behavior (already fixed in PR #32) - The cost-basis-rate consistency across legs (operator currently manages this manually; could be a future helper) Reference: see the actual on-disk entries in `aio-demo:/var/lib/fava/transactions.beancount` lines 7, 14, 21 as of 2026-06-06 18:00 UTC for the live example.

padreug commented

2026-06-06 18:31:05 +00:00

Author

Owner

Linking + posting conventions for the new settlement endpoint

Worked through these while talking out partial-settlement semantics. Putting them here so they land with the spec.

Forms the endpoint should produce

Form A — single payment nets both directions (3-leg). When one cash flow resolves an open payable AND an open receivable for the same user. Picking nance's actual state (50 EUR payable open from the drill expense, 100 EUR receivable open from the income), a 30 EUR cash payment from her that the operator allocates to clear the expense fully + 80 EUR of the income:

2026-06-06 * "Partial settlement from nance (30.00 EUR cash, nets expense + income)" #cash-payment #settlement ^MANUAL-4fe66163 ^exp-bbfe35fcb4cf4a0e ^inc-23dbe0fd230d4be0
  user-id: "4fe6616351ab4d709520f908ff68100a"
  source: "cash_settlement"
  payment-method: "cash"
  settled-by: "<admin user-id>"
  settles-entries: "bbfe35fcb4cf4a0e:50.00, 23dbe0fd230d4be0:80.00"
  Assets:Cash                                         30.00 EUR @ 1896.76 SATS
  Liabilities:Payable:User-4fe66163                   50.00 EUR @ 1896.76 SATS
  Assets:Receivable:User-4fe66163                    -80.00 EUR @ 1896.76 SATS

Postings balance: 30 + 50 − 80 = 0. Result: Payable zeroed, Receivable +20 (income remainder), Cash +30. Header links both source entries.

Form B — settles only one direction (2-leg). Same 30 EUR cash, but operator says "this is purely paying down the income receivable; leave the drill open":

2026-06-06 * "Partial settlement from nance (30.00 EUR cash, against income only)" #cash-payment #settlement ^MANUAL-4fe66163 ^inc-23dbe0fd230d4be0
  ...
  settles-entries: "23dbe0fd230d4be0:30.00"
  Assets:Cash                                         30.00 EUR @ 1896.76 SATS
  Assets:Receivable:User-4fe66163                    -30.00 EUR @ 1896.76 SATS

Result: Payable unchanged at −50, Receivable +70. Both obligations remain live on the books as separate items.

Follow-up "remainder" settlement

After Form A above, nance still owes 20 EUR (income remainder). She pays the last 20 EUR cash:

2026-06-08 * "Final settlement from nance (20.00 EUR cash, completes income)" #cash-payment #settlement ^MANUAL-4fe66163 ^inc-23dbe0fd230d4be0
  ...
  settles-entries: "23dbe0fd230d4be0:20.00"
  Assets:Cash                                         20.00 EUR @ 1896.76 SATS
  Assets:Receivable:User-4fe66163                    -20.00 EUR @ 1896.76 SATS

Only the income link is included — the expense was already fully settled in the prior tx, linking it again would suggest it's still being acted on. Beancount's link chain on ^inc-23dbe0fd230d4be0 already surfaces all three entries that touched this income:

^inc-23dbe0fd230d4be0:
  2026-06-06  Income $100 for nance         (+100 receivable)
  2026-06-06  Partial settlement (30 cash)  (−80  receivable)
  2026-06-08  Final settlement (20 cash)    (−20  receivable)
                                            ─────
                                              0 EUR — fully resolved

No need to also link prior settlement entries; the source-entry link is the anchor that ties the whole chain.

Scaling: new expenses/incomes landing on top of a partial state

The two-account + per-chain link model holds up as obligations layer. Continuing from after Form A (Receivable +20 from the income remainder, Payable cleared):

Day +2 — 40 EUR paint expense (org owes nance):

2026-06-09 * "paint for the hallway (40.00 EUR)" #expense-entry ^exp-9a4f12c8c0f04ec1
  ...
  Expenses:Materials:Paint                            40.00 EUR @ 1896.76 SATS
  Liabilities:Payable:User-4fe66163                  -40.00 EUR @ 1896.76 SATS

Payable: −40, Receivable: +20 (income remainder untouched), Net: −20.

Day +3 — 25 EUR income (nance collects from guest):

2026-06-10 * "guest payment received by nance (25.00 EUR)" #income-entry ^inc-7e2c5a1b3f4d49af
  ...
  Assets:Receivable:User-4fe66163                     25.00 EUR @ 1896.76 SATS
  Income:Other                                       -25.00 EUR @ 1896.76 SATS

Payable: −40, Receivable: +45 (20 old remainder + 25 new), Net: +5.

Day +4 — operator records a 30 EUR cash settlement, allocated 5 EUR to old income + 25 EUR to new income, leaving paint payable alone:

2026-06-11 * "Settlement from nance (30.00 EUR cash, 25 to new income + 5 to old income)" #cash-payment #settlement ^MANUAL-4fe66163 ^inc-23dbe0fd230d4be0 ^inc-7e2c5a1b3f4d49af
  ...
  settles-entries: "23dbe0fd230d4be0:5.00, 7e2c5a1b3f4d49af:25.00"
  Assets:Cash                                         30.00 EUR @ 1896.76 SATS
  Assets:Receivable:User-4fe66163                    -30.00 EUR @ 1896.76 SATS

Final state:

Account	Balance	Open chains
`Liabilities:Payable:User-4fe66163`	`-40.00 EUR`	`^exp-9a4f12c8c0f04ec1` (paint, fully open)
`Assets:Receivable:User-4fe66163`	`+15.00 EUR`	`^inc-23dbe0fd230d4be0` (15 EUR open of original 100), `^inc-7e2c5a1b3f4d49af` (closed)

Each chain stays independently traceable: old-income now shows the original + Form A's −80 + this −5 = 15 still open; new-income shows +25 + this −25 = closed; paint shows the +40 with no settlement events yet. New obligations don't muddy old chains, and a single settlement can touch any subset by listing all relevant links on the header.

Per-entry allocation metadata

Single key, comma-separated allocations:

settles-entries: "<entry-id>:<amount>, <entry-id>:<amount>, ..."

Scales to any number of source entries per settlement. Pairs with the header links 1:1 (every id in settles-entries: should appear as ^exp-… or ^inc-… on the header line). Amounts use the settlement's transaction currency.

(An earlier draft of this comment used separate settles-expense: / settles-income: keys, which can't hold multiple entries cleanly because Beancount metadata is a dict — using settles-entries: as a single CSV string sidesteps that. The header links remain the canonical record for Beancount's chain-query mechanism; this key is for human/admin-UI parsing.)

Linking convention summary

Settlement scenario	Linked entries (in addition to `^MANUAL-…`)
Settles only the expense	`^exp-…`
Settles only the income (or part of it)	`^inc-…`
Settles both in one cash flow (3-leg)	`^exp-…` AND `^inc-…`
Remainder of an already-partially-settled obligation	Just the source entry's link — Beancount surfaces prior settlements automatically
Multiple obligations of the same type (e.g. two incomes)	All relevant `^inc-…` / `^exp-…` links on the header
Pure cash refund / no source obligation	Just `^MANUAL-…`

Optional follow-up: `#fully-settled` tag, per chain

Beancount has no built-in "this obligation is fully closed" indicator. Cheap convention: when a settlement zeroes out a touched chain completely, tag the settling transaction.

For settlements that touch a single chain and close it, use a bare tag:

#fully-settled

For settlements that touch multiple chains and close some-but-not-all (like Day +4 above, which closed ^inc-7e2c5a1b3f4d49af but left ^inc-23dbe0fd230d4be0 at 15 EUR open), the tag needs to identify WHICH chain was closed. Two options:

Per-chain tag: #fully-settled-7e2c5a1b3f4d49af — appended for each chain the settlement actually closed
Per-chain metadata key: closes-chain: "7e2c5a1b3f4d49af" (CSV if multiple)

Either way, the settlement endpoint computes "did this take sum(position) WHERE link='^inc-X' to zero?" per touched chain and decorates accordingly. Doesn't affect postings; pure reporting aid. Can be added later without a migration.

Worth treating as a stretch goal on this issue or splitting into its own follow-up — flagging here so it's not lost.

## Linking + posting conventions for the new settlement endpoint Worked through these while talking out partial-settlement semantics. Putting them here so they land with the spec. ### Forms the endpoint should produce **Form A — single payment nets both directions (3-leg).** When one cash flow resolves an open payable AND an open receivable for the same user. Picking nance's actual state (50 EUR payable open from the drill expense, 100 EUR receivable open from the income), a 30 EUR cash payment from her that the operator allocates to clear the expense fully + 80 EUR of the income: ```beancount 2026-06-06 * "Partial settlement from nance (30.00 EUR cash, nets expense + income)" #cash-payment #settlement ^MANUAL-4fe66163 ^exp-bbfe35fcb4cf4a0e ^inc-23dbe0fd230d4be0 user-id: "4fe6616351ab4d709520f908ff68100a" source: "cash_settlement" payment-method: "cash" settled-by: "<admin user-id>" settles-entries: "bbfe35fcb4cf4a0e:50.00, 23dbe0fd230d4be0:80.00" Assets:Cash 30.00 EUR @ 1896.76 SATS Liabilities:Payable:User-4fe66163 50.00 EUR @ 1896.76 SATS Assets:Receivable:User-4fe66163 -80.00 EUR @ 1896.76 SATS ``` Postings balance: 30 + 50 − 80 = 0. Result: Payable zeroed, Receivable +20 (income remainder), Cash +30. Header links both source entries. **Form B — settles only one direction (2-leg).** Same 30 EUR cash, but operator says "this is purely paying down the income receivable; leave the drill open": ```beancount 2026-06-06 * "Partial settlement from nance (30.00 EUR cash, against income only)" #cash-payment #settlement ^MANUAL-4fe66163 ^inc-23dbe0fd230d4be0 ... settles-entries: "23dbe0fd230d4be0:30.00" Assets:Cash 30.00 EUR @ 1896.76 SATS Assets:Receivable:User-4fe66163 -30.00 EUR @ 1896.76 SATS ``` Result: Payable unchanged at −50, Receivable +70. Both obligations remain live on the books as separate items. ### Follow-up "remainder" settlement After Form A above, nance still owes 20 EUR (income remainder). She pays the last 20 EUR cash: ```beancount 2026-06-08 * "Final settlement from nance (20.00 EUR cash, completes income)" #cash-payment #settlement ^MANUAL-4fe66163 ^inc-23dbe0fd230d4be0 ... settles-entries: "23dbe0fd230d4be0:20.00" Assets:Cash 20.00 EUR @ 1896.76 SATS Assets:Receivable:User-4fe66163 -20.00 EUR @ 1896.76 SATS ``` **Only the income link is included** — the expense was already fully settled in the prior tx, linking it again would suggest it's still being acted on. Beancount's link chain on `^inc-23dbe0fd230d4be0` already surfaces all three entries that touched this income: ``` ^inc-23dbe0fd230d4be0: 2026-06-06 Income $100 for nance (+100 receivable) 2026-06-06 Partial settlement (30 cash) (−80 receivable) 2026-06-08 Final settlement (20 cash) (−20 receivable) ───── 0 EUR — fully resolved ``` No need to also link prior settlement entries; the source-entry link is the anchor that ties the whole chain. ### Scaling: new expenses/incomes landing on top of a partial state The two-account + per-chain link model holds up as obligations layer. Continuing from after Form A (Receivable +20 from the income remainder, Payable cleared): **Day +2 — 40 EUR paint expense (org owes nance):** ```beancount 2026-06-09 * "paint for the hallway (40.00 EUR)" #expense-entry ^exp-9a4f12c8c0f04ec1 ... Expenses:Materials:Paint 40.00 EUR @ 1896.76 SATS Liabilities:Payable:User-4fe66163 -40.00 EUR @ 1896.76 SATS ``` Payable: −40, Receivable: +20 (income remainder untouched), Net: −20. **Day +3 — 25 EUR income (nance collects from guest):** ```beancount 2026-06-10 * "guest payment received by nance (25.00 EUR)" #income-entry ^inc-7e2c5a1b3f4d49af ... Assets:Receivable:User-4fe66163 25.00 EUR @ 1896.76 SATS Income:Other -25.00 EUR @ 1896.76 SATS ``` Payable: −40, Receivable: +45 (20 old remainder + 25 new), Net: +5. **Day +4 — operator records a 30 EUR cash settlement, allocated 5 EUR to old income + 25 EUR to new income, leaving paint payable alone:** ```beancount 2026-06-11 * "Settlement from nance (30.00 EUR cash, 25 to new income + 5 to old income)" #cash-payment #settlement ^MANUAL-4fe66163 ^inc-23dbe0fd230d4be0 ^inc-7e2c5a1b3f4d49af ... settles-entries: "23dbe0fd230d4be0:5.00, 7e2c5a1b3f4d49af:25.00" Assets:Cash 30.00 EUR @ 1896.76 SATS Assets:Receivable:User-4fe66163 -30.00 EUR @ 1896.76 SATS ``` Final state: | Account | Balance | Open chains | |---|---|---| | `Liabilities:Payable:User-4fe66163` | `-40.00 EUR` | `^exp-9a4f12c8c0f04ec1` (paint, fully open) | | `Assets:Receivable:User-4fe66163` | `+15.00 EUR` | `^inc-23dbe0fd230d4be0` (15 EUR open of original 100), `^inc-7e2c5a1b3f4d49af` (closed) | Each chain stays independently traceable: old-income now shows the original + Form A's −80 + this −5 = 15 still open; new-income shows +25 + this −25 = closed; paint shows the +40 with no settlement events yet. New obligations don't muddy old chains, and a single settlement can touch any subset by listing all relevant links on the header. ### Per-entry allocation metadata Single key, comma-separated allocations: ``` settles-entries: "<entry-id>:<amount>, <entry-id>:<amount>, ..." ``` Scales to any number of source entries per settlement. Pairs with the header links 1:1 (every id in `settles-entries:` should appear as `^exp-…` or `^inc-…` on the header line). Amounts use the settlement's transaction currency. (An earlier draft of this comment used separate `settles-expense:` / `settles-income:` keys, which can't hold multiple entries cleanly because Beancount metadata is a dict — using `settles-entries:` as a single CSV string sidesteps that. The header links remain the canonical record for Beancount's chain-query mechanism; this key is for human/admin-UI parsing.) ### Linking convention summary | Settlement scenario | Linked entries (in addition to `^MANUAL-…`) | |---|---| | Settles only the expense | `^exp-…` | | Settles only the income (or part of it) | `^inc-…` | | Settles both in one cash flow (3-leg) | `^exp-…` AND `^inc-…` | | Remainder of an already-partially-settled obligation | Just the source entry's link — Beancount surfaces prior settlements automatically | | Multiple obligations of the same type (e.g. two incomes) | All relevant `^inc-…` / `^exp-…` links on the header | | Pure cash refund / no source obligation | Just `^MANUAL-…` | ### Optional follow-up: `#fully-settled` tag, per chain Beancount has no built-in "this obligation is fully closed" indicator. Cheap convention: when a settlement zeroes out a touched chain completely, tag the settling transaction. For settlements that touch a single chain and close it, use a bare tag: ``` #fully-settled ``` For settlements that touch multiple chains and close some-but-not-all (like Day +4 above, which closed `^inc-7e2c5a1b3f4d49af` but left `^inc-23dbe0fd230d4be0` at 15 EUR open), the tag needs to identify WHICH chain was closed. Two options: - **Per-chain tag**: `#fully-settled-7e2c5a1b3f4d49af` — appended for each chain the settlement actually closed - **Per-chain metadata key**: `closes-chain: "7e2c5a1b3f4d49af"` (CSV if multiple) Either way, the settlement endpoint computes "did this take `sum(position) WHERE link='^inc-X'` to zero?" per touched chain and decorates accordingly. Doesn't affect postings; pure reporting aid. Can be added later without a migration. Worth treating as a stretch goal on this issue or splitting into its own follow-up — flagging here so it's not lost.

padreug referenced this issue

2026-06-07 07:18:04 +00:00

Add user credit balance to absorb settlement overpay/round mismatch (prerequisite for #33) #41

padreug commented

2026-06-07 07:18:25 +00:00

Author

Owner

The honest fix needs a credit balance — filed as #41 — to absorb any cash that doesn't map onto a clean settle target. Should be merged together as one PR. Acceptance criteria for #33 stand as written; #41 makes them actually achievable without 400-ing operators in the middle of a cash transaction.

Implementation order when picked up:

Land #41's credit account + balance integration first (or in the same PR).
Then implement #33's auto-detection + 3-leg netting on top of it.
Then write tests/test_settlement_api.py (task #6 of the test plan) — tests cover both as a single behaviour surface.

Design session surfaced that the strict-matching path (reject when cash ≠ net obligation) creates a real operator footgun: cash has already been handed over by the time the API returns 400. Reverting to silent drift is what produced this bug. The honest fix needs a credit balance — filed as #41 — to absorb any cash that doesn't map onto a clean settle target. Should be merged together as one PR. Acceptance criteria for #33 stand as written; #41 makes them actually achievable without 400-ing operators in the middle of a cash transaction. Implementation order when picked up: 1. Land #41's credit account + balance integration first (or in the same PR). 2. Then implement #33's auto-detection + 3-leg netting on top of it. 3. Then write `tests/test_settlement_api.py` (task #6 of the test plan) — tests cover both as a single behaviour surface.

padreug referenced this issue from a commit

2026-06-07 13:39:53 +00:00

Net settlement + credit overflow on /receivables/settle (libra-#33, libra-#41)

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

aiolabs/libra#33

No description provided.

Rows
Columns

Settlement flow doesn't net related expense + income entries (links + postings incomplete) #33

What we saw

What actually got written

1. Income entry link is missing

2. Postings are 2-leg, leaving both per-user accounts open

Suggested direction

Acceptance

Out of scope for this issue

Linking + posting conventions for the new settlement endpoint

Forms the endpoint should produce

Follow-up "remainder" settlement

Scaling: new expenses/incomes landing on top of a partial state

Per-entry allocation metadata

Linking convention summary

Optional follow-up: #fully-settled tag, per chain

Optional follow-up: `#fully-settled` tag, per chain