If you reopen a closed month, the ledger should still know it was closed.

September is closed and September is wrong.

It is the middle of October. September was closed on the fourth working day and the pack went to the board. Somebody working through the October revenue schedule notices that a batch of invoices dated the last two days of September covers service that starts in October. The amount is not enormous and it is not trivial either. The question that reaches the controller is short: do we reopen September.

Search that question and the results are almost entirely mechanical. Sage explains how to reopen a general ledger period, Oracle documents opening and closing periods, Microsoft has a troubleshooting article for posting to a closed year in Dynamics GP, and Zuora walks through the reopen flow and notes that later periods reopen with it. There are glossary pages defining what a general ledger reopen is. All of it is accurate and all of it answers how. The part that decides the answer is not in any of them.

There are really two decisions hiding inside the one question, and separating them makes both easier. The first is whether the September figure has to change at all, which belongs to the accounting standard and has nothing to do with your software. The second is which posting date the entry carries and what the system records about it, which is yours to design. Teams tend to answer them together, and when the error feels serious they reach for the button.

The standard draws its line somewhere else entirely.

Read IAS 8 in the text rather than in a summary and the hinge is unmistakable. Paragraph 41 says that potential current period errors discovered in that period are corrected before the financial statements are authorised for issue, and that material errors sometimes go undiscovered until a subsequent period, in which case they are prior period errors and are corrected in the comparative information. The definition in paragraph 5 says the same thing from the other side: a prior period error arises from a failure to use, or misuse of, reliable information that was available when the financial statements for those periods were authorised for issue.

Authorised for issue. Not closed, not locked, not posted. The boundary that the standard cares about is the moment the statements went out, and that is a fact about your reporting calendar rather than about your period lock. For most finance teams the two are weeks or months apart. A monthly close that finishes on day four does not authorise anything for issue, and an error found in October against a September that is part of a year not yet reported is simply the close still finishing. A board pack is not a set of financial statements authorised for issue either, although it is a good reason to tell the board.

When the error does land on the far side of that line and it is material, paragraph 42 sets the treatment: correct it retrospectively in the first set of financial statements authorised for issue after its discovery, either by restating the comparative amounts for the periods presented or, if the error predates them, by restating the opening balances of the earliest period presented. Paragraph 46 adds the part people forget, which is that the correction is excluded from the profit or loss of the period in which the error was discovered. The year you found it in does not absorb it.

Two further paragraphs are worth knowing because they come up in practice. Paragraphs 43 to 45 allow for the possibility that retrospective restatement is impracticable, with paragraph 44 permitting a restatement of opening balances for the earliest period where it is practicable, which the standard explicitly acknowledges may be the current period. Paragraph 53 then rules out hindsight: when you reconstruct what the prior period figure should have been, you use what was knowable then. And paragraph 49 lists what has to be disclosed, which is the nature of the error, the amount of the correction for each line item affected for each prior period presented, the amount at the beginning of the earliest period presented, and, where restatement was impracticable, a description of how and from when the error has been corrected.

One more distinction saves a lot of unnecessary work. Paragraph 5 says changes in accounting estimates result from new information or new developments and are accordingly not corrections of errors, and paragraph 34 puts it plainly: the revision of an estimate does not relate to prior periods. If the bad debt provision turned out to be wrong because a customer failed in November, nothing about September was an error. That is a change in estimate, recognised prospectively under paragraph 36, and the closed period stays closed.

One error, two numbers, and a threshold that answers both ways.

Everything above hangs on the word material, so it is worth being precise about how that is measured, because the measurement is less obvious than it looks. The SEC staff addressed it in Staff Accounting Bulletin 108, which describes the two techniques used in practice. The rollover approach quantifies the error originating in the current year income statement. The iron curtain approach quantifies the error sitting in the balance sheet at the end of the current year, whenever it originated. The staff position is that exclusive reliance on either one does not appropriately quantify all misstatements, so you run both and adjust if either is material.

Our September cut-off is exactly the fact pattern SAB 108 uses for its second example, so we put numbers on it and worked both figures out. Take a company with 4.2 million dollars of pre-tax income. At the current year end, 212,400 dollars of next year’s revenue has been recognised in December. The same thing happened a year earlier, when 347,900 dollars of this year’s revenue was recognised in the prior December. One error, running two years.

The prior year error reverses into the current year and understates it, while the current year error overstates it, so the rollover number is the net of the two: 135,500 dollars, which is 3.23 percent. The iron curtain number is simply what is still sitting on the balance sheet at the year end, 212,400 dollars, which is 5.06 percent. Against a five percent rule of thumb, the first reads as a pass and the second reads as a fail. Same error, same company, same day, opposite answers.

Which is a reasonable moment to recall what Staff Accounting Bulletin 99 says about that threshold. The staff reminds registrants and their auditors that exclusive reliance on any percentage or numerical threshold has no basis in the accounting literature or the law. A percentage is a reasonable first step and it cannot be a substitute for the analysis. SAB 99 then lists the qualitative considerations that can make a quantitatively small misstatement material, and for a private company two of them earn their place on a close checklist: whether the misstatement affects compliance with loan covenants or other contractual requirements, and whether it has the effect of increasing management compensation. A number that is comfortably under any threshold can still be the number that decides a covenant test.

The third finding is the one worth carrying away, and it surprised us. Correct only the balance sheet side and the current year revenue understatement left behind is 347,900 dollars. Correct only the income statement side and the year end deferred revenue understatement left behind is also 347,900 dollars. Both single sided fixes land on the same figure, 8.28 percent of pre-tax income, which is larger than either of the two numbers that started the conversation. They converge because 347,900 dollars is the prior year error, and the prior year is where the problem actually lives. You cannot tidy your way out of it from the current period alone.

For a company heading into its first audit, there is a practical corollary. Under AU-C 450, your auditor accumulates every misstatement found during the audit other than those that are clearly trivial, communicates them to management and asks you to correct them, and if you decline they ask why and take that into account. Paragraph .11(b) requires them to weigh the effect of uncorrected misstatements related to prior periods, which is the rollover question in auditing language. Paragraph .A2 is pointed about the threshold: clearly trivial is not another expression for not material, and where there is any uncertainty about whether an item is clearly trivial, it is treated as not clearly trivial. Asking for that number at planning rather than discovering it in the summary of uncorrected misstatements is a short conversation that saves a long one.

For scale on how often the far side of the line gets reached at all, Ideagen Audit Analytics reported in May 2026 that total restatements among US public filers fell 18 percent in 2025, from 477 to 391, making it the second lowest annual count in their twenty year database. Debt and equity classification appeared in 27 percent of them and revenue recognition ranked second at 14 percent. Against the number of closes performed every month across those same companies, the restatement count is small, which is the encouraging reading: the overwhelming majority of errors found after a close are dealt with long before anything has to be restated.

A reopened month can still prove when it was closed.

Now the part that is genuinely a systems problem. Suppose you have decided, correctly, to reopen September and post the entry there. Think about what the period record looks like afterwards. A reopen sets the status back to open and clears the closed timestamp, because the period is no longer closed. Once it has done that, the row is identical to a period that was never closed in the first place. The backdated entry that follows arrives into an open period and is treated as ordinary current work, with nothing marking it as an adjustment to a month that had already been reported on.

That is a real gap and it is quiet, because everything works. The number is right, the period re-closes, the trial balance ties. What has disappeared is the fact that any of it happened. Nine months later an auditor asks for every entry posted into a period after that period was closed, and the honest answer is that the system cannot tell, so somebody reconstructs it by comparing posting dates against a close calendar kept in a spreadsheet.

In Rivane the period record carries the reopen as a durable fact rather than as a status. Alongside the status and the closed timestamp, the period holds whether it has ever been reopened, when that last happened, and how many times. The reopen path sets all three and never clears them again, so the marker survives the very status flip that erases everything else. A journal entry posting into a period carrying that marker is flagged as a prior period adjustment, and the important detail is where the flag comes from: it is computed from the period, not supplied by whoever is posting. A flag the caller can set is a flag the caller can leave unset, usually in exactly the circumstances where it matters.

The reopen itself requires two people. A requester, an approver who must be a different person, and a justification in words, all three mandatory, all three checked before the period is touched at all. A blank reason or a self approval is refused rather than warned about. The same transaction that changes the status writes a decision ledger record naming the action, the status before and after, both people and the reason, so the audit trail and the state change cannot come apart.

And not every period should be reopenable. Four states carry the whole model, and the interesting thing about them is how few edges there are.

Sealed is the one worth arguing for. Once a year has been filed, the ability to change it has negative value: there is no legitimate posting it enables and several illegitimate ones it permits. A state with no outbound edge costs almost nothing to implement and removes an entire category of question, including the awkward one about who has the permission.

Two gates sit in front of the close itself, and they matter here because they are what makes a reopen rare. A period cannot close while draft journal entries are still outstanding in it, and it cannot close while any item on the close checklist is incomplete. Most reopens exist because something was still in flight when the period was declared closed. Blocking the close until it is not in flight removes the reason for most reopens, which is a better outcome than controlling them well.

# A period that remembers it was closed, and an entry that inherits the fact.
# Shape only. No real entity, period or person.

accounting_period:
  entity: ENT-0004
  period: "2026-09"
  status: OPEN            # reopened, so OPEN again
  closed_at: null         # cleared by the reopen
  locked_at: null
  was_reopened: true      # durable. Set on reopen, never cleared
  reopened_at: 2026-10-14T11:02:00Z
  reopened_count: 1

# Written in the same transaction as the status change.
decision_ledger_entry:
  action: accounting_periods.reopened
  status_before: CLOSED
  status_after: OPEN
  dual_approval: true
  requested_by: USR-0117
  approved_by: USR-0004   # must differ from requested_by
  justification: "September revenue cut-off corrected before the Q3 pack"

journal_entry:
  posting_date: 2026-09-30
  is_restatement: true    # derived from the period, not asserted by the caller
  restatement_reason: "Posted into a period that had been closed"

# The rules that make the above hold:
#   only CLOSED has an edge back to OPEN
#   SEALED has no outbound edge at all
#   a reopen with a blank requester, approver or reason does not open anything
#   requester == approver is refused before the period is touched

Two limits worth stating plainly. Rivane does not decide for you whether an error is material or whether a prior period has to be restated, because that is a judgement that depends on facts the ledger does not hold, including what has been issued to whom. And the entry level flag records a fact about the system, that this entry posted into a period which had been closed, which is not the same as a conclusion under IAS 8 or ASC 250. It gives the population; the accounting judgement about each item in it stays yours.

What to put in place before the next one.

• Write down, before you need it, which periods in your calendar are reopenable and which are not. The useful line is not the month end, it is the point at which something left the building: a board pack, a lender certificate, a tax return, a signed set of accounts. Everything on the far side of that line is a different conversation from everything on the near side.
• Separate the two decisions in your own close notes. Decision one is whether the prior period figure has to change, which is the materiality question and belongs to the standard. Decision two is which posting date the entry carries in the system, which is an operational question and belongs to you. Most teams answer them as one question and reach for the Reopen button because the error feels serious.
• Quantify an error both ways before deciding it is immaterial. Work out the amount originating in the current period, and work out the amount sitting on the balance sheet at the period end, whenever it originated. If either one is material, the figure moves. SAB 108 is written for registrants, and the arithmetic is the same arithmetic whoever is doing it.
• Agree a clearly trivial threshold with your auditor at planning rather than at the end. AU-C 450 requires them to document the amount below which misstatements need not be accumulated, and knowing that number early tells your team which findings are worth routing anywhere at all.
• Require two named people and a written reason on every reopen. A requester, a different approver and a justification sentence cost about a minute at the moment of the reopen and are the only version of the story that still exists in March.
• Make the reopen marker durable in the data model, not in a status field. A status field describes the period now. What you need nine months later is whether this period was ever closed, which is a different fact and one that a status flip destroys.
• Derive the prior period flag on an entry from the period, rather than asking the person posting to tick a box. People who are mid correction are the least likely to classify their own entry correctly, and a flag that can be set by the caller can also be left unset.
• Give the correction a description that would make sense to somebody who was not there. What was wrong, which period it belongs to, how it was found, and what has changed so it does not recur. This is three sentences and it is the single most useful thing in the file.

Where this goes wrong.

• Reading the ERP period lock as the accounting boundary. The lock is a control over who can post and when. IAS 8 paragraph 41 turns on whether the statements for that period were authorised for issue, which is a fact about your reporting calendar. The two often disagree, and when the lock is the stricter one the team sometimes concludes that a correction is a bigger event than it actually is.
• Reopening the period as the default because it feels tidier to have the numbers land where the transaction happened. It is tidier, and it quietly rewrites a month that other people have already read. Reporting that went out, covenant certificates, management accounts and intercompany confirmations were all built on the version that existed before.
• Treating a single quantitative threshold as the answer. SAB 99 is direct about this: exclusive reliance on a percentage threshold has no basis in the accounting literature or the law. The qualitative list is where the practical risk lives for a private company, and loan covenant compliance sits on it.
• Letting the reopen wipe the evidence that the period was closed. If reopening clears the closed timestamp and flips the status back, the row afterwards is indistinguishable from a period that was never closed at all, and the backdated entry that follows looks like ordinary current period work.
• Correcting one side of a cut-off error and stopping. In the case we ran, fixing only the balance sheet or only the income statement left a 347,900 dollar misstatement either way, which is larger than either of the two numbers that prompted the work.
• Carrying immaterial differences forward year after year because each one was small on its own. This is the build-up that SAB 108 was written to address, and the uncomfortable property is that the longer it runs the harder it becomes to correct, because the correction itself eventually becomes material to the year you make it in.
• Assuming the reopen is rare enough not to need a control. It usually is rare, which is exactly why nobody remembers the circumstances of the one that happened, and why it is cheap to put dual control on it.

Data and API considerations.

• Keep a period record per entity with an explicit status, rather than inferring openness from the latest posting date. A derived notion of open cannot be closed, reopened or evidenced, and in a group each entity closes on its own schedule.
• Keep the reopen facts on the period: whether it was ever reopened, when it last happened, and how many times. The count matters more than it looks. A period reopened once is an incident. A period reopened five times is a close that is not finishing.
• Record the requester, the approver and the justification at the moment of the reopen, in the same transaction that changes the status. Written afterwards into a separate log, the two can disagree, and the one people trust is the one that is harder to produce.
• Flag the entry rather than only the period. The period tells you something happened in that month. The flag on the entry gives an auditor a population they can pull in one query, which is the form the request usually arrives in.
• Compute that flag from the period state, never from a field the caller supplies. An entry posting into a period that was previously closed is a prior period adjustment whether or not anybody says so.
• Keep a terminal state that nothing can reopen. Once a year has been filed, the value of being able to change it is negative. A status with no outbound edge is a small amount of code and it removes a whole category of argument.
• Correct by reversal and new entry rather than by editing the original. The original posting is the thing an auditor reconciles to the approval and the document behind it, and an edited entry has quietly broken that chain even when the new figure is right.

What an auditor will ask for.

• For each period: when it was closed, by whom, and whether it has ever been reopened, with the date and count of reopens surviving the reopen itself.
• For each reopen: who requested it, who approved it, the two being different people, the reason given in words, and the status the period held immediately before.
• The population of entries posted into a previously closed period, pullable as a list rather than reconstructed by comparing posting dates to a close calendar someone keeps in a spreadsheet.
• For each correction: the original entry, the reversal, the replacement, and the document or calculation that supports the new figure.
• The schedule of uncorrected misstatements for the period, with each item quantified on both the income statement and the balance sheet, and the conclusion that each was not material individually or in aggregate.
• The clearly trivial threshold in force, which AU-C 450 paragraph .12 requires the auditor to document and which is a useful thing for the finance team to hold too.

Six questions for your next close review.

• If somebody reopened a month six months ago, can our system tell us today that it was ever closed?
• Can we produce, in one query, every entry that posted into a period after that period had been closed?
• Who is allowed to reopen a period, and does the system require a second person and a written reason, or does it just require the permission?
• Which periods in our calendar should never be reopenable at all, and does anything in the system enforce that?
• When we last concluded that an error was immaterial, did we quantify it on both the income statement and the balance sheet, or only on the one where it looked smaller?
• What is our auditor’s clearly trivial threshold this year, and does our team know the number?

The close that finishes is the one you rarely have to reopen.

The good news in all of this is how much of it is settled. The standard has a clear answer and it is a generous one: an error found while the statements for that period are still unissued is corrected before issue, which covers most of what a monthly close turns up. The quantification has a defined method, and running it both ways takes a few minutes once somebody has done it once. The restatement data suggests the far side of the line is reached rarely. What is left is a design question, and design questions are the pleasant kind, because you only have to answer them once.

The design worth having is simply this: a period that remembers it was closed, a reopen that two people signed with a reason, an entry that inherits its own classification, and a filed year that cannot be touched at all. None of it is expensive, and together they turn an awkward conversation in March into a query. If you want to see how we have built it, the Rivane close management page walks through the close, the checklist gates and the period controls described here.

Sources

• IAS 8 Accounting Policies, Changes in Accounting Estimates and Errors, read in the text as adopted in Australia (AASB 108, compiled version applying to annual periods beginning on or after 1 January 2020, Authorised Version F2020C00282). The paragraph numbering is the IAS 8 numbering. The PDF was downloaded and the pages read directly rather than summarised. Source for the paragraph 5 definition of a prior period error and of impracticable, for paragraph 41 on errors discovered before the statements are authorised for issue, for paragraph 42 on correcting material prior period errors in the first set of statements authorised for issue after discovery, for paragraphs 43 to 45 on the limits of retrospective restatement, for paragraph 46 excluding the correction from the profit or loss of the period of discovery, for paragraph 49 on disclosure, and for paragraph 53 on hindsight.
• US Securities and Exchange Commission, Staff Accounting Bulletin No. 108, Topic 1N, Considering the Effects of Prior Year Misstatements when Quantifying Misstatements in Current Year Financial Statements, dated 13 September 2006. Read in full on the Commission site. Source for the rollover and iron curtain approaches and the staff position that neither alone is sufficient, for the worked build-up and sales cut-off examples, and for the statement that correcting prior year financial statements for immaterial errors would not require previously filed reports to be amended and that such correction may be made the next time the registrant files the prior year financial statements.
• US Securities and Exchange Commission, Staff Accounting Bulletin No. 99, Topic 1M, Materiality. Read in full. Source for the staff position that exclusive reliance on a percentage or numerical threshold has no basis in the accounting literature or the law, and for the list of qualitative considerations that can make a quantitatively small misstatement material, including whether it masks a change in earnings or other trends, whether it turns a loss into income or the reverse, whether it affects compliance with loan covenants or other contractual requirements, and whether it has the effect of increasing management compensation.
• AICPA, AU-C Section 450, Evaluation of Misstatements Identified During the Audit, 2020 edition, effective for audits of financial statements for periods ending on or after 15 December 2012 as amended. The PDF was downloaded and the requirements pages read directly. Source for paragraph .05 on accumulating misstatements other than those that are clearly trivial, .07 on communicating them to management and requesting correction, .09 on management declining to correct, .11(b) on considering the effect of uncorrected misstatements related to prior periods, .12 on documentation including the clearly trivial threshold, and .A2 on clearly trivial not being another expression for not material.
• Ideagen Audit Analytics, Financial Restatements Report, May 2026. The published findings page was read directly. Source for total restatements falling 18 percent in 2025 from 477 to 391, the second lowest annual count in a twenty year database, for debt and equity classification appearing in 27 percent of 2025 restatements and revenue recognition ranking second at 14 percent, for foreign private issuer restatements rising to 52, and for large accelerated filers reaching 25.5 percent of the total.
• Rivane close management. The period model described in the article is the one built and shipped: the four period statuses, the single reversible edge, the dual control required on a reopen, the durable reopen marker, and the entry level flag derived from it.

A note on how this was researched. The IAS 8 text and AU-C 450 were downloaded as PDFs and the relevant pages read directly rather than summarised, and every paragraph number quoted here comes from a page that was read. IAS 8 is cited in the form adopted in Australia as AASB 108, which reproduces the standard with the same paragraph numbering and is freely available; readers applying IFRS as issued by the IASB, or ASC 250 under US GAAP, should check their own text, and the two frameworks are close but not identical on disclosure. Both Staff Accounting Bulletins and the restatements report were read on their own pages rather than through a summary. The ERP help pages mentioned in the opening are described from what they cover and are not cited as authority. No suitable public posts on X were found on this topic during research, so none are embedded and none were invented. The cut-off figures were produced by running the arithmetic set out in SAB 108 Topic 1N over an example company that is not a real business, and the September scenario in the opening is an example rather than an account of anything that happened. Statements about Rivane describe what is built and shipped today, including the two limits stated above. Rivane has no public customers to cite and none are implied. Nothing here is accounting, audit or legal advice, and a material error correction is a conversation to have with your auditor.