Posting turns the invoices, payments, refunds, credits, write-offs, and memos in a batch into balanced debit-and-credit entries in your general ledger. Until you post the batch, its transactions affect what a customer owes, but they do not affect your books. This article explains what posting writes for each transaction type and which rules each entry must meet before Rhythm accepts it.
What Posting Does Before It Writes Anything
When you post a batch, Rhythm first removes entries and revenue recognition schedules from any earlier posting attempt for that same batch. This keeps the batch from getting duplicate entries if you post it more than once. If posting fails partway through, the batch has neither its old entries nor new ones, so retry the failed posting run before you rely on that batch’s numbers.
Rhythm does not automatically regenerate subledger entries after you make a correction or apply a fix. To create corrected accounting entries for prior activity, reopen the relevant period if needed, then unpost and repost the affected batches.
While a batch is in error status and has not posted, do not rely on its numbers in subledger or batch reports. They can be incomplete or misleading until you fix the error, such as a missing G/L account, and post the batch again.
What Each Kind of Transaction Posts
Invoices. Under accrual accounting, posting an invoice debits accounts receivable and credits revenue for each line. Rhythm uses the accounts on the product, or the business unit’s default account if the product does not have one. If Rhythm cannot find a receivable account, the invoice fails to post with a message that no accounts receivable account is configured. If Rhythm cannot find a revenue account on the product or through the missing-product default, the invoice fails with a message that no product configuration could be located. One failed line fails the whole invoice, and the batch is marked in error with that invoice listed.
Under cash accounting, invoices do not post entries because receivable and revenue are recognized later, when payment arrives. An invoice batch under cash accounting still posts successfully; it simply does not write ledger entries.
If an invoice is allowed to stay open, posts to accounts receivable, and is never paid, its balance due can show as negative in receivables-related records and reports.
Deferred revenue. If a product recognizes revenue over time, the invoice line credits deferred revenue at the time of sale instead of crediting revenue. How Revenue Recognition Schedules Work explains how Rhythm works out the release dates afterward. If deferral is turned on for a product but no deferred revenue account is configured, the invoice fails to post.
Revenue splits and bundled products. A product can include revenue splits that send agreed shares of a line’s revenue to other accounts instead of sending all revenue to the product’s main account. A bundled product sold as part of another product can also have its own financial setup, so its share of the sale posts to its own revenue account. Unlike an ordinary product, a bundled product with no financial setup has no fallback, so the invoice fails to post instead of using a default account.
Sales and payments across business units. When a sale or payment involves two business units, Rhythm records what one business unit owes the other using the due-to and due-from accounts set up between them. If that setup does not exist, a payment that crosses business units fails with a message that no due-to/due-from entry has been configured between the two business units. An invoice that crosses business units without that setup does not fail for the same reason; it posts using the default accounts for the batch’s own business unit. A standard invoice payment posts its usual cash-and-receivable lines only. It does not also create a separate entry to clear an existing due-to/due-from balance between business units, even when the transaction relates to cross-business-unit activity.
Posting can also fail with a due-to/due-from calculation error when a credit or payment’s business unit does not match the business unit of the related event or product. This can happen even when the sale itself does not cross business units. If you see this error, check that the transaction and its related event or product share the same business unit.
Payments. Posting a payment debits cash to the G/L account on the bank or merchant account used, and credits the invoices the payment pays down. Each invoice paid by the payment must already be posted or must be posting in the same batch, or the payment fails. A payment cannot be applied to a pro forma invoice because pro forma invoices are excluded from posting entirely. Any payment, memo, or refund against a pro forma invoice fails when posted. An overpayment fails unless the business unit has an overpayment liability account configured. A regular payment’s cash entry is aggregated across every item it purchased, so item-level fields like effective date and expiration date are not populated on that entry. Where those dates apply, look for them on the invoice’s own entry line instead.
In the subledger, this can appear as one debit line to the checking or bank account for the full payment amount, plus separate credit lines to accounts receivable for each invoice or receivable balance the payment reduces. Because an invoice posts to accounts receivable and revenue by line, and its payment separately posts a debit to cash and credits to the invoices it pays, one sale can correctly show multiple subledger lines across its invoice and payment activity instead of a single paired debit and credit under one revenue account.
Revenue under cash accounting. For a business unit on the cash basis, revenue is recognized only when payment arrives, not when the invoice is created. Posting a payment under cash accounting debits cash and credits revenue, or deferred revenue, directly using the same product accounts an invoice would have used. Rhythm reads the accounting method when each piece posts, so changing a business unit’s accounting method between posting an invoice and posting its payment can record revenue twice or not at all. Confirm the business unit’s accounting method before you start posting.
Refunds. Posting a refund reverses the cash movement from the original payment. Rhythm must find the original payment’s cash account and posted ledger entry, or the refund fails to post. If the original payment or credit is in a batch that has not posted yet, the failure message names that batch. Refunding a credit in the same batch as the credit itself requires a store-credit liability account on the business unit. If a refund’s own subledger entries were never generated, posting its batch can fail with a message about being unable to locate a cash account for the payment or refund, even though the real cause is the missing subledger entries rather than the account setup.
Credits. A credit given to a customer posts to the store-credit liability account on the business unit because it represents an amount owed back to the customer. If the business unit has no store-credit liability account configured, the credit fails to post, even for a manual credit that would otherwise use its own expense and liability accounts.
Warning
If your business unit's Store Credit Liability account is mapped to a deferred revenue account instead of an appropriate liability account, refunds and credit applications can post into deferred revenue incorrectly. Check Default G/L Accounts, map Store Credit Liability to a dedicated liability account, and repost the affected batch to correct it.
Write-offs. A write-off clears the receivable for an invoice. Depending on the method chosen, it debits either bad-debt expense under the allowance method or the invoice line’s original revenue account under the direct method. The allowance method fails unless a bad-debts expense account is configured on the write-off or the business unit. A write-off can also fail to post if Rhythm cannot find the original invoice’s receivable and revenue entries for the written-off line. Populating the missing G/L account on the invoice line’s product and posting the invoice again usually resolves it.
Credit and debit memos. A memo posts against the same accounts the original invoice used. Rhythm adjusts the same receivable and revenue lines instead of choosing new accounts.
Currency rounding. When conversion between the transaction currency and the business unit’s base currency creates a small difference in the base-currency amounts, Rhythm books that difference to the currency trading account configured on the business unit. If a difference exists and no trading account is configured, the entry fails to post.
The Rules Every Entry Follows
Two rules apply to every posted entry, no matter which transaction created it:
- It must balance. Debits and credits in each transaction currency on the entry must be equal. Rhythm refuses an entry that does not balance, and the batch is marked in error.
- It can only use accounts that belong to its own business unit. Rhythm refuses an entry that names an account from another business unit.
After an entry posts successfully, Rhythm saves it with the account names attached, so you can see where it posted when you review the batch or run a subledger report.
When you compare a deferred revenue batch total to your deferral waterfall, sum the relevant debit and credit lines instead of reading one line by itself. The batch total reflects the net of the positive and negative entries, so one line alone will not match the waterfall.
If you need to review split GL posting details, such as how a payment’s splits posted, use the Finance & Billing > Batches > Subledger Entries query.
Tip
Most posting failures come from a missing account, such as a receivable account, revenue account, store-credit liability account, or due-to/due-from setup between two business units. If a batch shows an error, the error message on the failed transaction usually names the missing account.
If a posted batch’s accounts do not match what you see in your accounting software, first check the batch’s Subledger Entries for its posting date to confirm the G/L account Rhythm intended to use. If the Rhythm-side account is correct, unpost and repost a low-dependency batch to see whether the mismatch happens there too before you escalate it further. Separately, if a Subledger Entries report’s totals do not match your batch or accounting-software export, check whether the report is returning duplicate rows for the same entry. Unposting and reposting the batch does not clear duplicate report rows on its own, so rule that out before you assume the batch itself is wrong.
A regular batch export to your accounting software does not always populate invoice number, product name, and product description on every row. The first row can represent the cash leg of a payment journal entry, which debits a cash account. Because a single payment may apply to multiple invoices, invoice-specific and product-specific values are not relevant to that row and appear instead on the accounts-receivable credit rows.
Tip
Subledger Entries in the console currently shows every amount with a dollar sign, regardless of the transaction's actual currency. Keep this in mind when you review entries for a multi-currency transaction — the amount is correct, but the currency symbol next to it may not match.
Related Reading
Posting only runs on batches you have assembled. See Create or Edit a Batch to learn how to put a batch together, and Download Batches to Your Accounting Software to learn what happens to posted entries afterward. To understand what an invoice is and how its balance and status stay correct before posting, see Invoices.