← Zurück zu KI-Automatisierung und Kostenkontrolle
Entdecke, wie der Skill hilft
Abrechnungsereignisse deduplizieren
Verhindert doppelte Belastungen durch wiederholte Verbrauchsereignisse und erhält eine rekonstruierbare Abrechnungshistorie.
deduplication-accounting-integrity
Teammitglieder mit diesem Skill
Wann ist der Skill hilfreich?
Nutze dies, wenn Webhooks oder Workerwiederholungen Verbrauchs- oder Kostenbücher beliefern.
Wobei hilft er dir?
- Leitet stabile Vorgangskennungen für wiederholungssichere Ereignisaufnahme ab.
- Bewahrt Buchungseinträge und stellt Korrekturen durch zusätzliche Einträge dar.
- Trennt Rohereignisse von Summen und verwendet exakte Geldarithmetik.
Das könntest du fragen
Verarbeite dasselbe Verbrauchsereignis dreimal mit nur einer Belastung und nachvollziehbarer Korrekturmöglichkeit. Liefere das Ereignis nach einem Worker-Neustart erneut. Das Journal enthält eine ursprüngliche Belastung und spätere Korrekturen als getrennte nachvollziehbare Einträge.
Ausführliche Dokumentation
Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.
Weniger anzeigen
Deduplication & Accounting Integrity
Usage and cost ledgers require financial-grade accounting integrity. Retries, webhook replays, queue redeliveries, and crash recoveries must never inflate usage or silently drop consumption.
Workflow
- Deterministic idempotency keys:
- Construct idempotency keys from stable business coordinates rather than random UUIDs generated at logging time:
- LLM / external API call:
{provider}:{providerRequestId}or{runId}:{stepIndex}:{attemptNumber}. - Queue job execution:
{queueName}:{jobId}:{executionAttempt}. - Periodic storage snapshot:
{tenantId}:{bucketId}:{windowStartIso}.
- LLM / external API call:
- Enforce a unique constraint (
UNIQUE (tenant_id, idempotency_key)) at the database or ingestion layer and handle conflicts with idempotent upserts (ON CONFLICT DO NOTHINGor upgrading'estimated'to'provider_reported').
- Construct idempotency keys from stable business coordinates rather than random UUIDs generated at logging time:
- Append-only immutable ledger:
- Never
UPDATEorDELETEcommitted usage or cost ledger rows to fix a bug, apply a credit, or change a price. - Record corrections, refunds, provider credits, or late invoice adjustments as compensating/adjustment ledger entries (
entryType: 'raw_usage' | 'adjustment' | 'credit' | 'reconciliation_delta') referencingoriginalEventIdwith a reason code and timestamp.
- Never
- Separate raw events from rollups:
- Keep the raw event table append-only as the single source of truth.
- Materialize hourly/daily/monthly rollups (
usage_rollups_hourly,usage_rollups_daily) as derived projections that can be deterministically rebuilt from the raw event log. - Track a watermark on rollups so late-arriving events trigger incremental recalculation of affected time buckets.
- Integer and fixed-point arithmetic:
- Never use IEEE 754 floating-point (
number/FLOAT/DOUBLE) to accumulate monetary costs. - Store and sum costs in integer sub-cent units (nanodollars
10^-9 USDor microdollars10^-6 USDusingBIGINT/BigIntorNUMERIC(20, 9)) because per-token LLM prices underflow 2- or 4-decimal cent columns.
- Never use IEEE 754 floating-point (
Anti-Patterns to Avoid
- Random UUID idempotency keys: Generating
crypto.randomUUID()inside the logger wrapper makes every retry look like a new event. - Rounding each event to cents (
0.01): Rounding a$0.0004LLM call before summing causes massive cumulative drift. - In-place backfills: Overwriting historical ledger rows without an audit trail makes it impossible to explain why past reported cost changed.
Enthaltene Dateien 1
SKILL.md
