[Due for payment 2026-06-19] Invoices - Invoice report field is not shown for invoice receiver

[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.5-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #73887
Email or phone of affected tester (no customers): sjdoisjndojsdoijsioj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Enable Invoices in workspace settings.
• User has created any type of invoice report field in workspace settings > Invoices > Invoice fields.

1. Go to staging.new.expensify.com
   2 [Sender] Send an invoice to any user.
2. [Receiver] Open the invoice report.

Expected Result:

Receiver can see the invoice report field.

Actual Result:

Receiver cannot see the invoice report field.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7177429_1781135486140.7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7177429

[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/cd68559b8895ad9a2a895534c7b4f5df470c486942786750ebc083a87851bee9

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #73887

[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.

[MelvinBot]

Proposal

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

When a workspace sends an invoice, the receiver cannot see the invoice report field, even though the sender can. Introduced by the new invoice fields feature in #73887 (deploy blocker, not in production).

What is the root cause of that problem?

PR #73887 changed the visibility gate for report fields on invoice reports. It now requires the brand‑new policy flag areInvoiceFieldsEnabled, instead of the previously‑used areReportFieldsEnabled:

• MoneyReportView.tsx:155 → const areFieldsEnabledForReport = isInvoiceReport ? policy?.areInvoiceFieldsEnabled : policy?.areReportFieldsEnabled;
• MoneyRequestViewReportFields.tsx:124
• DynamicEditReportFieldPage.tsx:84

The policy object these components use is usePolicy(report.policyID), and an invoice report's policyID points to the sender's workspace. The receiver is not a member/admin of that workspace, so they only get a reduced copy of the sender's policy in Onyx. That reduced copy historically includes areReportFieldsEnabled and fieldList (which is why expense‑report fields render for the receiver), but it does not include the newly‑added areInvoiceFieldsEnabled flag. So for the receiver the gate evaluates to undefined → falsy → fields hidden. The sender has the full policy, so the flag is truthy and they see the fields.

The flag is only ever set optimistically on the sender's side in Policy.ts (enablePolicyInvoiceFields/enablePolicyFields); nothing writes it into a receiver's Onyx.

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

Don't gate the receiver's view on the admin‑only areInvoiceFieldsEnabled flag that isn't propagated to them. The invoice‑target entries already arrive in the receiver's policy fieldList (same shipping mechanism as areReportFieldsEnabled), so visibility can be driven by the presence of those fields rather than the enabled flag.

At the three gate sites above, for invoice reports either:

• fall back to the already‑propagated flag, e.g. isInvoiceReport ? (policy?.areInvoiceFieldsEnabled ?? policy?.areReportFieldsEnabled) : ..., or
• render invoice report fields when sortedPolicyReportFields (the invoice‑target fields) are non‑empty, since they already pass through to the receiver.

Alternative / proper fix (backend)

The architecturally‑cleaner fix is to include areInvoiceFieldsEnabled in the reduced sender‑policy snapshot pushed to invoice receivers — exactly as the backend already does for areReportFieldsEnabled. That lives in Web‑Expensify/Auth (outside this repo) and would require an internal engineer. The App‑side change above is the faster deploy‑blocker remedy and keeps the fix in the regressing PR's repo.

One thing to confirm: that the receiver's fieldList actually contains the invoice‑target field definitions. This is highly likely (it's a single policy property carrying all targets, and expense fields already reach receivers), but a runtime check of a receiver's POLICY_<senderID> Onyx value / OpenReport response would confirm whether only the flag is missing or the field data too. If the field data is also missing, the backend fix is required.

What alternative solutions did you explore?

Reverting the gate change entirely back to !!policy?.areReportFieldsEnabled for invoice reports — works for the receiver but incorrectly couples invoice‑field visibility to the report fields toggle, so the scoped fallback above is preferred.

---

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

[mollfpr]

Closing — the invoice fields feature has been reverted via #93243, so this no longer reproduces on staging.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.