Ledger leftovers after BAN-348¶

Status: to fix. This page lists what is still wrong in the ledger after the
BAN-348 ledger repair. Nothing in the three open items below has
been corrected, and none of them is scheduled. Remove an item from this page once it is fixed.

The repair itself finished on 2026-10-08: 26,676 of 26,679 planned flows verified, and the
closing audits found every repaired GA and native flow at target. What it did and how is on
the repair page.

One interactive view is attached to this page:

Ledger leftovers notebook: one page per item with its
numbers, what is wrong, why it is still open and what fixing it takes. The rows behind each
item open on request, and any row shows its full detail: register id, flow, native flow,
Lithic token, amounts, dates and the register's notes.

The ticket is
BAN-348.

Open items¶

Item	Size	Amount	Data as of
Credit-card accounts	43 flows on 39 accounts	1,666.35	register of 2026-09-15
Stale holds	1,888 holds on 864 customer accounts and the all-zero account id	55,492.75	register of 2026-09-15; 22 flows re-read on 2026-10-08
Account reserve vs flows	693 accounts	34,820.54 in the register, 29.14 on 7 new accounts	register for 673 accounts; re-read on 2026-10-08 for 20

Rows dated 2026-09-15 have not been read again since and may have changed on their own. Read
the current state before acting on any of them.

Credit-card accounts¶

On 43 native flows on 39 CreditSecured accounts, the ledger's final amount is not Lithic's
final amount. On 42 the ledger took less than Lithic settled, 1,632.60 together; on 1 the
customer is owed 33.75. 40 flows simply end at a different amount, and 3 are voided purchases
with a return that were left in the wrong end state. 42 date from January to 21 April 2026,
1 from 22 April to 31 May 2026.

Why it is still open. A credit account's balance and statement are carried in be-credit
and LoanPro, so a ledger replay alone would leave what the customer owes wrong. The register
split these rows into their own file on 2026-09-15 for a separate decision, and the repair
plan never included them.

What fixing it takes. A decision with the credit side on whether to correct them. If
yes: a targeted native replay to Lithic's final state per flow, with the matching change in
be-credit and LoanPro.

Stale holds¶

1,888 holds that were never released, last touched between 2025-03-20 and 2026-03-24. The
register classed them as estate residue outside the BAN-348 incident, and the repair did not
touch them.

Kind	Holds	Amount
The customer's money kept reserved	963	29,757.27
Positive reservation: the customer has more available than they should	115	8,403.26
On the all-zero account id, no customer behind it	810	17,332.22

be-ledger's ExpireAuth job, which should release old holds, does not run; retiring it is
BAN-238,
which is in the Backlog. The holds on the all-zero account id come from unmatched Galileo
reversals that be-ledger stored without an account id between 2025-02-06 and 2025-11-19. The
register found a likely owner for 704 of them; 30 have two candidates and 76 none.

The closing re-read of 2026-10-08 covered 22 of these flows, on accounts it read for other
reasons, and all 22 still held money. The others were not read again.

What fixing it takes. Release or settle each flow, since ExpireAuth will not. Zero the
flows on the all-zero account id; the register sees no customer impact there. Decide whether
to take back the 115 positive reservations: releasing them lowers those customers' balance.

Account reserve vs flows¶

On 693 accounts, AccountBalance.ReservedAmount does not equal the sum of the account's
TransactionFlowCore holds.

Cause	Accounts
Galileo-era residue: a FlowCore hold left while AccountBalance is at 0, from before the mirror	620
Hold released in AccountBalance but never closed on the flow	36
AccountBalance reserve with no flow behind it	25
Both sides non-zero, fixed offset	4
The all-zero account id, 15,990.06; its holds are the 810 under Stale holds	1
New at the 2026-10-08 closing audit	7

13 of the register's accounts were in the repair plan. The closing re-read of 2026-10-08 read
both sides in one statement, and all 13 still differ. The same audit flagged 82 accounts the
register did not have: 75 cleared when read again, because the first read took the two sides
minutes apart, and 7 still differ, by 0.01 to 11.33. The other 673 accounts were not read
again after 2026-09-15.

Why it is still open. The register classed these as consistency only, outside BAN-348,
so the repair plan left them out. No ticket tracks them.

What fixing it takes. Per account, set AccountBalance.ReservedAmount to the FlowCore
sum, or release the orphan hold. Read both sides in one statement first: two reads minutes
apart produce false mismatches.

Decided, left as is¶

Refunds on GA flows. 20 GA flows carry a refund that Lithic sent under its own token,
569.45 together. The purchase sits on its native flow and the refund on the GA flow, so the
customer's net is right. The split (refund_01) was rejected by be-ledger because the GA
restore's idempotency key, GA-REPAIR:GA=<flow>, had already been used on these flows with
other amounts, and nothing was written. They were left as they are on 2026-10-08. The 20
dead-lettered messages in be-lithic must never be resent. Separating them needs a be-lithic
change that puts the previous and target amounts in the restore key.

Checked clean¶

GA flow audit, 2026-10-08: all 25,421 GA flows of the plan at reserved 0 and settled at
target; TransactionFlowCore equals the last posting on every flow.
Native flow audit, 2026-10-08: all 26,676 verified rows have their native flows at the
planned settled and reserved amounts, on the right account.
Processor callbacks equal the target on all 1,226 covered rows; the Lithic settlement file
has 1,130 of them, none different.
109 register rows outside the plan, all holds to release, were fixed by the message of a
plan row that shares their Lithic token or native flow.
The 3 held plan rows needed no message. P06385 (GA=259260782) and P07399 (GA=259278006) were
already at Lithic's final state at the 2026-10-06 preflight, with the settlement debited
since the register; the GA flow audit has both at target. P26672 is the same Lithic
transaction as P24731 (GA=259232482), which debit-none_01 fixed on 2026-10-08.