agent's currency converter used the expense date rate instead of the transa

Not specified by the original author.

TL;DR

The agent looked up the exchange rate for the day the expense was filed rather than the day the card was charged, so every conversion used the wrong rate. Change the rate lookup to use the transaction (posting) date from the card feed. The card network converted on the transaction date; the agent must use the same date.

Error

agent's currency converter used the expense date rate instead of the transaction date

Steps

1. Confirm the error: pick a converted expense and compare the agent's rate against the historical rate for the transaction date versus the expense date. Expected: the agent's rate matches the expense date, not the transaction date.
2. Change the converter to take the transaction date from the card feed record as the rate-date input. Expected: the lookup key is the charge date.
3. Handle edge cases: weekend and holiday transaction dates should fall back to the previous business day's rate, matching how networks settle. Expected: the fallback rule is documented in the code.
4. Re-run conversion over the affected expenses. Expected: converted amounts now match the card statement.
5. Add a regression check comparing converted totals to statement totals within tolerance. Expected: future wrong-date lookups fail the check loudly.

When to use

• An agent converts foreign expenses with the wrong date's rate.
• Converted amounts disagree with card statements.
• The expense date and transaction date differ by days or weeks.

When not to use

• No rate is available for the date (a data-availability problem).
• The amounts differ because of fees, not the rate.
• The expense is single-currency.

Tool compatibility

Applies to custom audit agents with currency conversion (Python, agent frameworks; current 2026 releases).

Variant phrasings

fx conversion used the filing date

Key the rate lookup to the transaction date.

converted total doesn't match the statement

The rate date is the usual suspect. Verify which date the agent used.

weekend transaction converted at the wrong rate

Fall back to the previous business day, like the network does.

Why it happens

Expense date (when the human filed) and transaction date (when money moved) routinely differ by days or weeks, and exchange rates move in between. The card network's conversion happened on the transaction date, so that date's rate is the economically correct one. Using the expense date is a convenient default that is quietly wrong, and the error compounds across every foreign expense the agent touches.

Provenance

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

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

Thread query: agent's currency converter used the expense date rate instead of the transaction date

TL;DR: The agent looked up the exchange rate for the day the expense was filed rather than the day the card was charged, so every conversion used the wrong rate. Change the rate lookup to use the transaction (posting) date from the card feed. The card network converted on the transaction date; the agent must use the same date.

Not specified by the original author.

TL;DR

The expense converted with the wrong rate source or the wrong date's rate. Check which rate and date the tool used, switch to the correct rate (card posting date rate or the documented actual rate), and correct the home-currency total.

Error

foreign currency expense converted at wrong rate

Steps

1. Open the expense and find the foreign amount, the converted amount, and the rate and rate date the tool used. Expected: all four values are visible.
2. Determine the correct rate: for card charges use the card network's posting-date rate; for cash use the documented exchange rate for the transaction date. Expected: you know which rate should apply.
3. Compute the expected home-currency total yourself (foreign amount times the correct rate). Expected: a number to compare against.
4. Override the converted total with the correct figure and attach rate evidence (card statement, exchange receipt). Expected: the expense shows the corrected total with documentation.
5. If the tool's rate feed is systematically off, report it to your admin. Expected: the feed gets corrected for everyone.

When to use

• A foreign-currency expense shows a converted total that does not match the card statement.
• The rate date differs from the transaction date.

When not to use

• Finance rejected the expense pending rate documentation (attach the evidence).
• The currency itself is wrong (fix the currency, not the rate).

Tool compatibility

• Expensify, Concur, Ramp multi-currency expenses; card-network rates.

Variant phrasings

Incorrect FX rate on expense

Same problem, shorter wording.

Currency conversion looks wrong

The reviewer-flag phrasing of the same issue.

Why it happens

Tools pick a rate source and date automatically (often the expense creation date, not the transaction date), and card networks settle at their own rates. Any mismatch between the tool's choice and reality shows up as a wrong total.

Provenance

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

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

Thread query: foreign currency expense converted at wrong rate error

TL;DR: The expense converted with the wrong rate source or the wrong date's rate. Check which rate and date the tool used, switch to the correct rate (card posting date rate or the documented actual rate), and correct the home-currency total.

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.