generation credit ledger reconciliation: Compare balance movements and source availability
A generation credit ledger reconciliation should answer two different questions: how the balance moved over a period, and which source credits are currently eligible to spend. Combining those questions into one unqualified sum can hide missing transactions, expiration timing, or unsettled job evidence.
Establish a consistent scope
Choose one user and a snapshot timestamp. Capture the balance row, relevant transaction entries, and the associated jobs under authorized read-only access. Record the extraction time and scope so another operator can distinguish a real discrepancy from reports taken at different moments.
For movement accounting, begin with an opening balance and add signed transactions within the defined interval. Grants, purchases, and refunds add credit; USAGE and expiration entries reduce it. Compare the resulting expected closing balance with the observed closing snapshot. Do not sum all historical grants without accounting for usage and expiration.
For spendability, inspect positive remainingAmount on eligible source entries. The consumption query excludes USAGE and EXPIRE entries and excludes sources whose expirationDate is not later than the current time. This is a current availability view, not the same measure as the signed history.
Join jobs without assuming settlement
Usage descriptions include a job identifier, which helps connect reservations to job records. A succeeded job normally records actual consumption equal to its held credits. Failed and canceled terminal paths invoke refunds and set actual consumption to zero.
An explicitly failed submission can still have pending refund settlement. An accepted upstream request whose reference could not be saved is a different investigation. Do not mark either case reconciled solely because a job exists in the table.
The refund helper uses deterministic per-job entries and recognizes matching historical refunds. Check those entries before concluding that a second missing-looking refund should be created.
Describe a discrepancy precisely
A useful report row names the expected amount, observed amount, difference, evidence timestamp, related job, and classification. Possible local classifications include missing source evidence, timing mismatch, pending settlement, or transaction conflict. These are report labels, not additional public gateway states.
For a fictional example, a closing balance can be ten credits below the movement calculation while a job reservation of ten is absent from the exported interval. That is a reason to check extraction boundaries before proposing a balance correction. It is not proof of a gateway defect.
Acceptance and escalation
Test the report using fixtures with a normal reservation, full refund, expired source, duplicate refund attempt, and concurrent snapshot timing. Require every discrepancy to remain visible until an operator explains it with evidence.
Do not automatically update production balances from this diagnostic report. Any correction needs its own reviewed accounting action and audit record. Continue with FIFO eligibility, refund evidence, and accepted-work ambiguity for the cases most likely to confuse a balance-only view.
Continue with costs and billing
Where these facts come from
- codebase: src/ai/api/credits.ts
- codebase: src/credits/credits.ts
- codebase: src/ai/jobs/service.ts
- codebase: src/ai/jobs/db.ts
- Editorial keyword hypothesis; search volume not measured