[Due for payment 2026-05-29] [$250] Reimbursable Report Shows “Pay” in ND Home but Cannot Be Paid; Report Missing Payment State in Classic

[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.51-3
Reproducible in staging?: Y
Reproducible in production?: Y
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. From Account A, create a reimbursable expense/report in a personal workspace
2. Submit the report to User B
3. Log in as User B in New Expensify
4. On Home, click Pay shortcut
5. Observe the report shows Done status with a “Pay” button
6. Click Pay > Mark as Paid > Nothing happens
7. Open the report : Expense is not visible, No Pay option available
8. Switch to Classic Expensify
9. Check Home and report

Expected Result:

Report should:
Appear consistently as payable across platforms
Allow Mark as Paid action to complete successfully
Display expense details within the report

Actual Result:

ND Home shows Pay option, but action does nothing
Inside report:
Expense is not visible
No Pay option available
Classic:
Report does not appear as needing payment
No payment action available

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

Recording.2631.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039364291459387025
• Upwork Job ID: 2039364291459387025
• Last Price Increase: 2026-04-15

[MelvinBot]

Proposal

What is the root cause of that problem?

This bug has two interrelated root causes that together produce all the reported symptoms:

Root Cause 1: Silent failure when clicking "Pay > Mark as Paid"

Both PayPrimaryAction and PayActionButton silently return without any user feedback when chatReport is null/undefined:

• PayPrimaryAction.tsx:94: if (!type || !chatReport) { return; }
• PayActionButton.tsx:140: } else if (chatReport && iouReport) { /* payment happens */ }

The chatReport is fetched via useOnyx from moneyRequestReport?.chatReportID. When the user navigates to the expense report from the Home page "Pay" shortcut, the MoneyReportHeader gets chatReport via useOnyx(\${ONYXKEYS.COLLECTION.REPORT}${moneyRequestReport?.chatReportID}`)(line 225). If the chat report data hasn't been loaded into Onyx yet at the time of the Pay click,chatReportisnull` and the payment silently does nothing.

Root Cause 2: Expense not visible when opening the report

In MoneyRequestReportPreviewContent.tsx:116:

const shouldShowAccessPlaceHolder = !iouReport && !shouldShowLoading;

When the IOU report is not in Onyx, the component shows the AccessMoneyRequestReportPreviewPlaceHolder (eye-disabled icon) and sets carouselTransactions = [], hiding all expenses. The loading state (shouldShowLoading at line 110) depends on chat report metadata (chatReportMetadata.hasOnceLoadedReportActions), not IOU report metadata. Once chat actions are loaded, loading appears done even if the IOU report hasn't been fetched — creating a timing gap where the placeholder shows instead of the expense.

Contributing factor: Divergent pay eligibility logic

The Home page's isPrimaryPayAction() (in ReportPrimaryActionUtils.ts) does NOT check isSettled(), isAutoReimbursable(), or isPayAtEndExpenseReport(). However, the actual Pay button rendering uses canIOUBePaid() (in IOU/index.ts:9799) which DOES check all of these. This means a report can appear as payable on the Home page while the Pay button is hidden or non-functional when the user actually opens the report.

Additionally, for personal workspace reports (policy type personal), the report type is expense (not iou), triggering the stricter expense report path in canIOUBePaid that requires isReportFinished (approved/closed). The IOU fast-path at line 9851 that only checks isPayer && !iouSettled && reimbursableSpend > 0 is skipped.

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

1. Fix the silent failure in payment callbacks — In PayPrimaryAction.tsx and PayActionButton.tsx, when chatReport is null, show a user-facing error or loading state instead of silently returning. This prevents the "nothing happens" experience.

2. Align pay eligibility checks — Reconcile isPrimaryPayAction() (used by Home page todos) with canIOUBePaid() (used by actual Pay button) so reports that appear as payable on the Home page are actually payable when opened. Specifically, isPrimaryPayAction should include the isSettled check that canIOUBePaid performs.

3. Fix the loading state timing for IOU report data — In MoneyRequestReportPreviewContent.tsx, the shouldShowLoading check should also account for whether the IOU report data has been loaded, not just the chat report metadata. This prevents showing the access placeholder prematurely.

What alternative solutions did you explore? (Optional)

• Pre-fetching the chat report and IOU report data before navigation from the Home page "Pay" shortcut, ensuring all required Onyx data is available before the report view renders. This would address the timing issue but doesn't fix the underlying silent failure or eligibility divergence.

---

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 - @suneox (External)

[melvin-bot]

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

[JasimMalook]

Proposal

What is the root cause of the problem?

The Home page determines whether a report should show the “Pay” shortcut using isPrimaryPayAction(). However, the actual report view uses canIOUBePaid() to determine whether payment is allowed.

These two checks do not fully share the same validation rules. Because of this mismatch, a report may appear payable on the Home screen while the report itself does not allow the payment action.

This creates the situation where the Pay button is visible in ND Home but the payment action cannot execute when the report is opened.

What changes do you think we should make?

We should align the logic used by the Home page with the logic used by the report payment flow.

Specifically, isPrimaryPayAction() should reuse or delegate to canIOUBePaid() (or a shared helper) so both locations evaluate the same payment eligibility rules.

For example:

const canPay = canIOUBePaid(report, policy, currentUserAccountID);

if (canPay) {
    showPayShortcut();
}

This ensures the Pay shortcut only appears when the report is truly payable, preventing the inconsistent UI state where the Home page shows Pay but the report itself cannot process the payment.

What alternative solutions did you explore?

Another option would be forcing the report data to refresh when navigating from the Home Pay shortcut. However, aligning the payment eligibility logic is the safer solution because it ensures both the Home screen and report view rely on the same validation rules.

Contributor details
Your Expensify account email: jasimmalook@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~014c25762fc2275193

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[KJ21-ENG]

Proposal

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

A report is appearing in NewDot as payable from Home/Reports (with a Pay action), but payment does not complete and the same report appears as finished/non-payable in other places (including Classic). This creates a cross-surface state mismatch: users are prompted to pay a report that is already treated as done.

What is the root cause of that problem?

The pay eligibility logic is split across two paths that are not aligned.

1. The Home/To-do "Pay" entry is derived from isPrimaryPayAction(), which can mark a report as payable when it is finished and has reimbursable spend, but does not apply the same guards used by actual payment execution (for example settled/auto-reimbursable/pay-at-end constraints).
   

   App/src/libs/ReportPrimaryActionUtils.ts

   Lines 170 to 227 in 1d43910

   	function isPrimaryPayAction(
   	report: Report,
   	currentUserAccountID: number,
   	currentUserLogin: string,
   	bankAccountList: OnyxEntry<BankAccountList>,
   	policy?: Policy,
   	reportNameValuePairs?: ReportNameValuePairs,
   	isChatReportArchived?: boolean,
   	invoiceReceiverPolicy?: Policy,
   	reportActions?: ReportAction[],
   	isSecondaryAction?: boolean,
   	) {
   	if (isArchivedReport(reportNameValuePairs) || isChatReportArchived) {
   	return false;
   	}
   	const isExpenseReport = isExpenseReportUtils(report);
   	const isReportPayer = isPayer(currentUserAccountID, currentUserLogin, report, bankAccountList, policy, false);
   	const arePaymentsEnabled = arePaymentsEnabledUtils(policy);
   	const isReportApproved = isReportApprovedUtils({report});
   	const isReportClosed = isClosedReportUtils(report);
   	const isProcessingReport = isProcessingReportUtils(report);
   	const isExported = isExportedUtil(reportActions);
   	const hasExportError = hasExportErrorUtil(reportActions, report);
   	const didExportFail = !isExported && hasExportError;
   	const isApprovalEnabled = policy ? policy.approvalMode && policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
   	const isSubmittedWithoutApprovalsEnabled = !isApprovalEnabled && isProcessingReport;
   	const isReportFinished = (isReportApproved && !report.isWaitingOnBankAccount) || isSubmittedWithoutApprovalsEnabled || isReportClosed;
   	const {reimbursableSpend} = getMoneyRequestSpendBreakdown(report);
   	if (isReportPayer && isExpenseReport && arePaymentsEnabled && isReportFinished && reimbursableSpend !== 0) {
   	return isSecondaryAction ?? !didExportFail;
   	}
   	if (!isProcessingReport) {
   	return false;
   	}
   	const isIOUReport = isIOUReportUtils(report);
   	if (isIOUReport && isReportPayer && reimbursableSpend > 0) {
   	return true;
   	}
   	const isInvoiceReport = isInvoiceReportUtils(report);
   	if (!isInvoiceReport) {
   	return false;
   	}
   	const parentReport = getParentReport(report);
   	if (parentReport?.invoiceReceiver?.type === CONST.REPORT.INVOICE_RECEIVER_TYPE.INDIVIDUAL && reimbursableSpend > 0) {
   	return parentReport?.invoiceReceiver?.accountID === currentUserAccountID;
   	}
   	return invoiceReceiverPolicy?.role === CONST.POLICY.ROLE.ADMIN && reimbursableSpend > 0;
   	}

   
   

   App/src/libs/actions/OnyxDerived/configs/todos.ts

   Lines 67 to 68 in 1d43910

   	if (isPrimaryPayAction(report, currentUserAccountID, login, bankAccountList, policy, reportNameValuePair)) {
   	reportsToPay.push(report);

2. The real payment button/flow uses canIOUBePaid(), which has stricter checks (!isSettled, !isAutoReimbursable, !isPayAtEndExpenseReport, archive checks, etc.), so a report may be shown as "Pay" in Home but not actually eligible to be paid.
   

   App/src/libs/actions/IOU/index.ts

   Lines 10466 to 10493 in 1d43910

   	const isPayer = isPayerReportUtils(userAccountID, currentUserEmail, iouReport, bankAccountList, policy, onlyShowPayElsewhere);
   	const {reimbursableSpend} = getMoneyRequestSpendBreakdown(iouReport);
   	const isAutoReimbursable = policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES ? false : canBeAutoReimbursed(iouReport, policy);
   	const isPayAtEndExpenseReport = isPayAtEndExpenseReportReportUtils(iouReport ?? undefined, transactions);
   	const isProcessing = isProcessingReport(iouReport);
   	const isApprovalEnabled = policy ? policy.approvalMode && policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
   	const isSubmittedWithoutApprovalsEnabled = !isApprovalEnabled && isProcessing;
   	const isApproved = isReportApproved({report: iouReport}) || isSubmittedWithoutApprovalsEnabled;
   	const isClosed = isClosedReportUtil(iouReport);
   	const isReportFinished = (isApproved || isClosed) && !iouReport?.isWaitingOnBankAccount;
   	const isIOU = isIOUReport(iouReport);
   	const canShowMarkedAsPaidForNegativeAmount = onlyShowPayElsewhere && reimbursableSpend < 0;
   	if (isIOU && isPayer && !iouSettled && reimbursableSpend > 0) {
   	return true;
   	}
   	return (
   	isPayer &&
   	isReportFinished &&
   	!iouSettled &&
   	(reimbursableSpend > 0 || canShowMarkedAsPaidForNegativeAmount) &&
   	!isChatReportArchived &&
   	!isAutoReimbursable &&
   	!isPayAtEndExpenseReport &&
   	(!isExpenseReport(iouReport) || arePaymentsEnabled(policy as OnyxEntry<OnyxTypes.Policy>))
   	);

3. In the report UI flow, payment callbacks can return without user feedback when required report data is missing at click time (!chatReport early-return path / guarded pay branch), which makes the "nothing happens" symptom worse during timing gaps.
   

   App/src/components/MoneyReportHeader.tsx

   Lines 581 to 585 in 1d43910

   	const confirmPayment = useCallback(
   	(type?: PaymentMethodType | undefined, payAsBusiness?: boolean, methodID?: number, paymentMethod?: PaymentMethod) => {
   	if (!type || !chatReport) {
   	return;
   	}

   
   

   App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

   Lines 250 to 262 in 1d43910

   	const confirmPayment = useCallback(
   	(type: PaymentMethodType | undefined, payAsBusiness?: boolean, methodID?: number, paymentMethod?: PaymentMethod) => {
   	if (!type) {
   	return;
   	}
   	setPaymentType(type);
   	setRequestType(CONST.IOU.REPORT_ACTION_TYPE.PAY);
   	if (isDelegateAccessRestricted) {
   	showDelegateNoAccessModal();
   	} else if (hasHeldExpensesReportUtils(iouReport?.reportID)) {
   	setIsHoldMenuVisible(true);
   	} else if (chatReport && iouReport) {
   	startAnimation();

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

1. Create a shared pay-eligibility helper used by both isPrimaryPayAction() and canIOUBePaid() (or have isPrimaryPayAction() delegate to the same core checks).
2. Ensure Home/To-do and Reports pay chips only appear when the report is truly payable by the same criteria used by payment execution (!isSettled, not auto-reimbursable, not pay-at-end, etc.).
3. In payment confirm handlers, replace silent return paths with explicit UX feedback (e.g., disabled state + "loading report/payment details" or a short error toast) when required report data is not ready.
4. Add regression tests that validate parity between listing eligibility and execution eligibility for finished/done expense reports across NewDot + Classic visibility expectations.

What alternative solutions did you explore? (Optional)

• Only patching the MoneyReportHeader/preview no-op branch would improve feedback but would not fix the core mismatch where Home still advertises "Pay" for reports that fail execution rules.
• Only hiding pay buttons in one surface (Home or report page) would reduce symptoms but keep logic drift; the sustainable fix is a single shared eligibility rule.

[trasnake87]

Proposal

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

A reimbursable report submitted in a personal workspace appears in the Home "Pay" shortcut, but clicking "Pay > Mark as Paid" does nothing, the expense is not visible inside the report, and Classic shows no payment action either.

What is the root cause of that problem?

The root cause is a mismatch in MoneyReportHeader.tsx between the button-visibility logic and the button-action logic. At line 602, shouldShowPayButton is computed purely from canIOUBePaid:

https://github.com/Expensify/App/blob/main/src/components/MoneyReportHeader.tsx#L602

For IOU reports (personal workspace), canIOUBePaid in src/libs/actions/IOU/index.ts returns true at line 9851 without ever inspecting chatReport:

https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/index.ts#L9851

However, the confirmPayment callback on the same MoneyReportHeader (line 669) gates the entire payment on chatReport being truthy:

https://github.com/Expensify/App/blob/main/src/components/MoneyReportHeader.tsx#L669

When a user navigates from the Home Pay shortcut directly to the expense report (via EXPENSE_REPORT_RHP), the chat report may not yet be in Onyx (it is not pre-fetched by SearchMoneyRequestReportPage), so chatReport resolves to null. The Pay button renders because canIOUBePaid ignores chatReport for IOU paths, but clicking it silently returns at line 669.

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

We should gate shouldShowPayButton on chatReport being available, so the button only renders when the payment can actually execute. In MoneyReportHeader.tsx:

// src/components/MoneyReportHeader.tsx line 602
// Before:
const shouldShowPayButton = isPaidAnimationRunning || canIOUBePaid || onlyShowPayElsewhere || reportHasOnlyNonReimbursableTransactions;

// After:
const shouldShowPayButton =
    isPaidAnimationRunning ||
    ((canIOUBePaid || onlyShowPayElsewhere || reportHasOnlyNonReimbursableTransactions) && !isEmptyObject(chatReport));

This ensures the Pay button only appears when we have the data required to complete the payment. Once openReport completes and the chat report loads into Onyx, chatReport will become non-null and the button will appear. This eliminates the confusing "nothing happens" experience entirely, replacing it with the button appearing once the report data is ready.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656