A transaction sometimes lands in the wrong batch. For example, a payment taken today might appear in yesterday’s batch, or an invoice might be in a batch for the wrong event. If the batch is open, closed, or in error, you can move the transaction to another batch without reopening or reversing it.
When to Use This
Use this when a transaction is in the wrong batch, and both batches are open, closed, or in error. If the transaction’s current batch has already been posted or downloaded, you cannot move the transaction out until you unpost the batch; see Unpost Batches.
Some transactions are connected, such as a payment applied to an invoice or a write-off for that invoice. Rhythm lets you move those related transactions at the same time, so they do not end up split across batches.
Moving a transaction changes only its batch. It does not void, clear, or hide the transaction from the payer's record. A payment moved this way does not affect revenue totals unless the payment has its own subledger entries.
If you need to keep a problem transaction out of your normal posting, move it into its own open batch. For example, you might do this for a write-off that needs review. After you are satisfied it should stay out of normal posting, set that batch's status to Archived. This isolates the transaction for review, but it does not fix any payment, receipt, or registration issue tied to the transaction. If the data itself needs correcting, plan to handle that separately.
Use the same unpost-then-move process when you need to correct deferred-revenue or G/L handling on items that were already posted. Unpost the batch they are in, then move them into the batch where they belong.
Prerequisites
You need permission to change a transaction's batch.
The transaction's current batch, and the batch you want to move it to, must each be open, closed, or in error. A batch that has been posted or downloaded cannot give up a transaction or receive one.
The organization linked on the transaction and its related records should point to an organization that still exists. Before you move a payment, check that the organization is correctly assigned on the invoice, the payment, and the order. A stale or missing organization link on any of them can stop the move, or a related reversal action, from completing.
When you move a transaction to correct something, use a target batch in the same fiscal period the original transaction was created in, not an earlier period.
Move a Single Transaction
- Open the transaction, such as an invoice, payment, refund, credit, credit memo, debit memo, or write-off. Under Finance in its options menu, select Move to Another Batch.... If the option is greyed out, hover over it to see whether the transaction has no batch or its batch can no longer give up transactions.
- On Select Transactions, review the transaction you are moving. If it has related transactions, they appear in a separate table, and their tick boxes are selected by default. Clear the tick box for any related transaction you do not want to move. If a related transaction is in a batch that cannot give up transactions, it appears disabled and you cannot select it.
- Choose the Target Batch from the list of open batches in the business unit.
- Select Confirm & Preview.
- On Confirm Changes, check the list of transactions that will move, then select Move Transactions.
Move Several Transactions at Once
- From a batch’s transaction list or from a transaction search, tick the rows you want to move. To find a specific payment this way, go to Finance & Billing › Transactions, choose the Payment transaction type, and search for it.
- From Transaction Options, select Move <n> Selected Transactions to Another Batch....
- Follow the same steps as above: choose any related transactions to include, pick the target batch, confirm the changes, and move the transactions.
Tip
If you are retrying an action that requires you to pick a batch only to complete the action, you do not need to choose the correct batch first. For example, with a retroactive coupon application, choose any available batch to finish the action, then move the resulting transaction into the batch you actually want.
Result
On the Complete step, each transaction shows its own result: either “Successfully moved to target batch.” or an error explaining what went wrong. When you close the window after a successful move, the page you were on refreshes.
Warning
Moving several transactions is not all-or-nothing. Rhythm moves each transaction separately, so if one fails, the transactions that already moved stay moved. There is no group undo. If you try again after a failure, Rhythm sends every transaction in the list again, including the ones that already moved.
Why a Move Can Be Refused
- The transaction's batch, or the batch you're moving it to, is not open, closed, or in error. A transaction in a posted or downloaded batch cannot be moved. You will see this error on that transaction’s row: “Unable to move a transaction once the batch it resides in has been posted.” Unpost the batch first if you need to correct it. If both the wrong batch and the correct batch have already been posted and exported to your accounting system, unposting to move the transaction may not be the right fix. Correcting the batch assignment across two already-exported, closed periods is usually an accounting decision that calls for a journal entry in your financial management system instead.
- The transaction is tied to a missing related order. If the order behind a transaction no longer exists, the move keeps failing no matter which batch you target. This is different from an ordinary posted-batch refusal, and unposting the batch will not fix it. If you only need to unblock the other, unaffected transactions in the same batch, create a new batch, move those transactions into it, then set that batch's status the way you need and add a note for the history. Leave the transaction tied to the missing order where it is.
- When moving several transactions from a list, Rhythm does not check each transaction’s current batch before you start. Only the target batch list is limited to open batches, so you can still select and send a transaction that is already in a posted batch. That transaction fails only when the move runs. This also applies to a single transaction: getting through Confirm & Preview successfully does not guarantee the final Move Transactions step will succeed, because the real validation happens then.
- The move fails with a technical error mentioning a foreign key to organizations, often with an undefined ID, instead of a clear validation message. This usually means the payment or invoice you are moving does not identify a connected organization. A payment or invoice should otherwise be movable between open batches. Open the transaction, confirm it has an organization selected, save it, and then retry the move. If no organization exists, create one and link the contact to it first. In some cases, simply reopening the payment and saving it again, with no other changes, has been enough to clear the error and let the move go through.
- Closing the dialog without using Close does not tell the page to refresh, even if some transactions already moved. This includes closing with Cancel, the × button, Escape, or a click outside the dialog. Reopen or refresh the page to see the current state.
The same open-batch rule blocks transferring a credit between accounts. If the credit you are transferring sits in a batch that is not open, the transfer fails the same way a move would. Reopen that batch before you try the transfer again.
Related Reading
When a batch you moved transactions out of or into is ready for the ledger, see Post Batches. If you need to correct something in a batch that has already been posted, see Unpost Batches first, then move the transaction.