[$250] Customer is unable to split a credit card expense in New Expensify

[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:
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: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. User logged into New Expensify.
2. User navigated to the workspace/account containing the credit card expense.
3. User selected an imported credit card expense.
4. User attempted to use the “Split” option on the expense.
5. The split action either failed, was unavailable, or did not complete successfully.

Expected Result:

User should be able to successfully split a credit card expense into multiple expenses within New Expensify.

Actual Result:

User is unable to split the selected credit card expense in New Expensify.

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 is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022055032968344652189
• Upwork Job ID: 2055032968344652189
• Last Price Increase: 2026-05-14

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Split" option for expenses is gated by isSplitAction() in ReportSecondaryActionUtils.ts. There is no explicit block on card transactions, but three conditions commonly affect credit card expenses:

1. Pending transaction (line 126): Card transactions that haven't posted yet have status === 'Pending', which hides Split entirely.
2. Non-reimbursable + policy config (line 154): Card expenses are typically non-reimbursable. If the workspace has both Instant Submit and Submit-and-Close enabled, Split is hidden for reports with only non-reimbursable transactions.
3. Report type (line 146): Split requires the expense to be on a workspace expense report (type EXPENSE). If the card expense is on a personal IOU report, Split will never appear.

Without the customer's specific transaction/policy state, the most likely cause is condition #1 (pending card transaction) or #2 (policy configuration blocking non-reimbursable splits).

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

This issue needs reproduction first to identify which specific condition is blocking the customer. The issue description lacks error messages, screenshots (they're in a private Slack thread), and specific reproduction steps.

Recommended next steps:

• Reproduce with a credit card expense on a workspace with various policy configurations (instant submit on/off, submit-and-close on/off)
• Check if the customer's card transaction was still in "Pending" status
• If the blocking condition is by design (e.g., pending transactions shouldn't be split), this may be working as intended and the issue should be closed with an explanation
• If the blocking condition is too restrictive (e.g., the non-reimbursable + submit-and-close + instant-submit combo shouldn't block split), relax the guard at line 154

Investigation details

The complete set of conditions in isSplitAction() that could hide Split:

Condition	Line	Likely for card expenses?
Report has != 1 transaction	115	No
Odometer distance request	122	No
Transaction is pending or has errors	126	Yes — unposted card transactions
Scanning with no amount	132	No
Already a bill split	142	No
Not an expense report	146	Possible — if not on a workspace
Report closed or beyond	150	Possible
Non-reimbursable + submit-and-close + instant-submit	154	Yes — card expenses are non-reimbursable
Not a policy member / no expense chat	170	Unlikely
Role-based (not submitter/admin/manager)	174-179	Possible

Additionally, even if Split is available, card transactions have stricter validation in computeSplitSaveErrorMessage() — the split total must exactly equal the original amount (non-card expenses allow the sum to be less).

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

Imported credit card expenses are non-reimbursable — getReimbursable returns the transaction's reimbursable flag, which the card import sets to false. So for an expense report that holds only card expenses, hasOnlyNonReimbursableTransactions(report.reportID) is true.

isSplitAction — the gate that decides whether the Split secondary action is offered (used by both getSecondaryReportActions and getSecondaryTransactionThreadActions) — has this guard:

App/src/libs/ReportSecondaryActionUtils.ts

Lines 154 to 156 in acf18a6

	if (hasOnlyNonReimbursableTransactions(report.reportID) && isSubmitAndClose(policy) && isInstantSubmitEnabled(policy)) {
	return false;
	}

On a workspace using Submit and close (approvalMode === OPTIONAL) + Instant submit (autoReporting instant) — a very common configuration — all three conditions are met for a card-only report, so isSplitAction returns false and Split is dropped from the ... menu entirely. That is the "Split option was unavailable" symptom.

The guard was added in commit e22d220ac3aa ("fix: don't allow split/merge for closed report") as a proxy for "this report auto-closes immediately." But it isn't scoped to closed reports — genuinely closed reports are already handled one block above:

App/src/libs/ReportSecondaryActionUtils.ts

Lines 150 to 152 in acf18a6

	if (report.statusNum && report.statusNum >= CONST.REPORT.STATUS_NUM.CLOSED) {
	return false;
	}

So the line-154 guard only adds value for reports that are not closed — i.e. still open — and there it directly contradicts the open-report branch at the end of the same function, which is explicitly designed to let the submitter/admin split an open report:

App/src/libs/ReportSecondaryActionUtils.ts

Lines 174 to 179 in acf18a6

	if (isOpenReport) {
	return isSubmitter || isAdmin;
	}
	// Hide split option for the submitter if the report is forwarded
	return (isSubmitter && isAwaitingFirstLevelApproval(report)) || isAdmin || isManager;

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

Scope the guard to non-open reports so a still-open card-only report falls through to the intended open-report branch (line 174):

-    if (hasOnlyNonReimbursableTransactions(report.reportID) && isSubmitAndClose(policy) && isInstantSubmitEnabled(policy)) {
+    if (!isOpenReportUtils(report) && hasOnlyNonReimbursableTransactions(report.reportID) && isSubmitAndClose(policy) && isInstantSubmitEnabled(policy)) {
         return false;
     }

isOpenReportUtils is already imported in this file (it's used a few lines below at line 166). With this change, an open card-only report on a Submit-and-close + Instant-submit policy correctly reaches return isSubmitter || isAdmin, so the submitter/admin sees Split again, while genuinely closed reports are still blocked by the statusNum >= CLOSED check above.

What alternative solutions did you explore? (Optional)

• Remove the line-154 guard entirely — the real closed-status check at line 150 already covers closed reports. Rejected as broader than necessary: it would also drop the guard for PROCESSING-state card-only reports, and I'd rather keep the change minimal and provably correct rather than re-deriving every state the original author intended to block.
• Exclude card transactions from hasOnlyNonReimbursableTransactions — rejected: that helper is shared across many call sites and the "non-reimbursable" classification is correct; the bug is in how isSplitAction uses it, not in the helper.

[KJ21-ENG]

Proposal

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

Users cannot successfully split an imported credit card expense in New Expensify. After attempting to split the card expense, the split does not reliably complete from the user's perspective.

What is the root cause of that problem?

The split flow hides the original expense by moving the original transaction to CONST.REPORT.SPLIT_REPORT_ID after creating split child transactions.

In src/libs/actions/IOU/SplitTransactionUpdate.ts, the non-reverse split path adds an optimisticData update that SETs the original transaction with reportID: CONST.REPORT.SPLIT_REPORT_ID, and it adds failureData to restore the original transaction. However, there is no matching successData entry that confirms this hidden reportID after the SplitTransaction API succeeds.

That leaves the client vulnerable to the API response or a Pusher update re-merging the original imported card transaction with its real expense report ID. For card-imported expenses this makes the parent card transaction reappear beside, or in place of, the split children, so the user sees the split as failed/not completed.

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

In updateSplitTransactions, when !isReverseSplitOperation, add a success Onyx update for the original transaction immediately alongside the existing optimistic/failure updates:

• Keep the existing optimistic SET that writes reportID: CONST.REPORT.SPLIT_REPORT_ID.
• Add successData for ${ONYXKEYS.COLLECTION.TRANSACTION}${originalTransactionID} that preserves/confirms reportID: CONST.REPORT.SPLIT_REPORT_ID after the API succeeds.
• Keep the existing failure rollback to the original transaction.
• Cover this with a focused unit test for splitting a card/imported expense, asserting that success data keeps the parent transaction on SPLIT_REPORT_ID so later server data does not restore it into the expense report.

This keeps the existing split creation flow intact and only fixes the missing success-state persistence for the original transaction.

What alternative solutions did you explore? (Optional)

We could try to special-case card expenses in the UI after saving, but that would only hide the symptom locally. The actual inconsistency is in the Onyx lifecycle for the split operation: optimistic and failure states are defined, but success state is missing for the parent transaction's hidden report ID.

[melvin-bot]

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

[melvin-bot]

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

[Abdulloh0109]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[trasnake87]

Proposal

The "Split" entry on the secondary action menu disappears (or stays disabled) for typical imported credit card expenses, because the visibility predicate that gates it treats every status === 'Pending' transaction the same way it treats partially-scanned receipts.

Root cause

The Split option for a transaction thread is gated by isSplitAction() in src/libs/ReportSecondaryActionUtils.ts:107-180. Two of its early-return checks are the source of the bug for imported credit-card expenses:

1 — Blanket isPending blocks every pre-posting card transaction.
src/libs/ReportSecondaryActionUtils.ts:126:

// src/libs/ReportSecondaryActionUtils.ts:119-128
const reportTransaction = reportTransactions.at(0);
const {amount} = getTransactionDetails(reportTransaction) ?? {};

if (isOdometerDistanceRequest(reportTransaction)) {
    return false;
}

if (isPending(reportTransaction) || !!reportTransaction?.errors) {
    return false;
}

isPending() (src/libs/TransactionUtils/index.ts:1421-1426) returns true for any transaction with transaction.status === 'Pending':

// src/libs/TransactionUtils/index.ts:1421-1426
function isPending(transaction: OnyxEntry<Transaction>): boolean {
    if (!transaction?.status) {
        return false;
    }
    return transaction.status === CONST.TRANSACTION.STATUS.PENDING;
}

For an imported credit-card expense, 'Pending' is the normal state delivered by the card feed until the merchant posts the transaction — the amount, merchant and date are already populated and the expense is fully displayed in the report. The intent of this branch was clearly to block the Split action for unsettled card or scanning transactions (where the amount can still change), not for every imported card expense whose status has not yet flipped to 'Posted'.

A purpose-built helper for exactly this case already exists at src/libs/TransactionUtils/index.ts:394-400:

// src/libs/TransactionUtils/index.ts:394-400
function isPendingCardOrScanningTransaction(transaction: OnyxEntry<Transaction>): boolean {
    return (
        (isExpensifyCardTransaction(transaction) && isPending(transaction)) ||
        (isScanRequest(transaction) && isMerchantMissing(transaction) && isAmountMissing(transaction)) ||
        (isScanRequest(transaction) && isScanning(transaction))
    );
}

That helper only blocks Expensify-card transactions whose amount may still change in authorization and scan requests that have not finished SmartScan. Importantly, it does not flag a bank-feed / CSV-imported card transaction that simply has status: 'Pending'.

2 — Workspace-config branches blank Split even when the amount is final.
src/libs/ReportSecondaryActionUtils.ts:154-161:

// src/libs/ReportSecondaryActionUtils.ts:154-161
if (hasOnlyNonReimbursableTransactions(report.reportID) && isSubmitAndClose(policy) && isInstantSubmitEnabled(policy)) {
    return false;
}

const arePaymentsDisabled = policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO;
if (isProcessingReportUtils(report) && isInstantSubmitEnabled(policy) && isSubmitAndClose(policy) && arePaymentsDisabled) {
    return false;
}

Credit-card expenses are non-reimbursable by default, so the line-154 trio (hasOnlyNonReimbursable + Submit-and-Close + Instant Submit) is precisely the configuration most workspaces that import card feeds run on. The branch at line 159 is even broader — it doesn't check hasOnlyNonReimbursableTransactions, so it also hides Split for processing reports on Submit & Close + Instant Submit + Reimbursement: No workspaces, regardless of the transaction's reimbursable flag. There is no product reason to hide Split here — splitting a card expense on a non-reimbursable workspace is exactly the workflow the bug reporter is trying to execute.

3 — !!reportTransaction?.errors short-circuits on transient/stale errors.
The same line bails out if reportTransaction.errors is set at all. Card feeds occasionally hydrate transactions with stale offline errors (e.g. failed prior edits) that never get cleared, and that alone is enough to hide Split forever.

Proposed fix

Narrow the gating logic at the top of isSplitAction to the cases that actually justify hiding Split, mirroring the pattern already used in src/libs/actions/IOU/ReportWorkflow.ts:245-253:

// src/libs/ReportSecondaryActionUtils.ts — change line 126
// Replace the broad pending-status guard with the card/scan-specific one,
// matching the pattern used in ReportWorkflow.ts:245 (`isPendingCardOrScanningTransaction`).
if (isPendingCardOrScanningTransaction(reportTransaction)) {
    return false;
}

Then add the matching import at the top of the file:

// src/libs/ReportSecondaryActionUtils.ts — extend the existing TransactionUtils import block
import {
    allHavePendingRTERViolation,
    getOriginalTransactionWithSplitInfo,
    hasReceipt as hasReceiptTransactionUtils,
    hasSmartScanFailedWithMissingFields,
    hasSubmissionBlockingViolations,
    isDuplicate,
    isManagedCardTransaction as isManagedCardTransactionTransactionUtils,
    isOdometerDistanceRequest,
    isOnHold as isOnHoldTransactionUtils,
    isPending,
    isPendingCardOrScanningTransaction, // <- add
    isPerDiemRequest as isPerDiemRequestTransactionUtils,
    isReceiptBeingScanned,
    isScanning as isScanningTransactionUtils,
    shouldShowBrokenConnectionViolationForMultipleTransactions,
} from './TransactionUtils';

Drop the unconditional !!reportTransaction?.errors branch — the page-level guard <FullPageNotFoundView shouldShow={!reportID || isEmptyObject(draftTransaction) || !isSplitAvailable}> in src/pages/iou/SplitExpensePage.tsx:505 plus the existing clearSplitTransactionDraftErrors call already cover the legitimate "transaction in error" state without hiding Split entirely. A targeted check on pendingAction === DELETE is enough if we still want to block half-deleted rows:

// src/libs/ReportSecondaryActionUtils.ts — replace the existing line 126 block with:
if (isPendingCardOrScanningTransaction(reportTransaction)) {
    return false;
}

if (reportTransaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
    return false;
}

Tighten the workspace-config branches so they only fire when there is no actionable state left — i.e. the report is already past Open and every transaction is non-reimbursable. Replace lines 154-161 with:

// src/libs/ReportSecondaryActionUtils.ts:154-161 — replacement
const isReportOpen = isOpenReportUtils(report);

// Only hide Split when the workspace has effectively auto-finalized the report
// AND there is nothing the submitter could still reimburse via the split.
if (
    !isReportOpen &&
    hasOnlyNonReimbursableTransactions(report.reportID, reportTransactions as Transaction[]) &&
    isSubmitAndClose(policy) &&
    isInstantSubmitEnabled(policy)
) {
    return false;
}

Note that hasOnlyNonReimbursableTransactions already accepts an explicit transactionsParam (src/libs/ReportUtils.ts:2570-2577), so passing reportTransactions avoids the redundant getReportTransactions(iouReportID) lookup the current call performs.

The redundant guard at line 159 can then be removed entirely — its only practical effect today is to hide Split for processing reports on Reimbursement-No workspaces even when a transaction is reimbursable, which is strictly more restrictive than the (correctly narrowed) line-154 block above.

Why this approach

isPendingCardOrScanningTransaction is the exact predicate Expensify already uses in src/libs/actions/IOU/ReportWorkflow.ts:245 (hasOnlyPendingCardOrScanFailTransactions) and src/libs/SearchUIUtils.ts:2350-2359 to gate report-level Submit/Approve flows for the same "amount may still change" reason. Reusing it in isSplitAction keeps the secondary-action menu consistent with the rest of the codebase and stops the menu lying to users whose imported card expense has a known final amount.

The narrowed policy-config check preserves the existing intent of the line-154 branch (don't offer Split on a report that has already auto-closed) while letting the user split a card expense on an Open report — which is the report state the bug reporter is on when they click the expense. We considered keeping the line 159 branch as an additional guard, but it duplicates the (now-fixed) line 154 check minus the per-transaction reimbursability test, so removing it is preferable to layering two near-identical conditions.

[github-actions]

⚠️ @Abdulloh0109 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.