[$250] Spend-Invoice report title in the message preview doesn't match the actual title

[applause-bot]

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.4.36-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176922/test-cases/41237520
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacBook Air 26.5.2 Chrome, iPhone 15 iOs 26.5.2
App Component: Search

Action Performed:

1. Create a workspace
2. Enable Invoices in the workspace settings
3. Send an invoice to another existing account
4. Open the invoice report, send a message in the details
5. Note the invoice report title
6. Navigate to Spend - Chats, observe the invoice report title in the message preview

Expected Result:

The invoice report title in the message preview matches the actual invoice report title

Actual Result:

The invoice report title in the message preview does not match the actual invoice report title. It shows "In $xx expense", instead of "User owes $xx"

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210869_1784310434537.Invoice_title.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7210869

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078189374610979579
• Upwork Job ID: 2078189374610979579
• Last Price Increase: 2026-07-17

Issue Owner

Current Issue Owner: @madmax330

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f64813395a42532826ace6d46739e47916b3daff16dfa0b7f7403022a55f4637

[MelvinBot]

Proposal

What is the root cause of that problem?

When you comment inside an invoice, the comment lives in a chat thread whose parent is the invoice report. The invoice report's own title is built from iou.payerOwesAmount → "User owes $xx", but the thread's name is built from the generic transaction-thread path, which returns iou.threadExpenseReportName → "$xx expense". Search → Chats labels each row In <report name> using that thread name, so it shows "In $xx expense" instead of the invoice title.

The core issue is an inconsistency the code already knows about elsewhere: getReportForHeader explicitly resolves an invoice chat thread to its parent invoice report so the header reads correctly — but the name-generation path (computeChatThreadReportName) does not apply that same rule. So the header says "User owes $xx" while the Search preview says "In $xx expense".

Evidence / trace

• Search → Chats builds each row and sets reportName: getReportName(report, …) — the In <chat name> label: SearchUIUtils.ts:2793.
• For a transaction/invoice chat thread, computeReportName short-circuits on the thread name and returns it before ever reaching the invoice branch: ReportNameUtils.ts:1015-1028.
• The thread name comes from the transaction-thread branch → getTransactionReportName, whose final return is iou.threadExpenseReportName. That key = `${amount} ${comment ? `for ${comment}` : 'expense'}` → "$xx expense" (en.ts:1574).
• The correct invoice title comes from getMoneyRequestReportName → iou.payerOwesAmount = `${payer} owes ${amount}` → "User owes $xx" (en.ts:1498).
• Existing precedent that invoice threads should display as their parent invoice report: getReportForHeader.

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

Make the name path apply the same invoice-thread rule the header already uses. In computeChatThreadReportName (transaction-thread branch), when the thread's parent report is an invoice report, return the invoice report title (the payerOwesAmount path via getInvoiceReportName) instead of the generic threadExpenseReportName, mirroring getReportForHeader. That fixes the Search preview and keeps it consistent with the report header and LHN.

What alternative solutions did you explore? (Optional)

Fixing it only at the Search layer (resolve the parent invoice report inside getReportActionsSections) would patch this screen but leave the underlying thread name inconsistent elsewhere, so the shared name path is the better place. Note: a plain expense's thread legitimately shows "$xx expense" — the change must be scoped to threads whose parent is an invoice report only.

Confidence & what would raise it

Medium–high. The string "In $xx expense" can only be produced by threadExpenseReportName, and the header-vs-preview inconsistency is confirmed by getReportForHeader. The one unverified assumption is that the tester's message created a chat thread whose parent is the invoice report (consistent with the observed string). Reproducing the flow and confirming the row's report resolves to an invoice-parented thread would make this high confidence.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96420) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 18:47:11 UTC.

Proposal

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

In Search → Chats, a message sent inside an invoice expense's details is grouped under a report labeled In $xx expense (e.g. In $13.00 expense), which does not match the actual invoice report title <receiver> owes $xx (e.g. Amina owes $13.00).

What is the root cause of that problem?

The In <name> label next to a chat search result is the report's name, resolved by getReportName → computeReportName.

When you comment in a single‑expense invoice, the comment is posted in the expense's transaction thread, not in the invoice report itself. For that thread, computeReportName first hits computeChatThreadReportName, and because the parent action is a transaction thread (isTransactionThread) it returns getTransactionReportName(...) and stops there:

App/src/libs/ReportNameUtils.ts

Lines 875 to 890 in 2a50714

	if (!isEmptyObject(parentReportAction) && isTransactionThread(parentReportAction)) {
	const linkedTransactionID = getLinkedTransactionID(parentReportAction);
	const linkedTransaction = linkedTransactionID ? transactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${linkedTransactionID}`] : undefined;
	const linkedTransactionReport = linkedTransaction?.reportID ? reports?.[`${ONYXKEYS.COLLECTION.REPORT}${linkedTransaction.reportID}`] : undefined;
	let formattedName = getTransactionReportName({
	translate,
	reportAction: parentReportAction,
	linkedTransaction,
	report: linkedTransactionReport,
	});
	if (isArchivedNonExpense) {
	formattedName = generateArchivedReportName(formattedName);
	}
	return formatReportLastMessageText(formattedName);
	}

getTransactionReportName has no invoice branch — its terminal case always returns the generic iou.threadExpenseReportName label:

App/src/libs/ReportUtils.ts

Lines 5628 to 5631 in 2a50714

	const amount = getTransactionAmount(linkedTransaction, !isEmptyObject(report) && isExpenseReport(report), linkedTransaction?.reportID === CONST.REPORT.UNREPORTED_REPORT_ID) ?? 0;
	const formattedAmount = convertToDisplayString(amount, getCurrency(linkedTransaction)) ?? '';
	const comment = getMerchantOrDescription(linkedTransaction);
	return translate('iou.threadExpenseReportName', formattedAmount, Parser.htmlToText(comment));

which renders as $13.00 expense:

App/src/languages/en.ts

Line 1573 in 2a50714

threadExpenseReportName: (formattedAmount: string, comment?: string) => `${formattedAmount} ${comment ? `for ${comment}` : 'expense'}`,

Because computeChatThreadReportName returns early, the invoice‑specific naming a few lines below — getInvoiceReportName, which produces Amina owes $13.00 — is never reached for the thread:

App/src/libs/ReportNameUtils.ts

Lines 1054 to 1063 in 2a50714

	if (isInvoiceReport(report)) {
	const chatReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.chatReportID}`];
	let chatReceiverPolicyID: string | undefined;
	const chatReceiver = chatReport?.invoiceReceiver as unknown;
	if (chatReceiver && typeof chatReceiver === 'object' && 'policyID' in chatReceiver) {
	chatReceiverPolicyID = (chatReceiver as {policyID: string}).policyID;
	}
	const invoiceReceiverPolicy = chatReceiverPolicyID ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${chatReceiverPolicyID}`] : undefined;
	formattedName = getInvoiceReportName(report, translate, policy, invoiceReceiverPolicy);
	}

So the transaction thread of an invoice is named like a plain expense ($13.00 expense) instead of inheriting the invoice title (Amina owes $13.00).

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

In computeChatThreadReportName, when the transaction thread's linked report is an invoice report, name it from the invoice report instead of the generic expense label:

if (!isEmptyObject(parentReportAction) && isTransactionThread(parentReportAction)) {
    const linkedTransactionID = getLinkedTransactionID(parentReportAction);
    const linkedTransaction = linkedTransactionID ? transactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${linkedTransactionID}`] : undefined;
    const linkedTransactionReport = linkedTransaction?.reportID ? reports?.[`${ONYXKEYS.COLLECTION.REPORT}${linkedTransaction.reportID}`] : undefined;

    let formattedName = isInvoiceReport(linkedTransactionReport)
        ? getInvoiceReportName(linkedTransactionReport, translate, policy)
        : getTransactionReportName({
              translate,
              reportAction: parentReportAction,
              linkedTransaction,
              report: linkedTransactionReport,
          });

    if (isArchivedNonExpense) {
        formattedName = generateArchivedReportName(formattedName);
    }
    return formatReportLastMessageText(formattedName);
}

getInvoiceReportName already returns <receiver> owes $xx for an open invoice, so the thread label now matches the invoice title. isInvoiceReport and getInvoiceReportName are already defined in this file, so no new imports are needed. For workspace‑receiver invoices we can resolve the receiver policy the same way the existing isInvoiceReport branch does (from the chat report's invoiceReceiver.policyID) and pass it as the fourth argument; for individual receivers (the reported case) no policy is required.

This is gated on isInvoiceReport(linkedTransactionReport), so regular expense/IOU transaction threads keep their existing $xx expense label.

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

• getReportName/computeReportName for a transaction thread whose linked transaction belongs to an open invoice report returns the invoice title (<receiver> owes $xx), not $xx expense.
• A transaction thread of a regular expense/IOU report still returns the $xx expense label (no regression).

What alternative solutions did you explore? (Optional)

• Add the invoice branch inside getTransactionReportName in ReportUtils.ts. Rejected: getInvoiceReportName/getMoneyRequestReportName live in ReportNameUtils.ts, which already imports getTransactionReportName from ReportUtils.ts, so calling back the other way introduces a circular import. Fixing it in computeChatThreadReportName keeps the invoice naming where it already lives.
• Special‑case the Search chat list at the rendering layer. Rejected: it would only patch this one surface, while the mismatch stems from the shared getReportName resolver and would still surface anywhere else the thread name is shown.

[aswin-s]

Proposal

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

On the Spend → Chats LHN, after sending a message in an invoice report's thread, the message preview displays the invoice thread title as "In $xx expense" instead of matching the actual invoice report title ("User owes $xx"). The word "expense" reveals the thread is being named with the generic expense format rather than the invoice-specific format.

What is the root cause of that problem?

getTransactionReportName at [src/libs/ReportUtils.ts:5605](https://github.com/Expensify/App/blob/5ed347bd61d2e69d2fd6405d38c8a88464e4e76b/src/libs/ReportUtils.ts#L5605)–5653 computes the LHN display name for a transaction thread. After early-exit guards (reversed, deleted, empty transaction, scanning, missing fields, pending waypoints, sent money), it falls through to a single unconditional return at line 5652:

return translate('iou.threadExpenseReportName', formattedAmount, Parser.htmlToText(comment));

iou.threadExpenseReportName (en.ts:1574) produces "$xx expense" (when no comment). There is no branch for report.type === CONST.REPORT.TYPE.INVOICE.

The caller, computeChatThreadReportName (src/libs/ReportNameUtils.ts:879), passes linkedTransactionReport as the report parameter — for an invoice, this IS the invoice report object. When a user replies in the invoice thread, the parent chat stores that thread name as childLastMessageText context (rendered as "In {threadName}" in the LHN), which becomes "In $xx expense" instead of "In User owes $xx".

The working analog that already produces the correct invoice name is getMoneyRequestReportName ([src/libs/ReportNameUtils.ts:387](https://github.com/Expensify/App/blob/5ed347bd61d2e69d2fd6405d38c8a88464e4e76b/src/libs/ReportNameUtils.ts#L387)–442). It has an explicit isInvoiceReport(report) branch (line 415–417) that calls getInvoicePayerName and then returns translate('iou.payerOwesAmount', formattedAmount, payerOrApproverName) → "User owes $xx" — exactly the actual invoice title format. The iou.payerOwesAmount key (en.ts:1498) is already present and localized in every locale file.

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

Single change — src/libs/ReportUtils.ts:5645 (before the final return in getTransactionReportName):

Add an invoice-report branch immediately after the isSentMoneyReportAction check and before the amount/formattedAmount lines:

// Add before line 5649
if (isInvoiceReport(report)) {
    return getMoneyRequestReportName({report, translate});
}

This delegates to the existing working helper which correctly produces "User owes $xx" for open invoices (via iou.payerOwesAmount), "User paid $xx" for settled invoices, and "Manager approved $xx" for approved invoices — keeping the thread title in sync with the actual invoice report title computed by computeReportName → getInvoiceReportName → getMoneyRequestReportName.

No new translation key is needed. getMoneyRequestReportName uses iou.payerOwesAmount, iou.payerPaidAmount, and iou.managerApprovedAmount which are already in all 10 locale files.

getTransactionReportName is called from three sites — all benefit from this fix:

• computeChatThreadReportName (ReportNameUtils.ts:879) — the LHN thread title path (primary)
• MergeTransactionsListContent — invoice display in merge UI
• Tests (tests/unit/ReportUtilsTest.ts)

Optional: Add a unit test in tests/unit/ReportUtilsTest.ts covering getTransactionReportName with a mock invoice report and verify it returns "ReceiverName owes $xx" to lock the new branch.

What alternative solutions did you explore? (Optional)

Alternative: Add new iou.threadInvoiceReportName translation key across all locale files. Rejected because iou.payerOwesAmount already exists in all locale files with the identical format ("${payer} owes ${amount}"), and getMoneyRequestReportName already handles all invoice state variants (open, settled, approved, waiting on bank). Creating a new key duplicates this infrastructure and introduces a maintenance burden of keeping two keys in sync across 10+ locale files.

Alternative: Fix in computeChatThreadReportName with an early-exit before calling getTransactionReportName. Rejected because it only fixes the LHN path and misses MergeTransactionsListContent, whereas fixing in getTransactionReportName covers all three call sites consistently.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

Search chat rows copy a static reportName onto each report action in getReportActionsSections() using getReportName(report, reportAttributesDerivedValue) (source). getReportName() does not compute invoice names; it only reads the derived report attribute and otherwise falls back to the raw report.reportName (source). For NewDot invoice reports, the actual report title is computed by getInvoiceReportName() / getMoneyRequestReportName() as payer owes amount (source, source), but the raw invoice report name can still be the generic transaction-thread-style value like $xx expense. When the Search result renders the In <report> header, SearchActionHeader asks getChatListItemReportName() for the label (source); if the live report is not available from Onyx, that helper uses the copied action.reportName before it can recompute the invoice title (source). That is why the preview can show In $xx expense while the invoice report header shows User owes $xx.

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

Compute the correct invoice report display name when building chat search report-action items instead of copying the raw fallback name. Specifically, update the type === CONST.SEARCH.DATA_TYPES.CHAT path in getSections() to pass translate into getReportActionsSections() (source), then have getReportActionsSections() set reportName through a small local helper.

That helper should keep the current getReportName(report, reportAttributesDerivedValue) behavior for non-invoice reports, but for isInvoiceReport(report) it should call getInvoiceReportName(report, translate, policy, invoiceReceiverPolicy). The needed policy data is already available in the search snapshot through existing helpers like getPolicyFromKey() and getChatReport() (source). For business invoice receivers, derive invoiceReceiverPolicy from the invoice room/chat report’s invoiceReceiver.policyID, matching the logic used by the report-title computation path (source).

This keeps the Search row fallback aligned with the real invoice report title even when the live Onyx report is not available at render time.

What alternative solutions did you explore? (Optional)

I also considered changing getChatListItemReportName() to ignore action.reportName for invoice-related search rows, but that would still leave incorrect invoice names stored on Search result items and would only fix this one render path. Computing the right title where the search item is created keeps the source of truth consistent for sorting, snapshots, and any other consumers of the same item data.

[MobileMage]

Proposal

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

When a workspace sends an invoice and someone posts a comment inside that invoice report, the invoice report's title inside the actual report header correctly shows the invoice-specific phrasing (e.g. "User owes $xx"). However, on the Search page's "Spend - Chats" tab, the same report is shown with a completely different, generic title such as an amount/expense style string instead of the invoice "owes" phrasing. The title used for the report row in Chats does not match the title of the report it links to.

What is the root cause of that problem?

The report header's title is built by getReportName in ReportNameUtils.ts, which explicitly special-cases invoice reports: when isInvoiceReport(report) is true it calls getInvoiceReportName(report, translate, policy, invoiceReceiverPolicy), which in turn calls getMoneyRequestReportName and takes the isInvoiceReport(report) branch to resolve the payer via getInvoicePayerName (individual receiver display name or receiver-policy name) before formatting iou.payerOwesAmount.

App/src/libs/ReportNameUtils.ts

Lines 1054 to 1062 in 5ed347b

	if (isInvoiceReport(report)) {
	const chatReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.chatReportID}`];
	let chatReceiverPolicyID: string | undefined;
	const chatReceiver = chatReport?.invoiceReceiver as unknown;
	if (chatReceiver && typeof chatReceiver === 'object' && 'policyID' in chatReceiver) {
	chatReceiverPolicyID = (chatReceiver as {policyID: string}).policyID;
	}
	const invoiceReceiverPolicy = chatReceiverPolicyID ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${chatReceiverPolicyID}`] : undefined;
	formattedName = getInvoiceReportName(report, translate, policy, invoiceReceiverPolicy);

The Chats row on the Search page, though, gets its text from getReportPreviewMessage in ReportUtils.ts (consumed via OptionsListUtils to build the last-message/preview text for LHN-style rows, which the Search "Chats" tab reuses). This function never calls isInvoiceReport anywhere in its body — it only special-cases split-bill actions, track-expense actions, approved/settled reports and non-reimbursable transactions. Because an invoice report is also a money-request-shaped report with a linked transaction and an iouReportAction, it falls straight into the generic early-return branch that any ordinary IOU/expense report would hit:

if (amount !== undefined && lastActorID && !isPreviewMessageForParentChatReport) {
    const amountToDisplay = convertToDisplayString(Math.abs(amount), currency);
    ...
    return `${requestorName ? `${requestorName}: ` : ''}${translate('iou.expenseAmount', amountToDisplay, comment)}`;
}

App/src/libs/ReportUtils.ts

Lines 5876 to 5885 in 5ed347b

	if (amount !== undefined && lastActorID && !isPreviewMessageForParentChatReport) {
	const amountToDisplay = convertToDisplayString(Math.abs(amount), currency);
	// We only want to show the actor name in the preview if it's not the current user who took the action
	const requestorName =
	lastActorID && lastActorID !== deprecatedCurrentUserAccountID
	? getDisplayNameForParticipant({accountID: lastActorID, shouldUseShortForm: !isPreviewMessageForParentChatReport, formatPhoneNumber: formatPhoneNumberPhoneUtils})
	: '';
	return `${requestorName ? `${requestorName}: ` : ''}${translate('iou.expenseAmount', amountToDisplay, comment)}`;
	}

iou.expenseAmount just formats "${formattedAmount}${comment ? ' for ${comment}' : ''}", producing a bare amount/expense-style string rather than the "X owes $xx" phrasing the header shows. There is no isInvoiceReport guard anywhere before this in getReportPreviewMessage, so invoice reports never get routed to the same getInvoiceReportName/getMoneyRequestReportName logic that the header uses, and the two title builders diverge for invoices only.

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

getReportPreviewMessage should short-circuit for invoice reports the same way getReportName does, delegating to the existing, already-correct helper instead of falling through the generic IOU branches. Right after the report is resolved (and before the split-bill/track-expense/amount branches), add an isInvoiceReport(report) check that returns getInvoiceReportName(report, translate, policy, invoiceReceiverPolicy) (passing through the policy/invoiceReceiverPolicy already threaded into this function's params, resolving invoiceReceiverPolicy the same way getReportName does from the report's chatReportID/invoiceReceiver), guaranteeing the Chats preview and the report header always render identical text for invoices:

if (isInvoiceReport(report)) {
    return getInvoiceReportName(report, translate, policy, invoiceReceiverPolicy);
}

This reuses the exact function already responsible for the correct header title, so there's no risk of the two diverging again, and it's a narrow, additive change that doesn't touch behavior for non-invoice IOU/expense reports.

What alternative solutions did you explore? (Optional)

An alternative would be to patch only the iou.expenseAmount/comment formatting so it reads more like an "owes" sentence, but that would just special-case the symptom for one branch while leaving the other branches (settled, approved, non-reimbursable) still capable of producing non-invoice phrasing for an invoice report; routing through getInvoiceReportName up front fixes all of them at once and keeps a single source of truth for invoice titles.

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 20:52:27 UTC.

How this proposal differs from the other proposals

Most other proposals stop at getReportPreviewMessage — they add !isInvoiceReport(report) to the "latest expense amount" branch and call it done. That only fixes the report-preview card (the "Abbasi owes …" card in the invoice room). It does not fix the symptom shown in the actual repro screenshot: the "In {reportName}" header on the chat row that reads "In PKR 89.00 expense".

This proposal's RCA is different in three ways:

1. It identifies that the reported symptom is a report-name path, not the preview-message path. The "In {name}" header comes from getChatListItemReportName → getTransactionReportName, a completely separate helper. A getReportPreviewMessage-only fix leaves the header wrong.
2. It traces where the comment actually lands. Commenting "in the details" of a single-expense invoice posts to the invoice's transaction thread (a CHAT-type thread), so the existing isInvoiceReport(report) guard in getChatListItemReportName is bypassed — something a preview-only RCA never surfaces.
3. It keeps the two preview helpers in sync and removes a latent bug. It also patches the English-only twin getReportPreviewReportActionMessage (the file requires the two stay in sync) and replaces an in-place Onyx-object mutation in the invoice branch with a copy.

Proposal

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

On an open invoice report, the report's actual title correctly reads "[Payer] owes [amount]" (e.g. "Abbasi owes PKR 89.00"), but in Spend → Chats (Search, type:chat) the same invoice surfaces with the wrong text — rendered as "[amount] expense" (e.g. "PKR 89.00 expense") instead of matching the real title.

What is the root cause of that problem?

There are actually two independent helpers that produce invoice-related preview text in this view, and each has its own gap:

1. The report preview message

getReportPreviewMessage (and its English-only twin getReportPreviewReportActionMessage) take an early "latest expense amount" branch whenever the report has a money-request action with an amount and an actor. That branch is meant for expense/IOU reports but was applied unconditionally, so invoice reports fell into it instead of the iou.payerOwesAmount branch a few lines below.

getReportPreviewMessage:

App/src/libs/ReportUtils.ts

Lines 5876 to 5884 in 5ed347b

	if (amount !== undefined && lastActorID && !isPreviewMessageForParentChatReport) {
	const amountToDisplay = convertToDisplayString(Math.abs(amount), currency);
	// We only want to show the actor name in the preview if it's not the current user who took the action
	const requestorName =
	lastActorID && lastActorID !== deprecatedCurrentUserAccountID
	? getDisplayNameForParticipant({accountID: lastActorID, shouldUseShortForm: !isPreviewMessageForParentChatReport, formatPhoneNumber: formatPhoneNumberPhoneUtils})
	: '';
	return `${requestorName ? `${requestorName}: ` : ''}${translate('iou.expenseAmount', amountToDisplay, comment)}`;

if (amount !== undefined && lastActorID && !isPreviewMessageForParentChatReport) {
    ...
    return `${requestorName ? `${requestorName}: ` : ''}${translate('iou.expenseAmount', amountToDisplay, comment)}`;
}

The same branch is duplicated in the English-only twin getReportPreviewReportActionMessage:

App/src/libs/ReportUtils.ts

Line 6092 in 5ed347b

if (amount !== undefined && lastActorID && !isPreviewMessageForParentChatReport) {

2. The "In {reportName}" header shown on each chat row

This is rendered by SearchActionHeader.tsx:

App/src/pages/inbox/report/SearchActionHeader.tsx

Line 39 in 5ed347b

const reportName = getChatListItemReportName(action, report, conciergeReportID, translate);

which calls getChatListItemReportName. That function already special-cases invoice reports — but only when the comment is posted directly on the invoice report:

App/src/libs/ReportUtils.ts

Lines 13053 to 13059 in 5ed347b

	function getChatListItemReportName(action: ReportAction & {reportName?: string}, report: Report | undefined, conciergeReportID: string | undefined, translate: LocalizedTranslate): string {
	if (report && isInvoiceReport(report)) {
	const properInvoiceReport = report;
	properInvoiceReport.chatReportID = report.parentReportID;
	return getInvoiceReportName(properInvoiceReport, translate);
	}

if (report && isInvoiceReport(report)) {
    const properInvoiceReport = report;
    properInvoiceReport.chatReportID = report.parentReportID;
    return getInvoiceReportName(properInvoiceReport, translate);
}

When a user opens an invoice and comments "in the details", the comment lands on the invoice's single-expense transaction thread (a CHAT-type thread whose parent is the invoice report), not the invoice report itself. So isInvoiceReport(report) is false, the branch is skipped, and the name falls through to the precomputed action.reportName, which was produced by getTransactionReportName:

App/src/libs/ReportUtils.ts

Lines 5605 to 5652 in 5ed347b

	function getTransactionReportName({
	translate,
	reportAction,
	linkedTransaction,
	report,
	}: {
	translate: LocalizedTranslate;
	reportAction: OnyxEntry<ReportAction | OptimisticIOUReportAction>;
	linkedTransaction: OnyxEntry<Transaction>;
	report: OnyxEntry<Report>;
	}): string {
	if (reportAction && isReversedTransaction(reportAction)) {
	return translate('parentReportAction.reversedTransaction');
	}
	if (reportAction && isDeletedAction(reportAction)) {
	return translate('parentReportAction.deletedExpense');
	}
	if (isEmptyObject(linkedTransaction)) {
	// Transaction data might be empty on app's first load, if so we fallback to Expense/Track Expense
	return isTrackExpenseAction(reportAction) ? translate('iou.createExpense') : translate('iou.expense');
	}
	if (isScanning(linkedTransaction)) {
	return translate('iou.receiptScanning', {count: 1});
	}
	if (hasMissingSmartscanFieldsTransactionUtils(linkedTransaction, report)) {
	return translate('iou.receiptMissingDetails');
	}
	if (isFetchingWaypointsFromServer(linkedTransaction) && getMerchant(linkedTransaction) === translate('iou.fieldPending')) {
	return translate('iou.fieldPending');
	}
	// The unit does not matter as we are only interested in whether the distance is zero or not
	if (isMapDistanceRequest(linkedTransaction) && !getDistanceInMeters(linkedTransaction, CONST.CUSTOM_UNITS.DISTANCE_UNIT_KILOMETERS) && !hasReceiptTransactionUtils(linkedTransaction)) {
	return translate('violations.noRoute');
	}
	if (isSentMoneyReportAction(reportAction)) {
	return getIOUReportActionDisplayMessage(translate, reportAction as ReportAction, linkedTransaction);
	}
	const amount = getTransactionAmount(linkedTransaction, !isEmptyObject(report) && isExpenseReport(report), linkedTransaction?.reportID === CONST.REPORT.UNREPORTED_REPORT_ID) ?? 0;
	const formattedAmount = convertToDisplayString(amount, getCurrency(linkedTransaction)) ?? '';
	const comment = getMerchantOrDescription(linkedTransaction);
	return translate('iou.threadExpenseReportName', formattedAmount, Parser.htmlToText(comment));

→ translate('iou.threadExpenseReportName', ...) → "[amount] expense":

App/src/languages/en.ts

Line 1574 in 5ed347b

threadExpenseReportName: (formattedAmount: string, comment?: string) => `${formattedAmount} ${comment ? `for ${comment}` : 'expense'}`,

(Separately, that branch also mutated the shared Onyx report object in place via properInvoiceReport.chatReportID = ....)

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

1. Exclude invoice reports from the "latest expense amount" branch

Apply this in both getReportPreviewMessage and getReportPreviewReportActionMessage (the file's own comment requires the two be kept in sync), so they fall through to the existing iou.payerOwesAmount branch that already matches getMoneyRequestReportName:

if (amount !== undefined && lastActorID && !isPreviewMessageForParentChatReport && !isInvoiceReport(report)) {

2. Resolve the invoice report for transaction threads too

Extend getChatListItemReportName so it resolves the invoice report both when the row's report is the invoice report and when it's a transaction thread whose parent is an invoice report, and stop mutating the Onyx object (use a copy):

const parentReport = report?.parentReportID ? getReport(report.parentReportID, deprecatedAllReports) : undefined;
const invoiceReport = report && isInvoiceReport(report) ? report : parentReport && isInvoiceReport(parentReport) ? parentReport : undefined;
if (invoiceReport) {
    const properInvoiceReport = {...invoiceReport, chatReportID: invoiceReport.chatReportID ?? invoiceReport.parentReportID};
    return getInvoiceReportName(properInvoiceReport, translate);
}

isInvoiceReport, getReport, deprecatedAllReports, and getInvoiceReportName are all already imported/used in ReportUtils.ts, so no new imports are needed. With both changes, open invoice reports produce a preview and a chat-row title that match the actual invoice report title (e.g. "Abbasi owes PKR 89.00") — regardless of whether the last activity was the invoice preview or a comment on its transaction thread.

Demo

Screen.Recording.2026-07-18.at.1.05.41.AM.mov

[ahmdshrif]

Proposal

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

For a Spend-Invoice report, the report title shown in the message/last-message preview does not match the report's actual title (the one rendered in the report header / details). The two are produced by different code paths that diverge for invoice reports.

What is the root cause of that problem?

The actual invoice title is computed live from the report state via getReportName → getInvoiceReportName → getMoneyRequestReportName (which returns the amount/payer-based name, e.g. the "spent/owes/paid" wording):

• App/src/libs/ReportNameUtils.ts

  Lines 356 to 359 in 5ed347b

  	function getInvoiceReportName(report: OnyxEntry<Report>, translate: LocalizedTranslate, policy?: OnyxEntry<Policy>, invoiceReceiverPolicy?: OnyxEntry<Policy>): string {
  	const moneyRequestReportName = getMoneyRequestReportName({report, policy, invoiceReceiverPolicy, translate});
  	const oldDotInvoiceName = report?.reportName ?? moneyRequestReportName;
  	return isNewDotInvoice(report?.chatReportID) ? moneyRequestReportName : oldDotInvoiceName;

• App/src/libs/ReportNameUtils.ts

  Lines 387 to 442 in 5ed347b

  	function getMoneyRequestReportName({
  	report,
  	policy,
  	invoiceReceiverPolicy,
  	translate,
  	}: {
  	report: OnyxEntry<Report>;
  	policy?: OnyxEntry<Policy>;
  	invoiceReceiverPolicy?: OnyxEntry<Policy>;
  	translate: LocalizedTranslate;
  	}): string {
  	// For expense reports with empty fieldList and empty reportName, return "New Report" (matches OldDot behavior)
  	if (isExpenseReport(report)) {
  	if (report?.reportName === '' && isPolicyFieldListEmpty(policy)) {
  	return CONST.REPORT.DEFAULT_EXPENSE_REPORT_NAME;
  	}
  	}
  	if (report?.reportName && isExpenseReport(report)) {
  	return report.reportName;
  	}
  	const moneyRequestTotal = getMoneyRequestSpendBreakdown(report).totalDisplaySpend;
  	const formattedAmount = convertToDisplayString(moneyRequestTotal, report?.currency);
  	let payerOrApproverName;
  	if (isExpenseReport(report)) {
  	const parentReport = getParentReport(report);
  	payerOrApproverName = getPolicyName({report: parentReport ?? report, policy});
  	} else if (isInvoiceReport(report)) {
  	const chatReport = getReportOrDraftReport(report?.chatReportID);
  	payerOrApproverName = getInvoicePayerName(chatReport, translate, invoiceReceiverPolicy);
  	} else {
  	payerOrApproverName = getDisplayNameForParticipant({accountID: report?.managerID, formatPhoneNumber: formatPhoneNumberPhoneUtils, translate}) ?? '';
  	}
  	const payerPaidAmountMessage = translate('iou.payerPaidAmount', formattedAmount, payerOrApproverName);
  	if (isReportApproved({report})) {
  	return translate('iou.managerApprovedAmount', payerOrApproverName, formattedAmount);
  	}
  	if (report?.isWaitingOnBankAccount) {
  	return `${payerPaidAmountMessage} ${CONST.DOT_SEPARATOR} ${translate('iou.pending')}`;
  	}
  	if (!isSettled(report?.reportID) && hasNonReimbursableTransactions(report?.reportID)) {
  	payerOrApproverName = getDisplayNameForParticipant({accountID: report?.ownerAccountID, formatPhoneNumber: formatPhoneNumberPhoneUtils, translate}) ?? '';
  	return translate('iou.payerSpentAmount', formattedAmount, payerOrApproverName);
  	}
  	if (isProcessingReport(report) || isOpenExpenseReport(report) || isOpenInvoiceReport(report) || moneyRequestTotal === 0) {
  	return translate('iou.payerOwesAmount', formattedAmount, payerOrApproverName);
  	}
  	return payerPaidAmountMessage;
  	}

The preview title, however, falls back to the report action's stored childReportName — a static snapshot captured when the report-preview action was created — instead of re-deriving the name from the live report:

• App/src/libs/ReportUtils.ts

  Line 5681 in 5ed347b

  return getReportName(report, reportAttributes ?? reportAttributesDerivedValue) || (originalReportAction?.childReportName ?? '');

• App/src/libs/ReportUtils.ts

  Line 5706 in 5ed347b

  return !!originalReportAction?.childReportName && originalReportAction?.childMoneyRequestCount === 0 ? originalReportAction?.childReportName : reportActionMessage;

Because the invoice name is amount/state-dependent and childReportName is not refreshed when the invoice total/status changes, the preview shows the stale snapshot while the header shows the live title — the mismatch reported here.

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

For invoice reports, derive the preview title from the live report name rather than the stale snapshot: prefer getReportName(report) and only fall back to childReportName when the report itself is unavailable. In the preview getters (ReportUtils.ts):

// instead of returning the stored childReportName snapshot for a loaded invoice report,
// use the live-computed name so it stays consistent with the header/details title
return getReportName(report, reportAttributes) || (originalReportAction?.childReportName ?? '');

The same fallback at ReportUtils.ts:5706 (empty/short-circuit branch) should not win over the live name once the report is loaded for invoice reports.

Regression note: keep the childReportName fallback for the genuinely-unavailable-report case (settled/unloaded iouReports) so non-invoice previews are unaffected.

[aswin-s]

Proposal

Updated