[`Hold for BZ checklist`] [Due for payment 2025-09-02] Reports with credit card expenses are failing to export to QuickBooks Online

[trjExpensify]

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: v9.1.95-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers): See thread for details
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @MitchExpensify @clarajones-expensify
Slack conversation (hyperlinked to channel name): #convert

Action Performed:

1. Connect a workspace to QuickBooks Online
2. Connect a third-party card feed in Company Cards
3. Create an expense report with card transactions
4. Export to QBO
5. Observe the report fail to export.

Expected Result:

The report should export to the card account specified for the card.

Actual Result:

The report fails to export with an error that looks like this.

Exporting report <reportID> failed: Account not found on policy <policyID>, make sure the QBO connection is synced and all centrally-managed cards are correctly configured under Domains > Company Cards.

It appears as those in the quickbooks_online_export_account NVP we're storing the name of the credit card account and not the ID as we should be.

"nameValuePairs": {
                "quickbooks_online_export_account": "Credit Card Payable Account Name",
                "quickbooks_online_export_account_policy_id": "09C377F506F31F99"

The accountID is what we need to export to the right account in QBO, and as such it should look like this:

"nameValuePairs": {
                "quickbooks_online_export_account": "964",
                "quickbooks_online_export_account_policy_id": "09C377F506F31F99"

Investigating with @francoisl for a bit, it appears as though the bug might lie here. If we compare that to QuickBooks Desktop, we see that row.accounts.at(0)?.id is used here, not just row.accounts.at(0).

Workaround:

N/A

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
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

See thread for details.

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dylanexpensify

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[daledah]

Proposal

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

The report fails to export with an error that looks like this.

What is the root cause of that problem?

We are using row.accounts.at(0) here

App/src/pages/workspace/accounting/qbo/export/QuickbooksCompanyCardExpenseAccountSelectCardPage.tsx

Line 84 in 4ebf8ad

[CONST.QUICKBOOKS_CONFIG.NON_REIMBURSABLE_EXPENSES_ACCOUNT]: row.accounts.at(0),

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

We should update this to

                    {
                        [CONST.QUICKBOOKS_CONFIG.NON_REIMBURSABLE_EXPENSES_EXPORT_DESTINATION]: row.value,
                        [CONST.QUICKBOOKS_CONFIG.NON_REIMBURSABLE_EXPENSES_ACCOUNT]: row.accounts.at(0).id,
                        [CONST.QUICKBOOKS_CONFIG.NON_REIMBURSABLE_BILL_DEFAULT_VENDOR]: row.defaultVendor,
                    },

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

None

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[francoisl]

Investigating with @francoisl for a bit, it appears as though the bug might lie here.

I'm not positive that's the where the issue is. From internal logs, I see that the API command that's called with the wrong value is SetCardExportAccount, so it would be more likely from here.

[muhammad-ali-abbasi]

---

Proposal — QBO export failing for reports with card expenses

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

When exporting a report that contains credit-card transactions (coming from a third-party card feed) to QuickBooks Online (QBO), the export fails. Users expect the report to export and have card expenses posted to the card account configured for that company card in the QBO mapping, but instead the export errors out.

What is the root cause of that problem?

Based on the export flow, QBO requirements, and how company-card export settings are stored and used:

1. Card-export account mismatch / missing mapping.
   QBO requires card transactions to be posted to a credit-card liability account (not an expense account). If a company card (especially a third-party feed) does not have a valid QBO account mapped or the mapped account is of the wrong type, the QBO API rejects the export.

2. Exporter builds an incorrect QBO payload for card transactions.
   The export builder appears to select the QBO account for lines globally (expense/account) without switching to the card account mapping when the transaction is a card charge. In other words, the code that assembles the AccountRef/Payment/Line objects for QBO exports is either:

   • not reading the per-card export account (the card’s assigned QBO account), or
   • falling back to a workspace-level expense account rather than the card-level liability account.

3. Insufficient pre-export validation and unclear error messaging.
   The app attempts the export and surfaces the raw error instead of detecting the situation early and showing a clear message like “This report contains card transactions but the card is not mapped to a QBO credit-card account — please map it in Company Cards → QuickBooks export settings.”

The combination of (1) and (2) is the usual reason QBO returns a failure for card exports.

Evidence locations in repo (verify locally):

• QBO UI + settings pages: src/pages/workspace/accounting/qbo/ (contains QBO pages, advanced/sync UI).
• The export flow is orchestrated from report actions: src/libs/actions/Report.ts (export helpers & API calls live here).
• Company card settings and export selection live under src/pages/workspace/companyCards/ and related actions.

---

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

High-level goal: Ensure the QBO export builder uses the correct QBO account for card transactions (the card’s assigned QBO credit-card account), validate mappings before attempting export, and show clear user-facing guidance for missing/wrong mappings.

1) Add a pre-export validation step (user-friendly checks)

• Where: Add into the export orchestration just before building/sending the QBO payload. This orchestration is called from the Report export flow — the best place to update is where the app gathers report transactions and chooses exporter settings (traceable from src/libs/actions/Report.ts).

• What it does:

  • Scan the report’s transactions for any that are isCardTransaction (i.e., belong to a company card or flagged as card-imported).

  • For each distinct company card referenced, check that:

    • The card is assigned to the workspace,
    • The card has a mapped QBO account configured, and
    • The mapped QBO account type is CreditCard (or in the acceptable QBO account types for card exports).

  • If any card fails the check, abort export with a clear message instructing the admin to update the card’s QuickBooks export account (link directly to Company Cards → the card → QBO export configuration). Do not send the bad payload to QBO.

2) Fix the export payload builder to use per-card account for card transactions

• Where: The code that constructs the QBO payload for line items lives in the report export logic (again: src/libs/actions/Report.ts and any QBO-specific helpers it calls — search for “QuickBooks”, “QBO”, or export helpers).

• What to change:

  • When building the QBO Line / AccountRef for a transaction:

    • If transaction is a card transaction, set AccountRef to the card’s configured QBO account (the card export account mapping).
    • If it’s not a card transaction, continue using the existing logic (workspace-level expense account or mapped expense account).

  • When exporting the overall report, make sure the report-level Payment / Credit handling reflects that the individual card charges will credit the mapped card (liability) account, and any reimbursements/payments are matched correctly.

3) Improve error handling & UX

• Where: Export caller and UI that shows export results (likely a modal or RHP).

• What to change:

  • If QBO returns a server-side error during export, translate it into actionable guidance when the error is related to account types (e.g., account type mismatch) — for example: “Export failed: Credit card transactions must be exported to a QuickBooks Credit Card account. Open Company Cards → Select Card → QuickBooks export and choose a credit-card account.”
  • If the error is unrelated (network/OAuth), show the existing messages.

4) Small data modeling / settings changes (if needed)

• Ensure company-card export settings in the UI store both:

  • the QBO account ID to export to, and
  • the account type metadata returned by QBO (so the frontend can verify type === 'CreditCard' without an extra server call).

• If the frontend does not already store account type, either:

  • store it with the account metadata when QBO syncs accounts (recommended), or
  • on validation, fetch QBO account details during export validation (less ideal but acceptable).

5) Telemetry & logging (operational)

• Add telemetry events / logs when:

  • Pre-export validation fails (include which cardIDs and which card->QBO mapping is missing or has wrong type).
  • Export payloads include card transactions and the accounts chosen.

---

Exact files / areas to inspect & update (where to make changes)

(These are real folders/files in the repository. I intentionally avoid inventing helper names; instead I point to the modules and the logical spots to edit.)

1. Report export orchestration

   • src/libs/actions/Report.ts — this file contains the report actions and the manual export flow. Add the pre-export card-mapping validation here before sending data to the accounting exporter.

2. QuickBooks integration pages / helpers

   • src/pages/workspace/accounting/qbo/ — UI pages for QBO config (Advanced / AutoSync / account mapping). Verify and update UI to store/return account type metadata when syncing accounts (so client can validate account types).
   • If there are QBO utility helpers (search for qbo or QuickBooks helpers), update the payload builder to use the per-card mapping for card transactions.

3. Company cards / card-export settings

   • src/pages/workspace/companyCards/ and related actions — ensure the card export UI allows selecting a QBO account and that value is persisted where the export flow can read it. Add a small helper that given a cardID returns its qboAccountID and ideally qboAccountType.

4. Tests & telemetry

   • Tests under tests/unit/ and E2E under tests/e2e/ to be added/updated (see test cases below).

If you want, I can run a repo grep for exact occurrences (e.g. search for QuickBooks, qbo, export in those folders) and paste the specific function blocks to modify — say the word and I’ll fetch them.

---

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

Unit tests

1. Pre-export validation (unit)

   • Report with card transactions referencing card A:

     • Card A has QBO account with type CreditCard → validation passes.
     • Card A has QBO account but type Bank or Expense → validation fails with suitable error code.
     • Card A has no QBO mapping → validation fails with suitable error code.

2. Payload builder (unit)

   • For a mixed report (card + expense lines), ensure:

     • Card transactions’ Line.AccountRef equals card’s QBO account id (liability account),
     • Non-card transactions use expense accounts as before.

Integration / E2E tests
3. Happy path (end-to-end)

• Connect workspace to QBO; make sure a credit-card account is available and mapped to the company card; create a report with that card’s transactions; export → assert success and that QBO received a payload with correct accountRefs.

4. Missing/wrong mapping (user flow)

   • Report with card transactions but card mapping missing or wrong type → attempt export → assert:

     • Export is prevented,
     • The user sees an actionable, clear message pointing to Company Cards → set QBO export account.

5. Regression test (race):

   • Ensure reports with no card transactions still export as before (no change in non-card behavior).

---

What alternative solutions did you explore? (Optional)

N/A

---