[Due for payment 2026-08-25] Invoice - "marked as paid" system message is different when copied as sender

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.45-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: #97022
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• User has sent an invoice. The invoice is paid by the receiver.
• Perform the steps below as sender:

1. Go to staging.new.expensify.com
2. Go to invoice room.
3. Open the paid invoice.
4. Right click on the paid system message > Copy to clipboard.
5. Paste the message on the composer.

Expected Result:

"marked as paid" will be pasted.

Actual Result:

"paid . Add a bank account to receive your payment." is pasted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7219096_1785179342943.1.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081833556087764882
• Upwork Job ID: 2081833556087764882
• Last Price Increase: 2026-07-27

Issue Owner

Current Issue Owner: @mallenexpensify

[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/56c039c06beb6e20545dce90e1a476abeba8447c728bfdf699a2e26d1049601a

[MelvinBot]

Proposal

What is the root cause of that problem?

Copying the message does not copy the "marked as paid" text you see on screen — it recomputes the text from scratch via getIOUReportActionDisplayMessage in the copy handler at ContextMenuActions.tsx:990.

Inside that function, the ELSEWHERE (marked-as-paid) branch picks between two strings based on a heuristic:

translationKey = hasMissingInvoiceBankAccount(IOUReportID) ? 'iou.payerSettledWithMissingBankAccount' : 'iou.paidElsewhere';

(ReportUtils.ts:10968)

For the sender, hasMissingInvoiceBankAccount returns true (they own the settled invoice and have no invoice bank account on the policy), so it returns payerSettledWithMissingBankAccount — "paid ${amount}. Add a bank account to receive your payment." — and the branch passes an empty amount (ReportUtils.ts:10993-10994). That yields the exact broken string reported: paid . Add a bank account to receive your payment.

Note the in-code comment on that heuristic already flags it as a temporary/buggy behavior tied to an internal tracking issue (Expensify/Expensify#507850).

Why the on-screen text still shows "marked as paid" (the display/copy mismatch)

The on-screen render also calls the same function (IouReportActionMessage.tsx:45), so in principle both paths should produce the same string. The difference is that hasMissingInvoiceBankAccount reads non-reactive module caches (deprecatedAllReports, getPolicy, isSettled) rather than the useOnyx subscriptions the component re-renders on. The displayed value is computed/memoized at one moment (when the heuristic returned false → paidElsewhere → "marked as paid"), while the right-click copy recomputes it later against updated caches (heuristic now true). This exact-mechanism part is not runtime-verified — confirming it would require inspecting Onyx policy.invoice.bankAccount and the invoice statusNum at both moments. What is confirmed by code is which branch produces the copied string and why the amount is empty.

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

1. Fix the broken string regardless of the mismatch: the payerSettledWithMissingBankAccount branch always passes an empty amount, so the copy (and any surface using it) reads "paid . Add a bank account…". Either pass the real formatted amount into that branch, or reword the string so it doesn't depend on an amount.
2. Make copy consistent with what's displayed: the copied text of a "marked as paid" system message should match the visible message. The cleanest options are (a) copy the report action's stored message rather than recomputing the heuristic in the copy path, or (b) make hasMissingInvoiceBankAccount reactive so display and copy always agree.
3. The underlying heuristic is already earmarked for a proper fix under the internal issue referenced in the code comment; the App-side changes above address the user-visible symptom in the meantime.

What alternative solutions did you explore? (Optional)

Confirming the exact display-vs-copy timing via a runtime repro (Onyx state inspection at render time vs. copy time) would let us decide between fix (2a) and (2b) with certainty.

---

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

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@Krishna2323 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[Krishna2323]

@MelvinBot Your root cause looks wrong. Please re-investigate.

You say the on-screen render also calls getIOUReportActionDisplayMessage (via IouReportActionMessage.tsx:45), and that display and copy diverge because hasMissingInvoiceBankAccount reads stale non-reactive caches. I don't think either part is true.

IouReportActionMessage is never reached here. ActionContentRouter.tsx:280 catches every IOU action with originalMessage.type === PAY and sends it to PaymentContent, before the ChatMessageContent fallback at line 506 that would reach IouReportActionMessage. So display goes through PaymentContent.tsx:37-39:

if (paymentType === CONST.IOU.PAYMENT_TYPE.ELSEWHERE) {
    return <ReportActionItemBasicMessage message={getElsewherePaymentReportActionMessage(translate, originalMessage)} />;
}

That never calls hasMissingInvoiceBankAccount. It always gives "marked as paid".

I added logs at all three sites and reproduced:

• On render, only PaymentContent fires -> "marked as paid".
• getIOUReportActionDisplayMessage does not fire on render at all. It fires only on right-click -> Copy, with hasMissingInvoiceBankAccount: true and the clipboard string "paid . Add a bank account to receive your payment.".
• At that moment ownerAccountID === currentUserAccountID, transferBankAccountID is undefined, and isSettled is true. All three genuinely hold, so the value isn't stale — it's correct for a check that shouldn't run in the copy path.

Staleness would require the heuristic to run twice with different results. It runs once, only on copy.

So the real cause looks like duplicated logic: PaymentContent and getIOUReportActionDisplayMessage are two separate implementations of the same message, and only the second has the hasMissingInvoiceBankAccount check plus the empty-amount translate(translationKey, '') in the payerSettledWithMissingBankAccount branch. Fix should remove that divergence rather than make the heuristic reactive.

Also, in the render log the action's reportID was undefined while in the copy log it was set, same reportActionID. Since getIOUReportActionDisplayMessage derives IOUReportID from reportAction?.reportID, the two sites aren't even getting the same inputs — reactivity alone wouldn't make them match.

Same divergence likely affects invoice payments via Expensify/VBBA: PaymentContent.tsx:63-76 formats a real amount, while getIOUReportActionDisplayMessage passes an empty amount to iou.settleInvoiceBusiness/iou.settleInvoicePersonal. Less visible because those strings handle an empty amount gracefully.

Can you verify the above and confirm before we settle on a fix?

[MelvinBot]

You're right on every point — thanks for the careful re-investigation. My earlier "stale non-reactive caches / display and copy diverge" mechanism was wrong. Verified against 4793a8f:

Corrected root cause: display and copy are two separate implementations of the same message, and only the copy path runs the hasMissingInvoiceBankAccount heuristic with an empty amount. There is no staleness — the heuristic runs exactly once, on copy.

• Display: ActionContentRouter.tsx:280 routes every IOU PAY action to PaymentContent before the ChatMessageContent fallback, so IouReportActionMessage is never reached. PaymentContent's ELSEWHERE branch (PaymentContent.tsx:37-39) calls getElsewherePaymentReportActionMessage, which never calls hasMissingInvoiceBankAccount → always iou.paidElsewhere → "marked as paid".
• Copy: ContextMenuActions.tsx:991 → getIOUReportActionDisplayMessage, whose own ELSEWHERE branch has the heuristic (ReportUtils.ts:10996) and, when it returns true, emits payerSettledWithMissingBankAccount with an empty amount (ReportUtils.ts:11024-11026). String template is paid ${amount}. Add a bank account… → "paid . Add a bank account to receive your payment." — the exact reported output.

Recommended fix (matches your direction): remove the divergence rather than make the heuristic reactive. Either copy the same message the display path renders, or have getIOUReportActionDisplayMessage's ELSEWHERE branch delegate to getElsewherePaymentReportActionMessage so both surfaces share one implementation.

Invoice VBBA/Expensify divergence also confirmed: display formats a real amount (PaymentContent.tsx:63-76) while copy passes '' to settleInvoiceBusiness/settleInvoicePersonal (ReportUtils.ts:11001). It's just less visible because those strings degrade gracefully on an empty amount ("Paid with business account" vs. "paid $X with business account …"). Consolidating the two implementations fixes this case too.

On the render-log reportID: undefined observation

Consistent with your point that the two sites aren't even fed the same inputs: PaymentContent never reads reportID at all (it works purely off originalMessage), whereas the copy path derives IOUReportID = reportAction?.reportID (ReportUtils.ts:10984) and feeds it to hasMissingInvoiceBankAccount. So even if reactivity were the issue, it couldn't reconcile the two — they're different code paths with different inputs.

---

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

[Krishna2323]

Thanks for the correction — we're aligned on the root cause now. A few things I'd like to clarify before moving forward, plus one additional finding.

New finding

I think the remaining callers of hasMissingInvoiceBankAccount are actually unreachable.

The function itself requires the report to be settled (isSettled(iouReportID)), but both remaining callers also check !isSettled(...), so the condition is self-contradictory and should always evaluate to false.

Could you please verify that? If that's correct, the HAS_MISSING_INVOICE_BANK_ACCOUNT attention/RBR state never fires today, so removing this copy isn't hiding an existing product nudge. It probably deserves its own issue rather than being bundled into this PR.

A few things to clarify

1. Could we explicitly decide the scope here? Either:

   • the minimal fix (remove the ternary so the ELSEWHERE branch always uses iou.paidElsewhere), or
   • fully consolidate the logic into a shared helper used by both PaymentContent and the copy path.

2. Small correction: the ELSEWHERE branch already delegates to getElsewherePaymentReportActionMessage via the translationKey === 'iou.paidElsewhere' check. The delegation isn't missing—the heuristic is just routing around it. So the minimal fix is removing the ternary.

3. Your comment gets cut off at "On the render-log reportID: undefined observation...". I'd like to understand that part, especially if we're planning to share the helper. Why do the two call sites receive different action shapes?

4. What should we do with payerSettledWithMissingBankAccount? It becomes unused across all language files. Remove it now, or leave it until Expensify/Expensify#507850?

5. Could you also confirm getIOUReportActionDisplayMessage at ReportUtils.ts:5664 (isSentMoneyReportAction) isn't affected? I don't think it is, but it would be good to confirm.

6. Finally, could you please add a unit test covering the ELSEWHERE branch for an invoice sender, asserting the copied string is "marked as paid"? That should prevent this from regressing.

@MelvinBot check these new findings and update your proposal and then we can proceed with the PR.