[$250] Error displayed when importing card transactions via CSV

[m-natarajan]

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.15-3
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: @scerrato88
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to Workspace > Company Cards.
2. Click Add Card.
3. Select a bank/card feed option.
4. Click Import transactions from file.
5. Upload a CSV file containing card transactions.
6. Map all required columns correctly. (The CSV columns were mapped correctly during the import flow.)
7. Complete the import process.

Expected Result:

The CSV should be imported successfully, or the system should provide a specific validation message identifying any issues with the file or mapped fields.

Actual Result:

The import fails and displays the generic error:
"Please ensure all fields are filled out correctly and try again. If the problem persists, please reach out to Concierge."

No additional information is provided about which field, row, or column is causing the failure.

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 screenshot for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022069053620673593010
• Upwork Job ID: 2069053620673593010
• Last Price Increase: 2026-07-06

Issue Owner

Current Issue Owner: @blimpich

[MelvinBot]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-08 22:23:46 UTC.

Proposal

Updated 2026-07-08: Corrected based on blimpich's production-log analysis in this comment. My original proposal assumed the rejection was data-specific and required a backend fix. That was wrong: the root cause is an App-side type bug and is fully fixable here.

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

CSV company-card transaction imports fail with a generic, non-actionable error ("Please ensure all fields are filled out correctly and try again…"). The failure has nothing to do with the CSV file's contents — the request is rejected before any row is parsed.

What is the root cause of that problem?

The frontend sends instanceID as a JSON number when it should be a string, and the backend rejects any non-string instanceID before parsing the file.

This only happens when re-importing into a pre-existing feed:

1. The settings-page flow seeds existingInstanceID from the stored feed settings: WorkspaceCompanyCardsSettingsPage.tsx:208 — existingInstanceID: selectedFeedData?.uploadLayoutSettings?.instanceID ?? null.
2. For legacy feeds, that stored instanceID is a number at runtime. The type says string (CompanyCards.ts:75), but Onyx/NVP is an untyped boundary, so the real value can be numeric.
3. ?? only substitutes on null/undefined, so a number passes straight through: CompanyCards.ts:1161 — const instanceID = existingInstanceID ?? Date.now().toString();.
4. JSON.stringify then emits it as a bare number in the request settings payload ("instanceID":1745351414130 instead of "instanceID":"1745351414130").
5. The backend reads instanceID with a string-only accessor, treats the numeric value as empty, and rejects the request as missing a required field — before any CSV row is parsed. blimpich confirmed this against production logs: all 6 of the affected account's attempts in one ~40-minute window threw the same synchronous rejection, and the downstream upload/scraper command was never reached.

Why it's not reproducible on test accounts: the Add New Card wizard has no existingInstanceID, so it falls back to Date.now().toString() — a genuine string the backend accepts. A clean test account always has a freshly-created (string) instanceID, so only legacy feeds with a stored numeric instanceID hit this. This matches the "Unable to reproduce" result and the fact that changing the CSV date format made no difference.

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

Primary fix (App, resolves this report): coerce instanceID to a string before it is sent. Narrowest change, at CompanyCards.ts:1161:

const instanceID = existingInstanceID ? String(existingInstanceID) : Date.now().toString();

This fixes every affected legacy feed with no data migration.

Secondary fix (App, real but not the cause here): the failure path always renders the hardcoded generic modal and discards the backend's actual error — failureData uses getImportFailedFinalModal() at CompanyCards.ts:1209 and the .catch returns the same static modal at CompanyCards.ts:1251-1256. This is why the user only ever saw the generic text. Surfacing the backend's real message would help future rejections, but on its own it would not have prevented this failure.

Optional backend hardening (outside App — escalate if desired): the backend silently treating a non-string instanceID as empty is permissive; it could be hardened to accept a numeric instanceID. The frontend coercion alone resolves the reported bug, so this is defense-in-depth only.

What changed from my original proposal & related issue

Corrected assumptions:

• My original proposal pointed at ImportTransactions.ts / the IMPORT_CSV_TRANSACTIONS command. The actual re-import path is CompanyCards.ts (IMPORT_CSV_COMPANY_CARDS).
• I originally concluded the real cause was server-side and required a backend engineer to escalate. Production logs show the rejection is caused by the App sending the wrong type — an App-side, one-line fix.
• Proposals citing bad CSV data, missing row-level validation, or date-format handling are not relevant: the request fails before any row is parsed.

Related issue: #93704 ("CSV card feed import succeeds but no cards are created — no validation for missing required fields") is a different failure mode (import succeeds, no cards created) and is not the same root cause as this one, though both touch the CSV card-import flow.

Still to confirm (does not change the fix): why legacy feeds store a numeric instanceID in the first place — most likely feeds created via an older upload path that wrote a raw numeric timestamp. Worth checking to estimate how many customers are affected.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94178) to create a draft PR (covers the App-side coercion fix; secondary modal fix can be included).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-22 13:55:12 UTC.

Proposal

What is the root cause of that problem?

The company‑card CSV importer does no row‑level validation of the file content and collapses every backend rejection into one hardcoded generic modal, so a file whose columns were mapped correctly but whose data the backend can't accept always surfaces the same useless message with no row/column detail.

Trace the chain:

1. The page only validates that the required columns are mapped and not duplicated — it never looks at the actual cell data:
   

   App/src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx

   Lines 81 to 100 in 2b78b56

   	const validate = () => {
   	const columns = Object.values(spreadsheet?.columns ?? {});
   	let errors: Errors = {};
   	const missingRequiredColumns = requiredColumns
   	.filter((requiredColumn) => !columns.includes(requiredColumn.value))
   	.map((requiredColumn) => requiredColumn.text)
   	.join(', ');
   	if (missingRequiredColumns) {
   	errors.required = translate('workspace.companyCards.addNewCard.csvErrors.requiredColumns', missingRequiredColumns);
   	} else {
   	const duplicate = findDuplicate(columns);
   	if (duplicate) {
   	errors.duplicates = translate('workspace.companyCards.addNewCard.csvErrors.duplicateColumns', duplicate);
   	} else {
   	errors = {};
   	}
   	}
   	return errors;
   	};

2. It then hands the raw rows to importCSVCompanyCards unconditionally:
   

   App/src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx

   Lines 138 to 149 in 2b78b56

   	setIsImportingTransactions(true);
   	const importFinalModal = await importCSVCompanyCards({
   	policyID,
   	workspaceAccountID,
   	layoutName,
   	layoutType,
   	columnMappings,
   	csvData: rows,
   	lastSelectedFeed: lastSelectedFeed ?? undefined,
   	workspaceCardFeeds,
   	existingInstanceID: addNewCard?.data?.existingInstanceID,
   	});

3. importCSVCompanyCards computes transactionsCount but never guards on it — it always fires the API, even when zero valid rows were produced, and stamps the single generic getImportFailedFinalModal() into failureData (and again in .catch):
   

   App/src/libs/actions/CompanyCards.ts

   Lines 1146 to 1176 in 2b78b56

   	const transactionsCount = transactions.length;
   	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER | typeof ONYXKEYS.COLLECTION.LAST_SELECTED_FEED>> = [
   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.LAST_SELECTED_FEED}${policyID}`,
   	value: feedNameWithDomainID as CompanyCardFeedWithDomainID,
   	},
   	];
   	const importFinalModal: ImportFinalModal = {
   	titleKey: 'spreadsheet.importSuccessfulTitle',
   	promptKey: 'spreadsheet.importCompanyCardTransactionsSuccessfulDescription',
   	promptKeyParams: {
   	transactions: transactionsCount,
   	},
   	pendingMessageKey: 'spreadsheet.importCompanyCardTransactionsPendingMessage',
   	};
   	const importFinalModalID = getImportFinalModalID();
   	const importFinalModalResult = waitForImportFinalModal(importFinalModalID);
   	const successData: Array<OnyxUpdate<typeof ONYXKEYS.IMPORTED_SPREADSHEET>> = [getImportFinalModalOnyxData(importFinalModalID, importFinalModal)];
   	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER | typeof ONYXKEYS.COLLECTION.LAST_SELECTED_FEED | typeof ONYXKEYS.IMPORTED_SPREADSHEET>> =
   	[
   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.LAST_SELECTED_FEED}${policyID}`,
   	value: lastSelectedFeed ?? null,
   	},
   	getImportFinalModalOnyxData(importFinalModalID, getImportFailedFinalModal()),
   	];

   
   

   App/src/libs/actions/CompanyCards.ts

   Lines 1217 to 1222 in 2b78b56

   	return API.write(WRITE_COMMANDS.IMPORT_CSV_COMPANY_CARDS, parameters, {optimisticData, successData, failureData})
   	.then(() => importFinalModalResult.promise)
   	.catch(() => {
   	importFinalModalResult.cancel();
   	return getImportFailedFinalModal();
   	});

4. That generic modal is the exact "Please ensure all fields are filled out correctly… reach out to Concierge." string the reporter saw:
   

   App/src/libs/actions/ImportSpreadsheet.ts

   Lines 82 to 87 in 2b78b56

   	function getImportFailedFinalModal(): ImportFinalModal {
   	return {
   	titleKey: 'spreadsheet.importFailedTitle',
   	promptKey: 'spreadsheet.importFailedDescription',
   	};
   	}

   
   

   App/src/languages/en.ts

   Lines 1198 to 1199 in 2b78b56

   	importFailedTitle: 'Import failed',
   	importFailedDescription: 'Please ensure all fields are filled out correctly and try again. If the problem persists, please reach out to Concierge.',

Now contrast with the sibling personal‑card importer (ImportTransactions.ts), which handles exactly this flow and has two guards the company‑card path is missing:

• Empty‑result guard — if no valid rows survive parsing it returns a specific invalidFileMessage instead of calling the API:
  

  App/src/libs/actions/ImportTransactions.ts

  Lines 256 to 263 in 2b78b56

  	const transactionList = buildTransactionListFromSpreadsheet(spreadsheet, settings);
  	if (transactionList.length === 0) {
  	return {
  	titleKey: 'spreadsheet.importFailedTitle',
  	promptKey: 'spreadsheet.invalidFileMessage',
  	};
  	}

• Date normalization — every date is normalized to yyyy-MM-dd via parseCSVDate, and rows with unparseable dates are skipped:
  

  App/src/libs/actions/ImportTransactions.ts

  Lines 154 to 160 in 2b78b56

  	// Parse the date using our multi-format parser
  	const parsedDate = parseCSVDate(dateValue);
  	// Skip rows with invalid dates
  	if (!parsedDate) {
  	continue;
  	}

The company‑card builder does neither. It sends the date raw (row.at(postedDateColumnIndex)?.trim()), and the raw csvDataWithGeneratedIDs is what gets serialized to the backend:

App/src/libs/actions/CompanyCards.ts

Lines 116 to 153 in 2b78b56

	const transactions: OptimisticCompanyCardCSVTransaction[] = [];
	for (const row of csvDataWithGeneratedIDs) {
	const transactionID = rand64();
	row[externalIDColumnIndex] = transactionID;
	const cardName = row.at(cardNumberColumnIndex)?.trim();
	const created = row.at(postedDateColumnIndex)?.trim();
	const merchant = row.at(merchantColumnIndex)?.trim() ?? '';
	const currency = row.at(currencyColumnIndex)?.trim();
	const amountValue = row.at(amountColumnIndex) ?? '';
	const amount = parseCSVAmount(amountValue);
	if (!cardName || !created || !currency || amount === undefined) {
	continue;
	}
	const category = categoryColumnIndex >= 0 ? (row.at(categoryColumnIndex)?.trim() ?? '') : '';
	const tag = tagColumnIndex >= 0 ? (row.at(tagColumnIndex)?.trim() ?? '') : '';
	const comment = commentColumnIndex >= 0 ? (row.at(commentColumnIndex)?.trim() ?? '') : '';
	transactions.push({
	transactionID,
	amount,
	created,
	currency,
	merchant,
	category,
	tag,
	comment: {comment},
	cardName,
	bank: feedName,
	reportID: '0',
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	});
	}
	return {csvDataWithGeneratedIDs, normalizedColumnMappings, transactions};
	}

App/src/libs/actions/CompanyCards.ts

Lines 1126 to 1138 in 2b78b56

	const {csvDataWithGeneratedIDs, normalizedColumnMappings, transactions} = buildOptimisticCompanyCardCSVTransactions(csvData, columnMappings, feedName);
	const instanceID = existingInstanceID ?? Date.now().toString();
	const parameters: ImportCSVCompanyCardsParams = {
	policyID,
	settings: JSON.stringify({
	columnMappings: normalizedColumnMappings,
	instanceID,
	layoutName,
	layoutType,
	}),
	csvData: JSON.stringify(csvDataWithGeneratedIDs),
	};

So: a correctly‑mapped file whose date column uses a format the backend doesn't accept (e.g. dd/MM/yyyy, Nov 2, 2025, an Excel serial), or a file where every required cell is blank/un‑parseable, sails past the column‑only validate(), hits the API with un‑normalized data, the backend bounces it, and failureData paints the one generic message — with no indication of which field/row/column failed. That matches "columns were mapped correctly during import, yet import fails with the generic error and no specifics" exactly.

So: column‑only validate() → no empty/date guard in importCSVCompanyCards → raw data sent → backend rejects → single hardcoded getImportFailedFinalModal() → user sees the generic, detail‑free error.

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

Bring the company‑card importer to parity with the personal‑card importer by reusing the patterns already in ImportTransactions.ts — no new infrastructure needed.

1. Normalize dates in the builder. In buildOptimisticCompanyCardCSVTransactions, run the posted date through the existing parseCSVDate (already exported from @libs/CSVDateUtils, used by the personal flow) and write the normalized value back into the row that gets serialized, skipping rows whose date can't be parsed — mirroring

   App/src/libs/actions/ImportTransactions.ts

   Lines 154 to 160 in 2b78b56

   	// Parse the date using our multi-format parser
   	const parsedDate = parseCSVDate(dateValue);
   	// Skip rows with invalid dates
   	if (!parsedDate) {
   	continue;
   	}

   . Apply it to the created value at

   App/src/libs/actions/CompanyCards.ts

   Lines 121 to 130 in 2b78b56

   	const cardName = row.at(cardNumberColumnIndex)?.trim();
   	const created = row.at(postedDateColumnIndex)?.trim();
   	const merchant = row.at(merchantColumnIndex)?.trim() ?? '';
   	const currency = row.at(currencyColumnIndex)?.trim();
   	const amountValue = row.at(amountColumnIndex) ?? '';
   	const amount = parseCSVAmount(amountValue);
   	if (!cardName || !created || !currency || amount === undefined) {
   	continue;
   	}

   and to row[postedDateColumnIndex] so the backend receives a canonical yyyy-MM-dd.

2. Add the empty‑result guard. In importCSVCompanyCards, after building transactions, short‑circuit when nothing valid was produced instead of calling the API — reusing the personal‑flow guard verbatim:

if (transactions.length === 0) {
    return Promise.resolve({titleKey: 'spreadsheet.importFailedTitle', promptKey: 'spreadsheet.invalidFileMessage'});
}

placed right after buildOptimisticCompanyCardCSVTransactions at

App/src/libs/actions/CompanyCards.ts

Line 1126 in 2b78b56

const {csvDataWithGeneratedIDs, normalizedColumnMappings, transactions} = buildOptimisticCompanyCardCSVTransactions(csvData, columnMappings, feedName);

. invalidFileMessage already exists at

App/src/languages/en.ts

Lines 1202 to 1203 in 2b78b56

	invalidFileMessage:
	'The file you uploaded is either empty or contains invalid data. Please ensure that the file is correctly formatted and contains the necessary information before uploading it again.',

.

3. Surface the backend's actual reason. The deeper UX gap is that failureData always stamps the fixed getImportFailedFinalModal() and discards whatever specific message the ImportCSVCompanyCards command returned. Read the server response message in the .catch/failure path and pass it through as the modal promptKey/prompt when present, falling back to the generic copy only when it isn't — so "which field/row failed" actually reaches the user. This touches

   App/src/libs/actions/CompanyCards.ts

   Lines 1167 to 1222 in 2b78b56

   	const successData: Array<OnyxUpdate<typeof ONYXKEYS.IMPORTED_SPREADSHEET>> = [getImportFinalModalOnyxData(importFinalModalID, importFinalModal)];
   	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER | typeof ONYXKEYS.COLLECTION.LAST_SELECTED_FEED | typeof ONYXKEYS.IMPORTED_SPREADSHEET>> =
   	[
   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.LAST_SELECTED_FEED}${policyID}`,
   	value: lastSelectedFeed ?? null,
   	},
   	getImportFinalModalOnyxData(importFinalModalID, getImportFailedFinalModal()),
   	];
   	if (shouldCreateFeed || shouldSetNickname) {
   	optimisticData.push({
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER}${workspaceAccountID}`,
   	value: {
   	settings: {
   	...(shouldCreateFeed
   	? {
   	companyCards: {
   	[feedName]: {
   	statementPeriodEndDay: null,
   	errors: null,
   	},
   	},
   	}
   	: {}),
   	...(shouldSetNickname
   	? {
   	companyCardNicknames: {
   	[feedName]: layoutName,
   	},
   	}
   	: {}),
   	},
   	},
   	});
   	failureData.push({
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER}${workspaceAccountID}`,
   	value: {
   	settings: {
   	...(shouldCreateFeed ? {companyCards: {[feedName]: null}} : {}),
   	...(shouldSetNickname ? {companyCardNicknames: {[feedName]: existingNicknames?.[feedName] ?? null}} : {}),
   	},
   	},
   	});
   	}
   	return API.write(WRITE_COMMANDS.IMPORT_CSV_COMPANY_CARDS, parameters, {optimisticData, successData, failureData})
   	.then(() => importFinalModalResult.promise)
   	.catch(() => {
   	importFinalModalResult.cancel();
   	return getImportFailedFinalModal();
   	});

   .

(1) and (2) are pure reuse of ImportTransactions.ts and immediately fix the structurally‑invalid‑but‑mapped case; (3) closes the "no detail" complaint for backend‑side rejections. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Replicate the personal‑card date parsing/empty guard directly inside CompanyCardsImportedPage's validate() so the Import button blocks before any request. This gives earlier feedback, but validate() runs on every render and would re‑parse the whole sheet repeatedly, and it duplicates logic that already lives in the action layer. Keeping validation in importCSVCompanyCards (where the transactions are already built) reuses the exact sibling pattern, runs once per submit, and keeps the page lean.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-22 13:44:55 UTC.

Proposal

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

Importing card transactions from a CSV (Workspace > Company Cards > Add Card > Import from file) fails with the generic "Please ensure all fields are filled out correctly…" error, with no indication of which field, row, or column is at fault.

What is the root cause of that problem?

The Company Cards import path skips the client-side validation its sibling Wallet path performs, then hard-codes a generic failure message — so bad input reaches the server and the user gets no specifics.

1. buildOptimisticCompanyCardCSVTransactions silently drops every row missing a required value (cardName/created/currency/amount):

   App/src/libs/actions/CompanyCards.ts

   Lines 128 to 130 in 256ad45

   	if (!cardName || !created || !currency || amount === undefined) {
   	continue;
   	}

2. But importCSVCompanyCards has no empty-list guard — it fires API.write even when 0 valid transactions were built:

   App/src/libs/actions/CompanyCards.ts

   Lines 1126 to 1138 in 256ad45

   	const {csvDataWithGeneratedIDs, normalizedColumnMappings, transactions} = buildOptimisticCompanyCardCSVTransactions(csvData, columnMappings, feedName);
   	const instanceID = existingInstanceID ?? Date.now().toString();
   	const parameters: ImportCSVCompanyCardsParams = {
   	policyID,
   	settings: JSON.stringify({
   	columnMappings: normalizedColumnMappings,
   	instanceID,
   	layoutName,
   	layoutType,
   	}),
   	csvData: JSON.stringify(csvDataWithGeneratedIDs),
   	};

3. The sibling Wallet path returns a specific message in exactly this case:

   App/src/libs/actions/ImportTransactions.ts

   Lines 258 to 262 in 256ad45

   	if (transactionList.length === 0) {
   	return {
   	titleKey: 'spreadsheet.importFailedTitle',
   	promptKey: 'spreadsheet.invalidFileMessage',
   	};

4. On any failure, both failureData and .catch substitute the hard-coded generic modal, discarding the backend's validation message:

   App/src/libs/actions/CompanyCards.ts

   Line 1175 in 256ad45

   getImportFinalModalOnyxData(importFinalModalID, getImportFailedFinalModal()),

   and

   App/src/libs/actions/CompanyCards.ts

   Lines 1217 to 1222 in 256ad45

   	return API.write(WRITE_COMMANDS.IMPORT_CSV_COMPANY_CARDS, parameters, {optimisticData, successData, failureData})
   	.then(() => importFinalModalResult.promise)
   	.catch(() => {
   	importFinalModalResult.cancel();
   	return getImportFailedFinalModal();
   	});

This explains all symptoms: it fails despite correct column mapping (the data fails per-value validation), shows generic copy, names no row/field, and is "unable to reproduce" since it depends on the CSV's date/amount/currency formatting.

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

In importCSVCompanyCards, port the Wallet path's guard and surface the real error:

if (transactionsCount === 0) {
    return Promise.resolve({titleKey: 'spreadsheet.importFailedTitle', promptKey: 'spreadsheet.invalidFileMessage'});
}

And in .catch((error) => …) (and failureData), pass the backend's returned message instead of always getImportFailedFinalModal(). Regression safety: the guard only changes the all-rows-invalid case (today a guaranteed failure); valid imports are untouched.

What alternative solutions did you explore? (Optional)

• Only reword importFailedDescription copy — incomplete: still generic, still fires a doomed request, still names no row/field.
• Only add the empty-guard — misses BE per-value rejections (e.g. unsupported currency) where >0 rows parse but the server still rejects; surfacing the BE message covers those too.

[melvin-bot]

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Error displayed when importing card transactions via CSV

What is the root cause of that problem?

I traced this to the path that handles CSV:

• src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:94 (translate): errors.duplicates = translate('workspace.companyCards.addNewCard.csvErrors.duplicateColumns', duplicate);
• src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:90 (translate): errors.required = translate('workspace.companyCards.addNewCard.csvErrors.requiredColumns', missingRequiredColumns);
• src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:121 (columnMappings): const columnMappings = columnNames.map((_, index) => columnNamesByIndex.at(index) ?? CONST.CSV_IMPORT_COLUMNS.IGNORE);
• The local evidence matches this recurring failure shape: NewDot and OldDot read different default account/card fields. Here, src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:94 and src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:90 do not agree on the same CSV value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:94 to derive CSV from the card/accounting data source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:90; that follows the safer family move to add fallback at the export/mapping layer, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Payments, Wallet, Bank, Billing, Cards surface and avoid changing money movement, bank/card/account settings.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/Payment*.ts for the exact issue flow: Error displayed when importing card transactions via CSV.
2. Cover the counter-case near src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx:94 so valid existing CSV behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep CSV consistent at the first read/write boundary shown above.

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[lorretheboy]

Proposal

What is the root cause of that problem?

The company-card CSV importer only validates that the required columns are mapped — it never validates the values in those columns. validate() checks for missing/duplicate column roles and nothing else:

App/src/pages/workspace/companyCards/addNew/CompanyCardsImportedPage.tsx

Lines 81 to 100 in 256ad45

	const validate = () => {
	const columns = Object.values(spreadsheet?.columns ?? {});
	let errors: Errors = {};
	const missingRequiredColumns = requiredColumns
	.filter((requiredColumn) => !columns.includes(requiredColumn.value))
	.map((requiredColumn) => requiredColumn.text)
	.join(', ');
	if (missingRequiredColumns) {
	errors.required = translate('workspace.companyCards.addNewCard.csvErrors.requiredColumns', missingRequiredColumns);
	} else {
	const duplicate = findDuplicate(columns);
	if (duplicate) {
	errors.duplicates = translate('workspace.companyCards.addNewCard.csvErrors.duplicateColumns', duplicate);
	} else {
	errors = {};
	}
	}
	return errors;
	};

When the rows are turned into transactions, any row whose required cell is bad (empty card number, empty currency, or an amount that parseCSVAmount can't turn into a number) is silently continued and produces no optimistic transaction:

App/src/libs/actions/CompanyCards.ts

Lines 128 to 130 in 256ad45

	if (!cardName || !created || !currency || amount === undefined) {
	continue;
	}

But the full, unfiltered csvData is still sent to the backend. So a CSV that is "mapped correctly" but contains an unparseable amount / blank currency / unrecognized date in some row passes the client check, the backend rejects the whole batch, and the catch path falls back to the generic failure modal:

App/src/libs/actions/CompanyCards.ts

Lines 1217 to 1222 in 256ad45

	return API.write(WRITE_COMMANDS.IMPORT_CSV_COMPANY_CARDS, parameters, {optimisticData, successData, failureData})
	.then(() => importFinalModalResult.promise)
	.catch(() => {
	importFinalModalResult.cancel();
	return getImportFailedFinalModal();
	});

which is the message the reporter saw:

App/src/languages/en.ts

Lines 1198 to 1199 in 256ad45

	importFailedTitle: 'Import failed',
	importFailedDescription: 'Please ensure all fields are filled out correctly and try again. If the problem persists, please reach out to Concierge.',

So: client validates column mapping but not cell values → bad rows are dropped locally yet still forwarded → backend rejects everything → user gets the generic "ensure all fields are filled out correctly" with no row/field detail. This also explains "unable to reproduce" — it only happens with specific cell contents.

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

Validate the cell values before calling the API, at the shared point that already inspects each row — buildOptimisticCompanyCardCSVTransactions:

App/src/libs/actions/CompanyCards.ts

Lines 116 to 150 in 256ad45

	const transactions: OptimisticCompanyCardCSVTransaction[] = [];
	for (const row of csvDataWithGeneratedIDs) {
	const transactionID = rand64();
	row[externalIDColumnIndex] = transactionID;
	const cardName = row.at(cardNumberColumnIndex)?.trim();
	const created = row.at(postedDateColumnIndex)?.trim();
	const merchant = row.at(merchantColumnIndex)?.trim() ?? '';
	const currency = row.at(currencyColumnIndex)?.trim();
	const amountValue = row.at(amountColumnIndex) ?? '';
	const amount = parseCSVAmount(amountValue);
	if (!cardName || !created || !currency || amount === undefined) {
	continue;
	}
	const category = categoryColumnIndex >= 0 ? (row.at(categoryColumnIndex)?.trim() ?? '') : '';
	const tag = tagColumnIndex >= 0 ? (row.at(tagColumnIndex)?.trim() ?? '') : '';
	const comment = commentColumnIndex >= 0 ? (row.at(commentColumnIndex)?.trim() ?? '') : '';
	transactions.push({
	transactionID,
	amount,
	created,
	currency,
	merchant,
	category,
	tag,
	comment: {comment},
	cardName,
	bank: feedName,
	reportID: '0',
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	});
	}

Instead of silently skipping a row that has the required columns but invalid data, collect the offending row index and reason (e.g. "amount in row 5 isn't a number", "currency missing in row 7"). Return that alongside the transactions, and in importTransactions surface a specific error through the existing errors/final-modal channel rather than calling the backend. This keeps the optimistic data and the data sent to the backend in agreement, and tells the user exactly which row/field to fix.

What alternative solutions did you explore? (Optional)

Add the same value checks directly in the page's validate() so the "Import" button blocks with a per-field message before submission. Functionally equivalent, but doing it in buildOptimisticCompanyCardCSVTransactions fixes it at the single point that already parses every cell and is shared by the import call.