[Due for payment 2026-09-01] [$250] Wallet - Upload CSV "flip amount sign" is not preserved for subsequent uploads

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.48-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
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:
Slack conversation (hyperlinked to channel name):

Action Performed:

Prerequesties: 2 CSV files of bank transactions where all the transactions have a -ve value.

1.Go to Account > Wallet > Import Transactions
2. Set up an import with -ve amounts and a non-USD currency and import with “flip negative sign"
3. Import a second file using the same mapping that you used in the first
4. Then, go to the same upload on the wallet, and click into it. Note there is no Flip amount sign
5. Check mapping and upload

Expected Result:

Additional transactions are all positive.

Actual Result:

Additional transactions are all negative.

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

Recording.3917.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022084588447521223436
• Upwork Job ID: 2084588447521223436
• Last Price Increase: 2026-08-04

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

Root Cause

When you re-import a second CSV to an existing personal card, the flipAmountSign setting from the first import is never restored, so amounts are imported with their raw (negative) sign.

The re-import path is different from the first import:

• First import goes through ImportTransactionsPage, which shows the Flip amount sign toggle and saves it via setImportTransactionSettings(...) into IMPORTED_SPREADSHEET.importTransactionSettings.
• Subsequent imports to an existing card navigate directly to the spreadsheet/columns step (PersonalCardDetailsHeaderMenu.tsx:122, WalletPage/index.tsx:647), bypassing that toggle. That's why there is no "Flip amount sign" option on the second upload.

On that re-import path, the saved layout is re-applied by applySavedColumnMappings — but it only restores the column → role mappings (columnMapping.names). It does not restore flipAmountSign, even though the saved layout stores it (SavedCSVColumnLayout.ts:66, written at ImportTransactions.ts:110).

As a result, when the import runs, importTransactionsFromCSV falls back to its default flipAmountSign = false, so the sign-flip step is skipped and the new transactions stay negative.

Solution

When applying the saved layout on the re-import path, also restore the saved import settings into IMPORTED_SPREADSHEET.importTransactionSettings — at minimum flipAmountSign, and ideally reimbursable too (both are stored on the saved layout), so the second import matches the first.

Concretely, in TransactionsImportedPage's effect (or inside applySavedColumnMappings), after loading savedLayout, merge its settings back:

Onyx.merge(ONYXKEYS.IMPORTED_SPREADSHEET, {
    importTransactionSettings: {
        flipAmountSign: savedLayout.flipAmountSign,
        isReimbursable: savedLayout.reimbursable,
    },
});

This makes importTransactionsFromCSV read the correct flipAmountSign from settings and flip the sign as it did on the first import.

Evidence chain & notes

1. Saved layout stores the flag: buildColumnLayout sets flipAmountSign (ImportTransactions.ts:73-124) and it's persisted to NVP_SAVED_CSV_COLUMN_LAYOUT_LIST.
2. The only writer of importTransactionSettings.flipAmountSign is setImportTransactionSettings, called only from ImportTransactionsPage.handleNext — which the existing-card re-import never visits.
3. applySavedColumnMappings restores only columnMapping.names, silently dropping flipAmountSign/reimbursable.
4. importTransactionsFromCSV defaults flipAmountSign = false when settings are empty, so the flip is skipped.

Related gap: currency and cardDisplayName are likewise not restored on re-import (they default to USD/Imported Card). For an existing card the backend keys off existingCardID, so this is less visible, but the optimistic transactions use the defaulted currency. Worth restoring these from savedLayout.accountDetails in the same change for consistency.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97779) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[mkhutornyi]

I'd like to see if we can get better proposals than Melvin.

🆘 C+ Help Wanted

[oqildev]

Proposal

What is the root cause of that problem?

Two different code paths reach the CSV column-mapping step, and only one of them ever records flipAmountSign.

First import (new card) goes through ImportTransactionsPage, which renders the Flip amount sign toggle and, on Next, persists it via setImportTransactionSettings(...) into IMPORTED_SPREADSHEET.importTransactionSettings:

• toggle + handleNext → ImportTransactionsPage.tsx#L43-L52, toggle at #L90-L97
• the only writer of importTransactionSettings.flipAmountSign → ImportSpreadsheet.ts#L154-L163

Re-import to an existing card navigates straight to the spreadsheet/columns step with a cardID, skipping ImportTransactionsPage entirely — PersonalCardDetailsHeaderMenu.tsx#L122 and WalletPage/index.tsx#L647. That's exactly why step 4 in the repro shows no "Flip amount sign" option — the page that owns that toggle is never visited.

Because the toggle page is skipped, nothing repopulates the settings. The prior import already wiped them: closeImportPage sets importTransactionSettings: null (ImportSpreadsheet.ts#L72-L82), and on re-upload setSpreadsheetData is handed importedSpreadsheet?.importTransactionSettings, which is now empty (components/ImportSpreadsheet.tsx#L146-L153).

On the columns page, TransactionsImportedPage does re-apply the saved layout for the card — but only the column→role mapping. Its effect calls applySavedColumnMappings (TransactionsImportedPage.tsx#L48-L70), and that function restores columnMapping.names and nothing else (ImportSpreadsheet.ts#L172-L203) — even though the saved layout stores flipAmountSign, reimbursable, and accountDetails.currency (SavedCSVColumnLayout.ts#L65-L69, currency at #L38-L39, written by buildColumnLayout at ImportTransactions.ts#L110).

So when the import runs, importTransactionsFromCSV reads settings = spreadsheet.importTransactionSettings ?? {} and destructures flipAmountSign = false (ImportTransactions.ts#L256-L257). The sign-flip step is gated on that flag (ImportTransactions.ts#L169-L172), so it's skipped and the new transactions keep their raw negative sign — the actual-result symptom.

Same mechanism also silently drops currency (back to USD) and reimbursable on re-import, since all three live only in importTransactionSettings, which nothing restores.

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

Fix layer: data/state restore, at the same point we already restore the saved layout on re-import.

In TransactionsImportedPage's effect (or inside applySavedColumnMappings, which already receives the full savedLayout), when a saved layout exists for existingCardID, also merge the saved settings back into IMPORTED_SPREADSHEET.importTransactionSettings, mapping:

• flipAmountSign ← savedLayout.flipAmountSign
• isReimbursable ← savedLayout.reimbursable
• currency ← savedLayout.accountDetails.currency
• cardDisplayName ← savedLayout.name

This mirrors exactly what the first-import flow does before it ever reaches the columns page, and leaves importTransactionsFromCSV as a single, path-agnostic consumer of importTransactionSettings — so the flip step fires, and the optimistic transactions get the right currency/reimbursable too. The effect already runs when the spreadsheet data loads, well before the user taps Import, so the merge has resolved by then.

I'd keep the write scoped to the re-import branch (guarded on existingCardID + savedLayout) so the first-import path is untouched.

What alternative solutions did you explore? (Optional)

Fall back to previouslySavedLayout inside importTransactionsFromCSV. The function already receives it (ImportTransactions.ts#L254), so when settings is empty we could source flipAmountSign/reimbursable/currency/name from it. It works, but I don't love it: the source of import settings would then depend on the path (settings-object for new cards, saved-layout for existing cards), and any UI on the re-import path that reads importTransactionSettings would still see empty state. Rejected in favor of restoring the state once, consistently, the same way the first import does.

Show the settings page (with the toggle) on the re-import path too. This would surface the flip toggle again, but it's a UX change beyond the reported bug, and it wouldn't fix the case where the user just re-uploads with the same mapping (the whole point of the saved layout). The saved value should carry over automatically.

[dilshodmackbook-sketch]

Note — I don't believe this should have been withdrawn as a duplicate. The two proposals mine overlaps with (from oqildev and Abdulloh0109) were both submitted at 17:57:57 UTC — the exact same second the Help Wanted label was applied to this issue, i.e. before it was formally opened to contributors. Mine was submitted at 17:57:58, making it the first proposal posted after Help Wanted. Since proposals made before an issue is opened for Help Wanted aren't part of the contributor queue, I'd kindly ask @mkhutornyi to reconsider the auto-withdrawal here. Restoring the full proposal below.

Proposal

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

When a user imports a second CSV into an existing personal (CSV) card, the “Flip amount sign” option they enabled on the first import is not preserved, so the new transactions are imported with their raw (negative) sign instead of being flipped positive.

What is the root cause of that problem?

The first import and the re-import take two different UI paths:

• First import goes through ImportTransactionsPage, which shows the Flip amount sign toggle and persists the choice into IMPORTED_SPREADSHEET.importTransactionSettings via setImportTransactionSettings.
• Re-import to an existing card navigates straight to the file picker (ImportTransactionsSpreadsheetPage → ImportSpreadsheet) with a cardID, skipping that page entirely — which is why there’s no Flip amount sign option on the second upload.

On the re-import path setSpreadsheetData is called without importTransactionSettings, so IMPORTED_SPREADSHEET.importTransactionSettings is undefined:

App/src/pages/settings/Wallet/ImportTransactionsSpreadsheetPage.tsx

Lines 13 to 23 in 1a78a43

	function ImportTransactionsSpreadsheetPage({route}: ImportTransactionsSpreadsheetPageProps) {
	const {cardID} = route.params ?? {};
	const backTo = cardID ? undefined : ROUTES.SETTINGS_WALLET_IMPORT_TRANSACTIONS;
	return (
	<ImportSpreadsheet
	backTo={backTo}
	goTo={ROUTES.SETTINGS_WALLET_TRANSACTIONS_IMPORTED.getRoute(cardID ? Number(cardID) : undefined)}
	/>
	);
	}

The saved layout for that card does store flipAmountSign (and reimbursable, currency, card name) — buildColumnLayout writes it and it’s persisted to NVP_SAVED_CSV_COLUMN_LAYOUT_LIST:

App/src/libs/actions/ImportTransactions.ts

Lines 107 to 124 in 1a78a43

	return {
	name: cardName,
	useTypeColumn: false,
	flipAmountSign,
	reimbursable: isReimbursable,
	offset: 0,
	dateFormat: null,
	accountDetails: {
	bank: CONST.PERSONAL_CARDS.BANK_NAME.CSV,
	currency,
	accountID: cardName,
	},
	columnMapping: {
	names,
	indexes,
	},
	};
	}

That saved layout is even already passed into importTransactionsFromCSV as previouslySavedLayout:

App/src/pages/settings/Wallet/TransactionsImportedPage.tsx

Lines 124 to 126 in 1a78a43

	const cardIDNumber = existingCardID ? Number(existingCardID) : undefined;
	const previouslySavedLayout = cardIDNumber && savedColumnLayouts ? savedColumnLayouts[String(cardIDNumber)] : undefined;
	const importFinalModal = await importTransactionsFromCSV(spreadsheet, accountID, cardIDNumber, previouslySavedLayout);

…but it is only used to roll back on failure. When building the transactions, the function reads settings solely from the spreadsheet, which on this path is empty — so flipAmountSign falls back to false and the sign-flip step is skipped:

App/src/libs/actions/ImportTransactions.ts

Lines 256 to 260 in 1a78a43

	const settings = spreadsheet.importTransactionSettings ?? {};
	const {cardDisplayName = 'Imported Card', currency = CONST.CURRENCY.USD, isReimbursable = true, flipAmountSign = false} = settings;
	// Build transaction list from spreadsheet
	const transactionList = buildTransactionListFromSpreadsheet(spreadsheet, settings);

App/src/libs/actions/ImportTransactions.ts

Lines 169 to 172 in 1a78a43

	// Flip sign if needed
	if (flipAmountSign) {
	parsedAmount *= -1;
	}

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

We already have the previous card’s configuration available as previouslySavedLayout inside importTransactionsFromCSV. When re-importing (i.e. previouslySavedLayout exists), seed the settings from it before falling back to defaults, letting any explicit spreadsheet settings still take precedence:

const savedSettings: ImportTransactionSettings = previouslySavedLayout
    ? {
          cardDisplayName: previouslySavedLayout.name,
          currency: previouslySavedLayout.accountDetails?.currency,
          isReimbursable: previouslySavedLayout.reimbursable,
          flipAmountSign: previouslySavedLayout.flipAmountSign,
      }
    : {};
const settings = {...savedSettings, ...spreadsheet.importTransactionSettings};
const {cardDisplayName = 'Imported Card', currency = CONST.CURRENCY.USD, isReimbursable = true, flipAmountSign = false} = settings;

Because settings is what buildTransactionListFromSpreadsheet and buildColumnLayout already consume, this restores flipAmountSign (fixing the reported bug) and also keeps currency, reimbursable, and the card name consistent with the first import. It additionally prevents buildColumnLayout from re-saving the layout with the wrong false/USD defaults on this same run. The first-import path is unaffected since previouslySavedLayout is undefined there.

What specific scenarios should we cover in automated tests to prevent this from happening again?

Unit-test importTransactionsFromCSV with an existingCardID and a previouslySavedLayout whose flipAmountSign is true, while spreadsheet.importTransactionSettings is empty:

• assert the optimistic transactions have their sign flipped (negative input → positive amount);
• assert the restored currency/reimbursable from the saved layout are used;
• and a control case with flipAmountSign: false where amounts keep their original sign.

What alternative solutions did you explore? (Optional)

Re-hydrate IMPORTED_SPREADSHEET.importTransactionSettings on the re-import path — e.g. Onyx.merge the saved layout’s settings back into state inside TransactionsImportedPage’s effect (or applySavedColumnMappings) after loading savedLayout. That also works, but it adds an extra Onyx write and re-render to restore state that is already threaded through to the import call, so fixing it at the point of use in importTransactionsFromCSV is more localized.

[ahmdshrif]

Note — I don't believe this should have been withdrawn as a duplicate.

Proposal

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

When I upload a second CSV to a personal card I already imported into, the "Flip amount sign" setting from the first upload is not applied — the new transactions come in negative. The second-upload screen never shows the toggle, so I can't set it again either.

What is the root cause of that problem?

The saved layout is the durable record of an import's configuration and it does store the flag (SavedCSVColumnLayout.ts#L62-L69). The structural bug: the "import into an existing card" flow restores exactly one field of that layout — the column mapping — and falls back to hard-coded defaults for every other field.

1. A repeat upload jumps straight to the file picker with a cardID, so backTo is undefined and ImportTransactionsPage — the only writer of importTransactionSettings (ImportTransactionsPage.tsx#L43-L52) — is never mounted: ImportTransactionsSpreadsheetPage.tsx#L14-L20. That is why there is no toggle (repro step 4).
2. The previous import already cleared the settings — closeImportPage() sets importTransactionSettings: null on unmount (ImportSpreadsheet.ts#L72-L81) — so the picker forwards undefined into the fresh Onyx.set (ImportSpreadsheet.tsx#L146-L153).
3. The restore step reads the saved layout but writes back only columns; flipAmountSign, reimbursable, accountDetails.currency and name are dropped: ImportSpreadsheet.ts#L172-L203, called from TransactionsImportedPage.tsx#L59-L70.
4. At import time the destructure supplies the defaults — flipAmountSign = false, currency = USD, isReimbursable = true, cardDisplayName = 'Imported Card' (ImportTransactions.ts#L256-L257). With the flag false the * -1 at L169-L172 never runs → amounts stay negative.

Every affected path takes those same defaults, so this is wider than the sign:

• Both repeat-upload entry points pass a cardID and skip the settings screen: the Wallet card row (WalletPage/index.tsx#L643-L649) and the card-details header menu (PersonalCardDetailsHeaderMenu.tsx#L118-L124).
• The default USD/isReimbursable also reach buildOptimisticTransactions and the API params (cardName: 'Imported Card', currency: 'USD') at ImportTransactions.ts#L283-L294 — the issue's non-USD prerequisite is not incidental.
• It is self-perpetuating: the rebuilt layout is written back with a null-then-set merge, i.e. a full replace (L336-L347). Upload Fix spaces #2 therefore destroys the stored flipAmountSign: true, currency and card name — exactly the title's "not preserved for subsequent uploads".

This is a gap in #95183 ("Use stored mappings for columns in CSV card import"), which added the restore for columns only. Nothing needs reverting — the restore just has to cover the rest of the layout.

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

Restore the whole saved layout at the single convergence point that already holds it — applySavedColumnMappings (ImportSpreadsheet.ts#L172) — above the !columnMapping?.names early return, so a layout with no usable names still restores settings:

Onyx.merge(ONYXKEYS.IMPORTED_SPREADSHEET, {
    importTransactionSettings: {
        cardDisplayName: savedLayout.name,
        currency: savedLayout.accountDetails?.currency,
        isReimbursable: savedLayout.reimbursable,
        flipAmountSign: savedLayout.flipAmountSign,
    },
});

Every consumer reads importTransactionSettings, so all of them inherit it at once: the sign flip, the optimistic transactions' currency/reimbursable, the API params, and the layout written back — which makes the round-trip stable for upload #3 and beyond. I'd add a case to the existing applySavedColumnMappings suite in tests/unit/ImportTransactions.test.ts.

Regression safety: this function has exactly one caller and it is guarded by if (!existingCardID) return, so the new-card flow (which writes these settings itself) is untouched, and the sibling applyCompanyCardSavedColumnMappings is unchanged.

Why the obvious spot-fixes fail. (a) Reading flipAmountSign straight from the layout inside importTransactionsFromCSV fixes only the sign: the still-missing settings object keeps feeding currency, reimbursable and cardName into buildColumnLayout at L286, so upload #2 still overwrites the stored layout with 'Imported Card'/USD and the next upload breaks again. (b) Making closeImportPage stop nulling importTransactionSettings looks like a one-liner but is wrong — ONYXKEYS.IMPORTED_SPREADSHEET is one global key, so card A's flip/currency/name would leak into a later import for card B, and it is still empty on a fresh device or after a cache clear. The per-card saved layout is the only correct source.

What alternative solutions did you explore? (Optional)

1. Show the toggle on TransactionsImportedPage for repeat uploads. Good follow-up so the setting stays visible, but it doesn't fix this: the toggle still initialises to false unless seeded from the layout, so nothing is preserved and every repeat upload becomes manual.
2. Route repeat uploads back through ImportTransactionsPage pre-filled from the layout. Correct data-wise, but it re-adds a screen to a deliberately shortened flow and still needs the same layout→settings mapping above.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-08-05 12:14:16 UTC.

Proposal

What is the root cause of that problem?

importTransactionsFromCSV treats "no import settings in Onyx" as "the user chose the defaults", when on the existing-card path it actually means "the user was never asked".

The settings page is the only writer of importTransactionSettings, and it is only reached when a card is being created:

App/src/pages/settings/Wallet/ImportTransactionsPage.tsx

Lines 43 to 52 in 0a0e504

	const handleNext = useCallback(() => {
	if (!cardDisplayName) {
	setShouldShowError(true);
	return;
	}
	// Store import settings in Onyx so they're available when importing
	setImportTransactionSettings(cardDisplayName, currency, isReimbursable, flipAmountSign);
	// No cardID = creating a new card
	Navigation.navigate(ROUTES.SETTINGS_WALLET_IMPORT_TRANSACTIONS_SPREADSHEET.getRoute());
	}, [cardDisplayName, currency, isReimbursable, flipAmountSign]);

Uploading to a card that already exists navigates straight to the file picker with the cardID, so that page is skipped entirely — which is exactly why step 4 of the repro reports no Flip amount sign option:

App/src/pages/settings/Wallet/PersonalCardDetailsHeaderMenu.tsx

Lines 118 to 124 in 0a0e504

	{isCSVImportedPersonalCard && (
	<MenuItem
	icon={icons.Table}
	title={translate('spreadsheet.importSpreadsheet')}
	onPress={() => Navigation.navigate(ROUTES.SETTINGS_WALLET_IMPORT_TRANSACTIONS_SPREADSHEET.getRoute(Number(cardID)))}
	/>
	)}

The settings from the first upload are gone by then — closeImportPage nulls importTransactionSettings after every import — and the restore step on the mapping page rebuilds only the column→role map, never the settings that live on the same saved layout:

App/src/libs/actions/ImportSpreadsheet.ts

Lines 200 to 202 in 0a0e504

	if (Object.keys(columnUpdates).length > 0) {
	Onyx.merge(ONYXKEYS.IMPORTED_SPREADSHEET, {columns: columnUpdates});
	}

So the import destructures the hard defaults, and the sign flip is skipped:

App/src/libs/actions/ImportTransactions.ts

Lines 256 to 257 in 0a0e504

	const settings = spreadsheet.importTransactionSettings ?? {};
	const {cardDisplayName = 'Imported Card', currency = CONST.CURRENCY.USD, isReimbursable = true, flipAmountSign = false} = settings;

The reporter's video shows this is not only about the sign. At t=29.98 the first batch reads €45.00, €89.30, €560.99 and the second batch reads -$28.40, -$15.00, -$12.80 — negative and USD, because currency is defaulted by that same line. The damage then compounds: those defaulted values are fed to buildColumnLayout and written back over the card's saved layout, so the saved flipAmountSign and currency are destroyed for every future upload too:

App/src/libs/actions/ImportTransactions.ts

Lines 343 to 347 in 0a0e504

	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.NVP_SAVED_CSV_COLUMN_LAYOUT_LIST,
	value: {[cardID]: columnLayout},
	});

The giveaway that this is the root and not a missing-restore symptom: the function is already handed the card's persisted configuration as previouslySavedLayout, but uses it only to roll back after a failure. PR #81885 introduced this path to pre-map columns and never covered the settings, so nothing intentional is being undone here.

In short: the importer resolves its settings from ephemeral per-upload state only, and silently reads its absence as a deliberate choice of defaults on the one path where the user is never shown the settings.

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

Resolve the settings per field in importTransactionsFromCSV, before they are used, instead of destructuring one object. Each field falls back from the explicit per-upload setting to the value the card already owns, and only then to today's default — settings.flipAmountSign ?? previouslySavedLayout?.flipAmountSign ?? false, and the same shape for currency from previouslySavedLayout?.accountDetails?.currency. ?? rather than || matters: a deliberate false from the settings page must not fall through.

The fix belongs at ImportTransactions.ts#L256-L260 and the resolved object must be passed to buildTransactionListFromSpreadsheet in place of the raw settings. That single point is enough: the function has exactly one caller, and both re-import entry points (card details and the wallet menu) funnel through it, so the amounts, the API params and the re-saved layout are all corrected at once.

The other two fields must not come from the saved layout. cardDisplayName and isReimbursable are still editable on the card after the first import — the reimbursable switch writes to the card through its own command, and the on-screen copy promises it governs imports ("When enabled, transactions imported from this card are marked as reimbursable by default"):

App/src/pages/settings/Wallet/PersonalCardDetailsHeaderMenu.tsx

Lines 84 to 95 in 0a0e504

	<ToggleSettingOptionRow
	title={translate('cardPage.markTransactionsAsReimbursable')}
	subtitle={translate('cardPage.markTransactionsDescription')}
	shouldPlaceSubtitleBelowSwitch
	switchAccessibilityLabel={translate('cardPage.markTransactionsAsReimbursable')}
	isActive={reimbursableSetting}
	onToggle={(isOn) => card && setPersonalCardReimbursable(card.cardID, isOn, reimbursableSetting)}
	pendingAction={card?.pendingFields?.reimbursable}
	errors={card?.errorFields?.reimbursable ?? undefined}
	onCloseError={() => card && clearCardErrorField(card.cardID, 'reimbursable')}
	wrapperStyle={[styles.ph5, styles.mb3]}
	/>

Sourcing those from the layout snapshot would make a re-import silently revert a rename or a toggle the user changed afterwards. They should resolve from the current card instead (existingCard?.reimbursable, existingCard?.nameValuePairs?.cardTitle), which the caller already has in Onyx and can pass in alongside previouslySavedLayout. Currency and the flip rule have no such live source, so the layout is correct for those two.

New-card imports are untouched: previouslySavedLayout and the card are both undefined there, and the settings page always writes all four fields, so no fallback is ever consulted.

Tests, in tests/unit/ImportTransactions.test.ts next to the existing importTransactionsFromCSV cases: an existing card with no spreadsheet settings and a saved layout of {flipAmountSign: true, currency: 'EUR'} over negative amounts must produce positive amounts, currency: 'EUR', and a re-saved layout that still carries flipAmountSign: true; and a card renamed with reimbursable turned off after the first import must win over the layout's stale name and flag. Both are in the branch below. Offline is unaffected — the optimistic transactions now carry the same currency and reimbursable value the request sends, so nothing snaps back on reconnect. Verified on web; the change is platform-agnostic action code.

I have not verified whether Auth honours cardName/currency for an existing card or re-derives them; the client-side effects above hold either way.

Compare branch: https://github.com/Expensify/App/compare/main...yusufdeveloper2903:App:yusuf/97779-import-settings?expand=1

What alternative solutions did you explore? (Optional)

Merging the saved settings into IMPORTED_SPREADSHEET from the effect that already applies the saved column mappings. It works, but it puts per-card settings into a global key that is only cleared on a successful import, so abandoning a re-import leaves them behind to seed the next new-card setup — and it fixes only the restore, leaving the importer still free to default when nothing restored them.