Six rate policies, explained with real expense report scenarios

An expense report came back to me last October with a note from the accountant: please redo Line 7 using the prior-month-end rate, not the transaction date. The transaction was a dinner in Frankfurt on October 5. The two candidates were the ECB EUR/JPY rate published on October 5 itself and the closing rate from September 30. The numbers were 162.41 yen per euro and 161.07 yen per euro respectively — a difference of 0.8% on a €280 dinner, about ¥240. Negligible by itself; not negligible across a year of expense submissions.

The puzzling thing was that I had used the transaction-date rate because it seemed obviously the most accurate. The accountant explained that the firm's policy was prior-month-end, applied uniformly across all entries that month, because the auditor had standardized the company on that policy to avoid arguments about timing on cross-month transactions. The "more accurate" rate was the wrong one for that book of accounts.

This is the gap between which rate is mathematically closest to economic reality and which rate is required by the policy the books are kept under. Zenrate supports six policies because those are the ones I've personally seen used across the accounts I file into.

The six, in one sentence each

1. Transaction date. The rate published on the day the transaction happened.
2. Prior month end. The closing rate from the last business day of the previous month, applied uniformly to every transaction in the current month.
3. Month start. The rate from the first business day of the current month, applied uniformly to every transaction in the month.
4. Prior month average. The arithmetic mean of all business-day rates from the previous month, applied to every transaction in the current month.
5. Prior week end. The rate from the last business day of the previous week, applied to every transaction in the current week.
6. Credit card statement rate. The rate the credit card network and issuer actually applied at settlement, entered manually from the cardholder's statement.

The first five are deterministic given a source and a date. The sixth is fundamentally different: it's the only one where the rate is not a public reference but is whatever the bank actually used, and the only one that requires manual entry of the rate itself.

A worked example: EUR/JPY for October 2024

Assume a corporate-card dinner in Frankfurt for €280 on Friday, October 5, 2024. The transaction needs to be translated to yen for the Japanese employer's books. Using illustrative ECB-style figures from October 2024 (numbers reasonable for the period but not pulled from a specific feed):

• Transaction date (October 5): rate 162.41 → ¥45,475
• Prior month end (September 30): rate 161.07 → ¥45,100
• Month start (October 1): rate 161.42 → ¥45,198
• Prior month average (September 2024): rate 161.94 (average of ~22 business-day rates) → ¥45,343
• Prior week end (Friday September 27, 2024): rate 161.18 → ¥45,131
• Credit card statement rate (Visa settlement on October 7, plus 1.6% issuer markup): rate ≈ 165.20 → ¥46,256

Six different numbers for the same dinner. The spread between the lowest and highest is about ¥1,200, or 2.5% of the smallest number. None is wrong; all are correct for their respective policies.

The credit-card statement rate is conspicuously the highest. That's because it includes the card network's settlement-day rate plus the issuer's foreign transaction markup — typically 1.0% to 3.5% on top of the network mid. The public reference rates (ECB, Mizuho, Treasury, HMRC) have no markup. Reconciling a corporate Visa statement to a Mizuho TTM expense report will always show a gap roughly equal to that markup.

Why companies pick each one

Transaction date is what you'd default to if you were inventing accounting from scratch. Most accurate to economic reality. Used by larger firms with automated systems that can pull a rate for every receipt date without manual effort. Also the right policy for one-off large transactions where the timing genuinely matters (wire transfers, contract payments, asset purchases).

Prior month end is the policy I see most often in Japanese SMEs. The reasoning is auditor-driven: one rate per month is easier to audit than 22. You eliminate any argument about which day's rate applies to a transaction that straddled a month boundary. The downside is that fast-moving currencies can produce rate-policy decisions that look arbitrary at boundary dates — a September 30 transaction at the September 30 rate is fine; an October 1 transaction at the September 30 rate (because October is now using that as its prior-month-end) feels wrong, even though it's correct.

Month start has the same simplification as prior-month-end but is "forward-looking" — you set the rate at the start of the month and apply it for the month. Common in companies that want to lock in a planning rate for budgeting and use the same rate for actual recording. Less common than prior-month-end in Japan; more common in companies with US headquarters that came up through QuickBooks-style monthly closing.

Prior month average smooths single-day spikes. The use case is businesses with high transaction volumes in volatile currencies — a Japanese SaaS billed monthly to customers in 15 currencies, for example, where any one currency's bad-rate day across the month would distort the monthly translation. You absorb the volatility into the average and apply it uniformly. The implementation cost is that you need at least a month of historical data before the policy can produce a number; Zenrate's prior-month-average code iterates through the previous month's business days and pulls each day's rate from the configured source.

Prior week end is rare but real. Companies on weekly close cycles — usually those with weekly payroll or weekly cash reconciliation — sometimes apply the same logic at week granularity. The previous Friday's closing rate becomes the rate for everything booked that week.

Credit card statement rate is in a different category. It's required, not optional, when reconciling expenses to a corporate card statement, because every other policy will produce a number that doesn't match the card statement. The card network's settlement-day rate plus the issuer's markup is what actually moved money; for reconciliation, that is the number. For any non-card transaction (wire transfer, cash exchange, direct debit), the credit-card policy doesn't apply and you should use one of the other five.

The mistake people make

Switching policies mid-year without documenting why is the single most common error I see. Auditors hate it. If your books for January through June used transaction-date and July through December used prior-month-end, the year-end numbers are not strictly comparable and any year-over-year analysis is contaminated. Worse, if no one wrote down when or why the switch happened, the auditor has to spend hours tracing it.

The fix is procedural: pick a policy and stay with it for at least the full fiscal year. If you need to change, change at the year boundary and document the reason in the company's accounting policy notes. Zenrate's settings allow mid-year changes but the UI surfaces a soft warning when one is made; we don't block the change because there are legitimate reasons (a corporate restructure, a new auditor, a policy from a parent company change), but we want the user to confirm the decision was deliberate.

The second-most-common error is mixing policies within a single submission. A trip expense report with three meals at transaction-date and two hotels at prior-month-end is wrong even if both policies are individually valid — within one submission, one policy applies. Zenrate enforces this at the entry level: the policy is set per account and applied automatically to every new entry, so the user can't accidentally pick different policies for different lines.

How Zenrate implements

The policy is an account-level setting in Zenrate's data model. Changing it from "transaction date" to "prior month end" updates the policy going forward; existing entries keep the policy they were recorded under. Each receipt record stores not just the rate value but the policy name and the lookup date the policy resolved to. So if your policy was prior-month-end on a transaction dated October 15, the receipt records the lookup date as September 30, the policy as prior-month-end, and the rate value Zenrate pulled for September 30. An auditor can replay the lookup and verify.

The credit-card policy is the only one that doesn't auto-fill the rate. When you select it for a receipt, Zenrate presents a manual entry field; you type the rate from the statement. We then record the policy as `credit_card` so the receipt's audit trail is clear that the rate is user-entered, not source-fetched. This is the correct behavior for an honest audit trail — claiming a system-fetched rate when the source was the cardholder's typed input would be a lie.

Why this matters for Zenrate

The policy isn't a feature; it's a constraint imposed by the way your company's books are kept. Zenrate's job is to expose what was already implicit in your workflow and apply it consistently across every receipt. Pick the policy once, in account settings, and every entry afterward uses the right rate for your jurisdiction without per-receipt decisions. The complexity moves from manual lookup per receipt to a one-time configuration choice, which is the kind of trade-off accounting software is supposed to make.

— Koryu, Endots LLC