[Due for payment 2026-03-13] [$250] Distance rate change retroactively updates all historical distance expenses, including Approved and Exported reports

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.15-10
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @marianaabussamra
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in as a workspace admin
2. Ensure there are existing distance expenses created under an older distance rate, on reports that are already Approved and Exported
3. Create a new distance rate for the workspace (or update the existing one)
4. Open previously approved and exported reports containing distance expenses and inspect the distance line items

Expected Result:

Distance expenses on reports that were already Approved and Exported should remain calculated with the original rate used at the time of approval/export, preserving historical reimbursement amounts.

Actual Result:

All historical distance expenses are recalculated to use the new distance rate, including those on Approved and Exported reports.
Previously approved/exported reports display updated (changed) distance amounts, so historical mileage reimbursement values are not preserved.
Opening the expenses display an error it doesn't match the calculation.
The exported report in QBO displays the correct (Old) rate

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

The screenshots for the issue are in slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @situchan

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022021573877488667076
• Upwork Job ID: 2021573877488667076
• Last Price Increase: 2026-02-18
• Automatic offers:
• situchan | Contributor | 110714786

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @situchan (External)

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022021573877488667076

[buildingvibes]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a workspace admin changes a distance rate (or creates a new one), all historical distance expenses — including those on already Approved and Exported reports — are retroactively displayed with the new rate. This causes the displayed amount to mismatch the originally approved/exported amount. The exported report in QBO retains the correct (old) rate, but the App shows the recalculated (new) rate, creating confusion and an error about the calculation not matching.

What is the root cause of that problem?

The root cause is that the getRate() function in src/libs/DistanceRequestUtils.ts (line 371–400) always resolves the rate value dynamically from the current policy state, rather than using a rate value snapshotted at the time the expense was created.

When a distance expense is created, the transaction stores only the customUnitRateID (a reference ID) in transaction.comment.customUnit.customUnitRateID. The actual rate value (cents per unit) is never persisted on the transaction itself. The getRate() function then looks up the rate via:

let mileageRates = getMileageRates(policy, true, transaction?.comment?.customUnit?.customUnitRateID);
// ...
const customMileageRate = (customUnitRateID && mileageRates?.[customUnitRateID]) || defaultMileageRate;

This means it always reads policy.customUnits[distanceUnitID].rates[rateID].rate — which is the current rate value. When the admin updates this rate, every historical expense referencing that rateID now displays the new rate, even though transaction.amount was calculated with the old rate at creation time.

This manifests in two places:

1. MoneyRequestView.tsx (line 423): When viewing an existing expense, it calls DistanceRequestUtils.getRate({transaction, policy}) to get the rate for display. The rateToDisplay and distanceToDisplay values are calculated from the current policy rate, not the original rate.

2. TransactionUtils/index.ts (around line 719–724): When waypoints or rates change, the amount is recalculated using DistanceRequestUtils.getDistanceRequestAmount(distanceInMeters, unit, rate) with the current policy rate.

Note that the distanceUnit is already correctly snapshotted on the transaction (transaction.comment.customUnit.distanceUnit) — the code at line 394 of DistanceRequestUtils.ts respects this via getDistanceUnit(). But the rate value itself has no equivalent snapshot.

What changes do you think we should make in order to solve the problem?

1. Snapshot the rate value on the transaction at creation time.

Add a rate field to TransactionCustomUnit in src/types/onyx/Transaction.ts:

type TransactionCustomUnit = {
    // ... existing fields ...
    /** The rate value (in cents per unit) snapshotted at expense creation time */
    rate?: number;
    /** The currency of the rate snapshotted at expense creation time */
    rateCurrency?: string;
};

2. Persist the rate when creating distance expenses.

In src/libs/TransactionUtils/index.ts, in the buildOptimisticTransaction function (and anywhere else a distance transaction is constructed), set comment.customUnit.rate and comment.customUnit.rateCurrency to the rate value at creation time.

3. Modify getRate() in src/libs/DistanceRequestUtils.ts to prefer the snapshotted rate for existing (non-draft) expenses.

In the getRate() function, after resolving the mileageRate from the policy, check whether the transaction already has a snapshotted rate. If so, use it instead of the policy's current rate. This should only apply when the expense is not being actively edited (i.e., the rate field is not being changed by the user):

function getRate({ transaction, policy, policyDraft, useTransactionDistanceUnit = true }) {
    // ... existing rate lookup from policy ...
    
    const snapshotRate = transaction?.comment?.customUnit?.rate;
    const snapshotCurrency = transaction?.comment?.customUnit?.rateCurrency;
    
    // For existing transactions with a snapshotted rate, use the original rate
    // This prevents policy rate changes from retroactively altering historical expenses
    if (snapshotRate !== undefined && snapshotRate !== null) {
        return {
            ...mileageRate,
            rate: snapshotRate,
            unit,
            currency: snapshotCurrency ?? mileageRate?.currency ?? policyCurrency,
        };
    }
    
    return {
        ...mileageRate,
        unit,
        currency: mileageRate?.currency ?? policyCurrency,
    };
}

4. When the user explicitly changes the rate on an existing expense, update the snapshot to the newly selected rate value (the existing code in TransactionUtils/index.ts around line 744–792 where customUnitRateID changes are handled should also write the new rate value to comment.customUnit.rate).

5. Backend alignment: The UpdatePolicyDistanceRateValue API command (WRITE_COMMANDS.UPDATE_POLICY_DISTANCE_RATE_VALUE) should also be updated on the backend side to not retroactively recompute transaction.amount for transactions on Approved/Exported reports. This is a backend change that should be coordinated with the API team.

What alternative solutions did you explore? (Optional)

1. Only fix the display layer: We could modify MoneyRequestView.tsx to back-calculate the original rate from transaction.amount / distance for approved/exported reports. However, this is fragile — rounding errors and edge cases (zero distance, currency mismatches) would make this unreliable, and it wouldn't fix recalculations in TransactionUtils.

2. Freeze the entire policy rate object on the transaction: Instead of just the rate value, we could store the full MileageRate object. This is heavier than needed — the customUnitRateID is still useful for referencing the rate's metadata (name, tax settings, etc.), and we only need to snapshot the numeric rate and currency.

3. Use modifiedAmount as a guard: Check if transaction.amount differs from the recalculated amount and treat transaction.amount as authoritative for approved/exported reports. This would work for display but wouldn't prevent the rate display from being wrong — users would still see the new rate listed even though the amount reflects the old rate.

The proposed approach of snapshotting the rate value is the cleanest solution because it follows the existing pattern already used for distanceUnit (which is snapshotted at transaction.comment.customUnit.distanceUnit), maintains backward compatibility (old transactions without a snapshot will fall back to the current policy rate), and is the standard accounting practice for expense rate locking.

[imgyf]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a workspace administrator modifies the distance rate (or creates a new rate that becomes the default), all historical distance expenses — including those on reports that have already been Approved and Exported to external accounting systems like QuickBooks Online — are retroactively recalculated and displayed using the new rate. This causes:

1. Display Mismatch: The expense amount shown in the New Expensify App differs from the amount originally approved and exported
2. Calculation Errors: The App displays an error stating the expense "doesn't match the calculation" because transaction.amount (old calculation) differs from the newly recalculated value
3. Audit Integrity Issues: Historical records no longer reflect the actual approved amounts, violating accounting audit trail requirements
4. External System Inconsistency: The exported report in QBO correctly retains the old rate, but the App shows the new rate, creating confusion

What is the root cause of that problem?

The root cause is architectural: distance rates are dynamically resolved from the live policy state rather than being snapshotted at the time of expense creation/approval.

Technical Breakdown:

1. Transaction Storage: When a distance expense is created, only the customUnitRateID (a reference identifier) is stored in transaction.comment.customUnit.customUnitRateID. The actual rate value (cents per mile/km) is never persisted on the transaction itself.

2. Dynamic Rate Resolution: The getRate() function in src/libs/DistanceRequestUtils.ts (lines ~371-400) always looks up the rate value from the current policy state:

   const mileageRates = getMileageRates(policy, true, customUnitRateID);
   const rate = mileageRates?.[customUnitRateID]?.rate; // Always current policy rate!

3. Display-Time Recalculation: In MoneyRequestView.tsx (line ~423) and other display components, getRate() is called every time the expense renders, pulling the live rate from the policy.

4. Amount Validation Mismatch: The App validates expenses by recalculating distance × current_rate and comparing it to transaction.amount (which was calculated using the original rate). When rates change, this validation fails.

5. Missing Rate Snapshot: Unlike the distanceUnit field (which IS correctly snapshotted at transaction.comment.customUnit.distanceUnit), the rate value has no equivalent snapshot mechanism.

Relevant code locations:

• src/libs/DistanceRequestUtils.ts - getRate() function (lines ~371-400)
• src/pages/iou/request/step/MoneyRequestView.tsx - Display component (line ~423)
• src/libs/TransactionUtils/index.ts - buildOptimisticTransaction() and update handlers
• src/libs/actions/Transaction.ts - Transaction update actions

What changes do you think we should make in order to solve the problem?

Solution Approach: Implement Rate Snapshotting with Selective Override

I propose snapshotting the rate value and currency at key transaction lifecycle events, then using these snapshots for historical expenses while allowing intentional rate updates during active editing.

1. Extend Transaction Type to Support Rate Snapshots

Add rate snapshot fields to TransactionCustomUnit in src/types/onyx/Transaction.ts:

type TransactionCustomUnit = {
    // ... existing fields ...
    customUnitRateID: string;
    distanceUnit: DistanceUnit;
    quantity: number;
    /** The rate value (in cents per unit) snapshotted at expense creation/approval time */
    snapshottedRate?: number;
    /** The currency of the snapshotted rate */
    snapshottedRateCurrency?: string;
    /** Timestamp when the rate was snapshotted (for audit purposes) */
    snapshottedAt?: string; // ISO 8601 timestamp
};

2. Snapshot Rate on Transaction Creation

In src/libs/TransactionUtils/index.ts, update buildOptimisticTransaction() to capture the current rate when creating distance expenses:

function buildOptimisticTransaction(
    amount: number,
    currency: string,
    reportID: string,
    // ... other params
    policy?: OnyxEntry<Policy>,
    policyTagList?: OnyxEntry<PolicyTagList>,
    policyCategories?: OnyxEntry<PolicyCategories>,
): Transaction {
    // ... existing code ...
    
    const customUnit = getCustomUnit(params, policy);
    
    // Snapshot the rate at creation time
    if (customUnit?.customUnitRateID && policy) {
        const mileageRate = getMileageRateByID(policy, customUnit.customUnitRateID);
        if (mileageRate) {
            customUnit.snapshottedRate = mileageRate.rate;
            customUnit.snapshottedRateCurrency = mileageRate.currency || policy.outputCurrency;
            customUnit.snapshottedAt = new Date().toISOString();
        }
    }
    
    // ... rest of transaction building
}

3. Snapshot Rate on Report Approval

Add rate snapshotting when a report is approved in src/libs/actions/Report.ts:

function approveMoneyRequest(reportID: string) {
    const report = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
    const transactions = getTransactionsByReportID(reportID);
    
    // Snapshot current rates for all distance expenses at approval time
    const updatedTransactions = transactions.map(transaction => {
        if (isDistanceRequest(transaction) && !transaction.comment?.customUnit?.snapshottedRate) {
            const policy = getPolicy(report?.policyID);
            const rateID = transaction.comment?.customUnit?.customUnitRateID;
            const mileageRate = rateID ? getMileageRateByID(policy, rateID) : null;
            
            if (mileageRate) {
                return {
                    ...transaction,
                    comment: {
                        ...transaction.comment,
                        customUnit: {
                            ...transaction.comment.customUnit,
                            snapshottedRate: mileageRate.rate,
                            snapshottedRateCurrency: mileageRate.currency || policy?.outputCurrency,
                            snapshottedAt: new Date().toISOString(),
                        },
                    },
                };
            }
        }
        return transaction;
    });
    
    // Optimistically update transactions with snapshotted rates
    Onyx.mergeCollection(ONYXKEYS.COLLECTION.TRANSACTION, 
        Object.fromEntries(updatedTransactions.map(t => [`${ONYXKEYS.COLLECTION.TRANSACTION}${t.transactionID}`, t]))
    );
    
    // ... proceed with approval API call
}

4. Modify getRate() to Respect Snapshots

Update getRate() in src/libs/DistanceRequestUtils.ts to use snapshotted rates for historical expenses:

function getRate({
    transaction,
    policy,
    policyDraft,
    useTransactionDistanceUnit = true,
    isEditing = false, // New param to indicate if user is actively editing
}: GetRateParams): RateData {
    const distanceUnit = useTransactionDistanceUnit 
        ? getDistanceUnit(transaction) 
        : getDefaultDistanceUnit(policy);
    
    const customUnitRateID = transaction?.comment?.customUnit?.customUnitRateID;
    const mileageRates = getMileageRates(policyDraft ?? policy, true, customUnitRateID);
    const policyCurrency = policy?.outputCurrency ?? CONST.CURRENCY.USD;
    
    // Get the live rate from policy (for new expenses or active editing)
    const liveRate = customUnitRateID && mileageRates?.[customUnitRateID]
        ? mileageRates[customUnitRateID]
        : getDefaultMileageRate(policy, distanceUnit);
    
    // Check for snapshotted rate (for historical expenses not being edited)
    const snapshottedRate = transaction?.comment?.customUnit?.snapshottedRate;
    const snapshottedCurrency = transaction?.comment?.customUnit?.snapshottedRateCurrency;
    
    // Use snapshotted rate if:
    // 1. A snapshot exists
    // 2. We're not actively editing the rate
    // 3. The transaction is not in draft state
    if (!isEditing && 
        snapshottedRate !== undefined && 
        transaction?.statusNum !== CONST.TRANSACTION.STATUS.DRAFT) {
        return {
            ...liveRate, // Keep metadata (name, tax settings) from live rate
            rate: snapshottedRate,
            currency: snapshottedCurrency ?? liveRate?.currency ?? policyCurrency,
            unit: transaction?.comment?.customUnit?.distanceUnit ?? distanceUnit,
            isSnapshotted: true, // Flag for UI indication
        };
    }
    
    return {
        ...liveRate,
        unit: distanceUnit,
        currency: liveRate?.currency ?? policyCurrency,
        isSnapshotted: false,
    };
}

5. Update Rate Change Handler to Update Snapshot

When a user explicitly changes the rate on an existing expense (legitimate update), update the snapshot in src/libs/TransactionUtils/index.ts:

function updateMoneyRequestDistanceRate(
    transactionID: string,
    newRateID: string,
    policy: OnyxEntry<Policy>,
) {
    const transaction = allTransactions?.[transactionID];
    const newRate = getMileageRateByID(policy, newRateID);
    
    if (!newRate) return;
    
    const updatedTransaction = {
        ...transaction,
        comment: {
            ...transaction.comment,
            customUnit: {
                ...transaction.comment?.customUnit,
                customUnitRateID: newRateID,
                // Update snapshot to the newly selected rate
                snapshottedRate: newRate.rate,
                snapshottedRateCurrency: newRate.currency || policy?.outputCurrency,
                snapshottedAt: new Date().toISOString(),
            },
        },
    };
    
    // Recalculate amount with new rate
    const distance = getDistanceInMeters(updatedTransaction);
    updatedTransaction.amount = calculateDistanceAmount(distance, newRate.rate);
    
    Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, updatedTransaction);
}

6. UI Indication for Snapshotted Rates

In MoneyRequestView.tsx, add a visual indicator when a snapshotted rate is being displayed:

const rateData = DistanceRequestUtils.getRate({transaction, policy});
// ...
{rateData.isSnapshotted && (
    <Text style={[styles.textMicro, styles.textSupporting]}>
        {translate('iou.rateSnapshotted', {
            date: DateUtils.formatDate(moment(transaction.comment?.customUnit?.snapshottedAt)),
        })}
    </Text>
)}

7. Backend Coordination

The backend should also be updated to:

1. Snapshot rates when processing CreateDistanceRequest API calls
2. Snapshot rates when processing ApproveMoneyRequest API calls
3. Include snapshottedRate in transaction data returned by GetReport and GetTransaction commands
4. NOT recalculate amounts for transactions on Approved/Exported reports when UpdatePolicyDistanceRateValue is called

What alternative solutions did you explore? (Optional)

Alternative 1: Report-Level Rate Freezing

• Freeze all rates on a report when it transitions to Approved/Exported state
• Rejected: More complex, requires report-level state tracking. Transaction-level snapshotting is cleaner and more granular.

Alternative 2: Amount-Based Rate Back-Calculation

• For existing transactions, back-calculate the original rate from transaction.amount / distance
• Rejected: Rounding errors, division by zero risks, and doesn't handle currency changes or tax adjustments properly.

Alternative 3: Versioned Rate History

• Store complete rate history in policy and reference specific rate versions
• Rejected: Over-engineered for this use case. Simple snapshotting achieves the same goal with less complexity.

Alternative 4: Immutable Transaction Amounts

• Once a transaction is approved, lock the amount field from any recalculation
• Rejected: This breaks legitimate edit scenarios where users need to correct distance or rate selection errors.

The proposed solution is superior because it:

1. Preserves audit integrity by locking rates at approval time
2. Allows legitimate edits when users intentionally update rates
3. Follows existing patterns (similar to distanceUnit snapshotting)
4. Provides transparency through UI indicators
5. Maintains backward compatibility (old transactions without snapshots fall back to current behavior)

Files Modified

• src/types/onyx/Transaction.ts
• src/libs/TransactionUtils/index.ts
• src/libs/DistanceRequestUtils.ts
• src/libs/actions/Report.ts
• src/libs/actions/Transaction.ts
• src/pages/iou/request/step/MoneyRequestView.tsx
• New/Update: Language translations for snapshot indicators

[HiepPP]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a workspace admin changes a distance rate (or creates a new one), all historical distance expenses are retroactively recalculated using the new rate -- including expenses on reports that are already Approved and Exported. This causes a mismatch with the amounts exported to QBO and displays a calculation error.

What is the root cause of that problem?

The getRate() function always resolves the rate value from the current policy state. It uses the customUnitRateID stored on the transaction to look up the rate in the live policy.customUnits.rates object:

App/src/libs/DistanceRequestUtils.ts

Lines 371 to 400 in 801ee41

	function getRate({
	transaction,
	policy,
	policyDraft,
	useTransactionDistanceUnit = true,
	}: {
	transaction: OnyxEntry<Transaction>;
	policy: OnyxEntry<Policy>;
	policyDraft?: OnyxEntry<Policy>;
	useTransactionDistanceUnit?: boolean;
	}): MileageRate {
	let mileageRates = getMileageRates(policy, true, transaction?.comment?.customUnit?.customUnitRateID);
	if (isEmptyObject(mileageRates) && policyDraft) {
	mileageRates = getMileageRates(policyDraft, true, transaction?.comment?.customUnit?.customUnitRateID);
	}
	// This will be fixed as part of https://github.com/Expensify/App/issues/66397
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const policyCurrency = policy?.outputCurrency ?? getPersonalPolicy()?.outputCurrency ?? CONST.CURRENCY.USD;
	const defaultMileageRate = getDefaultMileageRate(policy);
	const customUnitRateID = getRateID(transaction);
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const customMileageRate = (customUnitRateID && mileageRates?.[customUnitRateID]) || defaultMileageRate;
	const mileageRate = isCustomUnitRateIDForP2P(transaction) ? getRateForP2P(policyCurrency, transaction) : customMileageRate;
	const unit = getDistanceUnit(useTransactionDistanceUnit ? transaction : undefined, mileageRate);
	return {
	...mileageRate,
	unit,
	currency: mileageRate?.currency ?? policyCurrency,
	};
	}

The transaction only stores a reference (customUnitRateID) to the rate, not the rate value itself. When the admin updates the rate, this lookup returns the new value for every transaction referencing that rate ID.

The distanceUnit is already correctly snapshotted on the transaction at creation time, and getDistanceUnit() prefers the stored value. The same protection was not applied to the rate value:

App/src/libs/DistanceRequestUtils.ts

Lines 361 to 363 in 801ee41

	function getDistanceUnit(transaction: OnyxEntry<Transaction>, mileageRate: OnyxEntry<MileageRate>): Unit {
	return transaction?.comment?.customUnit?.distanceUnit ?? mileageRate?.unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES;
	}

What changes do you think we should make in order to solve the problem?

1. Add rate and currency snapshot fields to TransactionCustomUnit.

src/types/onyx/Transaction.ts

// Add after the distanceUnit field (line 167)
rate?: number;
currency?: string;

2. Snapshot the rate at transaction creation time in buildOptimisticTransaction, following the existing distanceUnit pattern.

App/src/libs/TransactionUtils/index.ts

Lines 515 to 519 in 801ee41

	if (isMapDistanceTransaction || isManualDistanceTransaction || isOdometerDistanceTransaction) {
	// Set the distance unit, which comes from the policy distance unit or the P2P rate data
	lodashSet(commentJSON, 'customUnit.distanceUnit', DistanceRequestUtils.getUpdatedDistanceUnit({transaction: existingTransaction, policy}));
	lodashSet(commentJSON, 'customUnit.quantity', distance);
	}

src/libs/TransactionUtils/index.ts

// Add after lodashSet(commentJSON, 'customUnit.quantity', distance) on line 518
const mileageRate = DistanceRequestUtils.getRate({
  transaction: existingTransaction,
  policy,
});
if (mileageRate?.rate !== undefined) {
  lodashSet(commentJSON, "customUnit.rate", mileageRate.rate);
}
if (mileageRate?.currency) {
  lodashSet(commentJSON, "customUnit.currency", mileageRate.currency);
}

3. In getRate(), prefer the snapshotted rate over the live policy value. This mirrors how getDistanceUnit() prefers transaction.comment.customUnit.distanceUnit over the policy unit.

src/libs/DistanceRequestUtils.ts

// Read snapshot values at the top of getRate()
const snapshottedRate = transaction?.comment?.customUnit?.rate;
const snapshottedCurrency = transaction?.comment?.customUnit?.currency;

// In the return object, prefer snapshot with fallback to live values
return {
  ...mileageRate,
  unit,
  rate: snapshottedRate ?? mileageRate?.rate,
  currency: snapshottedCurrency ?? mileageRate?.currency ?? policyCurrency,
};

4. Add rate to the pendingFields validation object in DebugUtils.ts (required because TransactionCustomUnit keys are included in pendingFields).

Existing transactions created before this fix have no snapshot stored, so the ?? fallback preserves current behavior (live policy lookup). This is the same backward-compatibility pattern used for distanceUnit and defaultP2PRate.

What alternative solutions did you explore? (Optional)

Considered storing the rate snapshot on the backend when the expense is approved/exported, so only finalized expenses would be locked. Rejected because: (a) the frontend already has the snapshotting pattern established for distanceUnit and defaultP2PRate, (b) a backend-only fix would still show incorrect values in the app until synced, and (c) snapshotting at creation time is simpler and consistent with the existing architecture.

---

Files Modified:

• src/types/onyx/Transaction.ts - Added rate and currency fields to TransactionCustomUnit
• src/libs/TransactionUtils/index.ts - Snapshot rate value and currency at transaction creation
• src/libs/DistanceRequestUtils.ts - Prefer snapshotted rate/currency over live policy values in getRate()
• src/libs/DebugUtils.ts - Added rate to pendingFields validation

Testing Performed:

• Reproduced the issue
• Applied the fix
• Verified the fix resolves the issue
• Checked for edge cases