Skip to main content
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

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

​
General Ledger (GL) Accounts

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

​
Financial 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.
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.
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.
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.
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.
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.
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.

​
Payment Types

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

​
Stripe

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

​
Financial Documents

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

​
Multi-Currency

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.
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.
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.
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.
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 for the full setup.
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.