> ## 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. # Paying a Statement > Take one payment against every Order on a Statement, split across Orders and lines however the customer needs. ## Overview You take a Statement payment from the **Pay** quick action on the Statement record, which opens a dedicated payment page listing every linked Order with its line and tax items. You can pay the full balance or a partial amount, and allocate it across Orders and lines as needed. > [!NOTE] > > This page covers staff-initiated payment. Where your implementation enables it, customers can also pay their own open Statements in the Portal, but that flow isn't covered in these guides yet. ## Prerequisites * The Statement is in a status that accepts payment: Draft, Open, Pending Payment, or Partial Payment Received. Paying a Statement in any other status returns `Statement is in {0} status and cannot accept payments.` * The **Pay** quick action is on the Statement page layout — see [Configuring Statements](https://docs.fusioncore.us/end-user-guides/orders/statements/configuring-statements.md). ## Paying a Statement **1. Open the payment page** On the Statement, click **Pay**. **2. Review any warnings** Before you enter an amount, check for banners on the page: * **Pending financial events** — `This Statement has pending financial events. Paying now may result in duplicate or conflicting charges.` Confirm those events first if you don't intend to double-charge. * **Unresolved discount code issues** — the page blocks payment until you click **Reprice** (one Order) or **Reprice All** (every Order) to resolve them. Trying to pay first returns `Payment cannot be processed: unresolved discount code issues exist on one or more orders. Please use the Reprice function to resolve them before proceeding.` * **Stale prices** — `Some orders require price and tax recalculation before payment. Please refresh the page to recalculate.` Refresh the page as instructed. **3. Enter the payment amount** Enter the total amount to pay. If the `FC_Set_Payment_Amount_To_Balance_Due` constant is enabled, the field is pre-filled with the Statement's balance due. The amount must be greater than zero and cannot exceed the Statement's balance due — going over it returns `Payment amount ({0}) exceeds the statement balance due ({1}).` **4. Allocate a partial payment (if applicable)** For a partial payment, allocate the total across the linked Orders and their lines. fusionCore splits tax proportionally as you allocate. Your allocations must add up to the total you entered, and no line can receive more than its own balance. You also can't allocate payment to an Order that's Voided or Written Off. **5. Resolve any Quote conversions** A Quote-type Order receiving a partial payment must become an Invoice first. If one or more of your linked Orders are Quotes, fusionCore prompts: `One or more Quote-type orders are receiving a partial payment and must be converted to Invoices. Please specify the invoice date.` Enter the invoice date and click **Convert and Pay**. If the `FC_Statement_Pay_Auto_Convert_To_Invoice` constant is enabled, this conversion happens automatically using today's date and you won't see the prompt. **6. Confirm zero-balance Orders** If any linked Order has no balance due but hasn't been confirmed yet, fusionCore tells you: `This statement includes unconfirmed orders with no balance due. They'll be confirmed automatically when you pay, or you can use the "Confirm" button to confirm them now without making a payment.` Click **Confirm** if you want to close those Orders out without a payment. **7. Choose a payment type and submit** Select a payment type — Cash, Check, Account Credit, a Wallet Item, or an online payment provider — and submit. > [!NOTE] > > Only Auto Charge-compatible payment types appear when a linked Order contains a product that requires Auto Charge: `Only supported payment methods are available because this Statement includes Order that has product that requires Auto Charge.` ## What the Payment Creates A successful payment creates one **Statement Financial Event** (Payment type) and one **Financial Event** on each Order the payment covered. Whether the Statement Financial Event starts Pending or Succeeded depends on the payment type: * **Cash, Check, and Account Credit** are offline: the Statement Financial Event is created Pending unless the payment type's `Auto_Update_Payment_FE_To_Succeeded__c` field is checked, in which case it succeeds immediately. * **Wallet Items and online provider payments** follow the provider's or wallet's own confirmation. When a Statement Financial Event succeeds, that outcome cascades to every Financial Event it created, the succeeded date stamps, the Statement's paid and balance-due rollups recalculate, and the Statement's status advances automatically (see [Statement Statuses](https://docs.fusioncore.us/end-user-guides/orders/statements/statement-statuses.md)). ## Approving or Declining a Pending Payment For an offline payment that stayed Pending, open the Statement Financial Event and click **Approve** or **Decline**. Both actions show you how many child Financial Events will be affected before you confirm: * **Approve** succeeds the Statement Financial Event and cascades Succeeded to every child Financial Event. * **Decline** fails the Statement Financial Event and cascades Failed to every child Financial Event. Both are blocked if a child Financial Event has already been individually approved, declined, or cancelled: `Detected approved/declined Financial Events linked to this Statement Financial Event.` or `Detected cancelled Financial Events linked to this Statement Financial Event.` > [!NOTE] > > A Financial Event created by a Statement Financial Event can't be approved or declined on its own — `This Status update is unavailable when the Financial Event is linked to the Statement Financial Event`. Approve or decline the parent Statement Financial Event instead. ## Limitations and Common Pitfalls with Statement Payment * **A locked Order can't be paid directly.** Once an Order is locked by a Statement (see [Creating a Statement](https://docs.fusioncore.us/end-user-guides/orders/statements/creating-a-statement.md)), attempting to pay it individually returns `This order cannot be paid directly. Please process payment through statement(s): {0}`. Pay it from the Statement instead. * **Discount code issues block payment until repriced.** Use **Reprice** or **Reprice All** — there's no way to push a payment through with unresolved discount issues. * **The payment form can go stale.** If someone else changes the Statement while you have the payment page open, submitting returns `Statement was modified since you opened the payment form. Please refresh and try again.` Refresh and re-enter your payment. * **Voided and Written Off Orders can't receive payment allocation.** Skip them when allocating a partial payment - these will be greyed out with no balance due payable. * **Always set the Statement's customer before taking payment.** A Statement without both an Account and a Contact can still be paid in Draft status — this isn't yet blocked. Set the Statement's customer first to avoid a payment recorded with no customer attached. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.