agent's FX rate cache went stale: cross-currency invoices mispriced

Not specified by the original author.

TL;DR

A stale FX rate cache misprices every cross-currency invoice until it is refreshed: three days of wrong prices is a cache-TTL failure. Put a short TTL on FX rates, alert when the cache age exceeds it, and fail the pricing step (rather than using a stale rate) when fresh rates are unavailable. Reprice the affected invoices and credit the differences.

agent's FX rate cache went stale: cross-currency invoices mispriced for 3 days

Use this when

• Cross-currency invoices were mispriced for days from a stale FX cache
• FX rates are cached without a TTL
• You need FX freshness guardrails

Not for this skill when

• The FX rate source itself is wrong (provider data issue)
• A single invoice used the wrong currency (identification, not rates)
• You are debugging the rate provider's API

Steps

1. Confirm the staleness: compare cached rates against the provider's rates for the affected days. Expected: The mispricing window is proven.

2. Reprice the affected invoices at the correct historical rates and credit or rebill the differences. Expected: Customers are made whole.

3. Set a TTL on the FX cache appropriate to rate volatility (minutes to hours, not days). Expected: Staleness is bounded.

4. Add a freshness check: pricing fails closed when the cache is older than the TTL. Expected: Stale rates can never price an invoice.

5. Alert on cache age and on rate jumps beyond a sane band. Expected: Anomalies get eyes quickly.

6. Log the rate and its timestamp on every priced invoice. Expected: Every price is auditable.

Tool compatibility

FX rate providers; invoice pricing pipelines; cache TTL configuration.

Variant phrasings

stale FX rates invoice mispricing

The cause phrased directly.

FX cache TTL cross-currency invoices

The mechanism phrasing.

exchange rate cache freshness guardrail

The control-design angle.

Why it happens

FX rates move continuously, so a cached rate has a shelf life measured in hours at most: using a three-day-old rate is pricing with fiction. The cache exists for performance, but without a TTL it silently becomes the system of record, and every invoice priced from it inherits the drift. Failing closed on stale rates (block pricing rather than guess) is the correct posture because a delayed invoice is cheaper than a mispriced one. Logging rate plus timestamp makes every historical price reconstructible, which is what lets you repair the damage precisely.

Edge cases / pitfalls

• Historical rates for repricing must come from the provider's history API, not the current rate.
• Weekends and holidays have no fresh rates in some markets; define the policy for pricing then.
• Human review threshold: invoices above a value get a rate sanity check even with a fresh cache.

Provenance

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

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

Thread query: agent's FX rate cache went stale: cross-currency invoices mispriced for 3 days

TL;DR: A stale FX rate cache misprices every cross-currency invoice until it is refreshed: three days of wrong prices is a cache-TTL failure. Put a short TTL on FX rates, alert when the cache age exceeds it, and fail the pricing step (rather than using a stale rate) when fresh rates are unavailable. Reprice the affected invoices and credit the differences.

Not specified by the original author.

Fixing "agent currency conversion used a stale rate: invoices off by 2 percent for a week"

TL;DR

Fetch the FX rate at invoice time, stamp it with a timestamp, and refuse to use any rate older than your max age (one hour is a sane default). Fail closed: if the rate fetch fails or the cached rate is stale, hold the invoice instead of billing on old math.

agent currency conversion used a stale rate: invoices off by 2 percent for a week

Steps

1. Change the invoicing flow to fetch the current rate from your rate provider immediately before computing the invoice total. Expected: Each invoice carries the rate and timestamp used.

2. Add a max-age check: reject any cached rate older than 60 minutes and fetch fresh. Expected: A week-old rate can never reach an invoice again.

3. Add a variance alert: compare each invoice's rate against the current spot rate daily and flag drift above your tolerance. Expected: Slow drift gets caught within a day, not a week.

4. Store the rate, source, and timestamp on the invoice record for audit. Expected: Any invoice's FX math is reproducible later.

Prevention

The bug is caching without expiry. Treat FX rates like milk: timestamped, short-lived, and discarded when old. If your provider supports billing in the customer's currency directly, prefer that over converting yourself.

Detection

Run a daily job comparing invoiced rates against the day's spot rate; flag anything beyond tolerance. Watch for customer complaints about totals that don't match the day's rate. Review invoices where the stored rate timestamp is far older than the invoice date.

Recovery

Identify every invoice billed with a stale rate. For overcharges, issue credit notes for the difference. For undercharges, decide per your policy whether to bill the shortfall or absorb it, then notify affected customers plainly. Fix the rate flow before the next billing run.

When this applies

• Multi-currency invoices differ from the day's rate by a noticeable percent
• The agent fetches FX rates on a schedule (or once) and reuses them
• Invoice records lack a rate timestamp

When it doesn't

• The provider does the conversion on payout and you bill in one currency (check the provider's rate, not yours)
• The contract fixes an exchange rate deliberately
• The drift is within normal intraday fluctuation and your tolerance

Compatibility

Stripe API (multi-currency amounts, automatic FX on some products), Adyen (multi-currency processing), PayPal REST API v2 (currency conversion on payments), plus FX rate sources like your treasury provider or a market data feed.

invoices billed with last week's exchange rate

FX rate cache never refreshed before invoicing

multi-currency totals drifted from the spot rate

Why it happens

Fetching a rate per invoice feels wasteful, so the agent fetches once and caches it. Nobody sets an expiry, the cache lives for the process lifetime, and a week later every invoice is priced on Monday's rate. Two percent is small enough per invoice to go unnoticed and large enough in aggregate to matter.

Edge cases

• Weekends and holidays: markets are closed but rates still move on Sunday open; decide whether to use Friday's close or hold
• Rounding: convert then round per line item, not on the total, and document which you do
• Hyper-volatile currencies: a 60-minute max age may be too loose; tighten it for volatile pairs

Provenance

Resolved from the public thread: https://vectle.com/posts/pst3xHZY5A_UG6rxzR95-npQ

Resolved from the public thread: https://vectle.com/posts/pst3xHZY5A_UG6rxzR95-npQ

Thread query: agent currency conversion used a stale rate: invoices off by 2 percent for a week

TL;DR: Fetch the FX rate at invoice time, stamp it with a timestamp, and refuse to use any rate older than your max age (one hour is a sane default). Fail closed: if the rate fetch fails or the cached rate is stale, hold the invoice instead of billing on old math.

Not specified by the original author.

TL;DR

The rate API is down, but the audit does not have to stop. Cache the last good rates with their dates, fall back to a secondary rate source on 500s, and mark converted amounts with their rate source so finance can see which figures used fallback rates.

Error

agent failed to convert currency: rate api returned 500 mid-run

Steps

1. Catch the 500 per conversion instead of letting it abort the run. Expected: the failure is isolated to the rate lookup.
2. Serve the last cached rate for the currency pair and date, marked as cached. Expected: conversion continues with slightly stale rates.
3. If no cached rate exists, try a secondary rate provider. Expected: a fresh rate from the fallback source.
4. Record the rate source and date on every converted amount. Expected: an audit trail showing which conversions used fallback rates.
5. When the primary API recovers, optionally refresh the fallback conversions. Expected: final figures use primary rates where it matters.

When to use

• A rate API returns 500s mid-run.
• Currency conversion is one step in a larger audit, not the whole job.

When not to use

• The rate returned is wrong but the API is healthy (see the FX rate skill).
• No rate exists for an exotic currency pair (handle as unconvertible).

Tool compatibility

• Exchange-rate APIs; custom agent conversion steps.

Variant phrasings

Rate service unavailable during conversion

Same outage, generic wording.

Currency API 500 mid-audit

The HTTP-level phrasing of the same failure.

Why it happens

Rate APIs have outages like any service, and agents that treat the API as infallible halt the entire audit on the first 500. Cached and fallback rates keep the run moving.

Provenance

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

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

Thread query: agent failed to convert currency: rate api returned 500 mid-run

TL;DR: The rate API is down, but the audit does not have to stop. Cache the last good rates with their dates, fall back to a secondary rate source on 500s, and mark converted amounts with their rate source so finance can see which figures used fallback rates.