[$250] Bulk Receipt Upload via SmartScan Creates Partial Expenses; Remaining Receipts Added as Comments

[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: 9.3.41-4
Reproducible in staging?: Needs Reproduction (Unable to reproduce, Tried with 15 receipts)
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: @rickbalut
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Click on the SmartScan icon
2. Upload multiple receipt files in bulk (e.g., 27 receipts)
3. Wait for processing to complete
4. Review the report

Expected Result:

All uploaded receipts should:
Be processed via SmartScan
Create individual expenses
Be added to the report

Actual Result:

Only a few receipts (e.g., 3 out of 27) are:
Converted into expenses
Successfully SmartScanned
Remaining receipts (e.g., 24):
Are attached in the report comment section
Not processed into expenses

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

Issue Owner

Current Issue Owner: @parasharrajat

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022038659048295847169
• Upwork Job ID: 2038659048295847169
• Last Price Increase: 2026-03-30

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two likely contributing factors:

1. DualDropZone routing confusion (most likely for drag-and-drop uploads): When a user drags files onto a report page, the DualDropZone component (App/src/components/DropZone/DualDropZone.tsx:49-87) presents two side-by-side zones — "Add Attachments" (left) and "SmartScan Receipts" (right). Files dropped on the left side go through handleAttachmentDrop → addAttachmentWithComment and become report comments with file attachments (not expenses). Files dropped on the right side go through onReceiptDropped → initMoneyRequest and become expense transactions. If the user isn't precise about which zone they drop onto, some files become comments instead of expenses.

Additionally, shouldDisplayDualDropZone (App/src/pages/inbox/report/ReportActionCompose/ReportActionCompose.tsx:294-301) can be false for certain report types (room chats, group chats, invoice reports, settled/approved reports). When this happens, ALL file drops go through a single "Add Attachments" drop zone (ReportActionCompose.tsx:772-782), meaning every file becomes a comment attachment — no receipt/expense option exists.

2. Rapid-fire API calls with no batching: When multiple files DO go through the receipt path, the createTransaction function (App/src/libs/actions/IOU/MoneyRequest.ts:180-284) fires API.write(WRITE_COMMANDS.REQUEST_MONEY) in a synchronous for-loop for every file with no throttling or batching. For 27 files, this sends 27 API calls almost simultaneously, which could overwhelm the server or Onyx sequential queue, causing some to fail silently.

Notable side bug (minor): onReceiptDropped in useAttachmentUploadValidation.ts:195-206 is missing a return statement after calling validateFiles in the shouldAddOrReplaceReceipt branch, causing validateFiles to be called twice — the second call is silently dropped by the isValidatingFiles guard.

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

1. Clarify the user's upload flow first: Since this is marked "Needs Reproduction", we should verify exactly which upload path the reporter used. The steps say "Click on the SmartScan icon" — if this means the IOURequestStepScan page's file picker, then all files should go through the receipt path correctly (no dual drop zone involved). In that case, the root cause is likely server-side (rapid API calls) and would need backend investigation.

2. Fix the onReceiptDropped missing return: Add return; after validateFiles([file], items); on line 202 of useAttachmentUploadValidation.ts so the single-file replacement case doesn't fall through to the bulk call.

3. Consider adding feedback when files go through the attachment path: When users drop files onto the "Add Attachments" side of the DualDropZone (or when shouldDisplayDualDropZone is false), there's no warning that files won't be SmartScanned. Adding a hint or confirmation could prevent accidental misrouting.

4. Investigate server-side throttling: If the issue is confirmed through the scan page flow (not drag-and-drop), the backend team should check whether 27 rapid RequestMoney API calls are all processed successfully or if some are dropped/throttled.

What alternative solutions did you explore? (Optional)

• Batch API for multi-receipt uploads: Instead of firing N individual RequestMoney API calls, introduce a batch endpoint that accepts multiple receipts in a single request. This would eliminate the rapid-fire issue entirely.
• Client-side queuing with retry: Add sequential processing with retry logic for multi-receipt uploads so each transaction completes before the next begins.

---

Detailed Investigation

Root Cause Analysis

Upload Flow Paths:

There are three distinct code paths for bulk receipt uploads in the App:

1. IOURequestStepScan page (via + menu → "Scan receipt"): DesktopWebUploadView.tsx:56-67 handles files via validateFiles() → all files go through the receipt/expense path. AttachmentPicker at line 109 has allowMultiple={shouldAcceptMultipleFiles}. No file limit issues (MAX_FILE_LIMIT=30, and 27 < 30).

2. Report page DualDropZone (drag-and-drop on chat): DualDropZone.tsx:49-87 has two DropZoneWrapper components — left for comments, right for receipts. The routing depends entirely on which zone the user drops onto.

3. HomePage/SearchPage ReceiptScanDropZone: useReceiptScanDrop.tsx:44-78 creates one transaction per file and navigates to confirmation. All files correctly become expenses.

The DualDropZone gate (shouldDisplayDualDropZone):

const shouldDisplayDualDropZone = useMemo(() => {
    ...
    const isRoomOrGroupChat = isChatRoom(report) || isGroupChat(report);
    return !isRoomOrGroupChat && (canModifyReceipt || hasMoneyRequestOptions) && !isInvoiceReport(report);
}, ...);

When false, only the attachment drop zone is rendered (line 772-782), meaning ALL files become comments.

Rapid-fire API call issue:

In MoneyRequest.ts:180-284, createTransaction loops through all files:

for (const [index, receiptFile] of files.entries()) {
    requestMoney({ ..., shouldHandleNavigation: index === files.length - 1 });
}

Each requestMoney call fires API.write(WRITE_COMMANDS.REQUEST_MONEY) immediately. For 27 files, this creates 27 nearly-simultaneous write commands with no throttling.

Evidence Chain

1. User uploads 27 receipts → files enter one of the three paths above
2. If via DualDropZone and files land on wrong side → handleAttachmentDrop → attachmentUploadType='attachment' → addAttachmentWithComment → report comments created
3. If via correct receipt path → 27 transactions created optimistically → 27 RequestMoney API calls fired rapidly → server may reject/throttle some
4. Result: some become expenses (3), rest appear as comments (24)

Relevant Code

• App/src/components/DropZone/DualDropZone.tsx:49-87 - Two side-by-side drop zones
• App/src/pages/inbox/report/ReportActionCompose/ReportActionCompose.tsx:294-301 - shouldDisplayDualDropZone gate
• App/src/pages/inbox/report/ReportActionCompose/ReportActionCompose.tsx:772-782 - Fallback single attachment-only drop zone
• App/src/pages/inbox/report/ReportActionCompose/useAttachmentUploadValidation.ts:185-209 - onReceiptDropped with missing return bug
• App/src/libs/actions/IOU/MoneyRequest.ts:180-284 - createTransaction rapid-fire loop
• App/src/libs/actions/IOU/index.ts:6529-6575 - requestMoney API write
• App/src/hooks/useReceiptScanDrop.tsx:44-78 - Home/Search page receipt drop handler

---

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.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When a user uploads multiple receipts at once via SmartScan, only a partial set becomes actual expense transactions. The remaining receipts are either silently dropped or appear as plain comment attachments on the report instead of being SmartScanned.

What is the root cause of that problem?

The primary bug is a missing return statement in onReceiptDropped() inside useAttachmentUploadValidation. When shouldAddOrReplaceReceipt && transactionID is true, the function calls validateFiles() with just the first file, but then falls through to call validateFiles() again with all files. The second call is silently dropped.

The reason the second call is dropped is the isValidatingFiles guard in validateFiles() inside useFilesValidation. Once the first validateFiles() call sets isValidatingFiles = true, the second call hits the guard, logs a warning, and returns immediately — discarding all the remaining receipts.

The impact chain: (1) user drops N files on the SmartScan zone, (2) first validateFiles() processes only file #1 and locks the guard, (3) second validateFiles() with all N files is silently rejected, (4) only 1 expense is created, and the remaining files may fall through to the attachment/comment path via handleAttachmentDrop, explaining why they appear as comments rather than expenses.

Note: MelvinBot's proposal identified this missing return but characterized it as a "Notable side bug (minor)" while focusing on DualDropZone routing and API throttling as the primary causes. Based on tracing the full code path, this missing return is actually the primary bug — it directly causes most receipts to be silently discarded by the isValidatingFiles guard before they ever reach the expense creation flow.

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

Add a return statement after the validateFiles call on line 202 in useAttachmentUploadValidation to prevent the fall-through:

 if (shouldAddOrReplaceReceipt && transactionID) {
     const file = files.at(0);
     if (!file) {
         return;
     }

     attachmentUploadType.current = 'receipt';
     validateFiles([file], items);
+    return;
 }

This ensures the single-file replacement path exits cleanly, and the bulk receipt path (validateFiles(files, items, {isValidatingReceipts: true})) is only reached when shouldAddOrReplaceReceipt is false — which is the normal multi-receipt upload case.

What alternative solutions did you explore? (Optional)

The existing MelvinBot proposal focuses on DualDropZone routing confusion and rapid-fire API calls as the primary causes, treating this missing return as minor. However, tracing the actual code execution shows this return bug is the direct mechanism by which receipts are lost — the isValidatingFiles guard silently eats the bulk call. The DualDropZone routing is a separate UX concern but not the cause of receipts being dropped when the user correctly targets the SmartScan zone. The API throttling concern is speculative and would only apply if all files actually made it past validation, which they don't due to this bug.

[MassoudFSharifi]

Proposal

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

When a user bulk-uploads receipts from the report-level SmartScan surface on desktop web, the whole batch is not consistently treated as a multi-receipt expense scan. Instead, the flow partially behaves like “replace the current receipt” and only a subset of the uploaded files ends up going through the expense-creation path.

---

What is the root cause of that problem?

The bug is in src/pages/inbox/report/ReportActionCompose/useAttachmentUploadValidation.ts.

ReportActionCompose.tsx derives shouldAddOrReplaceReceipt from the current screen state (isTransactionThreadView || isSingleTransactionView) and passes it into useAttachmentUploadValidation(). That flag is correct for a single-file replace flow, but useAttachmentUploadValidation uses it in two places without checking how many files were actually dropped:

1. onReceiptDropped():

   • if shouldAddOrReplaceReceipt && transactionID is true, it validates only files.at(0) for receipt replacement
   • then, because there is no return, it immediately calls validateFiles(files, ...) for the full batch too

2. onFilesValidated():

   • it again checks only shouldAddOrReplaceReceipt && transactionID
   • so even if a multi-file batch finished validation, it still routes that result to replaceReceipt() instead of initMoneyRequest()

So in transaction-thread / single-transaction report views, a multi-file SmartScan upload gets incorrectly routed into the single-receipt replacement path. The replace flow and the bulk-scan flow are both triggered off the same drop, and the batch never has a clean, exclusive path to initMoneyRequest().

This also matches the platform signal in the issue: the broken path is the desktop report composer SmartScan flow, not the dedicated IOURequestStepScan page used elsewhere.

---

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

We should make the replace-receipt flow strictly single-file only.

If the user drops exactly one file, keep the current replace behavior.
If the user drops more than one file, always treat it as a bulk SmartScan upload and send the batch through the existing initMoneyRequest() path that creates one expense per file.

That means:

• gate both onReceiptDropped() and onFilesValidated() on files.length === 1 before using replaceReceipt()
• add an early return after the single-file validateFiles([file], ...) call so the replace path and bulk path cannot run for the same event

Implementation

// File: src/pages/inbox/report/ReportActionCompose/useAttachmentUploadValidation.ts

-        if (shouldAddOrReplaceReceipt && transactionID) {
+        const shouldReplaceReceipt = shouldAddOrReplaceReceipt && files.length === 1;
+        if (shouldReplaceReceipt && transactionID) {
             const source = URL.createObjectURL(files.at(0) as Blob);
             replaceReceipt({transactionID, file: files.at(0) as File, source, transactionPolicy: policy, transactionPolicyCategories: policyCategories});
             return;
         }

         const initialTransaction = initMoneyRequest({
             reportID,
             personalPolicy,
             newIouRequestType: CONST.IOU.REQUEST_TYPE.SCAN,
             report,
             parentReport: newParentReport,
             currentDate,
             currentUserPersonalDetails,
             hasOnlyPersonalPolicies,
             draftTransactionIDs,
         });

         for (const [index, file] of files.entries()) {
             const source = URL.createObjectURL(file as Blob);
             const newTransaction =
                 index === 0
                     ? (initialTransaction as Partial<OnyxTypes.Transaction>)
                     : buildOptimisticTransactionAndCreateDraft({
                           initialTransaction: initialTransaction as Partial<OnyxTypes.Transaction>,
                           currentUserPersonalDetails,
                           reportID,
                       });
             const newTransactionID = newTransaction?.transactionID ?? CONST.IOU.OPTIMISTIC_TRANSACTION_ID;
             setMoneyRequestReceipt(newTransactionID, source, file.name ?? '', true, file.type);
             setMoneyRequestParticipantsFromReport(newTransactionID, report, currentUserPersonalDetails.accountID);
         }
         Navigation.navigate(
             ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(
                 CONST.IOU.ACTION.CREATE,
                 isSelfDM(report) ? CONST.IOU.TYPE.TRACK : CONST.IOU.TYPE.SUBMIT,
                 CONST.IOU.OPTIMISTIC_TRANSACTION_ID,
                 reportID,
             ),
         );
     };

     const {validateFiles, PDFValidationComponent, ErrorModal} = useFilesValidation(onFilesValidated);

     const validateAttachments = useCallback(
         ({dragEvent, files}: {dragEvent?: DragEvent; files?: FileObject | FileObject[]}) => {
             if (isAttachmentPreviewActive) {
                 return;
             }

             let extractedFiles: FileObject[] = [];

             if (files) {
                 extractedFiles = Array.isArray(files) ? files : [files];
             } else {
                 if (!dragEvent) {
                     return;
                 }

                 extractedFiles = getFilesFromClipboardEvent(dragEvent);
             }

             const dataTransferItems = Array.from(dragEvent?.dataTransfer?.items ?? []);
             if (extractedFiles.length === 0) {
                 return;
             }

             const validIndices: number[] = [];
             const fileObjects = extractedFiles
                 .map((item, index) => {
                     const fileObject = cleanFileObject(item);
                     const cleanedFileObject = cleanFileObjectName(fileObject);
                     if (cleanedFileObject !== null) {
                         validIndices.push(index);
                     }
                     return cleanedFileObject;
                 })
                 .filter((fileObject) => fileObject !== null);

             if (!fileObjects.length) {
                 return;
             }

             // Create a filtered items array that matches the fileObjects
             const filteredItems = dataTransferItems && validIndices.length > 0 ? validIndices.map((index) => dataTransferItems.at(index) ?? ({} as DataTransferItem)) : undefined;

             attachmentUploadType.current = 'attachment';
             validateFiles(fileObjects, filteredItems, {isValidatingReceipts: false});
         },
         [isAttachmentPreviewActive, validateFiles],
     );

     const onReceiptDropped = useCallback(
         (e: DragEvent) => {
             if (policy && shouldRestrictUserBillableActions(policy.id, ownerBillingGraceEndPeriod, userBillingGraceEndPeriods)) {
                 Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policy.id));
                 return;
             }

             const files = getFilesFromClipboardEvent(e);
             const items = Array.from(e.dataTransfer?.items ?? []);

-            if (shouldAddOrReplaceReceipt && transactionID) {
+            const shouldReplaceReceipt = shouldAddOrReplaceReceipt && files.length === 1;
+            if (shouldReplaceReceipt && transactionID) {
                 const file = files.at(0);
                 if (!file) {
                     return;
                 }

                 attachmentUploadType.current = 'receipt';
                 validateFiles([file], items);
+                return;
             }

             attachmentUploadType.current = 'receipt';
             validateFiles(files, items, {isValidatingReceipts: true});
         },
         [policy, userBillingGraceEndPeriods, ownerBillingGraceEndPeriod, shouldAddOrReplaceReceipt, transactionID, validateFiles],
     );

This works because it makes the two flows mutually exclusive and keys them off the actual input shape, not just the screen context. Single-file drops still replace the current receipt, while multi-file drops always stay in the existing bulk expense flow and create one draft transaction per receipt.

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

None

What alternative solutions did you explore? (Optional)

Adding only a return after the first validateFiles([file], items) call is not sufficient. That would stop the double-validation bug in onReceiptDropped(), but onFilesValidated() would still incorrectly route any validated multi-file batch to replaceReceipt() whenever shouldAddOrReplaceReceipt is true.

I also considered throttling or batching REQUEST_MONEY, but that is further downstream. The bug here happens before submission, when the report-composer SmartScan surface chooses the wrong flow for a multi-file upload.

[github-actions]

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