Placing an order does two financial jobs at the same time: it records what the buyer owes, and it takes or schedules payment. Rhythm handles both while processing the order, so you do not create the invoice yourself. This article explains how invoicing works, including two situations that often raise questions: one order creating more than one charge, and an order failing partway through processing.
How an Order Becomes an Invoice
When an order is processed, Orders & Inventory drafts one invoice line for each order line. It then groups those draft lines into as few invoices as possible. Lines go on the same invoice when they have the same bill-to party, due date, batch, and order type. Most orders use the same values on every line, so they create one invoice. Each invoice uses the order’s currency, billing address, purchase order number, memo, and business unit, and it links back to the order it came from. Invoice line text comes from the order, so it can vary by order type. For example, an online store order can include a product-level description that a membership order does not.
Processing an order and creating an invoice are related, but they are not the same action. Processing an order builds the invoice and takes or schedules payment, which completes the order in one step. Creating an invoice by itself only creates the financial record; it does not place or complete the order. Rhythm also assigns order numbers and invoice numbers separately. You cannot renumber or reformat either number, so a buyer or billing contact may see two different numbers for the same purchase.
The invoice due date comes from the invoice payment terms on the order. If the order has no payment terms, the invoice is due on the order date, so payment in full is expected right away. Rhythm uses the order date you enter, or leave blank, while taking the order for that calculation. The same date also affects fields like the membership join date and some reporting figures, so the wrong order date can affect all of them.
When a payment is applied to an order, the invoice reflects that payment. Once the order is paid in full, the order’s Balance Due goes to zero, and related records such as memberships, applications, and event registrations should clear their open-balance flags and move ahead with fulfillment. To review an order’s invoices, payments, and refunds, go to Orders & Inventory › Orders › Search, open the order, and select the Related Transactions tab on the Order 360 page. You’ll see them with the order’s Total, Less Payments, and Balance Due. For transactions dated May 3, 2024 or later, the invoice or payment date shown there reflects that transaction’s own date, including a later edit. Older transactions can still show the date the transaction was originally generated.
If an order has an installment plan, Order 360 also shows an Installments tab. The amount and count there show installments that are still scheduled for the future and have not been billed yet. They are not the order’s remaining outstanding balance. Once a billing run processes an installment, that portion no longer appears in the future count. Invoices created from an installment plan appear on the order’s Related Transactions tab with the order’s other invoices. Because installment billing can create several invoices from one order over time, the order’s Balance Due can briefly disagree with its invoices right after a scheduled installment is billed and paid. For example, it may show a negative balance or a $0 balance that is not accurate yet. During that window, trust the invoices and the Installments tab as the more reliable record instead of assuming the order is wrong.
Rhythm automatically emails an invoice when an order has a balance due. It does not send one for an order with a zero balance. For an order billed to an organization, order-related emails can go to the individual registrant or a group registration administrator without also going to the organization’s billing contact. Check who is actually set up to receive those emails. If an order was paid in full at checkout, its confirmation and invoice emails should reflect that. If a confirmation still shows an amount due, or a fully paid order unexpectedly sends an invoice email, check the order’s real payment status instead of relying on the email wording.
If an order includes an inline bundled product whose components use different AR G/L accounts, invoicing can post one AR debit under one component’s account for the full amount. It does not always post a separate debit for each component’s own account. When that matters to your books, compare your posted subledger entries with each bundled component’s configured AR account.
Warning
An order that creates more than one invoice cannot have a coupon applied retroactively later. If Rhythm refuses the coupon after the fact, check whether the order’s lines have different due dates, batches, or bill-to parties. Any of those differences splits the order across more than one invoice.
One Order, More Than One Charge
A product can use Merchant Account Routing to send its own proceeds to a specific merchant account instead of the store’s default merchant account. If you leave the setting off, the product’s payments go to the merchant account on the order as a whole. When one order includes lines that route to different merchant accounts, and the buyer pays by card or electronic check, Orders & Inventory creates one payment for each merchant account. The buyer sees more than one charge on their card or bank statement, even though they made one purchase. If the buyer uses a saved card set up for one merchant account, that card cannot pay for a line routed to a different merchant account. That portion needs a separate payment method.
When an order will create more than one card or electronic check payment, Orders & Inventory checks that each payment will succeed before capturing any of them. This helps avoid a partial charge where possible.
Splitting a Payment, or Leaving Some Owing
A buyer or staff member taking an order can choose to split payment on purpose. They can pay for some lines with one method and other lines with another, or leave part of the order to be invoiced instead of paid right away. This is sometimes called a Pay Later order, because the purchaser completes checkout without paying by card and payment is collected later. A checkout setting that allows multiple payment methods lets the buyer choose different payment types, such as check or card, on the same order. By itself, that setting does not let one order be split across two separate credit cards. Lines left to invoice are still fulfilled, so invoicing them later does not delay delivery. The amount left to invoice becomes the order’s balance due rather than showing as $0. If a line is accidentally included under more than one additional payment, Rhythm uses only the first payment that names it and ignores the rest.
Splitting a payment assigns whole order lines to each method, rather than dividing a dollar amount. You can send some lines to one card and other lines to another, but you can’t split a single line item’s price across two payment methods. In the portal, the second payment method’s card fields stay blank and inactive until the first payment method has been finalized and saved. That is the expected sequence, not a sign that something is broken.
You can only split a payment while taking the order. Once an order is placed, whether it was paid in full, left as pay later, or handled another way, you can’t go back and split its payment across methods afterward. If checkout cannot complete the split payment, you have two alternatives. You can process the order as one pay-later, invoice-it transaction and then record each payment separately afterward, or you can take the payments outside order processing through your payments console.
If you collect payment later on an order that was left to invoice, Rhythm does not add a credit card processing fee at that point. Card processing fees are only handled during the original checkout flow, not when you collect a deferred payment afterward.
A split payment can also change which customer email goes out. A single payment normally produces only the order confirmation, because that confirmation serves as the receipt. With a split payment, Rhythm has been observed to send a separate payment receipt for each payment made at the same time instead of the usual single order confirmation. When the second payment is scheduled for later, Rhythm sends the order confirmation for the first payment, then a separate payment receipt once the second payment completes. If your reconciliation depends on exactly which emails a split payment produces, confirm the behavior with a test order.
Paying from Store Credit Automatically
If the buyer has open credit on their account, such as credit from an earlier refund, and that credit is in the same currency as the order, Orders & Inventory applies it automatically. Credit is used oldest first until the order is paid in full or the credit runs out. You cannot select “store credit” as a payment method directly because Rhythm applies credit for you. An order can also request not to use the buyer’s credits if that is what you or the buyer intend. Checkout shows the buyer’s open credits and how much of the total they cover, so the buyer can see the credit before it is used. If you apply store credit as a partial payment on a pay-later order, check the order’s own details and Balance Due for the amount actually applied. The Related Transactions row for that store-credit payment can show $0.00 even when the payment went through correctly.
When Something Goes Wrong During Processing
If an order runs into a problem partway through processing, such as a declined card payment, Rhythm tries to undo the parts that already happened. It attempts to void or reverse any invoices, payments, and stock changes, then removes the order so the buyer or staff member can try again without a half-finished order left behind. Rhythm reverses those items step by step. In the rare case that a completed step cannot be undone, most often because a payment was already captured, that payment can remain with no matching order to explain it. Rhythm includes checks meant to prevent this, but they don’t catch every failure, so a mismatched charge can still occur. If a customer’s payment method shows a charge with no corresponding order, or an order you expected is missing after a failure, this is the most likely reason. Contact Support with the approximate date, amount, and buyer so the payment can be traced and resolved.
This mismatch has been observed when a processing error backed out the order transaction after the payment had already been captured at the gateway. The payment was left tendered with no order record to explain it. Compensating logic has since been updated to guard against this, so treat it as a rare, historical explanation for an otherwise unexplained charge rather than an everyday risk. Still bring it to Support as a case to trace instead of trying to resolve it by retrying.
Card and electronic check payments are authorized before they’re captured, so a failed authorization by itself does not create or fulfill an order. The scenario above happens later, after a payment has already been captured. Rhythm also pre-authorizes every payment on a multi-payment order only when the primary method is a card or electronic check. If the primary method is non-electronic, such as a check, and a card is added as a second payment, that card payment is not pre-authorized. A split payment that mixes an electronic and a non-electronic method this way can fail during processing and still leave the card charged with no order or invoice created. Splitting one payment across two different credit cards can also trigger a duplicate-authorization error even though the gateway shows both cards charged successfully, leaving the resulting order or registration in draft. If that happens, take the two card payments as two separate payment actions instead of one combined attempt.
Using store credit as part of a split payment can complete invoicing while leaving an event registration in draft. Related items such as guests, sessions, or add-on tickets may not be written to the registration, so check the registration itself after a split payment that includes store credit.
A processing failure can also leave behind an invoice that still references an order removed during the undo. When that happens, you see a record-not-found error when you try to open or cancel that invoice through the order. A similar interruption between the invoice, order, and payment can make the refund option disappear from an otherwise normal order, or make Rhythm report no associated payments even though a payment was made. Treat either issue as the same kind of broken link between records, and contact Support the same way.
Rhythm has changed how it responds when an order errors after a payment has already been taken. Instead of leaving that payment on file with no order to explain it, the associated payment is now removed along with the failed order, so a processor-side payment doesn't outlive the order it belonged to.
Rolling back a payment normally works by looking up the payment record Rhythm saved for it. If the card was charged at the gateway but Rhythm failed before saving that payment record, the usual rollback has nothing to look up and can't void the charge that way. For an electronic, non-zero payment that reached the gateway, Rhythm instead falls back to reversing the charge directly at the gateway using the gateway's own transaction identifier. Not every failed rollback means money was taken. If the failure happened before Rhythm ever called the gateway, there is nothing to reverse, and Rhythm avoids making a pointless gateway call. A related, separate defect has also been seen to leave a gateway capture in place with no payment record ever saved for it, creating an orphaned payment that needs manual cleanup. If you're reconciling a charge with no matching payment record, check for that cause along with the mid-rollback scenario above.
If you notice duplicate line items on an order that was invoiced and later paid by check, investigate it separately. It can point to duplicate accounting output rather than an issue with the order or invoice itself. Check the order's own line items against what was actually invoiced before assuming the duplication is only cosmetic.
Why an Order and Its Invoice Can Drift Apart
An order keeps its own copy of its line items, total, and balance due from the moment it was processed. The invoice is a separate financial record linked to the order, not the same record. Order lines and invoice lines also aren’t always one-to-one. Installment billing is the clearest example: one order line can create several invoices over time, each with a different amount and due date. If someone edits the invoice directly in your finance records later, such as removing a line from it, that edit changes the invoice but not the order. The removed amount is usually broken out onto a separate invoice rather than simply disappearing. The order’s Total and Balance Due on the Order 360 page still come from the order’s own lines, so they do not update after a direct invoice edit. If an order’s balance due does not match what its invoice currently shows, check whether the invoice was changed after the order was placed before assuming the order is out of date.
Reports of this mismatch do not always have the same cause once you look closely at a specific case. Sometimes the lower invoice total is fully explained by the invoice’s own audit log: a line item was removed, and a separate invoice was created for that line’s amount. In other cases, removing a line item from an invoice through Adjust Items and saving it has left the related order’s balance due and subtotal out of step with the invoice, as a defect that was later reported fixed after an engineering update. If you run into this, check the invoice’s audit log and look for a separate invoice covering the removed amount before treating it as unresolved.
The same one-way relationship applies to addresses. Changing an address on the order after it’s placed does not automatically update the address on its invoice, and changing the invoice does not update the order. If both records need the correction, update the address on each of them separately. An order’s own Billing Contact field can be blank even when its linked invoice and payment show a person’s name. That is expected when the order itself has no billing contact or billed organization attached, because the invoice and payment picked up their contact from whoever processed the order rather than from the order record.
Order status, invoice status, and payment status are separate fields on separate records, so they can legitimately disagree. For example, an order may show Open while its invoice shows Paid and its payment shows Complete. Don’t assume all three should always match; check each record for what it specifically tracks. An invoice-change process that fails partway through can also leave an event registration’s order-status field out of step with its invoice. For example, it may still show open when the balance is really zero. If a registration’s status looks wrong around the time of an invoice correction, check the underlying invoice and order before assuming the registration record itself is broken.
If an order seems blocked from an action, such as cancellation, because of a stale association with its invoice or payment, try re-saving the related invoice before you escalate. That has cleared the block in some cases.
Removing an item from an invoice this way has also been observed to change the order’s status to Completed rather than leaving it at Awaiting Payment, even though the order’s total still does not reflect the edit. If you see that mismatch, verify the order against its invoice before relying on the order’s status.