Closing a fiscal period does more than mark a month as final. It also affects revenue recognition schedules and your fiscal calendar. This article explains what closing does, what reopening undoes, and what to check if either process fails partway through.
If you backdate a transaction after a fiscal period’s snapshot has already been preserved, Rhythm does not rewrite that earlier snapshot. Rhythm keeps the original snapshot for data integrity, so historical reports can show a transaction date that differs from the fiscal period context recorded for it.
What Closing a Period Actually Does
When you close the current fiscal period, Rhythm does three things beyond marking that period closed:
- It recognizes revenue. Rhythm recognizes every revenue recognition schedule entry due on or before the period’s end. Entries dated after the period being closed are not changed and keep their current status.
- It closes finished revenue recognition schedules. If the close recognizes the last remaining entry on a schedule, Rhythm closes that schedule as part of the same close. A revenue recognition schedule can therefore close without anyone updating it directly, because the period containing its last entry was closed.
- It keeps your fiscal calendar ahead of you. During a close, Rhythm generates additional fiscal years as needed so your account always has at least three fiscal years open ahead of the one you are working in, up to a limit. Under ordinary use, you should not need to create future fiscal years by hand.
When you close the last period of a fiscal year, Rhythm closes that fiscal year along with the period.
After a close finishes, the figures it produced for that period are locked in. They stay fixed until you reopen the period and close it again, which is the only way to recalculate a period’s month-end numbers.
Tip
If your ledger’s monthly batch activity for a period does not include revenue that a schedule shows as recognized for that same period, check whether the close actually completed. Recognition and posting both happen during the close, so a failed close or a close that rolled back partway can leave recognized revenue and posted batches out of step for that period. When you reconcile deferred revenue, compare the month’s posted batch totals, its deferral waterfall, and the deferred revenue liability on your general ledger together. Each source tells a different part of the story, so relying on only one can give you an incomplete view.
What Reopening a Period Undoes
Reopening the previous fiscal period reverses the work that the close did for that period:
- It un-recognizes revenue. Rhythm reverses the revenue recognition entries that the close made for that period. Depending on how your account processes this, entries dated before the period that were also recognized when the close caught up may not be reversed by reopening, and they can remain recognized after the period reopens.
- It removes the period's close-related batches and ledger lines. Reopening deletes every deferred-revenue and cost-of-sales batch that the close created for the whole period, not only the batches tied to the correction that prompted the reopen. When a batch is unposted, that batch’s own subledger entries are removed as well. Together, those actions remove the subledger entries created by the close’s batches, so they will not return in queries until you close the period again.
- It marks the period, and its fiscal year if applicable, open again.
Fiscal years generated during the original close are not removed by reopening. Reopening affects the period’s recognition and batches, not the fiscal calendar structure the earlier close created.
Because reopening deletes the whole period’s deferred-revenue and cost-of-sales batches, reopen a period only when you intend to redo its close. Reopening is not a narrow undo for one transaction.
When you close the period again after reopening it, Rhythm recalculates and posts its entries using the product setup and G/L configuration that exist at that later time. It does not use the setup from when the period was first closed. If a fix changed how revenue is deferred or recognized, correcting deferred revenue for past periods can mean reopening and reclosing every affected period in sequence, starting from the earliest one, rather than jumping straight to the period you need to fix.
Before you repeat a reopen and close in your live account, test the reopen-and-reclose cycle in your sandbox. Comparing the resulting deferred revenue batches or reports against what you expect is a safe way to build confidence.
Warning
Reopening a fiscal period is a manual action you take deliberately. It does not, by itself, reopen closed revenue recognition schedules, and whether reclosing regenerates every deferred entry you expect depends on the state those schedules were left in. If subledger entries and a schedule’s recognized status do not agree after a reopen, check both carefully and contact Support before reclosing. Reposting in an inconsistent state risks double-counting revenue.
What Happens If a Close or Reopen Fails Partway
Closing and reopening each include several steps that run in the background, so they do not finish instantly. Either process can fail before all steps are complete. If you start a close or reopen for a period while the same action is already running for it, the new request can fail outright instead of starting a second run. Wait for the first one to finish before trying again.
If the failure happens before Rhythm writes anything, there is nothing to undo, and you simply see the failure. If earlier steps already wrote data before a later step failed, Rhythm tries to reverse what it wrote and put the period back to open. If that reversal also fails, Rhythm records the second failure behind the scenes instead of showing it to you, so you may see only the original close error.
In that case, some close-related records can remain in place even though the period is open again. A close can fail this way even when the Month End Close page showed the period as Ready to Close and every batch appeared posted and accounted for beforehand. That state does not guarantee the close itself will succeed. A period with an unusually large number of revenue recognition schedule entries can also hit a processing limit and fail partway for that reason alone. If you suspect this is happening, contact Support, because the entries may need to be worked through in smaller batches rather than simply waiting longer.
Reopening has a similar risk in the other direction. If one reopen step fails after an earlier step in the same reopen already made its change, the period can be left partly reopened with no automatic recovery. You may also be told the reopen succeeded even though it did not fully complete.
If you followed every prerequisite correctly and a close still fails, that does not necessarily mean you did anything wrong. A close can fail from causes outside your control, so do not assume you missed a step.
Warning
After a close or reopen reports a failure, or if you have any reason to doubt that it completed cleanly, verify the period’s actual state before you assume everything is back as expected. Check its batches, revenue recognition schedules, and status before you close or reopen it again. Contact Support if something looks inconsistent, because the product does not correct a partial close or reopen on its own.
One consequence is worth knowing: if a reopen does not fully remove a period’s earlier ledger lines, closing that period again later writes over those same ledger line identifiers instead of adding fresh ones. This is generally harmless as long as the earlier reopen otherwise completed, but it is another reason to confirm that a reopen finished cleanly before closing the same period a second time.
Related
See the related articles for the step-by-step tasks of closing the current period and reopening a period, how revenue recognition schedules work day to day, and setting up fiscal years.