AI credit transparency and auditability.
k
kamel sellaoui
Hi Gamma team,
I want to submit a feature suggestion for AI credit transparency and auditability.
Your current credit summaries are useful at a high level, but they are not sufficient for finance, operations, or internal control purposes. The current format groups activity into broad time windows and mixes user-facing labels with backend event names. That makes it difficult to reconcile credit consumption, identify anomalies, eliminate duplicates, and verify whether charges were correct.
What would solve this is an audit-grade credit usage ledger, available in-product and exportable as CSV.
Here is the minimum field set that would make the ledger operationally useful:
Field Why it matters
Timestamp per atomic event Required to reconstruct exact usage chronology and stop grouped-window ambiguity
Request ID / Job ID Needed to detect retries, duplicates, reversals, and repeated charges
Document ID Needed to link usage to a specific Gamma file
Workspace ID Needed for team/workspace reconciliation
User ID / User email Needed to attribute usage by person
Event type (internal name) Needed to distinguish actions such as generateV2, generateV2WithImages, image_edit_maskless, image generation, card generation, etc.
User-facing action label Needed so admins can interpret technical event names without support intervention
Credits debited per event Core audit field
Credits credited / reversed per event Needed to explain refunds, failed runs, corrections, or comped actions
Net credit impact Simplifies reconciliation
Event status success / failed / cancelled / clarification / reversed / comped
Output count Important for image-heavy and multi-output actions
Model / feature used Useful for cost attribution and debugging
Opening balance before event Needed for ledger traceability
Closing balance after event Needed for full balance reconciliation
Billing source Monthly refill, rollover, referral, one-time purchase, promo credit, admin adjustment
Exportable notes / metadata Useful for internal tagging and audit comments
Why this matters:
1. Finance teams need a real ledger, not a narrative summary.
2. Admins need to explain sudden spikes in usage.
3. Teams need to separate normal generation from retries, failed jobs, reversals, and manual adjustments.
4. Credit disputes cannot be resolved reliably without atomic event-level records.
5. Larger workspaces need CSV export for internal reporting, anomaly detection, and chargeback.
Suggested deliverables:
• A usage page with filterable event-level credit history
• CSV export
• Filters by date, workspace, user, document, and event type
• Separate views for credits consumed vs credits added
• Clear mapping between backend event names and billable product actions
This would materially improve trust, auditability, and enterprise readiness.
Best regards,
Kamel Sellaoui
Nik Payne (Gamma design)
kamel sellaoui this is super thoughtful, thank you. Totally hear you on needing an audit-grade, event-level ledger (not a grouped summary) for finance ops, reconciliation, and disputes. I’m going to pass this to the team.
Quick couple questions so we design it right:
1) Who’s the primary user for this in your org (finance, workspace admin, ops), and what’s the top 1-2 workflows they need (monthly close, anomaly detection, chargeback, dispute resolution)?
2) For the CSV, do you need it to include both debits and credits/adjustments in one unified ledger, or do you prefer separate exports/views for “consumed” vs “added”?
If you’ve got an example of another product’s usage ledger you consider “audit-grade,” I’d love to see it too.
k
kamel sellaoui
Nik wPayne (Gamma design)
Hi Elyn,
Thanks — this is exactly the direction we had in mind.
1. Primary users
The primary users would be:
• Workspace admins / operations
• Finance / reconciliation owners
Top workflows:
• monthly close and reconciliation
• anomaly detection and investigation
• usage attribution / internal chargeback by user or document when needed
In our case, the immediate need is to understand significant burn spikes on accounts, identify what generated them and reconcile totals cleanly.
2. CSV structure
Our preference is a unified ledger including both debits and credits/adjustments in the same export, with a clear net impact field per row.
The key requirement is that the ledger remains atomic and fully reconcilable, so that summing row-level impacts matches the balance movement for any selected period.
This is important because grouped summaries are not enough for finance ops, internal controls, or dispute handling, especially when an account shows unusually high burn on a specific day.
Best regards,
Kamel Sellaoui
Nik Payne (Gamma design)
kamel sellaouiThank you!