agent double-counted mileage and fuel for the same trip

Not specified by the original author.

TL;DR

Mileage reimbursement already covers fuel (the standard rate bundles fuel, wear, and insurance), so claiming fuel receipts on top of mileage for the same trip double-counts. Add a rule: for any trip with a mileage claim, flag fuel receipts on overlapping dates as duplicates of the mileage. One trip gets one vehicle-cost method.

Error

agent double-counted mileage and fuel for the same trip

Steps

1. Confirm the double-count: find trips with both a mileage claim and fuel receipts on the same dates. Expected: the overlapping pairs are visible.
2. Check company policy: standard mileage rate versus actual-cost method, and whether mixing is allowed. Expected: the policy confirms mileage already includes fuel.
3. Add the either-or rule to the agent: fuel receipts overlapping a mileage-claimed trip get flagged for review. Expected: the agent flags the overlap instead of passing both.
4. For flagged pairs, keep the mileage claim (or the method the policy prefers) and remove or reject the fuel receipts. Expected: each trip carries exactly one vehicle-cost method.
5. Re-run the audit over the vehicle expenses. Expected: the double-counts are flagged and totals drop to the correct amounts.

When to use

• An agent passes both mileage and fuel for the same trip.
• Vehicle expenses look inflated on audit.
• Policy uses the standard mileage rate.

When not to use

• The policy uses actual-cost method (fuel receipts are the method; mileage is the error).
• The fuel is for a rental car (rentals expense fuel separately by policy).
• The trips are genuinely different.

Tool compatibility

Applies to custom audit agents reviewing vehicle expenses (current 2026 releases).

Variant phrasings

mileage plus gas receipts for one trip

The standard rate already covers fuel. Flag the overlap.

vehicle costs doubled on the audit

Check for mileage-fuel pairs on the same dates.

rental car fuel flagged with mileage

Rentals are the exception: fuel is expensed separately. Exclude rentals from the rule.

Why it happens

The IRS standard mileage rate is a bundled rate: fuel, maintenance, insurance, and depreciation in one number. Claiming fuel on top is claiming the same cost twice. Agents that audit mileage and fuel as independent categories miss the relationship because the two expense types live in different buckets. The either-or rule encodes the economic reality that one trip has one vehicle cost.

Provenance

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

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

Thread query: agent double-counted mileage and fuel for the same trip

TL;DR: Mileage reimbursement already covers fuel (the standard rate bundles fuel, wear, and insurance), so claiming fuel receipts on top of mileage for the same trip double-counts. Add a rule: for any trip with a mileage claim, flag fuel receipts on overlapping dates as duplicates of the mileage. One trip gets one vehicle-cost method.

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:

Not specified by the original author.

TL;DR

The start and end odometer readings imply a different distance than the claimed miles, which reads as an error or an inflated claim. Check the readings for transposed digits or a wrong starting value, correct them, and resubmit. If the readings are right and the distance is right (e.g. a replaced odometer or a multi-day trip log), attach a written explanation.

Error

mileage claim rejected: odometer reading inconsistent with distance

Steps

1. Open the rejected mileage claim and compare the start reading, end reading, and claimed distance. Expected: you can see the arithmetic gap.
2. Check for data-entry errors: transposed digits, a start reading copied from the wrong trip, or a reading in kilometers entered as miles. Expected: the error is visible in the numbers.
3. Correct the readings and let the distance recompute, or correct the distance if the readings were right. Expected: start, end, and distance are arithmetically consistent.
4. If the numbers are genuinely inconsistent (odometer replaced, trip spanned a service visit), attach a written explanation with supporting evidence. Expected: the approver has documentation for the exception.
5. Resubmit the claim. Expected: the consistency check passes or the exception routes with documentation.

When to use

• A mileage claim is rejected for odometer inconsistency.
• Start and end readings were entered from memory and do not add up.
• An odometer replacement or unit change explains the gap.

When not to use

• The rejection is about the per-mile rate cap.
• The route distance itself is disputed.
• The claim lacks any odometer readings at all.

Tool compatibility

Applies across expense tools with odometer fields (Concur, Expensify, and others; current 2026 releases).

Variant phrasings

"odometer readings don't match" on a mileage claim

Same consistency check. Fix the digits or document the reason.

mileage rejected after an odometer replacement

The new odometer restarts the count. Document the replacement with the service record.

transposed digits on a mileage log

The most common cause. Re-enter carefully and the check passes.

Why it happens

Odometer consistency is an anti-fraud check: end minus start must equal the claimed distance, within tolerance. The usual cause is honest data entry error (transposed digits, wrong trip's start reading), but the check exists because inflated mileage is a classic expense fraud pattern. Legitimate inconsistencies (replaced odometers, multi-day logs) need documentation because the system cannot distinguish them from errors on the numbers alone.

Provenance

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

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

Thread query: mileage claim rejected: odometer reading inconsistent with distance

TL;DR: The start and end odometer readings imply a different distance than the claimed miles, which reads as an error or an inflated claim. Check the readings for transposed digits or a wrong starting value, correct them, and resubmit. If the readings are right and the distance is right (e.g. a replaced odometer or a multi-day trip log), attach a written explanation.