[$250] Ghost/Orphaned Expense Blocks QuickBooks Online Export with ONL118

[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:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
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: @JamieMcElroy
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open a report
2. Compare: Live report UI and PDF export version of the report
3. Observe: PDF export shows 3 Lenovo expenses and Live UI only shows 2
4. Search for the missing Apr 10 Lenovo expense under:
5. Spend → Expenses
6. Attempt to open the expense
7. Observe: “Hmm... it’s not here” error page
8. Attempt to export the report to QBO

Expected Result:

Missing expense should either:
Open normally for editing/viewing
OR be fully removed from backend/report payload state
QBO export should complete successfully

Actual Result:

Expense:
Exists in report/export payload
Appears in PDF export
Cannot be opened or modified
Remains marked as “(untagged)”
QBO export fails with:
ONL118

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

The screenshot for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057101328098884426
• Upwork Job ID: 2057101328098884426
• Last Price Increase: 2026-05-20

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a backend data integrity issue, not an App frontend bug. The orphaned/ghost expense exists in the backend report payload (which is why it appears in PDF exports and blocks QBO export validation), but the transaction record itself is inaccessible — likely deleted or corrupted at the data layer.

When a user navigates to the expense in the App, the frontend correctly shows the "Hmm... it's not here" page via FullPageNotFoundView because the transaction cannot be fetched into Onyx. The withFullTransactionOrNotFound HOC guards expense screens — if the transaction doesn't exist in Onyx, it renders the not-found view.

The ONL118 error is expected behavior: per the help docs, it fires when a billable expense is missing a customer/project. The ghost expense is untagged and can't be edited, so the export is permanently blocked.

The user is stuck because:

1. The expense can't be opened (transaction data missing/corrupted)
2. The expense can't be removed from the report (no UI action available for a non-existent transaction)
3. The expense blocks export (backend validation sees it in the report payload)

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

This appears to be a backend/internal issue. A separate internal investigation is needed to determine why the transaction became orphaned (deleted transaction still referenced in report payload) and to clean up the affected data.

On the App side, a potential defensive improvement would be to handle ghost transactions more gracefully — e.g., filtering out transactions from report views when the underlying transaction data cannot be fetched, or providing a UI action to remove orphaned expense references from a report. However, the primary fix must address the backend data inconsistency.

What alternative solutions did you explore? (Optional)

• Frontend-only filter: The App could skip rendering expenses whose transaction data fails to load, but this would mask the underlying data corruption rather than fix it.
• User-facing "remove orphaned expense" action: This would let users self-service, but risks hiding real data-fetch failures (e.g., temporary network issues) behind a destructive action.

---

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.

[dilshodmackbook-sketch]

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

Proposal

What is the root cause of that problem?

There are two layers here — one in NewDot, one on the backend.

NewDot (the count gap): the report view builds its transaction list with getAllNonDeletedTransactions:

App/src/libs/MoneyRequestReportUtils.ts

Lines 88 to 107 in cfeaadd

	function getAllNonDeletedTransactions(transactions: OnyxCollection<Transaction>, reportActions: ReportAction[], isOffline = false, includeOrphanedTransactions = false) {
	return Object.values(transactions ?? {}).filter((transaction): transaction is Transaction => {
	if (!transaction) {
	return false;
	}
	if (transaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	return true;
	}
	const action = getIOUActionForTransactionID(reportActions, transaction.transactionID);
	if (!action && includeOrphanedTransactions) {
	return true;
	}
	if (action?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && isOffline) {
	return true;
	}
	return !isDeletedParentAction(action) && (reportActions.length === 0 || !isDeletedAction(action));
	});
	}

For each transaction it looks up the matching IOU report action and then, on the final line, drops any transaction whose IOU action isDeletedAction is true:

App/src/libs/MoneyRequestReportUtils.ts

Line 105 in cfeaadd

return !isDeletedParentAction(action) && (reportActions.length === 0 || !isDeletedAction(action));

MoneyRequestReportView calls it with includeOrphanedTransactions = true, but that flag only covers the no-action orphan case — a transaction whose IOU action is deleted still gets filtered out:

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 126 to 127 in cfeaadd

	const reportTransactions = useReportTransactionsCollection(reportID);
	const transactions = useMemo(() => getAllNonDeletedTransactions(reportTransactions, reportActions, isOffline, true), [reportTransactions, reportActions, isOffline]);

So when an expense's IOU action has been deleted but the transactions_ record still exists in Onyx, NewDot hides the expense from the report. That is exactly the observed gap: the PDF is server-rendered from the full transaction set (3 expenses), while the live UI hides the deleted-action one (2). The expense is still findable under Spend → Expenses (it's in the transactions collection), but opening it 404s — "Hmm... it's not here" — because its transaction thread/action is gone.

Backend (the real cause): a normal expense delete removes both the IOU action and the transaction record. Here the action was deleted but the transaction was never detached from the report server-side — a partial delete. That orphaned transaction is what the PDF still renders and what the QuickBooks Online export still tries to sync, failing with ONL118 (ONL118 is a QBO backend error code — it does not exist anywhere in the App code).

Since the issue is Needs Reproduction, this is a code-review analysis rather than a confirmed repro — but the NewDot filtering above deterministically explains the 3-vs-2 discrepancy.

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

The server inconsistency itself needs backend investigation — why the delete left the transaction attached to the report, and why the QBO export errors with ONL118. NewDot can't repair an orphaned server record.

What NewDot can fix is hiding the ghost so the user has no way to see or remove it. A transaction that is still present in Onyx but whose IOU action is deleted is the same class of orphan as one with no action at all (a normal delete removes the transaction record too). includeOrphanedTransactions should cover both:

  const action = getIOUActionForTransactionID(reportActions, transaction.transactionID);
- if (!action && includeOrphanedTransactions) {
+ // A transaction still present in Onyx whose IOU action is missing OR deleted is an
+ // orphan (a normal delete removes the transaction record too). Surface it so the user
+ // can see and remove the ghost expense instead of it silently lingering on the report.
+ if ((!action || isDeletedAction(action)) && includeOrphanedTransactions) {
      return true;
  }

With this, the report table view shows all 3 expenses (matching the PDF), and the user can select the ghost expense and delete it from the report — re-issuing the delete that the backend missed, which clears it from the export payload — without needing to open it.

What alternative solutions did you explore? (Optional)

• Treat this as backend-only and make no NewDot change. The partial-delete and ONL118 do have to be fixed server-side, but that leaves users with a report whose UI count silently disagrees with its PDF/QBO export and no NewDot-side way to clear the ghost. The one-line filter change closes that gap directly, so it's worth doing alongside.
• Reconcile the UI list against the server's authoritative transaction list. Heavier, and unnecessary — the orphaned transaction is already in the Onyx collection (Spend → Expenses finds it); it's only the getAllNonDeletedTransactions filter that hides it. The targeted fix above is smaller and lower-risk.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 14:16:39 UTC.

Proposal

What is the root cause of that problem?

All three reported symptoms are downstream effects of one backend condition, not three separate App bugs: a transaction that is still persisted in the report payload but whose IOU report action is missing/inconsistent in the synced data — an orphaned transaction. NewDot has no code that produces this state, and by design it cannot render or act on a transaction that has no money‑request action.

Evidence (verified at e8c6aa8):

1. ONL118 is a backend QuickBooks Online export error — it does not exist anywhere in App. git grep "ONL118" -- 'src/**' returns zero matches. The export is fire‑and‑forget from the client: exportToIntegration (Report/index.ts:6019) runs a single API.write(REPORT_EXPORT, …) (L6069) with no client‑side precondition, and the only failure handling is a generic message (L6047). The App neither generates nor can prevent ONL118; it is returned by the QBO connector on the server.

2. The live UI renders a report's expenses from its IOU report actions, not from the raw transaction list. Linking a transaction to its action runs through getIOUActionForReportID → getIOUActionForTransactionID (ReportActionsUtils.ts:2568‑2575), which matches originalMessage.IOUTransactionID across the report's actions. If the orphan's IOU action is absent from the synced actions, this returns undefined, so the transaction has no money‑request action to render → the live report shows 2, while the backend payload the PDF is generated from still has 3.

3. Opening it from Search → Expenses dead‑ends for the same reason. Search lists transactions from its own snapshot, so the orphan still appears. Tapping it runs createAndOpenSearchTransactionThread (SearchUIUtils.ts:2494), which calls the same getIOUActionForReportID (L2507); with no IOU action and no childReportID (hasActualTransactionThread is false, L2514) there is no real parent action to resolve to. The flow is already hardened for "Search didn't return the IOU action for deleted items" (L2547‑2557), but for a genuinely action‑less transaction the thread resolves to a report with no parent money‑request action → NotFoundPage ("Hmm… it's not here").

In short: the orphan exists server‑side (PDF + QBO payload see it) but is unrepresentable client‑side (no IOU action), and QBO export rejects the whole report with ONL118. The defect is in the data, not in NewDot.

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

This requires a backend fix; there is no correct App‑side change. In Auth / Web‑Expensify / the QBO connector:

• Reconcile the report payload so the orphaned transaction is either (a) re‑linked to a valid IOU report action, or (b) fully removed from the report total/payload — matching the issue's own Expected Result ("open normally … OR be fully removed").
• The QBO export path should not hard‑fail the entire report with ONL118 because of one unresolvable line item; it should skip/flag the orphan, or block with an actionable, transaction‑specific message instead of an opaque code.
• Run a backend audit/migration to find and clean existing orphaned transactions (transactions referenced by a report payload that have no corresponding IOU action).

I am explicitly not proposing an App diff: the App has no data for the missing action, so every client‑only change papers over the corruption rather than resolving it, and would be rejected on correctness (see alternatives).

What alternative solutions did you explore? (Optional)

App‑side band‑aids considered and rejected — each hides the corruption instead of fixing it:

• Render orphaned transactions in the report view from getReportTransactions (ReportUtils.ts:1306) instead of from IOU actions — surfaces the row, but with no IOU action there is still nothing to open or edit, and it diverges the App's per‑report rendering model from the rest of the product.
• Synthesize a thread for the action‑less transaction in Search — createAndOpenSearchTransactionThread already creates a thread when childReportID is missing; forcing it further just relocates the same NotFoundPage.
• Surface the real backend error instead of the generic message on export failure — exportToIntegration shows common.genericErrorMessage today; mapping ONL118 to specific copy is a separate UX enhancement and does not unblock the export.

[melvin-bot]

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

[melvin-bot]

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