Split Expense - The error “Receipt is missing” is displayed when performing a split.

[lanitochka17]

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

---

Version Number: 9.3.37-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-8760/folder/13177029/41237802/1247679227
Email or phone of affected tester (no customers): joelarmandotester+737@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacOS 15.7.4 / Chrome
App Component: Money Requests

Action Performed:

1. Goto staging.new.expensify.com
2. Sign in to an account
3. Go to a 1:1 DM or group.
4. Create a split expense with only amount.

Expected Result:

The split expense should be created correctly without error.

Actual Result:

An error message appears stating that the receipt is missing when creating a split expense. This does not show the amount entered, and when accessing to edit a field, an error message appears stating that the page is not here.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7101647_1773357873607.Screen_Recording_2026-03-12_at_7.20.29_PM.mov

Recording.5093.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: Unable to determine with high confidence - NEEDS INVESTIGATION
Related Issues: None found

Recommendation: NEEDS INVESTIGATION

I conducted an extensive investigation but was unable to identify a specific PR in the current staging deploy (9.3.37-0) that definitively introduced this bug. The issue appears to be related to merchant field validation during split expense creation.

Labels: No changes made (keeping DeployBlockerCash due to low confidence)

Detailed Analysis

Evidence

The bug occurs when creating a split expense with only an amount (no merchant specified). The error message "Receipt missing details" appears, which corresponds to the receiptMissingDetails translation key.

Technical Analysis

The validation logic in /src/components/MoneyRequestConfirmationList.tsx (lines 1079-1083) checks:

if (isEditingSplitBill && areRequiredFieldsEmpty(transaction, transactionReport)) {
    setDidConfirmSplit(true);
    setFormError("iou.error.genericSmartscanFailureMessage");
    return;
}

This calls areRequiredFieldsEmpty which checks if the merchant is missing:

function areRequiredFieldsEmpty(transaction, transactionReport) {
    const isFromExpenseReport = transactionReport?.type === CONST.REPORT.TYPE.EXPENSE;
    return (isFromExpenseReport && isMerchantMissing(transaction)) || isCreatedMissing(transaction);
}

Split expenses are initialized with merchant: CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT (which equals "(none)"), and this is considered an invalid/missing merchant by the isMerchantMissing validation function in /src/libs/ValidationUtils.ts.

Investigation Attempts

1. Checked all PRs in the staging deploy checklist - none explicitly modify split expense merchant handling
2. Searched git history for changes to:
   • /src/libs/actions/IOU/Split.ts - no recent changes
   • /src/components/MoneyRequestConfirmationList.tsx - no relevant changes found
   • /src/libs/TransactionUtils/index.ts - no recent changes
   • /src/libs/ValidationUtils.ts - no recent changes
3. Reviewed PR Fix manual distance expense from QAB showing amount as zero #84658 (distance expense merchant fix) - affects distance expenses only, not splits
4. The validation logic appears to have existed for a while, but something subtle may have changed in how split expenses are processed or how the report type is determined

Root Cause Hypothesis

The issue likely stems from one of these scenarios:

1. A backend change that now sets split expense reports as EXPENSE type when they previously weren't
2. A subtle timing issue where validation runs before the merchant field is properly initialized
3. A change in how the isEditingSplitBill flag is determined or when validation is triggered

Recommendation

This requires investigation by the PR author who implemented the split expense validation logic, or by reviewing the Backend changes that may have affected report typing. The team should:

1. Check if there were backend changes affecting split expense report types
2. Review when/how isEditingSplitBill is set to true
3. Consider whether split expenses should skip merchant validation or initialize with a valid merchant value
4. Tag @MelvinBot (author of the MoneyRequestConfirmationList validation logic) for insights

[MelvinBot]

Proposal

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

When a user creates a split expense with only an amount (no receipt) from a 1:1 DM or group chat on staging (v9.3.37-0), an error message about a missing receipt is displayed. The amount entered is not shown, and attempting to edit fields shows a "page is not here" error. This does not reproduce in production, indicating a recent regression.

What is the root cause of that problem?

This issue is closely related to #85150 (distance receipt placeholder flash) and shares the same underlying cause: PR #82672 introduced setMoneyRequestReceiptState which unconditionally sets receipt: {state: 'OPEN'} on all draft transactions whenever the amount, date, merchant, or description is modified (src/libs/actions/IOU/index.ts:1428-1468).

The chain of events:

1. User enters an amount for a split expense → setMoneyRequestAmount is called → setMoneyRequestReceiptState sets receipt: {state: 'OPEN'} on the draft transaction, even though no receipt was attached.

2. The draft transaction (with contaminated receipt state) is read by createSplitsAndOnyxData at src/libs/actions/IOU/index.ts:7066:

   const existingTransaction = allTransactionDrafts[`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${CONST.IOU.OPTIMISTIC_TRANSACTION_ID}`];
   

3. hasReceipt() (src/libs/TransactionUtils/index.ts:574) checks !!transaction?.receipt?.state, which now returns true for any draft transaction modified through the normal flow — even manual expenses with no receipt.

4. This contaminated state affects multiple downstream checks:

   • isScanning() at src/libs/TransactionUtils/index.ts:1420-1433 depends on hasReceipt() and isPartialTransaction()
   • hasMissingSmartscanFields() at src/libs/TransactionUtils/index.ts:1497 is the gatekeeper for showing "Receipt missing details"
   • The TransactionPreview component at src/libs/TransactionPreviewUtils.ts:241 evaluates hasFieldErrors = hasMissingSmartscanFields(transaction, iouReport)

5. Additionally, the optimistic split transaction is not recognized as a bill split by the TransactionPreview component because getOriginalTransactionWithSplitInfo (src/libs/TransactionUtils/index.ts:2637) checks transaction.comment.splits — a field only populated by the server, not set optimistically. This causes isBillSplit to be false in the preview, making the split render as if it were a regular expense.

6. The "page is not here" error when editing fields is likely caused by SplitBillDetailsPage.tsx:89-90 where isEditingSplitBill depends on areRequiredFieldsEmpty(transaction, transactionReport). Since the split transaction has reportID: '-2' (SPLIT_REPORT_ID), the transactionReport resolves to undefined, and any field validation issue puts the page into an unexpected editing state.

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

The fix should be applied in setMoneyRequestReceiptState at src/libs/actions/IOU/index.ts:1428-1468. The function should not set receipt: {state: 'OPEN'} unconditionally on all draft transactions. It should only set the receipt state when the transaction actually has a receipt attached (i.e., when there is already a receipt.source on the draft transaction).

This is the same fix that should resolve #85150. The guard should check whether the draft transaction already has a receipt before contaminating it with receipt state:

function setMoneyRequestReceiptState(transactionID: string, isDraft: boolean) {
    if (!isDraft) { return; }
    // Only set receipt state if the transaction already has a receipt
    const draftTransaction = allTransactionDrafts[`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${transactionID}`];
    if (!draftTransaction?.receipt?.source) { return; }
    Onyx.merge(...);
}

What alternative solutions did you explore? (Optional)

An alternative would be to add guards in the downstream consumers (hasMissingSmartscanFields, isScanning, getReportPreviewMessage) to exclude split transactions. However, this would be treating symptoms rather than the root cause. The draft transaction should never have receipt state set when no receipt was provided.

---

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.