Nothing in a batch reaches your general ledger until you post it. Posting turns each invoice, payment, refund, credit, memo, and write-off in the batch into balanced accounting entries. It also marks the batch as posted, so you can download it to your accounting software.
When to Use This
Post a batch after you review its transactions and are ready to record them in your books. You can post one batch or several batches at once, as long as they all belong to the same business unit.
Prerequisites
- You need permission to post batches.
- Every product on an invoice in the batch needs a revenue account before the batch can post. If a product does not have one yet, the posting wizard lets you add it while you post.
- You can post only batches with an open, closed, error, or verified status. You cannot post a batch that is already posted, already downloaded, or has been in posting status for less than five minutes.
Post One or More Batches
- From the batches list, select the batch or batches you want to post, then choose Post... from Batch Operations. You can also open one batch page and select Post this Batch, or choose Post... from its menu. After a batch is posted or downloaded, both options are unavailable and show the reason "This batch has already been posted."
- On Product Configurations, review any products listed under Products Needing Configuration. For each product, choose a Revenue G/L account, or select Advanced... to add more financial details. Products that already have setup appear under Configured Products, where you can adjust them the same way.
- Select Save Configuration & Continue if any product needed setup, or Continue if none did.
- On Review Batches, check the Ready to Post and Unable to Post cards. At this stage, a batch appears as unable to post only if it has already been posted. Any other issue that blocks posting appears after you post.
- Select Post Batches.
Setting a product's revenue account here does not change which revenue category its sales use elsewhere, because the batch does not control that. Revenue follows the G/L code on the product itself, such as an event registration package, along with your business unit's accounting setup. Turn on deferred revenue for a product, including a product bundled inline into another product, only when you want that product's revenue deferred. Posting does not otherwise require deferred revenue setup.
Result
Rhythm posts the eligible batches as a background job, then shows Complete with each batch's status. If any batch failed, you also see the transaction and error message that caused the failure.
To confirm what a batch posted, review the Subledger Entries report, run a Subledger Entries or Subledger Entries by Batch query, or open the invoice's 360 page, which can show its subledger entries directly. A posted batch's debits and credits should always total the same amount. Treat a mismatch as a sign that something went wrong, not as an expected result.
Why a Batch Cannot Be Posted
Its status isn't postable. Only open, closed, error, and verified batches can post. A batch that has been in posting status for more than five minutes is treated as stuck, so you can try posting it again.
It belongs to a different business unit than the others you selected. All batches in one posting request must belong to the same business unit.
A transaction in it depends on a batch that isn't posted yet. A payment or adjustment whose original transaction is in another batch cannot post until that other batch posts first. The batch ID in the error points to the other batch that holds the referenced transaction. That batch must be posted, not just closed, before your batch can post. The error message tells you to post the source batch first, and the other batches you selected still post normally. This is the most common reason a refund batch cannot post: a refund that references a payment in a batch with error status stays blocked until that original payment batch is corrected and successfully posted. If you keep seeing an unsuccessful-posting notice for the same batch, an earlier batch it depends on is usually still unresolved. The notice keeps appearing until every batch behind the error is corrected and posted.
A batch it depends on failed in the same posting run. If a batch fails, every batch in the same run that depends on its transactions also fails, so you can correct and post them together.
A referenced liability account, such as Store Credit Liability, is missing on the business unit. Posting can fail when a liability account is missing under Finance & Billing › Setup › Business Units. Add the missing account and try posting again. If the account is already configured and the same error still appears, this has also been observed as a product issue rather than a setup problem. Contact Support instead of assuming the business unit setup is wrong.
A refund is in the batch ahead of its payment. If you place a refund in a batch before the payment it offsets, Rhythm can have trouble reconciling the batch during posting because it expects the payment to be available for the offset. Move the refund into the same batch as its payment, or keep it in its own batch until the payment posts. Do not leave the refund ahead of the payment it belongs with.
A related credit or invoice is stuck in an archived batch. A payment cannot post if its related credit is in an archived batch. The archived batch never generated the accounts-receivable and revenue subledger entries that a payment needs to reverse or apply against, so the payment has nothing to post against. The same is true in reverse: a payment that backs out a credit needs that credit's original batch context and subledger entries, which an archived batch does not have. You can see which batch a related credit or invoice is in from the payment's related transactions. Because you cannot move a transaction into or out of an archived batch yourself, contact Support to realign the records into an open batch.
The business unit or a business unit-scoped account is missing. Some errors point past the transaction to setup at the business-unit level. For example, a payment with an overpayment cannot post without an overpayment liability account configured for its business unit, and a credit or store credit cannot post without a Store Credit Liability account configured there. Review the business unit's default accounts under Finance & Billing › Setup › Business Units, then add whichever account is missing.
A payment crosses business units and the product isn't set up for it. When a payment is collected in a different business unit than the merchandise or other product it pays for, posting depends on that product's own inter-business-unit due to/due from accounts. Those accounts are set on the product's Financial Setup, not only on the due to/due from accounts configured between the business units themselves. If posting fails for a cross-business-unit payment, check that setting on the product.
The product behind a transaction was deleted. If a product used on a transaction was later deleted, such as an older chapter dues or membership product, Rhythm no longer has a product record or financial setup to show you. Posting still needs an account for that line's revenue, so set the business unit's Missing Product Revenue G/L account as a fallback. Rhythm credits that account for any sale whose product has no financial setup of its own, including a product that no longer exists.
A hidden or unlocatable dependent batch. If you are posting several errored batches together and one fails because it references another batch that does not appear in your batch search, contact Support. The batch it depends on may not be available through the normal batch list.
Tip
Posting leaves void and deleted transactions out of the ledger entries it creates, even though a void transaction's amount is still counted in the batch totals.
Tip
If subledger amounts look doubled for a batch, check whether the batch was posted more than once at the same time. This can happen if you include it in two separate posting requests or select Post twice in quick succession. Nothing stops two posting attempts for the same batch from running at the same time.
Warning
A batch with no transactions when it is posted may be deleted automatically instead of being kept as an empty posted batch. If you expected to see that batch afterward and cannot find it, check whether it was removed this way. If you recreate a batch using the same ID and posting makes it disappear the same way, archive the recreated batch instead of trying to post it again.
Two Batches That Depend on Each Other
Sometimes two batches block each other at the same time. Batch A's error says a transaction in batch B must be posted first, while batch B's error says the same thing about batch A. This has been seen between a daily credit card batch and a miscellaneous batch posted separately, between a return or refund batch and the earlier batch holding the related overpayment credit, and after applying credit funds to certain event registration transactions. A batch can also stay blocked because a related batch is already in error from an earlier failed run. The error message on the blocked batch usually names the related batch you need to clean up first.
Posting each batch by itself repeats the same error. If you keep posting the batches one at a time instead of together, the issue can escalate. One batch can move from the open-status dependency error into an Error status of its own, and the other batch's message then changes to say that the now-errored batch must be posted first. Posting the related batches together usually resolves it:
- Search the batches list, for example by Status: Error, or by the batches' name or date, to find every related batch.
- Select all of the related batches at once.
- Choose Post... from Batch Operations, the same way you post a single batch.
If one of the related batches is already posted, unpost it first so you can post it together with the others in the same request.
Occasionally, the error names a batch as still open even though you can see it is already posted. The mismatch can also persist after you have tried posting the related batches together, or after unposting and reposting them. Both are signs of an incorrect batch status rather than a real posting-order problem. If it does not clear after you retry once, contact Support instead of repeating the same attempt.
Posting That Happens Automatically
A batch can also post itself without anyone starting it when it has an automatic closing time and that time arrives while the batch is still in a postable status. This runs on the same schedule Rhythm uses to check for due work, so posting can happen up to a few minutes after the closing time. If the batch is no longer in a postable status when its time comes, nothing happens and the batch stays as it was.
If you are checking whether an automatic posting ran, look carefully at the batch names and dates in your search results first. A batch that is open and named for the current date does not mean automatic posting failed on an earlier batch. It may simply be a different batch than the one you expected to see posted.
What Reposting Regenerates
An invoice or credit memo's subledger entries, including its G/L account, department value, and account name, are generated from the product's financial configuration and account setup at the moment the batch posts. Changing that setup afterward does not retroactively update a batch that is already posted, including a batch in a fiscal period that has since closed.
To carry a G/L, department, or account-name correction over to already-posted transactions, unpost the affected batch and post it again. Reposting regenerates the batch's subledger entries, and what a query or the Subledger Entries report shows for it, from the current product and account configuration. If a whole category of transactions posted to the wrong account, look at the product behind them instead of editing the invoices directly. Update that product's G/L account in its own Financial Setup, then unpost and repost the affected batches so the correction carries through to their subledger entries.
Changing your revenue G/L configuration after batches have already posted and been downloaded can leave deferred revenue schedules, month-end subledger reports, and previously exported accounting entries out of step with the new setup. Unposting and reposting the affected batches regenerates their subledger entries from the current configuration, but anything already downloaded or exported to your accounting software needs its own review. Regenerating a Rhythm report does not retroactively correct an export you already sent.
Reviewing or changing a product's configuration during the posting wizard does not always clear an invalid G/L reference that is already attached to a pending batch. If a batch stays stuck on an invalid G/L account after you correct the product, unpost and repost the batch, or move the affected transaction, instead of expecting the review step alone to fix it. The opposite limitation also applies: if the product itself is missing or has an incorrect G/L account, such as a miscellaneous product with no G/L account of its own, unposting and reposting will not correct a wrong subledger code by itself. Fix the product's own financial setup first, then unpost and repost the affected batches.
If Posting Fails
A batch that fails to post shows an error status, along with the transaction and message that caused the failure. Correct the cause, often a product that still needs financial setup, then post the batch again. Any invalid or missing G/L account setup on a transaction in the batch blocks posting the same way, not only a missing product revenue account. If posting fails partway through for reasons outside your control, the affected batches may be reopened so you can try again. Check each batch's status on its own page.
- The error refers to a pro forma invoice. A payment, memo, or refund posted against a pro forma invoice fails because pro forma invoices are excluded from posting entirely. Open the invoice and use Invoice Options › Adjust Items to make the adjustment that clears its pro forma status and assigns it to a batch, then reopen and repost the batch that failed.
- A membership or event date is far out of range. A badly mistyped term, start, or expiration date, such as a start year of 205 instead of 2025 or an expiration date decades in the future, can make Rhythm try to build a revenue recognition schedule spanning hundreds of years. Instead of the plain sixty-month schedule limit, this sometimes appears during posting as a generic "Unknown Error" or a maximum item size error because the oversized schedule is failing, not the batch itself. If a batch fails this way for no obvious reason, check the term, start, and expiration dates on the memberships or events it contains before assuming the batch has too many transactions.
- A cancelled order's deferral doesn't always disappear on its own. Posting does not build a revenue recognition schedule for an invoice whose order is already cancelled before the batch posts. See How Revenue Recognition Schedules Work for what happens to that deferred amount instead. However, cancelling an order after its invoice already has a schedule does not stop that schedule by itself. Posting a later, replacement order's batch has been observed to add deferral entries that reflect the cancelled order as well as the new one, making the deferred total look doubled. If a deferred balance does not match your active orders, check whether a cancelled order's own schedule is still contributing to it.
- The error names a schedule or a subledger lookup, not something in your setup. Occasionally, a batch fails because a generated revenue recognition schedule identifier is invalid, or because Rhythm cannot find the accounts-receivable subledger entry it expects for a write-off, even though the write-off's account is configured correctly. Both errors point to a data problem behind the scenes rather than something you can fix in Finance & Billing setup. Contact Support with the batch and transaction involved.
- A refund or credit points to a payment or invoice that's voided. Posting a refund or credit looks up the subledger entries on the payment or invoice it reverses. A voided transaction never generates subledger entries, so a refund still tied to a payment that was voided, or a payment still applied to an invoice that was voided, can fail to post. The failure sometimes appears as the ordinary cross-batch message that a referenced batch is not posted yet, even when that batch is already posted, because Rhythm cannot tell the difference between missing entries and an unposted dependency. This has also been seen specifically under cash accounting. If you run into it, check whether the payment or invoice behind the refund or credit was voided. Voiding the refund as well, or moving it into its own batch to archive and recording it manually in your accounting software, are the approaches that have resolved it.
- A cancellation-fee store credit payment fails with a product-type error. A cancellation fee paid out as store credit can occasionally fail posting with an error that refers to an undefined product type. There is no separate product-type setting to configure, so contact Support if you see this.
- A multi-currency batch fails over a small exchange-rate difference. In a multi-currency business unit, a refund or similar transaction can occasionally fail to post with an unbalanced-entries or currency-code error tied to the foreign currency, even when the business unit's currency trading account is already configured for rounding differences. This has also happened on batches that do not use multiple currencies at all. Treat a currency-related validation error as its own cause instead of assuming your currency setup is wrong, and contact Support if reconfiguring the account does not clear it. A related, more specific error names a currency conversion rounding difference together with a missing currency trading account; treat that combination as its own diagnostic clue when a batch otherwise looks correctly set up.
- Posting seems stuck with no clear error. Rhythm can decline to finish posting a batch to avoid creating duplicate subledger entries. Reopening the batch and posting it again, sometimes more than once, has resolved this without leaving behind incorrect accounting.
- One bad transaction is blocking an otherwise-good batch. If a single transaction keeps generating the error, move only that transaction to a separate batch. See Move Transactions to Another Batch, then archive that batch once it is set aside. The rest of the original batch can then post normally. You can also move a batch's errored transactions into a dedicated batch for unresolved transactions so the rest of the affected batches can keep posting. This only postpones the problem because the moved transactions still need to be corrected and posted eventually.
- You need to void something that batches have already posted on top of. If you are reversing a historical transaction that later batches depend on, unpost the affected batches starting with the most recent and working backward to the oldest before you void anything. After the void is in place, repost them in the opposite order, from oldest to newest.
- A credit or store credit fails over liability account setup. A credit posts to the business unit's Store Credit Liability account, and the batch fails if that account is not configured there. A store credit itself has no cash account or other financial settings to configure. Refunding one is expected to simply return the credit with nothing else to set up. Adding the G/L account to your chart of accounts is not enough by itself. You also need to select it as the business unit's Store Credit Liability account under Business Units setup before the affected batches can post.
- A batch shows errors, but you're really asking whether a payment went through. A batch's posting status and whether a customer's payment was actually charged are separate questions. Missing G/L setup is a common, unrelated reason a batch shows errors and needs manual reconciliation, regardless of whether the payments inside it were successfully charged.
Related Reading
To reverse a posting and correct something inside it, see Unpost Batches. To fix a transaction that landed in the wrong batch before you post, see Move Transactions to Another Batch. For the accounts a product's or business unit's configuration uses when a batch posts, see Product Financial Setup and Business Units.