> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fusioncore.us/llms.txt
> Use this file to discover all available pages before exploring further.

# Accounting Troubleshooting

> Common problems with Business Units, Financial Periods, Payment Types, Stripe, Financial Documents, and Multi-Currency — what you see, why it happens, and how to fix it.

If something isn't working in your accounting set up, find the symptom below. Most problems trace back to a setting on a record, not to a bug. Work through the matching section.

## Business Units

<AccordionGroup>
  <Accordion title="I can't write off an Order — the write-off fails">
    **What you see.** You try to write off an Order and it fails, sometimes naming a Business Unit.

    **Why.** A write-off needs a **Default Write-Off Account** on the Business Unit. The check runs against the Business Unit on each order item, not just the Order header, so a single item pointing at a Business Unit that has no Default Write-Off Account is enough to stop the write-off.

    **Fix.** Open each Business Unit used on the Order and set a **Default Write-Off Account**. Make sure every Business Unit in play has one, not just the main one. See [Creating a Business Unit](/end-user-guides/accounting/business-units/creating-a-business-unit).
  </Accordion>

  <Accordion title="A write-off or adjustment posted as Succeeded before anyone reviewed it">
    **What you see.** A write-off or adjustment was marked **Succeeded** automatically, with no manual approval step.

    **Why.** **Auto-Update Write-Off FE To Succeeded** and **Auto-Update Adjustment FE To Succeeded** are both turned **on** by default on a new Business Unit. While they are on, those entries post as Succeeded the moment they fire. A zero-dollar write-off or adjustment always posts as Succeeded, even with these turned off.

    **Fix.** If you want a manual review step, open the Business Unit and turn off the matching auto-update checkbox. A Succeeded entry is treated as final, so confirm with your administrator how your org reverses one before relying on auto-posting. See [Configuring Automatic Write-Offs and Adjustments](/end-user-guides/accounting/business-units/configuring-automatic-write-offs-and-adjustments).
  </Accordion>

  <Accordion title="A Business Unit's default account went blank on its own">
    **What you see.** A Business Unit's Default Credit, Write-Off, or Tax account is suddenly empty, and no one cleared it.

    **Why.** Deleting a GL Account that a Business Unit used as a default does not block the delete — it silently clears the reference instead. The field just goes blank.

    **Fix.** Re-pick the default account on the Business Unit. After you remove any GL Account, check the defaults on Business Units that may have used it. See [Business Units](/end-user-guides/accounting/business-units/index).
  </Accordion>

  <Accordion title="I can't save a Default Tax Product on the Business Unit">
    **What you see.** Choosing a product as the **Default Tax Product** blocks the save.

    **Why.** The product must be active, must be marked as a tax product, and must not have a pricing condition configured. If any of those is wrong, the save is rejected.

    **Fix.** Open the product and confirm it is active, flagged as a tax product, and has no pricing condition, then re-select it on the Business Unit. See [Business Units](/end-user-guides/accounting/business-units/index).
  </Accordion>

  <Accordion title="My Business Unit logo isn't showing on documents">
    **What you see.** You uploaded an image to the Business Unit, but it doesn't appear on financial documents or other branding.

    **Why.** Branding reads the image from the **Logo URL** field. The upload screen shows every URL field and selects none by default, so it's easy to save the image to a different URL field. If your org hasn't enabled Salesforce **Content Deliveries**, the upload fails entirely.

    **Fix.** Re-upload and explicitly choose **Logo URL** as the destination field. If the upload errors out, ask your administrator to confirm Content Deliveries is enabled. Note that the saved image is public — anyone with the link can view it, so never upload confidential images. See [Uploading an Image to the Business Unit](/end-user-guides/accounting/business-units/uploading-an-image-to-the-business-unit).
  </Accordion>
</AccordionGroup>

## General Ledger (GL) Accounts

<AccordionGroup>
  <Accordion title="I can't save a GL Account, even though Business Unit doesn't look required">
    **What you see.** Saving a GL Account fails and the **Business Unit** field doesn't show the usual "required" marker.

    **Why.** Business Unit is required by fusionCore even though it isn't marked required at the field level. A GL Account with no Business Unit cannot be saved.

    **Fix.** Set a Business Unit on the GL Account before saving. See [General Ledger (GL) Accounts](/end-user-guides/accounting/general-ledger-gl-accounts).
  </Accordion>

  <Accordion title="I can't change a GL Account's Business Unit, or can't delete a Business Unit">
    **What you see.** Changing the Business Unit on a GL Account is blocked, or deleting a Business Unit is blocked.

    **Why.** A GL Account used as a Business Unit's **Default Credit Account** or **Default Write-Off Account** must stay in that same Business Unit, and a Business Unit cannot be deleted while GL Accounts still reference it. The match is enforced from both directions.

    **Fix.** First clear the GL Account from any Default Credit or Write-Off Account fields that point at it, or reassign and remove the referencing GL Accounts, then make your change. See [General Ledger (GL) Accounts](/end-user-guides/accounting/general-ledger-gl-accounts).
  </Accordion>

  <Accordion title="Marking a GL Account inactive didn't stop it from being used">
    **What you see.** You unchecked **Active** on a GL Account, but it can still be selected elsewhere.

    **Why.** **Active** is advisory. It does not, by itself, block the account from being chosen.

    **Fix.** Treat **Active** as a flag, not a hard block. To truly prevent use, reassign the records that reference it. See [General Ledger (GL) Accounts](/end-user-guides/accounting/general-ledger-gl-accounts).
  </Accordion>
</AccordionGroup>

## Financial Periods

<AccordionGroup>
  <Accordion title="I can't Fetch or Lock — it says the action is only for Open periods">
    **What you see.** Clicking **Fetch** or **Lock** returns "Action is available only for Open Financial Periods."

    **Why.** Fetch and Lock only run while the period is **Open**. A **Closed** period can't be re-fetched or re-locked from these buttons, and this package ships no "reopen" button.

    **Fix.** Confirm your numbers before you close a period, because closing is effectively permanent. If a period is already closed, you cannot reopen it from the record page — work with your administrator. See [Locking Financial Periods](/end-user-guides/accounting/financial-periods/locking-financial-periods).
  </Accordion>

  <Accordion title="Fetch reported success but no lines were linked to the period">
    **What you see.** You click **Fetch**, see a success message, but the period has no Financial Event Lines attached.

    **Why.** Fetch only links a line when its parent event is **Succeeded** and the succeeded date falls inside the period's dates — other lines are skipped silently. A line can also be skipped when a status guard on the parent event (for example, an Order in a paid or voided state) blocks the update mid-job, which can leave the job reporting success while linking nothing.

    **Fix.** Confirm the events you expect are Succeeded and dated inside the period, then Fetch again. If lines you expect still don't appear, check the period's **Batch Job Error Message** and review the related Order statuses before re-running. See [Fetching Financial Event Lines](/end-user-guides/accounting/financial-periods/fetching-financial-event-lines).
  </Accordion>

  <Accordion title="Lock failed and named a specific line">
    **What you see.** Clicking **Lock** stops with an error that names one Financial Event Line.

    **Why.** Lock runs extra pre-flight checks beyond Fetch: every linked line's parent event must have succeeded inside the period's dates, and no succeeded line in the range may be left unlinked. The lock stops at the first line that fails and names it.

    **Fix.** Fetch the lines before you lock so every in-range succeeded line is linked, fix the line named in the error, then Lock again. See [Locking Financial Periods](/end-user-guides/accounting/financial-periods/locking-financial-periods).
  </Accordion>

  <Accordion title="A Fetch or Lock job ended with an error but some rows still changed">
    **What you see.** The **Batch Job Status** shows an error, yet some lines were processed.

    **Why.** These jobs commit the rows they can and report the first failure they hit, so a job can partially succeed.

    **Fix.** Read the **Batch Job Error Message**, fix the underlying data, and re-run. See [Financial Periods](/end-user-guides/accounting/financial-periods/index).
  </Accordion>

  <Accordion title="I can't start a second Fetch or Lock">
    **What you see.** A second Fetch or Lock won't start, or the button does nothing.

    **Why.** You can't run two jobs at once. While a job is processing, the next one is blocked.

    **Fix.** Wait for the **Batch Job Status** to reach a completed state (for example, Completed Fetch or Completed Lock), then click again. See [Financial Periods](/end-user-guides/accounting/financial-periods/index).
  </Accordion>

  <Accordion title="A period locked even though its transactions were out of balance">
    **What you see.** A Financial Period locked successfully even though a linked transaction's total debits did not equal its total credits.

    **Why.** The debit-equals-credit check during Lock is provided by the Transaction Generator accelerator. Without that accelerator installed and up to date, an out-of-balance transaction does not block the lock.

    **Fix.** Make sure the current Transaction Generator accelerator is installed in your org so Lock can flag a debit-credit mismatch and stop. Reconcile the named transaction, then lock again. See [Locking Financial Periods](/end-user-guides/accounting/financial-periods/locking-financial-periods).
  </Accordion>

  <Accordion title="I can't save a Financial Period because the dates overlap or are reversed">
    **What you see.** Saving a period returns "Provided dates are overlapping with other Open Financial Period," or it rejects a Start Date later than the End Date.

    **Why.** Two **Open** periods cannot have overlapping dates, and a period's Start Date may not be after its End Date.

    **Fix.** Close or adjust the existing overlapping period, and make sure Start Date is on or before End Date, then save. See [Creating a Financial Period](/end-user-guides/accounting/financial-periods/creating-a-financial-period).
  </Accordion>

  <Accordion title="A Financial Period report link shows a 'Missing Report Id' message or won't appear">
    **What you see.** A report field on the Financial Period shows "Missing Report Id in Constant custom metadata record," or a link you added doesn't show up.

    **Why.** Out of the box, all five report fields ship empty, so each shows the missing-id message until a report ID is pasted in. The fields are read-only and hidden unless you have the **Financial Period Reports** permission set, the value must be only the 18-character report ID (not the full URL), and a new value appears only after you refresh the page.

    **Fix.** Paste the 18-character report ID into the **Text Value** for each of the five report Constants, confirm you have the Financial Period Reports permission set, and refresh the record. See [Financial Period Reports](/end-user-guides/accounting/financial-periods/financial-period-reports).
  </Accordion>
</AccordionGroup>

## Payment Types

<AccordionGroup>
  <Accordion title="My payment method is missing from the pay screen">
    **What you see.** A Payment Type you set up doesn't appear when staff or members go to pay.

    **Why.** A Payment Type is filtered out of the pay screen for several reasons: its **Display Payment Type** hides it (offline types can't show in the portal), its **Supported Currencies** list omits the order's currency in a multi-currency org, its Stripe provider account doesn't match the environment (sandbox versus production), or the method isn't eligible for that transaction (for example, Cash and Check don't appear for installments).

    **Fix.** Open the Payment Type and check, in order: the **Display Payment Type** value, whether **Supported Currencies** is blank (blank means all currencies) or includes the order's currency, that the provider account matches your environment, and that the method fits the transaction type. See [Payment Types](/end-user-guides/accounting/payment-types/index).
  </Accordion>

  <Accordion title="I can't save a Payment Type — the save is blocked with an error">
    **What you see.** Saving a Payment Type fails with an on-screen message, and there's nothing under **Setup > Validation Rules** to explain it.

    **Why.** These rules are enforced by fusionCore in code, not as declarative validation rules. Common ones: a `Card`, `ACH`, `Alipay`, or `WeChat Pay` method needs a **Payment Provider Account**; `Valid for All Refunds` can't be combined with a Payment Provider Account; the auto-succeed checkboxes can't be used with a Payment Provider Account; **Allow as Wallet Item** requires `Card` or `ACH` plus a provider account; and you can only have one Account Credit Payment Type per Business Unit.

    **Fix.** Read the on-screen message — it names the rule that fired — and adjust the record to match. For provider-backed (Stripe) methods, set a Payment Provider Account and use `Refund only if original payment`. See [Setting up Custom Payment Types](/end-user-guides/accounting/payment-types/setting-up-custom-payment-types).
  </Accordion>

  <Accordion title="My offline (Cash/Check) Payment Type won't save">
    **What you see.** An offline Payment Type fails to save.

    **Why.** Offline methods are `Cash`, `Check`, or `Account Credit`. Picking `Card`, `ACH`, `Alipay`, or `WeChat Pay` makes it an online method that needs a Payment Provider Account, and offline types can't be set to `Portal` or `Portal and Staff` display.

    **Fix.** Use an offline payment method, set **Display Payment Type** to `Staff`, and leave the provider account blank. For card or bank methods, set them up as Stripe Payment Types instead. See [Setting up Offline Payment Types](/end-user-guides/accounting/payment-types/setting-up-offline-payment-types).
  </Accordion>

  <Accordion title="A saved card or bank account (Wallet Item) doesn't work at checkout">
    **What you see.** A member's saved payment method fails or doesn't appear at checkout.

    **Why.** Wallet Item support needs all three Stripe components configured on the Card or ACH Payment Type, the method must be `Card` or `ACH`, and a Payment Provider Account must be set. If the saved-method component is missing, saved methods don't work.

    **Fix.** Confirm the Payment Component, Refund Component, and saved-method (Wallet Item) component are all set on the Payment Type, and that the method and provider account are correct. See [Setting up Stripe Payment Types](/end-user-guides/accounting/payment-types/setting-up-stripe-payment-types/index).
  </Accordion>

  <Accordion title="I can't edit a Payment Type that members are already using">
    **What you see.** Changing **Allow as Wallet Item**, **Payment Method**, or **Payment Provider Account** on a Payment Type is blocked.

    **Why.** If any member's saved Wallet Item still references this Payment Type, those fields are locked to protect live saved methods.

    **Fix.** Migrate or remove the wallet items that reference the Payment Type first, then make your edit. See [Payment Types](/end-user-guides/accounting/payment-types/index).
  </Accordion>

  <Accordion title="I can't delete a GL Account that a Payment Type uses">
    **What you see.** Deleting a GL Account is blocked.

    **Why.** A GL Account set as the **Deposit Account** on any Payment Type can't be deleted while it's in use.

    **Fix.** Reassign the Payment Type to a different Deposit Account first, then delete the GL Account. See [Setting up Custom Payment Types](/end-user-guides/accounting/payment-types/setting-up-custom-payment-types).
  </Accordion>

  <Accordion title="A Stripe refund didn't happen instantly">
    **What you see.** You submitted a Stripe refund, but its outcome isn't visible right away.

    **Why.** Stripe refunds run as a background job and reconcile through a webhook. The final result only appears once that job completes; on failure, the related event is marked failed with an error message rather than throwing an error in the UI.

    **Fix.** Wait for the job to reconcile and check the event's status and any error message. If it stays unreconciled, suspect the webhook (see the Stripe section). See [Taking and refunding a Stripe payment](/end-user-guides/accounting/payment-types/setting-up-stripe-payment-types#taking-and-refunding-a-stripe-payment).
  </Accordion>
</AccordionGroup>

## Stripe

<AccordionGroup>
  <Accordion title="Validation never reaches Succeeded">
    **What you see.** You click **Validate** on the Payment Provider Account, but the status never changes to **Succeeded** even though your keys look correct.

    **Why.** Validation is asynchronous and two-stage. **Validate** creates a Stripe test customer and then waits for Stripe to call your webhook back. If the webhook isn't set up or is misconfigured, validation never completes. The inbound event is also accepted only if it arrives within about 10 seconds, so a stale attempt won't finish.

    **Fix.** Set up the webhook before you validate, confirm the webhook endpoint URL ends with the correct path, and then re-run **Validate**. See [Common Issues and Troubleshooting](/end-user-guides/stripe/troubleshooting).
  </Accordion>

  <Accordion title="The payment modal never loads">
    **What you see.** The Stripe card-entry window doesn't appear when a member tries to pay.

    **Why.** Usually one of: a wrong **External Id** on the Payment Provider Account, the wrong **Payment Component** on the Payment Type, missing or incorrect Stripe keys, a user missing the Stripe permission set, an unvalidated account, or — a common one — the webhook set up on the platform account instead of the correct **connected account**, which makes the modal hang on loading.

    **Fix.** Work through the checks on the troubleshooting page in order, paying special attention to confirming the webhook lives on the correct connected account. See [Common Issues and Troubleshooting](/end-user-guides/stripe/troubleshooting).
  </Accordion>

  <Accordion title="The modal loads but the payment hangs on Process Payment">
    **What you see.** A member can enter card details, but clicking **Process Payment** hangs and no payment event is created.

    **Why.** This is almost always the webhook or the integration user: the Stripe integration user is missing its permission set (so the callback is silently dropped), the **Request Signature Secret** doesn't match the webhook's signing secret in Stripe, or the webhook URL is wrong. A `500` in Stripe's logs points to a signature/secret problem.

    **Fix.** Confirm the integration user has its permission set, that the Request Signature Secret exactly matches Stripe, and that the webhook endpoint URL is correct. Use the Stripe webhook delivery list to find the failed call and read why. See [Common Issues and Troubleshooting](/end-user-guides/stripe/troubleshooting).
  </Accordion>

  <Accordion title="Payments succeed in Stripe but statuses don't sync back into the org">
    **What you see.** Stripe shows the payment, but the record in your org doesn't update.

    **Why.** When the org rejects an inbound webhook — a missing or wrong signature, an event older than five minutes, or an event meant for a different org or the wrong live/test mode — it quietly returns a success code to Stripe, so Stripe never retries. The failure is easy to miss.

    **Fix.** Confirm the signing secret and endpoint URL exactly match, that you're sending from the right Stripe account and mode, and check the Stripe webhook delivery list rather than waiting for a retry. See [Connected Account Webhook Set Up](/end-user-guides/stripe/connected-account-webhook-set-up).
  </Accordion>

  <Accordion title="Validation worked before, but now it's back to not-validated">
    **What you see.** A previously validated Payment Provider Account shows as no longer validated after an edit.

    **Why.** Editing the **External Id**, **Request Signature Secret**, or **Stripe MDT Prefix** clears the validation status automatically.

    **Fix.** Re-run **Validate** after any of those edits. See [Connected Account Webhook Set Up](/end-user-guides/stripe/connected-account-webhook-set-up).
  </Accordion>

  <Accordion title="Payments fail with 'Multiple Payment Provider Accounts were found with the same External Id'">
    **What you see.** Validation or payment fails naming a duplicate External Id.

    **Why.** Each Payment Provider Account's **External Id** must be unique. Two accounts sharing one breaks both validation and payment processing. A missing or unknown External Id instead reports a missing secret.

    **Fix.** Give each Payment Provider Account a unique External Id and never reuse one. See [Stripe](/end-user-guides/stripe/index).
  </Accordion>

  <Accordion title="I can't set up Alipay or WeChat Pay">
    **What you see.** Saving a Payment Type for Alipay or WeChat Pay fails with "This payment method is not available with current Stripe setup."

    **Why.** Alipay and WeChat Pay are only available on a Stripe **Direct** account. A standard connected-account setup blocks them.

    **Fix.** Use a Stripe Direct account for these methods. See [Stripe Direct Accounts](/end-user-guides/stripe/stripe-direct-accounts/index).
  </Accordion>

  <Accordion title="An Alipay or WeChat Pay payment fails with an 'invalid currency' error">
    **What you see.** An Alipay or WeChat Pay payment fails, and the Stripe log mentions an invalid or unsupported currency (for example, "Payments with wechat\_pay support the following currencies: usd, cny").

    **Why.** The currencies Alipay and WeChat Pay accept depend on the **Stripe account's company location**, not the customer's location. In practice that means CNY plus the currency of the Stripe account's country. The methods must also be enabled in the Stripe dashboard, and very small amounts can be rejected (1 CNY is only about \$0.15).

    **Fix.** Enable Alipay and WeChat Pay in your Stripe dashboard, transact in a currency the Stripe account supports (CNY or the account's home currency), and use a reasonable amount. See [Stripe](/end-user-guides/stripe/index).
  </Accordion>

  <Accordion title="A pending payment was cancelled before the member finished">
    **What you see.** A payment left waiting for the member auto-cancelled.

    **Why.** Payments waiting on member action are cancelled after a method-specific window: about 60 minutes for card (3-D Secure), 7 days for ACH microdeposit verification, and 5 minutes for Alipay and WeChat Pay. A slow member misses the window.

    **Fix.** Ask the member to complete verification promptly, or re-take the payment. See [Stripe testing — production and sandbox](/end-user-guides/stripe/stripe-testing-production-sandbox).
  </Accordion>

  <Accordion title="A large batch of saved-card charges partly failed">
    **What you see.** When charging many saved payment methods at once, some events end as **Failed** with "Callout limit exceeded."

    **Why.** Charging saved methods runs inline and stops at the Salesforce callout limit (or about 110 seconds), marking the remaining events failed.

    **Fix.** Split very large batches into smaller runs. See [Common Issues and Troubleshooting](/end-user-guides/stripe/troubleshooting).
  </Accordion>

  <Accordion title="Validation fails in production with a key error">
    **What you see.** In a production org, **Validate** fails with a message about a missing or wrong secret or public key.

    **Why.** The account may need to use the sandbox (test) keys via **Force Test Mode**. The fusionCore team manages the actual keys, which live in custom metadata, not on the record.

    **Fix.** Confirm the webhook is reachable and re-run **Validate**. If the key error persists in production, confirm with the fusionCore team before turning on **Force Test Mode** on a live account. See [Payment Providers](/end-user-guides/accounting/payment-providers).
  </Accordion>
</AccordionGroup>

## Financial Documents

<AccordionGroup>
  <Accordion title="The View Document button shows a message instead of opening the PDF">
    **What you see.** Clicking **View Document** or **View Summary Document** shows an explanatory message rather than the document.

    **Why.** The record must pass several checks first. For an Order: it needs a synced **Order UUID** (a brand-new or unsynced Order has none yet), at least one product line, and an **Order Type** of **Quote** or **Invoice**. For a Financial Event: it needs an event UUID, and Payment or Refund events must be **Succeeded** (Installment events skip the status check). Only **Payment**, **Refund**, and **Installment** event types produce a document.

    **Fix.** Read the on-screen message and resolve the named condition — let a new Order finish syncing, add a product, set a supported Order Type, or wait for the event to reach Succeeded. See [Where to find your Financial Documents](/end-user-guides/accounting/financial-documents/where-to-find-your-financial-documents).
  </Accordion>

  <Accordion title="Staff click View Document and get an access error on the PDF page">
    **What you see.** The button runs, but the document page throws an access error.

    **Why.** Two permission sets are required: one that grants the buttons and one that grants the Visualforce pages the buttons open. With only the first, the button works but the page is blocked.

    **Fix.** Ask your administrator to assign both Financial Documents permission sets. See [Configuring Financial Documents](/end-user-guides/accounting/financial-documents/configuring-financial-documents).
  </Accordion>

  <Accordion title="Nothing happens when I click View Document">
    **What you see.** Clicking the button appears to do nothing.

    **Why.** Each document opens in a new browser tab, and a pop-up blocker can suppress it.

    **Fix.** Allow pop-ups for your Salesforce site, then click the button again. See [Where to find your Financial Documents](/end-user-guides/accounting/financial-documents/where-to-find-your-financial-documents).
  </Accordion>

  <Accordion title="Fields are blank on the generated document">
    **What you see.** A field you added to the document renders empty.

    **Why.** A field prints only if the user opening the document can read it. If that user (or the portal context, for customer-facing documents) lacks field-level read access, the field renders blank.

    **Fix.** Confirm field-level security for the running user and the portal context. See [Configuring Financial Documents](/end-user-guides/accounting/financial-documents/configuring-financial-documents).
  </Accordion>

  <Accordion title="The document shows a currency code like INR instead of a symbol">
    **What you see.** Currency amounts print a three-letter ISO code (for example, `INR`) rather than a currency symbol.

    **Why.** Documents render the currency symbol when one is available and fall back to the ISO code when it isn't. Some symbols, such as the Indian Rupee, can't be rendered by the underlying document engine, so the code is shown instead. It never prints blank or "null."

    **Fix.** This is expected behavior — the ISO code is correct and unambiguous. No change is needed. See [Configuring Financial Documents](/end-user-guides/accounting/financial-documents/configuring-financial-documents).
  </Accordion>
</AccordionGroup>

## Multi-Currency

<AccordionGroup>
  <Accordion title="I turned on multi-currency and now I want to turn it off">
    **What you see.** Multi-currency is enabled and there's no option to disable it.

    **Why.** Enabling multi-currency is a permanent Salesforce change. Once on, it can't be turned off.

    **Fix.** There's no way to reverse it — always test it in a sandbox first. See [Enabling Multi-currency](/end-user-guides/accounting/multi-currency/enabling-multi-currency).
  </Accordion>

  <Accordion title="An Order was created in the wrong currency">
    **What you see.** A new Order has a currency you didn't intend, and you weren't asked to pick one.

    **Why.** The **Create Order** action inherits the currency from the source Account or Contact. It's never chosen during Order creation, so a wrong currency on the source record carries straight onto the Order.

    **Fix.** Set the **Account Currency** or **Contact Currency** correctly before you click **Create Order**. See [Creating Multi-Currency Orders from Account/Contact](/end-user-guides/accounting/multi-currency/creating-multi-currency-orders-from-account-contact).
  </Accordion>

  <Accordion title="I get a 'currency not supported' or conversion error">
    **What you see.** A transaction fails with a currency-conversion or "currency not supported" error.

    **Why.** Conversion fails when the source or target currency has no active, rated currency in Setup. A currency that exists only as a label, with no conversion rate, will fail.

    **Fix.** In **Setup > Currency Setup**, activate and set a conversion rate for every currency you transact in before going live. Note that fusionCore uses the current stored rate and rounds to two decimal places. See [Enabling Multi-currency](/end-user-guides/accounting/multi-currency/enabling-multi-currency).
  </Accordion>

  <Accordion title="A currency I activated isn't selectable as a Payment Type's supported currency">
    **What you see.** **Supported Currencies** on a Payment Type doesn't offer a currency you activated in Salesforce.

    **Why.** That field is a fixed list of nine ISO codes: AUD, GBP, CAD, EUR, INR, JPY, SGD, AED, USD. A currency outside this list can't be selected there. A blank field means all currencies are allowed.

    **Fix.** If your currency is in the list, select it; otherwise leave the field blank to allow all currencies. Matching is case-insensitive, and the field has no effect in a single-currency org. See [Supported Currencies on Payment Type](/end-user-guides/accounting/multi-currency/supported-currencies-on-payment-type).
  </Accordion>

  <Accordion title="No products show on an Order in a given currency">
    **What you see.** You create an Order in one currency, but the product picker has nothing to add.

    **Why.** An Order only offers Products that have an active **standard price-book entry** in the Order's currency. fusionCore reads product availability and price from those per-currency standard price-book entries, not from a single value on the Product record.

    **Fix.** Make sure each Product has an active standard price-book entry in every currency you sell in:

    * **The Product's own currency** is handled for you. Set the price in the Product's **Standard Price** field (`FCORE_PAY__Standard_Price__c`) and save; fusionCore creates or updates the standard price-book entry for that currency automatically.
    * **Additional currencies** are not generated by fusionCore. Add a price for the Product in each other currency you transact in, using Salesforce's standard multi-currency price-book tools, so an active standard entry exists for that currency.

    A Product appears on an Order in a given currency only once an active standard price-book entry exists for it in that currency.

    See [Multi-Currency](/end-user-guides/accounting/multi-currency/index) for the full setup.
  </Accordion>

  <Accordion title="No payment methods show on an Order in a given currency">
    **What you see.** You create an Order in one currency, but no payment methods are offered when you try to pay.

    **Why.** An Order only offers Payment Types that support the Order's currency. A Payment Type whose **Supported Currencies** list omits that currency is filtered out of the pay screen.

    **Fix.** On each Payment Type, either leave **Supported Currencies** blank (which allows all currencies) or include the Order currency's ISO code in the list. See [Supported Currencies on Payment Type](/end-user-guides/accounting/multi-currency/supported-currencies-on-payment-type).
  </Accordion>
</AccordionGroup>