[$250] AMEX direct connection - updating transaction start date doesn't remove expenses

[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.19-5
Reproducible in staging?: Needs Reproduction (Reproduction blocked, Needs card transactions)
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: @abbagail
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Login into New Expensify
2. Go to Workspace > [Workspace Name] > Company card
3. Click on a card
4. Select the transaction start date
5. Set a new transaction start date
6. Update the card
7. Go to spend page to see epxneses tied to the card

Expected Result:

When you check spend, the new date range of expenses for that card that has not been approved will update as well.

Actual Result:

When you check spend, all unapproved expenses stay the same.

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071275770603474895
• Upwork Job ID: 2071275770603474895
• Last Price Increase: 2026-06-28

Issue Owner

Current Issue Owner: @tylerkaraszewski

[MelvinBot]

Issue Analysis

Root Cause (likely backend): Updating a company card's transaction start date does not remove already-imported, unapproved expenses that now fall outside the new range. The App frontend that handles this change only updates the card's scrapeMinDate field and fires the UpdateCardTransactionStartDate command — it never touches existing transactions/expenses. So whether out-of-range unapproved expenses get pruned is entirely determined server-side (the company-card import/Auth layer), and that pruning isn't happening. This means the fix is outside the Expensify/App repo and should be investigated by an internal engineer with backend access.

Recommended next step: Escalate to an internal engineer to investigate the UpdateCardTransactionStartDate backend handler — specifically whether moving the start date forward is expected to delete (or just stop importing) already-imported unapproved transactions before the new date. Worth confirming the intended product behavior first, since "Expected Result" here assumes existing expenses are retroactively removed, which the current frontend does not do and is not designed to do.

Investigation details

Frontend is not responsible. updateCardTransactionStartDate in CompanyCards.ts:772-829 (and the assigned-card equivalent Card.ts:524-577) builds optimistic/finally/failure data that only writes to the WORKSPACE_CARDS_LIST Onyx collection — setting the card's scrapeMinDate, its pending state, and error state. It then calls API.write(UPDATE_CARD_TRANSACTION_START_DATE, …).

A repo-wide search for scrapeMinDate confirms it is used only to (a) display the current start date and (b) carry the new value in the update command — there is no frontend logic anywhere that removes transactions or expenses when the start date changes. Any retroactive cleanup of existing imported expenses can therefore only come from the backend response to this command.

Confidence: High that the App frontend is not the cause; the responsible logic (and any fix) lives in the backend company-card import service. Note this issue is still flagged Needs Reproduction (Reproduction blocked, Needs card transactions), so the expected behavior itself should be validated with the team before any change.

---

Next Steps for Contributor+ team:
To accept: This requires a backend change outside Expensify/App — please escalate to an internal engineer rather than implementing here.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's analysis.

[lorretheboy]

Proposal

What is the root cause of that problem?

updateCardTransactionStartDate builds its optimistic/success/failure data to touch only the card record's scrapeMinDate field — it never removes the now-out-of-range transactions from Onyx. So after the date is changed, the card shows the new start date but every previously-imported, unapproved expense dated before that new start date stays in Onyx and keeps showing on the spend page.

App/src/libs/actions/CompanyCards.ts

Lines 772 to 829 in 6ca714a

	function updateCardTransactionStartDate(domainOrWorkspaceAccountID: number, cardID: string, newStartDate: string, bankName: CompanyCardFeedWithNumber, oldStartDate?: string) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${domainOrWorkspaceAccountID}_${bankName}`,
	value: {
	[cardID]: {
	scrapeMinDate: newStartDate,
	pendingFields: {
	scrapeMinDate: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	errorFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];
	const finallyData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${domainOrWorkspaceAccountID}_${bankName}`,
	value: {
	[cardID]: {
	pendingFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${domainOrWorkspaceAccountID}_${bankName}`,
	value: {
	[cardID]: {
	scrapeMinDate: oldStartDate,
	pendingFields: {
	scrapeMinDate: null,
	},
	errorFields: {
	scrapeMinDate: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	},
	},
	];
	const parameters: UpdateCardTransactionStartDateParams = {
	cardID: Number(cardID),
	startDate: newStartDate,
	};
	API.write(WRITE_COMMANDS.UPDATE_CARD_TRANSACTION_START_DATE, parameters, {optimisticData, finallyData, failureData});
	}

The same bug exists in the assigned/personal-card path, which is a near-duplicate that also only updates scrapeMinDate:

App/src/libs/actions/Card.ts

Lines 524 to 581 in 6ca714a

	function updateAssignedCardTransactionStartDate(cardID: string, newStartDate: string, oldStartDate?: string) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.CARD_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CARD_LIST,
	value: {
	[cardID]: {
	scrapeMinDate: newStartDate,
	pendingFields: {
	scrapeMinDate: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	errorFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];
	const finallyData: Array<OnyxUpdate<typeof ONYXKEYS.CARD_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CARD_LIST,
	value: {
	[cardID]: {
	pendingFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.CARD_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CARD_LIST,
	value: {
	[cardID]: {
	scrapeMinDate: oldStartDate,
	pendingFields: {
	scrapeMinDate: null,
	},
	errorFields: {
	scrapeMinDate: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	},
	},
	];
	const parameters: UpdateCardTransactionStartDateParams = {
	cardID: Number(cardID),
	startDate: newStartDate,
	};
	API.write(WRITE_COMMANDS.UPDATE_CARD_TRANSACTION_START_DATE, parameters, {optimisticData, finallyData, failureData});
	}

Causal chain: the user moves the start date forward → the API command sends only cardID + startDate and the optimistic data merges only the card's scrapeMinDate → no transaction collection keys are cleared → the transactions whose date precedes newStartDate are still present in Onyx → the spend page (which lists transactions by cardID) keeps rendering them, so "all unapproved expenses stay the same."

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

When newStartDate moves forward, also remove the affected expenses optimistically. In updateCardTransactionStartDate, look up the transactions belonging to this cardID whose date is before newStartDate and that are still unapproved (i.e. on an open/draft report, not yet approved/settled), and add Onyx.METHOD.SET … null entries for those transaction keys to optimisticData. The failureData should restore them if the write fails.

App/src/libs/actions/CompanyCards.ts

Lines 773 to 789 in 6ca714a

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${domainOrWorkspaceAccountID}_${bankName}`,
	value: {
	[cardID]: {
	scrapeMinDate: newStartDate,
	pendingFields: {
	scrapeMinDate: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	errorFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];

Apply the identical change to the duplicated assigned-card path so both entry points stay in sync:

App/src/libs/actions/Card.ts

Lines 525 to 541 in 6ca714a

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.CARD_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CARD_LIST,
	value: {
	[cardID]: {
	scrapeMinDate: newStartDate,
	pendingFields: {
	scrapeMinDate: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	errorFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];

Since the logic is now non-trivial and duplicated, the cleanest approach is to extract a small shared helper that, given a cardID and newStartDate, returns the optimistic/failure Onyx updates for the out-of-range unapproved transactions, and call it from both functions.

What alternative solutions did you explore? (Optional)

Leave the transaction removal entirely to the backend response and only ensure the App applies the returned onyxData (no optimistic removal). This is simpler but the change won't appear offline and will lag until the server round-trip completes, which is the symptom reported here.

[melvin-bot]

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

[kitvasyl]

Proposal

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

Advancing an AMEX company card’s transaction start date leaves older, unapproved card expenses visible on the Spend page.

What is the root cause of that problem?

WorkspaceCompanyCardEditTransactionStartDatePage.submit() calls updateCardTransactionStartDate() in src/libs/actions/CompanyCards.ts.

That action’s success path only sends cardID/startDate, updates WORKSPACE_CARDS_LIST[cardID].scrapeMinDate, and clears its pending field. It has no state transition that removes transactions for the same cardID whose created date is before the new start date. Consequently, the card setting changes while those unapproved expenses remain in transaction/report state and continue appearing in Spend.

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

Update the UpdateCardTransactionStartDate command so that, when the date moves forward, it atomically removes imported transactions for that card that are older than the new date and belong to unapproved reports, while preserving approved expenses. Return the corresponding transaction/report Onyx updates with the command response so updateCardTransactionStartDate() applies the card-date and expense changes together.

Add coverage for moving the date forward with older unapproved and approved card expenses, moving it backward, and API failure.

What alternative solutions did you explore? (Optional)

Deleting only locally loaded transactions inside CompanyCards.ts would leave unloaded expenses on the server and make report totals and rollback handling inconsistent, so the filtering and deletion should remain atomic in the command.

[godzillaxbox19982014-lgtm]

Proposal

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

AMEX direct connection - updating transaction start date doesn't remove expenses

What is the root cause of that problem?

I traced this to the path that handles workspace name, card expense, AMEX:

• src/libs/actions/IOU/SplitTransactionUpdate.ts:94 (SplitTransactionUpdate): isFromSplitExpensesFlow?: boolean;
• src/libs/actions/IOU/SplitTransactionUpdate.ts:120 (SplitTransactionUpdate): isFromSplitExpensesFlow,
• src/libs/actions/IOU/SplitTransactionUpdate.ts:203 (hasEditableSplitExpensesLeft): const hasEditableSplitExpensesLeft = splitExpenses.some((expense) => (expense.statusNum ?? 0) < CONST.REPORT.STATUS_NUM.SUBMITTED);
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/libs/actions/IOU/SplitTransactionUpdate.ts:94 and src/libs/actions/IOU/SplitTransactionUpdate.ts:120 do not agree on the same workspace name, card expense, AMEX 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/libs/actions/IOU/SplitTransactionUpdate.ts:94 to derive workspace name, card expense, AMEX from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/libs/actions/IOU/SplitTransactionUpdate.ts:120; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

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/ReportUtils*.ts for the exact issue flow: AMEX direct connection - updating transaction start date doesn't remove expenses.
2. Cover the counter-case near src/libs/actions/IOU/SplitTransactionUpdate.ts:94 so valid existing workspace name, card expense, AMEX 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 workspace name, card expense, AMEX consistent at the first read/write boundary shown above.

[melvin-bot]

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

[github-actions]

⚠️ @lorretheboy 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).

[Abdulloh0109]

What is the root cause of that problem?

Changing a company card's transaction start date does exactly one thing on the App side: it updates the card's scrapeMinDate and fires the UpdateCardTransactionStartDate command. It does not — and cannot — remove the expenses that were already imported before the new date.

On save, the edit page reads the current value from card.scrapeMinDate and calls updateCardTransactionStartDate(...):

App/src/pages/workspace/companyCards/WorkspaceCompanyCardEditTransactionStartDatePage.tsx

Line 48 in 6ca714a

const currentStartDate = card?.scrapeMinDate;

App/src/pages/workspace/companyCards/WorkspaceCompanyCardEditTransactionStartDatePage.tsx

Lines 75 to 84 in 6ca714a

	const submit = () => {
	if (dateOptionSelected === CONST.COMPANY_CARD.TRANSACTION_START_DATE_OPTIONS.CUSTOM && !isRequiredFulfilled(startDate)) {
	setErrorText(translate('common.error.fieldRequired'));
	return;
	}
	const newStartDate = dateOptionSelected === CONST.COMPANY_CARD.TRANSACTION_START_DATE_OPTIONS.FROM_BEGINNING ? '' : startDate;
	updateCardTransactionStartDate(domainOrWorkspaceAccountID, cardID, newStartDate, bank, currentStartDate);
	Navigation.goBack(ROUTES.WORKSPACE_COMPANY_CARD_DETAILS.getRoute(policyID, feedName, cardID), {compareParams: false});

updateCardTransactionStartDate builds optimistic/finally/failure data that touch exactly one field — the card's scrapeMinDate in WORKSPACE_CARDS_LIST — and then calls UpdateCardTransactionStartDate with just cardID + startDate:

App/src/libs/actions/CompanyCards.ts

Lines 772 to 829 in 6ca714a

	function updateCardTransactionStartDate(domainOrWorkspaceAccountID: number, cardID: string, newStartDate: string, bankName: CompanyCardFeedWithNumber, oldStartDate?: string) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${domainOrWorkspaceAccountID}_${bankName}`,
	value: {
	[cardID]: {
	scrapeMinDate: newStartDate,
	pendingFields: {
	scrapeMinDate: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	errorFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];
	const finallyData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${domainOrWorkspaceAccountID}_${bankName}`,
	value: {
	[cardID]: {
	pendingFields: {
	scrapeMinDate: null,
	},
	},
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST}${domainOrWorkspaceAccountID}_${bankName}`,
	value: {
	[cardID]: {
	scrapeMinDate: oldStartDate,
	pendingFields: {
	scrapeMinDate: null,
	},
	errorFields: {
	scrapeMinDate: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	},
	},
	];
	const parameters: UpdateCardTransactionStartDateParams = {
	cardID: Number(cardID),
	startDate: newStartDate,
	};
	API.write(WRITE_COMMANDS.UPDATE_CARD_TRANSACTION_START_DATE, parameters, {optimisticData, finallyData, failureData});
	}

There is no code path here, nor anywhere else on the client, that deletes the transactions whose date falls before the new scrapeMinDate. So raising the start date flips the card setting but leaves the already-imported unapproved expenses in place — exactly the reported "all unapproved expenses stay the same."

The "spend page" the reporter checks is the Spend tab, which renders the Search page. Search pulls its results from the server on navigation, so it isn't showing a stale local cache — it's showing what the backend still has. The expenses persist because they were never removed server-side.

Pruning already-imported, unapproved expenses when the start date moves forward is by definition a server operation: only the backend UpdateCardTransactionStartDate handler can drop those transactions (and the report actions they live on) and push the matching Onyx removals down to the client. The App side is complete and correct — it sends everything the backend needs (cardID + the new startDate). The behavior the issue asks for cannot be produced by any App-side change.

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

Fix this in the backend, not the App. When the new start date is later than the previous one, the UpdateCardTransactionStartDate command should remove the unapproved/unsubmitted company-card expenses for that card dated before the new scrapeMinDate, and return Onyx updates that delete those transactions and their report actions so the Spend/Search view reflects the new range.

No App-side change is appropriate here. The client could in theory optimistically drop the card's pre-startDate, not-yet-approved transactions from Onyx inside updateCardTransactionStartDate (CompanyCards.ts#L772-L829), but that's purely cosmetic: without the backend deletion they reappear on the next sync, and the client can't reliably determine the approval state of every such transaction. The real fix has to live in the command.

What alternative solutions did you explore? (Optional)

• A frontend selector/refresh on the Spend (Search) page — rejected: Search re-queries the server on navigation, so there is no stale local snapshot to refresh; the expenses are genuinely still present in backend data.
• Sending a different/extra parameter from the edit page — rejected: UpdateCardTransactionStartDate already receives cardID + the new startDate (CompanyCards.ts#L772-L829), which is everything needed to recompute the range. The gap is the backend not acting on it, not missing input.