Journal Entries & Estimates
Reclass vs adjusting entry: what's the difference?
A reclass moves an amount from one account to another. An adjusting entry changes what the books say happened. That's the working distinction — and it breaks down faster than most explanations admit.
The short version, as most people use the terms:
| Reclass | Adjusting entry | |
|---|---|---|
| What it does | Moves an amount between accounts, departments, vendors, or whatever dimension the books are organized on | Changes an amount to reflect something that happened or should have been recorded |
| Net income effect | Often none — the amount lands somewhere else within the same statement | Usually yes — it changes revenue, expense, or a balance that feeds them |
| Typical trigger | Something was coded to the wrong place, or a balance needs to be presented differently | An accrual, a deferral, an estimate being trued up, or something known to be understated |
| Typical timing | Often a recurring close task — the same sweep every month | Anywhere in the cycle, whenever the need is identified |
That table is how the terms get used in practice. It isn't a standard, and the moment you check it against published definitions it starts coming apart.
The definitions genuinely conflict
This is worth knowing before you spend time trying to get the vocabulary exactly right: different reputable sources split these terms on entirely different axes.
- By purpose. AccountingTools treats adjusting entries as the ones that bring statements into compliance with the accounting framework — accruals and deferrals of revenue and expense — and puts error fixes in a separate bucket called correcting entries.
- By income statement impact. FinQuery frames it differently: a reclass moves an amount with no income statement impact, an adjustment has one. Same two words, a different dividing line.
- By inclusion. Other treatments fold reclassifications in as a type of adjusting entry, alongside accruals, deferrals, and estimates — so the two categories stop being parallel at all.
Which explains something most people notice and assume is their own gap: nobody sits you down and teaches the distinction, because there isn't a clean one to teach.
What a reclass usually looks like
The clearest cases are where the amount is right and its location isn't.
Something has been coded to the wrong department, cost center, or vendor. An expense belongs in an account that was created later for exactly that purpose. A balance needs to be presented differently than it sits in the ledger — a debit balance in accounts payable, which is effectively a receivable, moved for presentation.
Reclasses are often systematic rather than one-off. If something is flowing to the wrong place, it's usually been flowing there for a while and will keep flowing there until the underlying coding changes. That's why they show up as recurring close tasks: the same sweep, every month, until someone fixes it upstream.
It's also where the more technical version lives — not a miscoding at all, but a judgment about how something should be classified, made once and then applied each period.
What an adjusting entry usually looks like
Here the amount itself is what's wrong or missing.
The textbook cases are accruals and deferrals: revenue earned but not billed, expense incurred without an invoice, a prepaid being consumed. In practice the more common version is a true-up — an estimate or reserve being brought to what the calculation now says it should be, most often as part of close.
"True-up" is itself one of those words that shows up constantly without a precise definition — it gets its own treatment here. It generally means adjusting a recorded amount to the better figure once more information is available, which is the same mechanic behind most estimate work.
Reclass vs accrual
Narrower than the general reclass-vs-adjusting-entry question, this one comes up constantly in practice: something is sitting in the wrong account, and you're not sure whether to move it (reclass) or true it up through an accrual.
The test is whether the total is right. If the amount is correct and it's just booked to the wrong account, department, or period within the same statement, that's a reclass — you're moving it, not changing it. If the amount itself is wrong or incomplete because something hasn't been recorded yet, that's an accrual, and it's really an adjusting entry with a specific mechanism: accrue now, true up to the actual once it's known. A balance sitting in the wrong cost center is a reclass; a balance that's simply too low because an invoice hasn't arrived is an accrual.
And then there are correcting entries
A third term, used for the case where something has been recorded wrong for a while and needs to be fixed retroactively — a series of periods where an amount never posted, or posted to the wrong place, and the cumulative effect has to be brought back.
Some sources treat this as its own category. Others treat it as a reclass if it only moves amounts between accounts, or as an adjusting entry if it changes a total. All three readings appear in practice.
Worth separating the bookkeeping question from a different one: if what you found means a prior period was materially misstated, that's not a vocabulary question at all. That's a misstatement question, and it's decided on materiality rather than on what you name the entry.
Why the label matters less than it seems
The practical answer, and the one that saves the most time: what the entry is called is secondary to whether its impact is right.
The questions that actually decide whether an entry is correct are the same regardless of the label. Is it hitting the right account, the right department, the right customer, the right period? Does the amount tie to something? Does the resulting balance make sense?
A reviewer might look at an entry described as an adjustment, decide it's really a reclass, and ask for the description to change. That's a reasonable note and it takes ten seconds to act on. It's also a different order of problem from the entry hitting the wrong account, which is the thing worth spending your attention on.
Where naming does matter
Three cases where it's worth being deliberate:
- The description is what a reviewer reads first. Calling something a reclass when it changes net income invites a question you'll have to answer. Naming it accurately is a way of pre-empting review comments, not just a formality.
- The audit trail outlives your memory. An entry described as "reclass — move Q3 media spend from marketing to program costs" is still legible a year later. "Adjustment" on its own is not.
- Recurring entries get inherited. Whoever prepares it next month reads the description before they read the support. A recurring entry's design tends to outlive the person who built it, and the description is most of what carries forward.
It matters at flux review too. A reclass between two accounts reviewed separately shows up as a movement in both, in opposite directions, and the commentary on each should name the reclass and the other account — otherwise two reviewers chase the same entry from opposite ends. A reclass inside a single rolled-up line nets to nothing at that level, which is one reason some errors never reach a flux queue at all.
Beyond those, precision about which word applies is mostly semantics — and being cautious about how you describe an entry is more useful than being confident about which category it belongs to.
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: why a recurring entry's design goes stale, what actually goes into an accounting estimate, correcting the amount versus rebuilding the process, and reversing entries. A different vs. question that shows up during flux: flux analysis vs variance analysis. If you're pulling detail to support an entry, the flux Excel template has the same threshold logic built in.
Found something wrong or missing? Tell me here — anonymous, thirty seconds.