Every Finance & Billing transaction needs a batch unless the transaction already has one. For each business unit, batch assignment settings choose one default recurring batch for all transactions. You can also add rules for specific transaction types, payment types, card types, or merchant accounts. The recurring batch opens new batches and posts old ones on schedule, so staff do not have to manage batches manually.
What It Controls
This setup has two connected parts. Batch assignment settings send each new transaction to the right recurring batch. Recurring batches control the schedule. Each recurring batch opens a batch for its business unit, names and numbers it, then posts it and opens the next batch automatically. In Finance & Billing setup and Support conversations, "BU" is common shorthand for business unit.
When you clear an invoice's pro forma setting and make it a real invoice, Rhythm also needs to assign that invoice to a batch. A financial invoice needs a batch, while a pro forma invoice does not. Your default recurring batch or batch assignment rules can supply that batch automatically when the invoice is created through a process that assigns one. If you convert the invoice manually, you still need to choose a batch during that change.
Batch assignment is separate from revenue and general ledger coding. Routing a transaction to a batch only decides which batch it belongs to for reconciliation. It does not change the G/L account the transaction posts to. For example, a transaction can be in a daily credit card batch and still post to the correct G/L code for its product area.
Tip
Name each recurring batch, and the batches it opens, for the activity that actually lands there. A daily credit card batch is easiest to reconcile when it only receives credit card activity. If refunds or other payment methods also route there, update the name or adjust your rules so the name and contents match.
Where to Find It
Go to Finance & Billing › Setup › Batch Assignment Settings to edit routing rules for your current business unit. Go to Finance & Billing › Setup › Recurring Batches to create or edit recurring batches. To configure another business unit, switch the working business unit in the top bar. Batch Assignment Settings uses your current working business unit, because each business unit has at most one settings record.
The Settings
Batch Assignment Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Default Recurring Batch: | An active recurring batch for this business unit | None | Receives the transaction when no rule matches. You must choose one before you can save |
| Batch Assignment Rules | An ordered list, with each rule naming a recurring batch and optional transaction types, payment types, card types, and a merchant account | None | Sends matching transactions to a specific recurring batch instead of the default. Rhythm uses the first matching rule in the list |
Select Add Batch Assignment Rule to add a rule. Each rule needs a description and a recurring batch. Transaction type, payment type, card type, and merchant account conditions are optional. Leave a condition blank when the rule should match every value for that condition. Use the up and down arrows next to a rule to move it in the list, because Rhythm uses the first matching rule when more than one rule applies.
Tip
Put your broadest rule, with few or no conditions, last in the list. Because the first matching rule wins, a broad rule placed earlier can catch transactions you meant for a more specific rule lower down.
ACH and Wire Transfer are separate payment-type values. A rule that matches Wire Transfer does not also match ACH payments. If the same batch should receive both, select both values in the rule's payment-type condition. Card type works the same way for the card brand. Rhythm matches the card brand reported by your payment gateway, so a card the gateway misidentifies, such as an American Express card reported as Visa, can route by a card-type rule as Visa.
Transaction type matters too. An order-related credit card transaction uses the Order transaction type. If your Credit Cards rule does not include Order, those transactions can miss the rule and fall through to the default batch. If you add a transaction type to one payment-method rule for consistent routing, consider adding the matching transaction type to your other rules, such as Electronic Checks, Paper Checks, and the default, so every payment method routes consistently. An offline credit card payment can also post to a different batch than an online one unless your rules cover it. If offline card payments consistently show up somewhere unexpected, check whether your rule conditions include that case. A rule setup issue can send an electronic check or ACH payment into a credit card batch, or vice versa, so review the rule's exact conditions before assuming Rhythm routed the payment incorrectly.
Recurring Batches
| Setting | Options | Default | Effect |
|---|---|---|---|
| Business Unit | A business unit | The working business unit | Controls which business unit's batches this recurring batch opens. You cannot change it after creation |
| Name: | Any text | Blank | Sets the display name and provides the basis for the suggested identifier and templates |
| ID: | Text starting with the business unit's identifier | Suggested from the name | Sets the recurring batch's permanent identifier. You cannot change it after creation |
| Status: | Active, Inactive | Active | Controls whether the recurring batch runs on its schedule |
| Batch ID Template | A template | Built from the name and the date | Controls how each batch this recurring batch opens is identified |
| Batch Name Template | A template | Built from the name and the date | Controls how each batch this recurring batch opens is named |
| Batch Schedule | Daily, Weekly, Monthly, Yearly, or Advanced | Weekdays at 5:00 PM | Controls when the current batch is posted and the next one opens |
Choose a schedule type, Daily, Weekly, Monthly, Yearly, or Advanced, then set how often it runs and at what time. Rhythm describes the schedule back to you in words, such as "At 06:00 PM (EST)," so you can confirm it matches what you intended. Rhythm always reads and runs that time in Eastern Time, no matter which time zone your business uses. Keep that in mind when you choose a time. If the schedule needs to align with your local evening, a payment processor's cutover time, or month-end processing, set it relative to Eastern Time instead of your local clock. If you change a cutoff time with your payment processor, update the matching recurring batch's schedule in Rhythm to the same target time so the two stay aligned.
A schedule that runs on the hour is the safest choice, because the process that rolls a recurring batch over checks on the hour. If you set a cutoff at a time that is not on the hour, such as 9:30 PM, a transaction created after your cutoff but before the next hourly check can still be picked up by the batch that should have already closed.
For a daily batch that should open a fresh batch for each new calendar day, an early-morning Eastern Time creation time is usually safer than a late-evening time. A later time can let a transaction from just after midnight in your own time zone still fall into the previous day's batch, which makes day-by-day reconciliation harder.
If your schedule runs every working day rather than daily, transactions from Saturday, Sunday, and the following Monday can all be grouped into the batch dated for the last working day before the weekend. If you want weekend transactions to land in their own batch instead of being folded into a weekday batch, change the schedule to run daily.
Tip
If the daily processing you expect from a recurring batch is not happening, first confirm that the recurring batch exists, is set to Active, and points to the batch you expect. Also check whether it stopped rolling forward at a fiscal-year boundary. A recurring batch cannot open a batch dated outside an open fiscal year, so if multiple days' worth of transactions are piling into one older batch, confirm that a new fiscal year has been created and is open.
Tip
If activity temporarily has nowhere to go while you correct a recurring batch's timing, an open catch-all batch can keep transactions flowing. Point the default recurring batch at it, then switch the default back once the properly scheduled recurring batch is ready. If a recurring batch stops accepting new transactions with a batch-related error, deactivating it and then reactivating it can also resolve the error and let renewals process again, though this is not confirmed as an intended fix.
Tip
If administrators cannot process payments because automatically assigned transactions are targeting a batch that has already closed, an administrator can restore processing by mass-updating the recurring batch's active batch to the current day's batch. Re-saving batch assignment settings that already look correct is also a reasonable step to try if payment-link errors continue for no obvious reason.
Some features outside Finance & Billing, such as certain job-posting coupon codes, depend on default batch settings for the business unit. If creating one of these fails only in your sandbox and works in your live account, check whether default batch settings exist where it is failing.
Dependencies and Precedence
- A recurring batch must exist before you can route to it. Create at least one active recurring batch for a business unit before you choose a Default Recurring Batch: or build a rule.
- Rules and the default must stay within the business unit. A rule or default recurring batch must belong to the same business unit as the settings you are editing.
- Only one schedule per day, at most. A recurring batch's schedule cannot run more than once every 24 hours.
- A rule's bank account condition has no effect on routing. A rule can include a bank account condition, but only merchant account, transaction type, payment type, and card type decide where the transaction goes.
- A batch that is already posted cannot accept a new transaction. If the batch a rule or default points to has been posted, Rhythm refuses an incoming transaction targeting it, including a join, renewal, or registration, instead of placing it somewhere else. Reopen the batch, or point routing at the current one, to let transactions resume.
- A new day's batch must exist before Portal payments can use it. If the current target batch has already posted and the next scheduled recurring batch has not been created yet, an incoming Portal payment has no open batch to use and fails with an error naming the posted batch.
- A batch's System Created Date is stored in UTC. A transaction entered late in your local evening can be stamped with the next calendar day's date, which can make it land in a different day's batch than you expected. If a transaction appears to be in the wrong day's batch only near your local end of day, check whether the difference between UTC and your local time explains it.
- Batch and date scope at a period boundary can shift a reconciliation count. A query or report run around the start or end of a period can pick up a small number of entries from a batch dated just outside the period you meant to cover. Even after you are confident you chose the right dataset, double-check batch dates at the edges of your range before treating a small variance as an error.
- Deleting a batch while it is in the middle of posting can leave a stale reference behind. If a batch still appears as related to a recurring batch after that batch was deleted, and it blocks you from deleting the recurring batch, the batch may have been deleted during posting. Contact Support if reassigning or removing the reference does not clear it.
For cleaner reconciliation between your Rhythm batches, your payment gateway's disbursements, and your financial management system, consider keeping batches separated by payment method and transaction type. For example, credit card payments, credit card refunds, ACH/eCheck payments, ACH/eCheck refunds, checks, and manual payments can each have their own batch.
Change Impact and How to Revert
Saving an active recurring batch, or switching one back on, opens a batch right away if it does not already have one, so your change can create activity immediately instead of waiting for the next scheduled run. Closing a batch by hand creates a new open batch automatically only when an active recurring batch manages that batch. A batch created outside of a recurring batch is not replaced this way.
Changing a Rhythm Payments recurring batch's cutoff time can delay next-day funding. Confirm that the new cutoff still lines up with your card processor's own daily cutoff before you change it, because a later Rhythm cutoff can push settlement, and the funding you expect the next day, later than you intend.
Saving an active recurring batch, or switching one back on, opens a batch right away if it does not already have one, so your change can create activity immediately instead of waiting for the next scheduled run.
Turning a recurring batch back on after it was off can also post its old batch and open a new one right away if the schedule's next run time passed while it was off.
Do not manually post a batch that a recurring schedule manages. Weekly and monthly recurring batches post themselves on schedule. If you post one by hand ahead of that schedule, incoming transactions can still target the now-posted batch. This interrupts new transaction intake until you unpost it and let the schedule take over again, or otherwise correct the routing.
Deleting a recurring batch is only possible when no batch, default, or rule still points to it. If it is still referenced, remove those references first, or switch it to Inactive instead of deleting it.
Changing a business unit's default or rules affects only new transactions from that point forward. It does not move transactions that are already assigned to a batch.
Permissions
You need the Collect Administrator role to view or change batch assignment settings and recurring batches. See Set Access and Permissions in Finance & Billing.
Validation and Errors
- A Portal order or payment fails with a message that no batch was specified. This means no batch assignment was available for that transaction's business unit when it was processed, usually because no active Default Recurring Batch: is configured for it. Set one up here before Portal purchases in that business unit can complete. By itself, this message does not mean there is a product problem.
- Rhythm refuses to save batch assignment settings without a Default Recurring Batch:.
- If a rule with both a merchant account and a bank account chosen will not save, and the business unit only has one bank account anyway, leave the rule's bank account blank. The merchant account alone is enough to match the transaction.
- Rhythm refuses a default or rule when its recurring batch belongs to a different business unit.
- A recurring batch's identifier must begin with its business unit's identifier. Rhythm refuses a schedule that runs more often than once every 24 hours.
- You cannot change a recurring batch's business unit after it is created; Rhythm refuses the save.
Related Tasks
Once your recurring batches are running, download their batches to your accounting software; see Accounting Software, Downloads, and Document Templates. Set up your chart of accounts and merchant accounts, which batch assignment rules can reference, in Chart of Accounts, Bank Accounts, and Reporting Dimensions.