Journal Entries & Estimates
Reversing entries: which accruals to reverse
A reversing entry is built to cancel itself out on the first day of the next period. A non-reversing entry stays exactly where you booked it until something else clears it. Most ERPs make this a checkbox, not a second entry — which is exactly why it's worth knowing when to check it.
The mechanics are simple once you've seen them once: book the accrual on the last day of the period you're closing, mark it reversing, and the system automatically books the mirror image — same accounts, same amount, opposite debit/credit — dated the first day of the next period. That nets the accrual account back to zero. It does not mean the next period's P&L sees nothing: whatever the real invoice or actual amount turns out to be still posts on top, and what actually shows up next period is the difference between your accrual and that actual number.
What decides whether an entry should reverse isn't the account or the dollar amount. It's whether the entry is estimating something that will be replaced by a real number soon, or correcting what a balance actually is.
| Reversing | Non-reversing | |
|---|---|---|
| What it's fixing | An estimate standing in for a real number that hasn't posted yet | The balance itself — a number that was wrong, missing, or needs to change permanently |
| What happens next period | Auto-reverses on day one, no action required; the real transaction posts on top | Stays booked. Nothing undoes it |
| Typical use | Revenue earned but not yet billed, accrued payroll and related benefits, accrued expenses awaiting an invoice | True-ups, reclasses, depreciation, corrections of a prior error |
| Risk if you get it backward | An entry that should have reversed doesn't — it silently carries forward and double-counts next period | An entry that shouldn't have reversed does — it undoes a real, permanent correction |
Revenue earned but not yet billed: a worked example
A services company performed $45,000 of work in August under a contract that bills in arrears — the invoice won't go out until early September, but the revenue was earned in August and belongs there. On August 31, book a reversing accrual for the estimate:
| Date | Account | Debit | Credit |
|---|---|---|---|
| Aug 31 (reversing) | Unbilled receivable | 45,000 | — |
| Aug 31 (reversing) | Revenue | — | 45,000 |
Mark it reversing, and on September 1 the system books the mirror entry without anyone having to remember to:
| Date | Account | Debit | Credit |
|---|---|---|---|
| Sep 1 (auto) | Revenue | 45,000 | — |
| Sep 1 (auto) | Unbilled receivable | — | 45,000 |
The actual invoice, once the final hours are billed, turns out to be $45,200 — slightly more than the estimate. It posts as an ordinary, non-reversing entry:
| Date | Account | Debit | Credit |
|---|---|---|---|
| Sep (actual) | Accounts receivable | 45,200 | — |
| Sep (actual) | Revenue | — | 45,200 |
The unbilled receivable account nets to exactly zero — the reversing pair cancels there and only there. Revenue itself does not net to zero across the two months: August correctly shows $45,000 earned, and September's P&L nets to $200 (the $45,000 reversal against the $45,200 actual), which is exactly the amount the original estimate was off by. Nobody typed a second entry, chose a date by hand, or had to remember three weeks later that August's accrual needed to come back out.
Why the flag, not just a second entry
You could get the same result by typing both entries yourself. The reversing flag exists because typing the second one is exactly the kind of task that gets missed — booked to the wrong date, booked twice by two different people who didn't know the other had already done it, or simply forgotten three closes from now when nobody remembers the original accrual existed. The flag ties the two entries together as one action: note the original in the current month, and the system carries the reversing half into the next one, dated correctly, without a second decision to get wrong.
It also makes the accrual visible as what it is. An entry flagged reversing tells a reviewer, on sight, "this is an estimate, and a real number is going to replace it next month." An entry that should have been flagged and wasn't is a different kind of problem — it looks permanent when it isn't, and whoever reviews next month's trial balance has no signal that anything is supposed to come back out.
Where else this shows up
Revenue earned but unbilled is the cleanest example because the estimate-vs-actual gap is easy to see, but the same mechanic covers most accruals for something that hasn't been recorded on its own yet:
- Accrued payroll and related benefits. Wages earned through month end but not yet paid get accrued on the last day of the period, and reverse when the actual payroll run posts in the next period — so the accrual doesn't double up with the real payment.
- Accrued expenses awaiting an invoice. The same shape as the utilities accrual on the true-up page, except here the accrual itself is booked to reverse, and the actual invoice posts on top of a clean slate rather than needing a separate true-up entry to net against the accrual.
The common thread: an estimate stands in for a real number that's known to be coming soon, and it needs to come back out on its own once the real number shows up — not be manually tracked and cleared. That's different from a suspense or clearing account, which doesn't use this mechanic at all: a clearing account empties when the offsetting transaction actually posts or gets matched, and a suspense item gets investigated and reclassed to where it belongs, not auto-reversed on a fixed date it may not be resolved by.
Standing accruals: the non-reversing alternative
Some accruals are deliberately never reversed. A standing accrual is a balance that gets recalculated every month and adjusted to the new figure — booking only the difference — rather than reversed and rebooked in full. Bonus accrued over the year, accrued paid time off, and an annual audit fee accrued monthly are the usual examples: the balance carries forward because the liability genuinely carries forward, and each month's entry moves it to where the calculation says it should be.
Both approaches can land the balance in the same place. The difference is what the entries show. A reversing accrual shows the full estimate going in and coming back out every month; a standing accrual shows only the change. For flux, that changes what the movement means: on a standing accrual, the month's movement is the adjustment, so the explanation is whatever changed in the calculation.
The trouble starts when the two get mixed on the same account. An accrual that's adjusted to a calculated balance and flagged to reverse gets undone on day one, and next month's difference-only entry is then booked against a balance that's already back at zero. If an account is meant to hold a standing balance, the reversing flag stays off, and the support is the calculation of what the balance should be — not the list of invoices it's waiting for.
When not to use it
A reversing entry is the wrong tool the moment the entry isn't a placeholder for a number that's about to replace it — when it's meant to be the correct, standing figure itself.
A true-up is the clearest contrast, and it's worth being precise about the difference: a true-up corrects a reserve or estimate to a better figure by booking the difference only, and that correction is supposed to remain on the books — it's not a reversal and rebook of the whole amount, and reversing it next period would just put the wrong balance back. Depreciation, a reclass between accounts, and a correction of a prior period's error are the same — each one is meant to be the new, standing number, not a placeholder waiting to be replaced. A revenue or expense amount that landed in the wrong month, specifically, gets moved with a reclass, not a reversing entry: reclassing corrects where the amount sits, permanently, while flagging that same fix reversing would undo the correction on day one of the next period and put the error right back.
The test is the same one that separates a reclass from an adjusting entry: ask what the entry is actually for. If the answer is "to hold a place for a real number that's coming soon," it reverses. If the answer is "to make the balance correct, permanently, as of now," it doesn't.
Most of this surfaces again at flux review. The free flux template flags which balances moved enough to explain. The CloseOps Flux & Variance System ($79) starts from your trial balance instead: confirm each account's classification and it builds the income statement and balance sheet flux statements, then ranks what to investigate.
Related: true-up in accounting, reclass vs adjusting entry, and what actually goes into an accounting estimate.
Found something wrong or missing? Tell me here — anonymous, thirty seconds.