Posting writes a batch’s accounting entries to the general ledger. If a posted batch is wrong, such as when it includes a payment that should not be there, you cannot edit those transactions while the batch remains posted. Unposting removes the batch’s entries and revenue recognition schedules, then returns the batch to open status so you can correct it and post it again.
When to Use This
Unpost a batch when you need to change or remove a transaction locked inside a posted batch. Because unposting removes real ledger entries, use it when you plan to correct the batch and post it again. If an invoice or order already has a payment attached, you cannot void it while that payment is in a posted or downloaded batch. Unpost the batch first, then make the correction. If Rhythm says a posted batch cannot accept new order or payment activity because it is already posted, unposting is the fix.
Whether you need to unpost depends on the transaction’s current batch status. If a payment is still in an unposted batch, you can usually correct it directly. Once the batch is posted, you need to unpost the batch first. The same applies to a batch created for a deferred-revenue run or another download that has not yet been posted or downloaded in Rhythm. Because there is nothing to unpost yet, correct the source transaction and regenerate the batch before you post or download it. If you already downloaded a batch from Rhythm but have not posted it in your outside financial system, you do not need to reverse anything there. Correct the source transaction, regenerate the batch, and use the corrected file instead of the one you already downloaded.
Some corrections that feel like direct edits require you to unpost and repost instead. For example, if a transaction posted with the wrong payment type, unpost the batch, correct it, and post it again. Rhythm refuses a mass update to the payment type on an already-posted transaction. Unposting and reposting can also help with troubleshooting. If a posted batch looks correct but something downstream, such as a sync to your accounting software, did not finish as expected, unposting and reposting sometimes clears it.
Understanding batches and how to unpost them also helps with other finance corrections, such as voiding a payment, when the posted batch status gets in the way.
Tip
Unposting and reposting puts real transactions back into your general ledger a second time. Some organizations avoid this as a bookkeeping practice and prefer another review path first. Confirm that it fits your accounting controls before you use it as a routine fix.
Prerequisites
- You have permission to unpost batches.
- Each batch is posted or downloaded, or has been stuck "posting" for more than sixty minutes.
- Each batch's fiscal period is still open. You cannot unpost a batch in a closed period until you reopen that period.
- If the batch is from an earlier accounting period, every period between that period and the current one must also be open.
Unpost a Batch
- From the batches list, select the batch or batches you want to unpost, then choose Unpost... from Batch Operations. From a single batch's page, select Unpost this Batch, or select Unpost... from its menu. Until the batch is posted or downloaded, both options are unavailable and show the reason "This batch has not yet been posted."
- Review the batches you selected for unposting. The page lists every batch you selected, regardless of status, and does not remove batches that cannot be unposted. Check each batch's status before you continue.
- If another posted batch depends on transactions in the batches you are unposting, a Dependent Batches Detected card lists those batches and explains that Rhythm will unpost them too.
- Select Unpost Batches.
Result
Rhythm unposts the requested batches and any dependent batches together as a background job. When the job finishes, Rhythm shows how many batches were unposted successfully and how many failed, including the transaction and error for each failure.
Warning
Selecting Unpost Batches acts immediately on every batch listed, including dependent batches you did not select yourself. Rhythm does not show a separate confirmation naming what will be removed, so review the list carefully before you select it.
Unposting Several Batches at Once
You can select every batch you want to unpost from the batches list and update them together with Bulk Changes, the same action you use to post or download several batches at once. To find batches by date, such as everything in a range you need to correct, use advanced search in Finance & Billing before you select them.
Warning
A bulk unpost can fail partway through and stop on a batch that returns an error, even when that same batch unposts successfully on its own afterward. If a bulk unpost or bulk post stops with an error, continue batch by batch instead of repeating the same bulk request. Watch for two other messages: if a selected batch has already been deleted, deselect it and continue with the rest; if the message says some selected batches are already in Open status, deselect those and continue with the ones that still need action.
After a bulk repost, check the result list instead of assuming every batch changed. If a batch still shows a status of Downloaded in the results, that may mean the batch’s status did not actually change.
Reposting many batches at once does not reopen fiscal periods for you. You still need to reopen periods one at a time through Month End Close before their batches can be unposted.
Why an Unpost Can Be Refused
- The batch isn't posted or downloaded, and it has not been stuck "posting" for more than sixty minutes. Only batches in those statuses can be unposted.
- Its fiscal period is closed. Reopen the period before you unpost a batch that belongs to it.
- The batches you selected span more than one business unit. Unpost each business unit's batches in a separate request.
- A dependent batch is still posted and was not included in the request. This can happen when another batch that depends on yours was posted after the page loaded. Reload the page so Rhythm picks up the current dependents, then try again.
- A transaction in the batch references a transaction in a different, still-open batch. Posting the batch that holds the reference is blocked until the referenced batch is closed first. This is a common reason a batch you are trying to unpost, correct, and repost stays blocked on another batch.
- A dependency crosses fiscal periods. A dependent batch can be in an earlier period than the batch you are trying to unpost. If that earlier period is closed, Rhythm refuses the later batch’s unpost, or a reopen of its own period, until you address the earlier period too.
- The batch is from several closes back. Unposting a batch from an older accounting period can require reopening every period between it and the current one, one month-end close at a time, not just the batch's own period.
Tip
This is also why voiding or deleting an invoice, such as one from an installment plan, can be refused with a batch error. The batch named in the error must be unposted first, and if that batch’s month is already closed, you must reopen the period before you can unpost it.
What Unposting Changes
When unposting succeeds, the batch returns to open status, but it still shows when it was previously posted and downloaded. Rhythm removes its subledger entries and revenue recognition schedules, including schedules with entries that were already recognized in a fiscal period that has since closed. You cannot partially undo an unpost. If unposting fails partway through, a batch can be left open with some entries still in place, and you will see that only on the batch’s own page.
Removing a batch’s revenue recognition schedules is not the same as canceling the order behind them. If you cancel an order, cancellation does not delete schedules that were already created. Those schedules are removed only when the batch that posted them is unposted or reopened, so an older schedule can remain visible after the related order is canceled.
Deferral schedules use the product’s deferral configuration and dates from the time the batch was posted. Later changes, such as adjusting a product’s deferral setup, its G/L accounts, or a membership’s dates, do not update a schedule that already exists. To make an affected posted batch use the new configuration, unpost it and post it again. The same applies after you activate a membership whose deferral schedule was calculated incorrectly beforehand. Unposting and reposting to correct a deferral this way does not delete the underlying invoices or payments. It rebuilds only the batch’s entries and schedules.
Rhythm does not create subledger entries retroactively. To record a correction in the fiscal period where it belongs, such as backing out a duplicate deferral or a missed deferral reversal, reopen that period and the periods after it. Then unpost and repost the affected batches so the entries regenerate in the correct period, not in whichever period is open now. Reposting can also refresh other subledger values that are set at posting time, such as an accounting project, once you reopen the periods needed for the correction.
Warning
A membership record with an expiration date set unrealistically far in the future can make Rhythm defer revenue for decades. That can cause a credit card batch to fail to post or refuse to close. If a batch error points to a membership deferral that looks wrong, check the membership’s expiration date before you assume the batch itself is broken.
Applying a Correction to Already-Posted Batches
Posting uses the financial configuration, such as G/L accounts and department settings, that was in effect when the batch posted. Changing that configuration afterward, including a product’s revenue G/L mapping or department assignment, does not recalculate batches that already posted. To make an already-posted batch reflect a corrected configuration, unpost it, reopening its fiscal period first if needed, and post it again.
This also applies to deferred revenue. If you turn on deferred revenue recognition, or change its G/L accounts, after payments already posted under the old configuration, those existing postings do not move to the new accounts on their own. Unposting and reposting the affected batches is what moves them.
Warning
If your accounting system’s G/L structure changes after a batch has already posted and been exported, a later transaction in that batch, such as a refund, can still reference the old account and fail to export. You have two ways to recover: recreate the old G/L account in your accounting system using the name or code the historical transaction expects, or reopen the batch’s fiscal period and repost it so the current G/L structure is transmitted instead.
Because you cannot directly change the G/L account on a posted batch in a closed fiscal period, the correction always requires reopening the affected period, or year, and reposting the batch. You cannot edit the closed posting in place.
If revenue G/L configuration changes after batches have already posted and been exported to your accounting software, take a fresh look at deferred revenue schedules, month-end subledger reports, and previously exported entries. Regenerating or revalidating them after a configuration change is safer than assuming nothing downstream was affected.
If a Batch Won't Post or Unpost
Some blocked batches are best handled by isolating the problem transaction instead of trying to fix the whole batch in place. If a transaction blocks posting because it references a credit, product, or line item that no longer exists, moving it into a separate archived batch lets the rest of the batch post normally. An archived batch is excluded from your accounting-system feed, so it is also useful when you know a transaction is wrong, such as one created for testing, and need to keep it out of your accounting close without deleting it. Because the right way to isolate a blocked transaction depends on exactly what it references, work through this with Support instead of following a single fixed recipe. In some cases, Support has also moved a batch’s date forward to keep a period close moving while the underlying issue is investigated separately.
If you already posted duplicate batches to your accounting software, the cleanup depends on which fiscal periods are affected. You may need to delete the duplicate batches, or record a manual journal entry that offsets the duplicated amounts, instead of expecting Rhythm to reconcile them automatically.
If a batch error says a batch it depends on is still open, even though that batch looks closed to you, reopening the relevant accounting month and then unposting and reposting the referenced batch has cleared this. In some cases, the referenced batch is not just closed but fully Posted already, and the error still incorrectly calls it Open. Treat that mismatch the same way, and contact Support if reposting the referenced batch does not clear it.
A posting failure can also come from a payment that was refunded and then voided. Because a voided payment has no subledger entries of its own, a refund tied to that payment has nothing to reference when the batch tries to post. The resulting error can point at an unrelated batch as needing to post first. If you see a posting error like this, check whether the referenced payment was both refunded and voided before troubleshooting the batch the error names.
You cannot simply delete a contact or invoice tied to a posted and downloaded batch, including to satisfy a privacy request. Anonymizing the record, rather than deleting it, keeps the posted batch and your accounting history intact while removing the personal information.
Troubleshooting Subledger and Download Results
If subledger entries look duplicated, doubled, or otherwise wrong after posting, unposting and reposting the batch is the first thing to try. It resolves the mismatch in some cases, but not always. If the discrepancy remains after a repost, contact Support instead of repeating the action. The same applies to an ACH batch showing doubled amounts. A batch-posting issue is a common cause, and unposting and reposting sometimes clears it.
If duplicate entries appear in your accounting software after a batch downloads, check whether entries there are set to be automatically removed when you unpost the corresponding batch in Rhythm. This setting controls whether unposting also cleans up the downloaded side, not just Rhythm’s own entries.
After a fix changes what a batch download reports, such as a corrected date field or a new column like Department in the Subledger Entry report, an existing batch may still need to be unposted and reposted before the correction appears. Downloading the same batch again without reposting it first can still show the old values.
If an invoice’s balance due does not reconcile with a payment that has already posted, unposting and reposting the affected batch is a reasonable troubleshooting step before you escalate it.
A fix to how batches are assigned does not change batches that were already closed, posted, or downloaded. Rhythm does not retroactively reassign historical batches, because changing a prior posted or closed batch would create an accounting inconsistency. The fix applies only to activity going forward.
Related Reading
To post a batch after you correct it, see Post Batches. If the transaction you need to fix should be in a different batch, see Move Transactions to Another Batch once the batch is unposted.