Prior depreciation is the field everything downstream is calculated from

Of the dozen or so fields on an asset import, prior depreciation is the one that behaves differently from the rest.

A wrong description is cosmetic. A wrong date in service usually announces itself, because the current-year figure comes out visibly odd. Prior depreciation does neither. It is the running total the destination software starts from, and a wrong value there produces a plausible current year, a plausible next year, and a wrong basis for as long as the client owns the asset.

What the field actually holds

Prior depreciation is accumulated depreciation on that asset through the end of the prior tax year — everything taken before the year you are now preparing.

That matters because the destination does not simply store it. Drake, Lacerte and ProConnect all recompute forward: given cost, method, life, convention, date in service and prior depreciation, the software calculates the current year itself. You are not importing this year's number. You are importing the starting point it will be derived from.

Which is why the failure is quiet. Supply a prior figure that is too low and the software will happily compute a current-year deduction from it, produce a schedule that foots, and carry a basis that is wrong by exactly the amount you were short.

Prior depreciation and accumulated depreciation are not always the same number

Two vocabularies overlap here and they do not mean the same thing on every page.

Accumulated depreciation on a book or financial statement generally includes the current year. Prior depreciation on a tax fixed-asset schedule generally does not — it stops at the end of the previous year, with the current year printed in its own column beside it.

A schedule printed for book purposes, or an asset register out of an accounting system rather than a tax suite, may use the first convention. Reading it as the second overstates prior by one year's depreciation, and the overstatement is not visible in any total, because the document footed correctly under its own convention.

Check what the column headers say and whether a separate current-year column exists. If prior and current are both printed, prior almost certainly excludes current.

Whether §179 and bonus sit inside the figure is a property of the print

This is the part that causes trouble on migration, and it deserves precision because the instinct to "fix" it is exactly wrong.

Some schedules print prior depreciation as a single combined figure that already includes prior §179 and prior special depreciation allowance. Others print those components in their own columns beside it. Fixed Assets CS and Drake both fold them in, and Drake states so in its own report footer.

The consequence is that you cannot know from the number alone whether adding the components to it is completing the figure or double-counting it. The only reliable evidence is the document: what the column is headed, what the footer says, and whether the printed subtotal for that column equals the sum of the rows under it.

That last test is the useful one. Transcribe the column as printed, sum the rows, and compare against the subtotal the schedule printed for that same column. Under either convention, a faithful transcription ties. A re-derived figure — components added back in because the total "looked low" — can only break a tie that transcription would have passed.

Where the number is missing rather than wrong

A distinct problem, and more common than it should be: the components exist in the prior firm's system but were never printed.

Lacerte's summary depreciation schedule prints one prior depreciation figure and no component columns at all. The total is correct and complete. What is absent is the split between prior regular depreciation, prior §179 and prior bonus — absent, not zero, and not blank.

For carrying the asset forward, the combined figure is what the destination needs, so nothing is lost. For a disposal, a business-use drop, or a state that decoupled from bonus, the split is the input, and recapture reaches back for exactly those components. The full account of what the summary variant omits covers where to recover them.

Typing zero into the component columns because the import form has slots for them converts "the document did not say" into "the client took none". Those are different statements, and only one of them is supported by the page in front of you.

Checking a prior figure in about a minute

Compare it against elapsed years. Cost, method, life and date in service imply a rough expectation for accumulated depreciation. A prior figure far from that expectation is worth a second look before it becomes the basis of everything after it — not because the expectation is authoritative, but because a mismatch usually means the wrong column was read.

Check for an asset already fully depreciated. Prior depreciation equal to cost, with a current year still printed, is a contradiction worth resolving at the source.

Tie the column to its own subtotal. Sum the prior depreciation of every row in a group and compare against the printed subtotal for that group, at a dollar's tolerance. This is the check that catches a dropped or duplicated row, which is the most common way a prior figure goes wrong in transit.

What we do with it

Prior depreciation is transcribed as the schedule printed it. It is never re-derived by adding components back in, and never adjusted to match an expectation — the printed subtotal is the comparison, and transcription is what ties against it under either convention the suite used.

Where a print does not separate the components, they come back empty and flagged as not present in the source rather than zeroed, which blocks the download until a preparer resolves it. Where the figure is present, it lands in the destination's own prior depreciation field — including Lacerte's fixed asset import, which has no import field for state prior depreciation at all, a gap worth knowing about before you build the file rather than after.

FAQ

What is prior depreciation on a fixed asset schedule?

Accumulated depreciation on that asset through the end of the previous tax year. The current year is normally printed in a separate column beside it, and the destination software recomputes the current year from the prior figure rather than storing it.

Is prior depreciation the same as accumulated depreciation?

Not reliably. Accumulated depreciation in a book or financial-statement sense usually includes the current year; prior depreciation on a tax schedule usually stops at the end of the previous year. Reading one as the other overstates the figure by a year.

Does prior depreciation include §179 and bonus?

It depends on the print. Some schedules fold prior §179 and prior special depreciation allowance into the combined figure — Fixed Assets CS and Drake both do, and Drake says so in its report footer — while others print them as separate columns. The printed subtotal for the column is the evidence.

What happens if prior depreciation is imported too low?

Nothing rejects. The software computes a current-year deduction from the figure supplied, the schedule foots, and the basis carried forward is wrong by the shortfall — which surfaces on disposal, potentially years later.

The schedule shows one prior depreciation column and no components. Is that an error?

No. Some prints, including Lacerte's summary variant, report a complete combined total without separating prior regular depreciation, §179 and bonus. The total is correct; the split is simply not on the page, and the prior firm's client file still holds it.