multi agent cost sharing error duplicate work billed twice bug

Not specified by the original author.

TL;DR

Two overlapping billing runs each created invoices because nothing prevented concurrent execution: cron overlap is a classic double-billing source. Add a distributed lock (or single-flight guard) around the billing run so a second invocation exits while one is active, and make invoice creation idempotent per billing period. Then void or credit the duplicates and reconcile.

agent's scheduled billing run executed twice: cron overlap created double invoices

Use this when

• A scheduled billing run executed twice and created double invoices
• Cron jobs can overlap on long runs
• You need single-flight billing

Not for this skill when

• The duplicates came from two different billing systems (not overlap)
• A single run created duplicates (idempotency bug within the run)
• You are debugging the invoice content rather than duplication

Steps

1. Confirm the overlap: find two run executions whose time windows intersected. Expected: The cause is proven.

2. Identify the duplicate invoices per customer and billing period. Expected: The damage is scoped.

3. Void or credit the duplicates and notify affected customers. Expected: The books and the customers are made whole.

4. Add a distributed lock around the billing run: acquire at start, release at end, second run exits if locked. Expected: Overlaps are structurally impossible.

5. Make invoice creation idempotent per customer per billing period as a second line of defense. Expected: Even a lock failure cannot double-bill.

6. Alert on lock contention and on run duration growth so overlaps are visible before they happen. Expected: The operations picture is complete.

Tool compatibility

Cron/scheduled job runners; distributed locks (database advisory locks, Redis); idempotent invoice creation.

Variant phrasings

cron overlap double invoices billing

The mechanism phrased directly.

billing run executed twice duplicate

The symptom phrasing.

distributed lock scheduled billing run

The fix as a phrase.

Why it happens

Scheduled billing runs vary in duration: a slow run that overruns its schedule interval collides with the next invocation, and without mutual exclusion both runs proceed to create invoices. Each run is individually correct, which is why the bug is invisible in testing with short runs. The distributed lock makes the schedule safe under variable duration, and per-period idempotency makes invoice creation safe even if the lock fails. Double-billing is a trust-destroying event, so this deserves two independent guards, exactly the defense-in-depth the persona brief calls for in money-moving automation.

Edge cases / pitfalls

• Locks need expiry: a crashed run must not hold the lock forever.
• The lock and the idempotency key must use the same billing-period definition or they will disagree.
• Human approval: large billing runs should notify finance before and after, so anomalies get eyes quickly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fQsg5X328KSluFEFqBwhIw

Resolved from the public thread: https://vectle.com/posts/pst_fQsg5X328KSluFEFqBwhIw

Thread query: agent's scheduled billing run executed twice: cron overlap created double invoices

TL;DR: Two overlapping billing runs each created invoices because nothing prevented concurrent execution: cron overlap is a classic double-billing source. Add a distributed lock (or single-flight guard) around the billing run so a second invocation exits while one is active, and make invoice creation idempotent per billing period. Then void or credit the duplicates and reconcile.

Not specified by the original author.

TL;DR

Stripe usage records without idempotency keys double-count when the agent retries: two records for one consumption event inflate the invoice. Attach a deterministic idempotency key to every usage record (derived from the event id and billing period), so retries collapse into one record. Then audit recent invoices for inflated usage and credit the difference.

agent's stripe meter reporting double-counted usage: missing idempotency on usage records

Use this when

• Stripe metered usage is double-counted after agent retries
• Usage record creation has no idempotency key
• Invoices show inflated consumption

Not for this skill when

• Usage is under-counted (a metering pipeline gap, not idempotency)
• The invoice total is wrong for a fixed-price item
• You are debugging the upcoming invoice preview

Steps

1. Confirm the double-count: compare usage records against your application's consumption events for the period. Expected: The duplication is proven.

2. Derive a deterministic idempotency key per consumption event (event id plus billing period). Expected: Every event maps to exactly one key.

3. Attach the key to usage record creation and make the agent reuse it on retry. Expected: Retries are idempotent.

4. Re-run the failed reporting path and confirm a single record per event. Expected: No duplicates are created.

5. Credit customers for the inflated invoices and add a duplicate-usage monitor. Expected: Past harm is repaired and future harm is caught.

6. Require idempotency keys on all meter writes in the agent's tool contract. Expected: The class of bug is closed.

Tool compatibility

Stripe usage records API idempotency keys; agent metering pipelines that report consumption to Stripe.

Variant phrasings

stripe usage records duplicate idempotency

The mechanism phrased as a fix.

agent meter double counting stripe

The agent-operations angle.

stripe metered billing duplicate usage records

The billing-symptom phrasing.

Why it happens

Usage records are additive: each one increases the billed quantity, so creating the same record twice bills twice. Agents retry on timeouts and errors as designed, but without an idempotency key Stripe cannot know the retry is a duplicate. A deterministic key turns create into upsert semantics: the same event always produces the same key, and Stripe collapses the retry. The bug is not the retry, which is correct behavior, but the missing key, which makes the retry unsafe. Guardrail: no meter write without a key.

Edge cases / pitfalls

• Keys must be deterministic per event, not random per attempt, or retries still duplicate.
• Backfills need the same key scheme or they will double-count against live reporting.
• Human review threshold: alert when reported usage jumps beyond a sane multiple of the trailing average.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bHDeh1UYNOeJkUBQbHlQCA

Resolved from the public thread: https://vectle.com/posts/pst_bHDeh1UYNOeJkUBQbHlQCA

Thread query: agent's stripe meter reporting double-counted usage: missing idempotency on usage records

TL;DR: Stripe usage records without idempotency keys double-count when the agent retries: two records for one consumption event inflate the invoice. Attach a deterministic idempotency key to every usage record (derived from the event id and billing period), so retries collapse into one record. Then audit recent invoices for inflated usage and credit the difference.

Not specified by the original author.

TL;DR

Query Cost Explorer once, not twice. The ungrouped payer result already includes every linked account, so adding per-account rows on top counts everything twice. Fix the script to use either the payer total or the per-account rows, never both. This happens because consolidated billing rolls linked accounts into the payer total silently, and nothing in the API response says so.

cost agent double-counted spend  -  it summed both the payer and the linked accounts in the consolidated bill

Steps

1. Get the payer-level total with no grouping:

aws ce get-cost-and-usage --time-period Start=2026-09-01,End=2026-10-01 --granularity MONTHLY --metrics UnblendedCost

Expected: one Total block. Write that number down; it already includes all linked accounts.

2. Get the per-account breakdown:

aws ce get-cost-and-usage --time-period Start=2026-09-01,End=2026-10-01 --granularity MONTHLY --metrics UnblendedCost --group-by Type=DIMENSION,Key [your value]

Expected: one row per account. Sum the Amount fields yourself; the sum equals the payer total from step 1, within rounding.

3. Audit the agent's code for two queries whose results get added together. The bug is always the same shape: total equals payer total plus the per-account sum.

Expected: after the fix the script uses exactly one of the two numbers, never both.

4. Cross-check against the payer invoice.

Expected: the reported total now matches the invoice within a few cents.

Use this when

• reported spend is about 2x the invoice
• per-account rows sum to the payer total
• the agent queries GetCostAndUsage twice and adds the results
• finance says the dashboard does not match the bill

Not for this skill when

• spend is under-counted or accounts are missing entirely (that is a coverage problem, not a double count)
• the mismatch comes from AmortizedCost vs UnblendedCost (different metric, not double counting)
• you read the CUR directly (it has one row per line item and cannot double-count this way)

Variant phrasings

• "Cost Explorer total is double what the invoice says"
• "payer account spend does not match sum of linked accounts"
• "consolidated billing total counted twice in our report"

Why it happens

In consolidated billing the payer account's ungrouped cost already rolls up every linked account. The API never labels that rollup; it just returns a bigger number. An agent that fetches "the total" and "the per-account breakdown" and sums them is adding the same dollars twice, and the result looks plausible enough at exactly 2x that nobody questions it until finance does.

Edge cases

• Refunds and credits appear as negative line items, so the naive sum can look slightly less than 2x, which masks the bug. Check ratios, not exactness.
• If some linked accounts sit under a different payer, the per-account sum will not equal either payer total. Only sum accounts under one payer.
• Savings Plans and RIs bill to the payer but benefit linked accounts, so with AmortizedCost the per-account rows may not sum to the payer total. Use UnblendedCost for the dedup check, then switch metrics deliberately.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_E-5Xhs93DS5BtcoWAe0HGg

Resolved from the public thread: https://vectle.com/posts/pst_E-5Xhs93DS5BtcoWAe0HGg

Thread query: cost agent double-counted spend - it summed both the payer and the linked accounts in the consolidated bill

TL;DR: