[$250] P2P - Transaction details and legal disclosures are missing in the payment email

[jponikarchuk]

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.70-1
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/13176725/test-cases/41237082
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 15.7.4 Chrome
App Component: Notifications

Action Performed:

Preconditions:
User A and User B have wallet enabled and positive balance
User B is logged out
User B's email can be accessed

1. As user A, navigate to the chat with User B
2. Send a message to user B
3. Click on the + button in the compose box, select "Pay User B"
4. Enter the amount, select "Pay with Wallet"
5. Open the emails in User B's Inbox

Verify the other email is be a receipt that has a IOU preview at the top and should also have a footer that includes more detailed transaction information and a list of legal disclosures

Expected Result:

The email with the subject "User A paid User B" includes more detailed transaction information and a list of legal disclosures
The email with the subject "Chat with User A" User A's payment preview is not shown as an expense, sent by User B

Actual Result:

The email with the subject "User A paid User B" doesn't include detailed transaction information and a list of legal disclosures
The email with the subject "Chat with User A" User A's payment preview is shown as an expense, sent by User B

In Prod: 1st issue is the same, 2nd issue - "Chat" email is not received

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054157174317289380
• Upwork Job ID: 2054157174317289380
• Last Price Increase: 2026-05-12

Issue Owner

Current Issue Owner: @KioCoan

[MelvinBot]

Proposal

Problem: Two issues with P2P payment notification emails:

1. The "User A paid User B" email is missing detailed transaction information and legal disclosures.
2. The "Chat with User A" email incorrectly shows User A's payment as an expense sent by User B.

Root Cause: This appears to be a backend/internal issue. A separate internal investigation is needed.

The App frontend triggers payments via API commands (PayMoneyRequest, PayMoneyRequestWithWallet, SendMoneyElsewhere, SendMoneyWithWallet) and sends only transaction data (amount, currency, reportIDs, payment method). It contains no email template code or email content logic — all payment notification email rendering, including transaction detail formatting and legal disclosure inclusion, is handled entirely server-side.

Recommended Fix: The fix needs to be applied to the backend email generation and templating system, not in the App repo. Specifically:

1. The payment receipt email template needs to be updated to include transaction details and legal disclosures for P2P wallet payments.
2. The chat notification email needs to correctly attribute the payment action to the sender (User A) rather than displaying it as an expense from the recipient (User B).

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

I traced the P2P "Pay with Wallet" path end-to-end on the App side and the two defects described in this issue are not produced by anything Expensify/App writes to Onyx or ships to the server. Both come out of the server-side email-rendering layer.

1. The payload sendMoneyWithWallet actually sends. The + → Pay → Pay with Wallet flow lands in sendMoneyWithWallet, which fires a single API command — SEND_MONEY_WITH_WALLET — with the params returned by getSendMoneyParams:

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

Lines 530 to 560 in cfeaadd

	function sendMoneyWithWallet({report, quickAction, amount, currency, comment, currentUserAccountID, recipient, created, merchant, receipt, optimisticChatReportID}: SendMoneyActionParams) {
	const {params, optimisticData, successData, failureData} = getSendMoneyParams({
	report,
	quickAction,
	amount,
	currency,
	commentParam: comment,
	paymentMethodType: CONST.IOU.PAYMENT_TYPE.EXPENSIFY,
	managerID: currentUserAccountID,
	recipient,
	created,
	merchant,
	receipt,
	optimisticChatReportID,
	currentUserAccountID,
	});
	startTracking(
	{
	scenario: CONST.TELEMETRY.SUBMIT_EXPENSE_SCENARIO.SEND_MONEY,
	iouType: CONST.IOU.TYPE.PAY,
	requestType: 'pay',
	isFromGlobalCreate: isEmptyObject(report) || !report?.reportID,
	hasReceipt: !!receipt,
	},
	{skipSubmitExpenseSpan: true},
	);
	playSound(SOUNDS.DONE);
	API.write(WRITE_COMMANDS.SEND_MONEY_WITH_WALLET, params, {optimisticData, successData, failureData});
	notifyNewAction(params.chatReportID, undefined, true);
	}

The parameter type for that command is intentionally narrow — IDs + a small JSON details blob, nothing else:

App/src/libs/API/parameters/SendMoneyParams.ts

Lines 6 to 20 in cfeaadd

	type SendMoneyParams = {
	iouReportID: string;
	chatReportID: string;
	reportActionID: string;
	paymentMethodType: PaymentMethodType;
	transactionID: string;
	newIOUReportDetails: string;
	createdReportActionID: string | undefined;
	reportPreviewReportActionID: string;
	createdIOUReportActionID: string;
	transactionThreadReportID: string;
	createdReportActionIDForThread: string | undefined;
	receipt?: Receipt;
	receiptState?: ValueOf<typeof CONST.IOU.RECEIPT_STATE>;
	};

type SendMoneyParams = {
    iouReportID: string;
    chatReportID: string;
    reportActionID: string;
    paymentMethodType: PaymentMethodType;
    transactionID: string;
    newIOUReportDetails: string;
    createdReportActionID: string | undefined;
    reportPreviewReportActionID: string;
    createdIOUReportActionID: string;
    transactionThreadReportID: string;
    createdReportActionIDForThread: string | undefined;
    receipt?: Receipt;
    receiptState?: ValueOf<typeof CONST.IOU.RECEIPT_STATE>;
};

There is no rendered HTML, no receipt footer copy, no legal-disclosure text, and no chat-preview body in this payload. The newIOUReportDetails JSON is just {amount, currency, requestorEmail, requestorAccountID, comment, idempotencyKey, created?, merchant?} — built at

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

Lines 91 to 103 in cfeaadd

	const recipientEmail = addSMSDomainIfPhoneNumber(recipient.login ?? '');
	const recipientAccountID = Number(recipient.accountID);
	const comment = getParsedComment(commentParam);
	const newIOUReportDetails = JSON.stringify({
	amount,
	currency,
	requestorEmail: recipientEmail,
	requestorAccountID: recipientAccountID,
	comment,
	idempotencyKey: Str.guid(),
	...(created && {created}),
	...(merchant && {merchant}),
	});

— i.e., the backend already has every field it needs to render the receipt block (amount, currency, comment, merchant, created date) and to scope the legal-disclosure footer (it knows paymentMethodType === EXPENSIFY).

2. The optimistic IOU report and report-preview action NewDot writes locally are correct. I want to rule out the possibility that the App is mis-attributing the actor and that mis-attribution is leaking into the email.

• buildOptimisticIOUReport sets managerID = payerAccountID (User A, the payer) and ownerAccountID = payeeAccountID (User B, the payee):

  App/src/libs/ReportUtils.ts

  Lines 6553 to 6560 in cfeaadd

  	return {
  	type: CONST.REPORT.TYPE.IOU,
  	chatReportID,
  	currency,
  	managerID: payerAccountID,
  	ownerAccountID: payeeAccountID,
  	participants,

• buildOptimisticReportPreview then computes the preview actor by branching on report type — for a P2P IOU (not invoice, not expense report) it returns iouReport?.managerID, i.e., User A. That value is then assigned to both actorAccountID and accountID on the REPORT_PREVIEW action:

  App/src/libs/ReportUtils.ts

  Lines 7492 to 7522 in cfeaadd

  	const reportActorAccountID = (isInvoiceReport(iouReport) || isExpenseReport(iouReport) ? iouReport?.ownerAccountID : iouReport?.managerID) ?? -1;
  	const delegateAccountDetails = getPersonalDetailByEmail(delegateEmail);
  	const isTestTransaction = isTestTransactionReport(iouReport);
  	const isTestDriveTransaction = !!transaction?.receipt?.isTestDriveReceipt;
  	const isScanRequest = transaction ? isScanRequestTransactionUtils(transaction) : false;
  	return {
  	reportActionID: reportActionID ?? rand64(),
  	reportID: chatReport?.reportID,
  	actionName: CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW,
  	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
  	originalMessage: {
  	linkedReportID: iouReport?.reportID,
  	},
  	message: [
  	{
  	html: message,
  	text: message,
  	isEdited: false,
  	type: CONST.REPORT.MESSAGE.TYPE.COMMENT,
  	},
  	],
  	delegateAccountID: delegateAccountDetails?.accountID,
  	created,
  	accountID: iouReport?.managerID,
  	// The preview is initially whispered if created with a receipt, so the actor is the current user as well
  	actorAccountID: hasReceipt ? deprecatedCurrentUserAccountID : reportActorAccountID,
  	childReportID: childReportID ?? iouReport?.reportID,
  	childMoneyRequestCount: 1,
  	isOptimisticAction: true,
  	childLastActorAccountID: deprecatedCurrentUserAccountID,
  	childLastMoneyRequestComment: comment,

So the REPORT_PREVIEW action that gets sent up has actorAccountID = User A and accountID = User A — which is what the chat-notification email should label the preview by. The "an expense, sent by User B" rendering inverts this; the App is not the source of that inversion.

3. Optimistic chat text written to Onyx is just the local chat message, not email body. lastMessageText / lastMessageHtml on the IOU report are set from the IOU report action's message ("sent $X.XX with Expensify") at

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

Lines 183 to 194 in cfeaadd

	const optimisticIOUReportData: OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT> = {
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticIOUReport.reportID}`,
	value: {
	...optimisticIOUReport,
	lastMessageText: getReportActionText(optimisticIOUReportAction),
	lastMessageHtml: getReportActionHtml(optimisticIOUReportAction),
	pendingFields: {
	createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	},
	},
	};

— this is the chat row, not the email template input.

Conclusion. Both defects are server-side rendering bugs in Web-Expensify:

• The User A paid User B receipt template under SEND_MONEY_WITH_WALLET is omitting the transaction-detail block (amount, currency, date, merchant, comment, transaction ID) and the wallet-payment legal-disclosure footer, despite the payload providing every field needed.
• The Chat with User A notification composer is reading the wrong field on the IOU REPORT_PREVIEW action — likely ownerAccountID (User B) instead of actorAccountID / managerID (User A) — and labelling the preview as an expense from the payee.

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

No code change in Expensify/App is required. The fix belongs in the server-side email-rendering layer (Web-Expensify):

1. P2P payment-receipt template (subject User A paid User B): restore the transaction-details block and the legal-disclosures footer for the SEND_MONEY_WITH_WALLET path. Every field needed is already in newIOUReportDetails + the persisted IOU report.
2. Chat-notification email composer (subject Chat with User A): for a REPORT_PREVIEW action linked to a P2P IOU report (i.e., not invoice, not expense report), render the preview body from actorAccountID / managerID (the payer) rather than ownerAccountID (the payee). The App already writes the correct actor on the action.

I'd route this to the backend/email team. I'm happy to capture the exact SEND_MONEY_WITH_WALLET request payload and the resulting REPORT_PREVIEW action JSON from a fresh repro and attach them here if that speeds the backend investigation.

What alternative solutions did you explore? (Optional)

• Could the App's optimistic lastMessageHtml leak into the email body? No — the email is composed by the server from canonical report/action state after the write completes, and the optimistic lastMessageHtml written at

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

  Lines 183 to 194 in cfeaadd

  	const optimisticIOUReportData: OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT> = {
  	onyxMethod: Onyx.METHOD.SET,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticIOUReport.reportID}`,
  	value: {
  	...optimisticIOUReport,
  	lastMessageText: getReportActionText(optimisticIOUReportAction),
  	lastMessageHtml: getReportActionHtml(optimisticIOUReportAction),
  	pendingFields: {
  	createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
  	},
  	},
  	};

  is the same string OldDot writes for the same flow. If it were the source, the bug would also reproduce on OldDot, and the receipt would still be missing the detail/disclosure blocks (which lastMessageHtml doesn't contain anyway).
• Could we flip ownerAccountID / managerID on the optimistic IOU report so the backend's current reader produces the right actor? Rejected — that field assignment matches OldDot for SendMoney (payer = manager, payee = owner) and is consumed by many other call sites (report rendering, balance computation, settlement). Inverting it to paper over an email bug would regress everything else. The correct field for "actor of the preview" already exists on the action (actorAccountID); the backend should read that.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-12 11:14:13 UTC.

Proposal

What is the root cause of that problem?

I traced the full P2P "Pay with Wallet" path on the App side and the email content described in this issue isn't produced by anything NewDot sends.

The user takes the + → Pay → Pay with Wallet flow, which hits sendMoneyWithWallet and writes a single API command:

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

Lines 530 to 560 in 3a13517

	function sendMoneyWithWallet({report, quickAction, amount, currency, comment, currentUserAccountID, recipient, created, merchant, receipt, optimisticChatReportID}: SendMoneyActionParams) {
	const {params, optimisticData, successData, failureData} = getSendMoneyParams({
	report,
	quickAction,
	amount,
	currency,
	commentParam: comment,
	paymentMethodType: CONST.IOU.PAYMENT_TYPE.EXPENSIFY,
	managerID: currentUserAccountID,
	recipient,
	created,
	merchant,
	receipt,
	optimisticChatReportID,
	currentUserAccountID,
	});
	startTracking(
	{
	scenario: CONST.TELEMETRY.SUBMIT_EXPENSE_SCENARIO.SEND_MONEY,
	iouType: CONST.IOU.TYPE.PAY,
	requestType: 'pay',
	isFromGlobalCreate: isEmptyObject(report) || !report?.reportID,
	hasReceipt: !!receipt,
	},
	{skipSubmitExpenseSpan: true},
	);
	playSound(SOUNDS.DONE);
	API.write(WRITE_COMMANDS.SEND_MONEY_WITH_WALLET, params, {optimisticData, successData, failureData});
	notifyNewAction(params.chatReportID, undefined, true);
	}

The payload shape for that command is just IDs + a small JSON details blob — there is no rendered HTML, no receipt footer, no legal-disclosure copy, and no chat-preview body in it:

App/src/libs/API/parameters/SendMoneyParams.ts

Lines 6 to 21 in 3a13517

	type SendMoneyParams = {
	iouReportID: string;
	chatReportID: string;
	reportActionID: string;
	paymentMethodType: PaymentMethodType;
	transactionID: string;
	newIOUReportDetails: string;
	createdReportActionID: string | undefined;
	reportPreviewReportActionID: string;
	createdIOUReportActionID: string;
	transactionThreadReportID: string;
	createdReportActionIDForThread: string | undefined;
	receipt?: Receipt;
	receiptState?: ValueOf<typeof CONST.IOU.RECEIPT_STATE>;
	};

The optimistic IOU report and the report-preview action that NewDot writes locally also look correct for User A paying User B:

• buildOptimisticIOUReport sets managerID = payerAccountID (User A) and ownerAccountID = payeeAccountID (User B):

  App/src/libs/ReportUtils.ts

  Lines 6554 to 6577 in 3a13517

  	return {
  	type: CONST.REPORT.TYPE.IOU,
  	chatReportID,
  	currency,
  	managerID: payerAccountID,
  	ownerAccountID: payeeAccountID,
  	participants,
  	reportID: optimisticIOUReportID ?? generateReportID(),
  	stateNum: isSendingMoney ? CONST.REPORT.STATE_NUM.APPROVED : CONST.REPORT.STATE_NUM.SUBMITTED,
  	statusNum: isSendingMoney ? CONST.REPORT.STATUS_NUM.REIMBURSED : CONST.REPORT.STATE_NUM.SUBMITTED,
  	total,
  	unheldTotal: total,
  	nonReimbursableTotal: 0,
  	unheldNonReimbursableTotal: 0,
  	// We don't translate reportName because the server response is always in English
  	reportName: `${payerEmail} owes ${formattedTotal}`,
  	parentReportID: chatReportID,
  	created,
  	lastVisibleActionCreated: created,
  	fieldList: policy?.fieldList,
  	parentReportActionID,
  	};
  	}

• buildOptimisticReportPreview then sets reportActorAccountID = iouReport.managerID for a P2P (non-invoice/expense) IOU — i.e., User A is the actor of the preview, which matches expected behavior:

  App/src/libs/ReportUtils.ts

  Lines 7479 to 7528 in 3a13517

  	function buildOptimisticReportPreview(
  	chatReport: OnyxInputOrEntry<Report>,
  	iouReport: Report,
  	comment = '',
  	transaction: OnyxInputOrEntry<Transaction> = null,
  	childReportID?: string,
  	reportActionID?: string,
  	// TODO: conciergeReportID will be required eventually. Ref: https://github.com/Expensify/App/issues/66411
  	conciergeReportID?: string | undefined,
  	): ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW> {
  	const hasReceipt = hasReceiptTransactionUtils(transaction);
  	const message = getReportPreviewMessage(iouReport, conciergeReportID);
  	const created = DateUtils.getDBTime();
  	const reportActorAccountID = (isInvoiceReport(iouReport) || isExpenseReport(iouReport) ? iouReport?.ownerAccountID : iouReport?.managerID) ?? -1;
  	const delegateAccountDetails = getPersonalDetailByEmail(delegateEmail);
  	const isTestTransaction = isTestTransactionReport(iouReport);
  	const isTestDriveTransaction = !!transaction?.receipt?.isTestDriveReceipt;
  	const isScanRequest = transaction ? isScanRequestTransactionUtils(transaction) : false;
  	return {
  	reportActionID: reportActionID ?? rand64(),
  	reportID: chatReport?.reportID,
  	actionName: CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW,
  	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
  	originalMessage: {
  	linkedReportID: iouReport?.reportID,
  	},
  	message: [
  	{
  	html: message,
  	text: message,
  	isEdited: false,
  	type: CONST.REPORT.MESSAGE.TYPE.COMMENT,
  	},
  	],
  	delegateAccountID: delegateAccountDetails?.accountID,
  	created,
  	accountID: iouReport?.managerID,
  	// The preview is initially whispered if created with a receipt, so the actor is the current user as well
  	actorAccountID: hasReceipt ? deprecatedCurrentUserAccountID : reportActorAccountID,
  	childReportID: childReportID ?? iouReport?.reportID,
  	childMoneyRequestCount: 1,
  	isOptimisticAction: true,
  	childLastActorAccountID: deprecatedCurrentUserAccountID,
  	childLastMoneyRequestComment: comment,
  	childRecentReceiptTransactionIDs: hasReceipt && !isEmptyObject(transaction) && transaction?.transactionID ? {[transaction.transactionID]: created} : undefined,
  	childOwnerAccountID: iouReport?.ownerAccountID,
  	childManagerAccountID: iouReport?.managerID,
  	...((isTestDriveTransaction || isTestTransaction) && !isScanRequest && {childStateNum: 2, childStatusNum: 4}),
  	};
  	}

Both observed defects — (1) the User A paid User B receipt missing the detailed transaction block and the legal-disclosure footer, and (2) the Chat with User A notification rendering the IOU preview as "an expense, sent by User B" — are produced by the email-composition layer on the server (Web-Expensify), which builds the receipt template and the chat-notification body from canonical report state at send time. None of that text originates in or is forwarded through SEND_MONEY_WITH_WALLET.

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

No code change in Expensify/App is required for this regression. The fix belongs in the email-rendering layer on the backend:

1. The P2P payment-receipt template (subject User A paid User B) — the transaction-details block and the legal-disclosures footer need to be restored for the SEND_MONEY_WITH_WALLET path.
2. The chat-notification email composer (subject Chat with User A) — for REPORT_PREVIEW actions linked to a P2P IOU report, the rendered body is inverting actor/recipient and labelling the preview as an expense from the receiver.

I'd recommend routing this to the backend/email team. I'm happy to capture the exact SEND_MONEY_WITH_WALLET payload from a fresh repro and attach it here if that speeds the backend investigation.

What alternative solutions did you explore? (Optional)

I considered whether NewDot's optimistic data could leak into the email content (e.g., via lastMessageHtml on the chat report being read by the email service), but the email is composed from the canonical IOU/chat state on the server after the write completes, and the optimistic lastMessageHtml / lastMessageText written here is the same as what OldDot would produce:

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

Lines 183 to 194 in 3a13517

	const optimisticIOUReportData: OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT> = {
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticIOUReport.reportID}`,
	value: {
	...optimisticIOUReport,
	lastMessageText: getReportActionText(optimisticIOUReportAction),
	lastMessageHtml: getReportActionHtml(optimisticIOUReportAction),
	pendingFields: {
	createChat: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	},
	},
	};

[melvin-bot]

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

[melvin-bot]

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

[Abdulloh0109]

Proposal

What is the root cause of that problem?

This bug has two halves; the App repo is responsible for only one of them.

Half 1 — "User A paid User B" receipt email is missing transaction details and legal disclosures. That email is rendered server-side by the backend (Web-Expensify / Mobile-Expensify email templates). The App repo is a React Native client and does not generate the HTML body, the footer, or the legal/disclosure block of receipt emails. No frontend code in Expensify/App controls the email layout or what gets stitched into its footer — that template lives outside this repo.

Half 2 — In the "Chat with User A" email, the embedded payment preview is shown "as an expense, sent by User B". This half is influenced by the App repo because the optimistic data the App sends to the backend determines the shape of the REPORT_PREVIEW action that the email renderer later embeds.

Tracing the P2P-wallet flow: getSendMoneyParams in src/libs/actions/IOU/SendMoney.ts:115 calls buildOptimisticIOUReport(recipientAccountID, managerID, ...). Looking at the function signature in src/libs/ReportUtils.ts:6543-6572, the first arg becomes ownerAccountID and the second becomes managerID. For the send flow the values resolve to ownerAccountID = User B (the recipient) and managerID = User A (the sender).

buildOptimisticReportPreview is then called in src/libs/actions/IOU/SendMoney.ts:149. Inside that builder, src/libs/ReportUtils.ts:7505 computes the report-preview actor by branching on isInvoiceReport/isExpenseReport: for an IOU it returns iouReport?.managerID. The adjacent accountID on line 7528 is also set from managerID, and childOwnerAccountID / childManagerAccountID on lines 7537–7538 are copied straight from the IOU report. The backend email template renders the embedded preview by reading childOwnerAccountID (= User B), interprets it as "the submitter of the expense", and labels the preview "an expense, sent by User B". The discrepancy: for a P2P SEND, the IOU report's ownerAccountID is the recipient of the money rather than the originator of the action, so any consumer that treats childOwnerAccountID as "actor" inverts the perspective.

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

Two-part fix, with explicit acknowledgment that only part B is in this repo:

(A) Backend, NOT in this repo: Add the detailed transaction info + legal disclosures footer to the P2P receipt email template, and fix the production delivery of the "Chat with User A" email. These live in Web-Expensify / Mobile-Expensify email templates and SMTP/delivery infra. A C+ on this issue should hand part A to the Notifications team. I am not proposing a change to email-template source here because it does not exist in Expensify/App.

(B) In this repo — fix the actor attribution on the optimistic REPORT_PREVIEW action so the backend email renderer (and any other consumer that reads childOwnerAccountID as "actor") sees the payment from the correct side. In src/libs/actions/IOU/SendMoney.ts:149 the call to buildOptimisticReportPreview(chatReport, optimisticIOUReport) is made with no explicit actor; inside src/libs/ReportUtils.ts:7492-7541 the function derives the actor from iouReport.managerID for IOU reports — accidentally correct for SEND but only because of the way SendMoney happens to populate managerID.

Concrete change: extend buildOptimisticReportPreview with an optional actorAccountID parameter (defaulting to today's derivation so other call sites are unaffected). In SendMoney.ts pass currentUserAccountID explicitly. Inside the builder, when that parameter is provided, use it for actorAccountID and mirror it into childLastActorAccountID and the accountID field on line 7528. Leave childOwnerAccountID / childManagerAccountID alone (they still reflect the underlying IOU report relationship), but treat the explicit actorAccountID as authoritative for "who created this preview" wherever the renderer asks that question.

Scope:

• Files touched: src/libs/actions/IOU/SendMoney.ts (one call site, one new arg) and src/libs/ReportUtils.ts (one function signature, ~3 lines inside the builder).
• Files NOT touched: Email templates (different repo), other buildOptimisticReportPreview callers (MoneyRequestBuilder.ts, Split.ts, PerDiem.ts, Hold.ts) — they keep the current derivation by passing nothing.
• Frontend or backend? Frontend for half B. Half A is purely backend and must be done in Web-Expensify.
• Platforms affected: All platforms listed in the bug (Windows Chrome and macOS Chrome/Safari — the email originating client doesn't matter; the email content is server-rendered from the data the App sends).

What alternative solutions did you explore? (Optional)

• Swap the args at SendMoney.ts:115 so that ownerAccountID = sender (User A) and managerID = recipient (User B). Would fix the email perspective for free, but inverts conventions that many other call sites rely on (getIOUPayerAndReceiver in TransactionPreviewUtils.ts:61-74, the IOU message-text builder around ReportUtils.ts:7014-7022, search/preview components). Net regression risk is much higher than threading an explicit actor through.
• Just file the bug against the backend repo and do nothing here. This is the honest baseline — the receipt-email footer is unambiguously a backend concern. I'm proposing part B only because the App repo also contributes to the email's payload via the report-preview action shape, and fixing it on the App side reduces ambiguity for the backend renderer.
• Update the email template to read actorAccountID instead of childOwnerAccountID. Cleaner long-term, but not in this repo and requires a backend PR + deploy. The proposed App-side change makes both paths agree without waiting on that.

[github-actions]

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

[Marshall7777]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.