# Correct a Prior Period Reconciliation Error Safely

- Author: PreciseBankFlow (https://www.precisebankflow.com)
- Published: 2025-12-30
- Updated: 2025-12-30
- Category: Finding reconciliation errors
- Canonical: https://www.precisebankflow.com/blog/correct-a-prior-period-reconciliation-error

> How to correct a prior period reconciliation error: decide if it is material, adjust the current period or restate, and keep closed reports intact.
To correct a prior period reconciliation error, first decide whether the error is material to the reports already issued. An immaterial error is fixed with a dated, labelled entry in the current open period. A material one may require restating the earlier figures. Either way, leave the closed reconciliation untouched and document the correction beside it.

## What counts as a prior period reconciliation error?

A prior period reconciliation error is a mistake in the cash records of a month that has already been closed and signed off. The error was made, or missed, in that month and only came to light later. It is different from a timing item, which belongs to the old month on purpose and clears on its own.

Typical examples:

- A bank charge listed on the March reconciliation as "to be recorded" that nobody ever booked.
- A deposit recorded twice in February, found in June because one copy never cleared.
- A check entered for the wrong amount, carried as an outstanding item for months.
- A reconciliation finished with an unexplained adjustment that turns out to hide a real error.

The test is simple. If the item would still be wrong after every timing difference has cleared, it is an error. An outstanding check that clears in the following month is not. A reconciling item that shows a negative amount where it should be positive can be either, and [negative reconciling items on a bank reconciliation](/blog/negative-reconciling-items) explains how to tell.

### A worked example used throughout

The rest of this post follows one example with invented figures. In July, a reviewer at a small distributor notices that every reconciliation since March has carried a book-side item of 1,180.00 labelled "wire fee, to be recorded". The March bank statement shows the fee. The ledger never got the entry. Cash in the books has been overstated by 1,180.00 for four month-ends, and March, April, May and June have all been closed.

## Is the prior period reconciliation error material?

Materiality decides the route. An error is material when it is large enough, or sensitive enough, that it could change a decision made by someone reading the reports. Size is the first measure, but nature counts too: a small error that hides theft or breaks a loan covenant can be material at any size.

Questions that help the judgment:

- How large is the error compared with income for the period and with the cash balance?
- Were the affected reports sent to a lender, an investor, a regulator or a tax authority?
- Does the error change a ratio, a covenant or a bonus calculation?
- Is the error a one-off, or a symptom of a control that failed?

In the example, 1,180.00 against a quarterly income of several hundred thousand is small. The monthly reports went to the owner only. The fee was genuine, not hidden. The reviewer judges it immaterial, and the correction can go in the current period.

If you cannot decide on your own, ask the person who signs the financial statements, or the engagement partner if the company is audited. That is a judgment for them, not for the person preparing the reconciliation.

## Correcting the prior period error in the current period

For an immaterial error, book a correcting entry dated in the current open period. The entry fixes the balance today without changing the closed months. Its description should say what it corrects, which period the error belongs to, and where the support is filed.

The entry for the example, dated 31 July:

| Account | Debit | Credit |
| --- | ---: | ---: |
| Bank charges expense | 1,180.00 | |
| Cash, operating account | | 1,180.00 |

Description: "Wire fee per March bank statement, page 2, not recorded at the time. Correction of a prior period error, immaterial. See July reconciliation support."

After posting, the July reconciliation no longer needs the 1,180.00 book-side item. The adjusted book balance and the adjusted bank balance agree without it. The July expense line is 1,180.00 higher than it would otherwise be, so note it on the July management report if anyone reads expenses month by month.

Some charts of accounts have a dedicated account for prior period adjustments. Using one keeps the current month's expense lines clean. Use it if your firm has it; do not create one just for a single small item.

### Corrections that cross a fiscal year end

A prior period error that belongs to a fiscal year already closed raises extra questions. The year's financial statements may have gone to a lender, and a tax return may have been filed on figures that included the error. Booking the correction in the new year is still the usual bookkeeping step for an immaterial amount. Flag it to whoever prepares the tax return, because the treatment of an old expense or income item for tax purposes is their call, not the reconciler's. Note the year the item belongs to in the entry description so it is easy to find when they ask.

## When a prior period error calls for restatement

A material prior period error usually calls for restating the earlier figures rather than absorbing the correction in the current period. Under IFRS, [IAS 8 on accounting policies, estimates and errors](https://www.ifrs.org/issued-standards/list-of-standards/ias-8-accounting-policies-changes-in-accounting-estimates-and-errors/) says an entity corrects material prior period errors retrospectively by restating the comparative amounts, unless doing so is impracticable.

Restatement is a reporting decision, not a bookkeeping one. It changes figures that people have already relied on, so it involves whoever owns the financial statements and, for audited entities, the auditor. US GAAP has its own guidance, and private companies, nonprofits and tax filings each bring their own rules. The person preparing the bank reconciliation should raise the issue, quantify it and stop there.

What the preparer can do is make the restatement easy:

1. Compute the error's effect on each affected month and each affected account.
2. List every report that used the wrong figures.
3. Prepare the correcting entries, dated as the reporting owner directs.
4. Keep the original closed reconciliations, so the before and after can both be shown.

## Keeping closed reconciliation reports intact after a correction

A closed reconciliation is a record of what was known and signed at the time. Keep it exactly as it was. Attach the correction to the current period instead, with a note that cross-references the old month. A reviewer should be able to see both the original and the fix without anything having been rewritten.

In practice:

- Leave the March to June reconciliation files and reports unchanged.
- In the July reconciliation file, add a memo: "1,180.00 item carried since March cleared by correcting entry dated 31 July."
- Save a copy of the March statement page showing the fee with the July support.
- Initial and date the memo as preparer, and have the reviewer do the same.

This also protects you if something else turns up. A closed report that was edited after sign-off cannot be trusted as evidence, and a forensic reviewer will treat silent changes to old records as a red flag. [Forensic accounting software](/blog/forensic-accounting-software) is built around keeping that kind of trail, and the same logic applies to an ordinary close file.

## Mistake: reopening a closed period to fix an old reconciliation error

Reopening a closed period and editing the original entry feels tidy, but it usually causes more trouble than the error did. Every report generated from that period changes. The beginning balance of every later reconciliation shifts. Software that tracks reconciled lines may flag every month since as out of balance.

The damage in the example would be wide. Booking the fee on its March date would lower the March ending cash by 1,180.00. The April, May and June reconciliations would each start from a different opening balance than the one they were signed with. Their reports would no longer foot to the figures in the review notes. Someone would then spend a day explaining four months of discrepancies that never existed.

There is a related temptation: making the old difference disappear with an unexplained adjustment. That is a plug, and [plugging a bank reconciliation](/blog/plugging-a-bank-reconciliation) explains why it makes the next correction harder. A clear correcting entry in the open month is the safer route.

Reopen a period only when the reporting owner has decided to restate and the system has no other way to record it. Even then, export the original reports first.

## Documenting a prior period correction for the reviewer

The support file for a prior period correction should let a reviewer rebuild the decision without asking you a question. It should hold the evidence of the error, the materiality judgment, the entry and the sign-off. Treat it as part of the current month's reconciliation package.

A checklist for the file:

- [ ] The source document that proves the error, such as the bank statement page, check image or deposit slip.
- [ ] The period the error belongs to, and each month-end it affected.
- [ ] The amount, and the accounts it affected.
- [ ] The materiality judgment, who made it and the reasons.
- [ ] The correcting entry, its date and its description.
- [ ] The cause, and what has changed so it does not recur.
- [ ] Preparer and reviewer initials with dates.

The cause line matters most over time. In the example, the cause was a reconciliation process that allowed a "to be recorded" item to roll forward without an owner. The fix was a rule that every book-side item must be posted before the reconciliation is signed.

Catching these items in the month they happen is cheaper than correcting them later. [PreciseBankFlow](/) foots each statement and lists every line it cannot match to the ledger as an exception for review, which puts an unbooked fee in front of someone while the period is still open.