Every invoice, payment, refund, credit, and write-off belongs to a batch. If you do not choose a batch, Rhythm looks for the right one automatically and refuses the transaction when it cannot find a safe match. This article explains how Rhythm assigns batches, how it handles money going back to a customer, and what to check when a transaction is refused for batch reasons.
How Rhythm Picks a Default Batch
When a new transaction does not include a batch, Rhythm checks the batch assignment rules for that transaction's business unit. Keep these points in mind:
- If the business unit has no batch assignment settings, Rhythm has no default batch to use, so it refuses the transaction instead of saving it without a batch. You often see this as an order or invoice error when you test a renewal flow or another process that creates an order or invoice in a business unit without a configured default recurring batch. It can also leave invoice processing with no batch options, because Rhythm has nothing to use when it calculates the default for that business unit.
- Assignment rules choose a batch only by the transaction's type and business unit. They do not look at the transaction's amount, customer, product, or date, so use another process when you need routing based on those details.
- If more than one rule matches a transaction, Rhythm uses the first matching rule in the order your rules are listed. There is no separate priority setting beyond that order.
- These rules apply to standalone invoices and standalone payments, not to invoices and payments created from an order. Rhythm assigns an order to one batch, and every invoice or payment created from that order goes into the same batch. Invoice and payment assignment rules only take over for standalone invoices or payments created outside the order workflow.
- A payment taken well after its invoice was created, such as a payment for an invoice that has been open for weeks, is assigned like any other new payment. Rhythm uses the payment's own type and business unit, along with the current payment batch assignment rules. The payment does not need to use, or return to, the batch where the invoice originally landed.
- A payment received after the batch containing its original order has already been posted cannot be added to that original batch. Rhythm treats the payment as a standalone payment and assigns it using payment batch assignment rules, or the default batch if no rule matches.
Reconciliation is cleaner when you separate batches by payment method and transaction type. For example, keep credit card payments, credit card refunds, ACH/eCheck payments, ACH/eCheck refunds, checks, and manual payments in their own batches. That makes it easier to compare Rhythm's batches, your gateway's disbursements, and your financial management system.
Many assignment rules point to a recurring batch instead of one fixed batch. A recurring batch is a saved rule that resolves to whichever batch is currently active, so your default batch for a transaction type can move forward as one batch closes and the next one opens. Rhythm also records some order and invoice dates in GMT. When that date is combined with your batch's date, an order or invoice can occasionally show the next calendar day, especially for portal orders placed later in your local day.
Refunds, Credits, Cancellations, and Returns Follow the Original Money
A refund, credit, cancellation, or return does not get its batch the same way as a new invoice or payment. Rhythm routes it to the same batch as the transaction it reverses:
- Rhythm routes a cancellation or return by finding the order it belongs to.
- Rhythm routes a refund or credit by finding the original payment that the money is being returned from.
If Rhythm cannot find that original order or payment, the routing calculation fails instead of falling back to a default batch. This can happen, for example, when the wrong identifier is used to start the cancellation or refund.
Refund, credit, cancellation, or dispute transactions related to an auto-renewal invoice can also cause posting errors if you move them out of the auto-renewal processing batch and into a separate, manually created batch. Keep those transactions in the same batch as the related auto-renewal invoices to avoid that class of posting error.
Why a Transaction Is Refused Instead of Landing Somewhere Unexpected
Whether you choose a batch or Rhythm assigns one automatically, Rhythm checks that the batch can accept the transaction before it saves anything. A batch accepts a new transaction only when it is:
- an open or error-status transactions batch, not closed, verified, posting, posted, downloaded, or archived, and
- in the same business unit as the transaction. This same-business-unit check does not apply to refunds, which can post into a batch outside that match.
If the batch fails either check, Rhythm refuses the transaction and saves nothing. This check runs every time a transaction is created, whether you choose the batch yourself or Rhythm assigns it by default. A poorly configured recurring batch can therefore refuse automatically assigned transactions just as easily as a manually chosen batch can. A portal member's ACH invoice payment can be refused this way too, so if ACH payments are failing in the portal, check the business unit's recurring batch and batch assignment configuration instead of the payment method. The same status check is why a registration checkout can fail: if it targets a miscellaneous batch that has already been posted, the order cannot be accepted until that batch is reopened or unposted.
Warning
A refusal caused by the batch a rule pointed to does not always say that directly. The message may only describe the batch's status, without mentioning that the batch came from automatic assignment. If a transaction is refused and you did not choose a batch yourself, check your business unit's recurring batch configuration before assuming the transaction is the problem.
Occasionally, a "no batch specified" payment error is an isolated, temporary incident rather than a configuration problem. If a retry succeeds and the error does not return, you likely do not need to change any batch assignment setup for it.
When the Batch an Assignment Points to No Longer Exists
If a recurring batch's current active batch has been deleted or no longer exists, Rhythm cannot calculate a default batch, and the transaction fails. The message tells you how to fix it: go to the recurring batch, deactivate it, and then reactivate it so Rhythm regenerates its active batch. This can also happen after a sandbox refresh leaves a business unit with no usable active batch, if every batch it could resolve to comes back inactive. Creating a new default batch and assigning it in batch assignment settings resolves the resulting order errors the same way.
If the recurring batch's active batch still exists but is closed or posted, Rhythm still calculates that batch as the default, then refuses the transaction during the acceptance check described above. That is why a missing batch and a batch that cannot accept transactions right now can both point back to the same recurring batch configuration. If several transactions across different purchase types all start failing at once with a batch-related message, check whether the active recurring batch for that business unit still points to the current period's batch instead of an earlier batch that has since closed or posted. A recurring batch is expected to advance to a new batch dated for the current day. If you see it still pointing to a prior day's batch, the recurring batch failed to update and needs attention. You can recover by updating the recurring batch's active batch to the current day's batch. Payment submissions typically work again right away, and the batch then continues to roll forward on its normal schedule.
A closed-batch or posted-batch refusal does not always mean the batch you thought you selected is the real cause. The effective cause can still be the recurring batch configuration behind the scenes, such as a disabled recurring batch or a business unit with no active default batch, even when you believed you had chosen a different batch yourself.
Deleting a batch removes the batch record itself, but it does not remove the batch reference on transactions that already point to it. An invoice or payment that still names a deleted batch can fail with a record-not-found error when you try to open its batch from that transaction, even outside the recurring-batch scenarios described above.
Related
See the related articles for setting up automatic batch assignment and recurring batches, creating and editing batches by hand, finding and reviewing a batch, and moving a transaction to a different batch after the fact.