How to check an extracted depreciation schedule before you import it

A spreadsheet of assets arrives. Someone produced it from a prior preparer's depreciation schedule PDF — a junior with a keyboard, an OCR tool, a model, it does not matter which. There are 180 rows. Each one has a description, a date, a cost, a method, a life and two depreciation figures. Nothing is blank.

The problem with a transcription is that a wrong one looks exactly like a right one. There is no formatting difference between a cost of 15,240 that the document printed and a cost of 15,240 that was assembled out of a 1,500 on one line and a 524 on the line beneath it. Both are six characters in a cell. Once the file is imported, the wrong one becomes the client's basis, and it stays the client's basis until somebody sells the asset.

So the check has to happen before the import, and it has to be a check the transcription cannot pass by accident.

The printed subtotals are the only independent evidence on the page

There is a temptation to verify a spreadsheet by summing it and looking at the result. That proves nothing. A column of extracted numbers summed by the person who extracted them is one measurement compared against itself; if a row was dropped, the sum is smaller and equally self-consistent.

The printed subtotals are different. They were produced by the software that owned the data — Lacerte, Drake, UltraTax, Fixed Assets CS — from the complete asset list, before anything was printed or scanned or read back. They are the one figure on the page that did not come through the transcription. Comparing your rows against them is the only arithmetic on the document that can disagree with you.

That is the entire check, and it is worth stating plainly because it inverts the instinct: the totals are not a convenience at the bottom of the schedule. They are the audit trail.

Three columns carry the check

Tie the extracted rows against the printed subtotals on cost, prior depreciation and current-year depreciation, for every group the schedule totals, and then in grand total.

Those three do the work because they are the ones that are both printed as subtotals and load-bearing downstream. Cost is the basis. Prior depreciation is what the destination software needs in order to calculate forward correctly. Current-year depreciation is what ends up on the return this year. A transcription that ties on all three has had every row's most consequential figures verified against a number produced independently.

Description, date in service, method and life do not sum, so no printed subtotal can check them. They have to be read.

One caution on current-year depreciation: transcribe what the schedule printed in that column and compare against the subtotal printed for that same column. Whether §179 and bonus sit inside that figure or beside it is a property of the print — Fixed Assets CS and Drake both put them inside, and Drake says so in its own footer. Re-deriving the column by adding components back in will break a tie that transcription would have passed.

Why the tolerance is a dollar

Printed depreciation schedules round to the dollar. Sum 180 rounded rows and compare against a subtotal that was itself rounded, and small differences appear that mean nothing at all.

A dollar absorbs that. Anything larger is not rounding — it is a row. A missing line, a duplicated line, a digit read wrong, a figure picked up from the column beside the one you wanted. The useful property of a tight tolerance is that it converts a vague worry about accuracy into a specific statement: either this group balances or exactly one thing in it is wrong.

Resist widening it. A tolerance generous enough to make an awkward document tie is a tolerance that will let a real error through on the next one, and you will not know which document was which.

Totals are hierarchical, and the grand total often does not cover the whole page

Schedules do not print one flat set of totals. They print subtotals for each leaf group — furniture and fixtures, leasehold improvements, one per rental property — and then roll those up, sometimes through an intermediate section total, into a grand.

Two consequences for anyone tying out by hand.

The same group is named two ways. The rows sit under a heading that reads SOFTWARE, and the subtotal line beneath them reads TOTAL SOFTWARE. They are one group. So are HEART HEATING & COOLING LLC and Heart Heating & Cooling, LLC on a document that spells its own client differently in two places. Fold case, punctuation and spacing before you match a heading to a subtotal, or you will chase a difference that is a naming convention rather than a figure.

The grand total may deliberately exclude a section. On a Lacerte print, the grand covers depreciation and amortisation totals separately below it. A grand that does not match your sum is not automatically an error — check first whether every group on the page tied against its own printed subtotal. Full coverage group by group is a stronger verification than one grand line, because it localises: it says not merely that the whole is right but that each part is.

When it does not tie, the gap names the suspect

An out-of-balance group carries information in the size of the difference.

Compare the gap against the individual rows in that group. If one row's own figure equals the gap, that row is almost certainly the story — it was dropped, or it was picked up twice. This is a two-minute check with a spreadsheet filter and it resolves the majority of differences immediately.

If nothing matches the gap exactly, the difference is spread across several rows, which usually means a column was misaligned rather than a line lost. That failure has its own signature — a Drake import that puts the cost in the wrong column is the version of it that survives all the way into a return.

Then the finding that surprised us most. Across our own validation runs on real schedules, roughly four documents in five that failed to balance had transcribed every number correctly. The differences were labels and scope, not figures: a group spelled two ways, a scan whose OCR ate the spaces in FurnitureandFixtures and produced a heading that matched nothing, six subtotals a print labelled * RENTAL TOTAL - identically, a page range that swept in a schedule belonging to a different entity.

The practical instruction is to read a difference as "check the labels and the scope first, the digits second". Most of the time the arithmetic was never wrong.

The one error a tie-out cannot catch

Be clear about the limit of the method, because a check you trust further than it deserves is worse than no check.

A tie-out verifies that your rows match the totals on the schedule you read. It cannot tell you that you read the right schedule.

A single client file can print a federal listing, an AMT copy, an ACE copy, a book copy, a state copy and a next-year projection. Each of those carries the same assets with different figures, and each one foots perfectly against its own printed totals. Transcribe the AMT copy and you will get a clean tie on numbers that do not belong in the federal return.

So the check before the check is a scope check. Read the heading on the first page of the range you worked from and confirm what it announces. Watch particularly for a document whose first pages are a current-year federal listing and whose later pages switch to a variant copy without a new cover — the totals will still tie, section by section, all the way through.

What we do with it

The tie-out above is what this tool automates, and it is the whole reason the product exists rather than a feature on top of it.

Every conversion compares the totals printed on the source PDF against the totals summed from the extracted rows, per activity and in grand total, at a one-dollar tolerance. If they do not agree, the import file is not downloadable — not flagged, not warned about. Blocked, with the out-of-balance group named and the rows most likely responsible listed first. The same gate is enforced where the file is built, so a new export format cannot route around it.

The difference between blocking and warning is the difference between a check and a decoration. A warning is read once, on a Tuesday, by someone with four other returns open.

What we do not do is compute. A figure the schedule did not print comes back empty and flagged, never defaulted and never zeroed — the Lacerte summary schedule is the standing example, since it omits prior §179 and prior bonus entirely.

Most people reading this arrived holding someone else's PDF, which is its own job with its own traps — that is the prior year depreciation schedule for a new client, and what happens to an uploaded schedule covers the retention and §7216 side of sending one anywhere. And if you want to check a Drake or ProConnect import file you built some other way, the import file checker is free, needs no account and stores nothing.

FAQ

What tolerance should I use when tying out an extracted depreciation schedule?

One dollar. Printed schedules round to the dollar, so summing many rounded rows produces small differences that carry no meaning. A difference larger than a dollar indicates a missing, duplicated or misread row rather than rounding.

Which columns are worth tying out?

Cost, prior depreciation and current-year depreciation. Those three are printed as subtotals and are the figures the destination software uses to calculate forward. Description, date in service, method and life do not sum, so no printed total can verify them.

The group subtotals all balance but the grand total does not. Is the extraction wrong?

Not necessarily. Some prints total sections separately below the grand — on a Lacerte schedule the grand is depreciation-only, with amortisation totalled apart. If every group of rows tied against its own printed subtotal, the extraction is verified group by group, which is a stronger check than the single grand line.

One group is off. How do I find the row?

Compare the size of the difference against the individual rows in that group. A row whose own figure equals the difference was most likely dropped or counted twice. If no single row matches, the difference is spread across several rows, which points to a misaligned column rather than a lost line.

My totals tie. Does that mean the file is safe to import?

It means your rows match the totals on the schedule you read. It does not confirm you read the right schedule. An AMT, ACE, book, state or next-year copy foots perfectly against its own printed totals, so confirm from the page heading which listing you worked from before you rely on the tie.

Does anything check the fields that do not sum?

Nothing arithmetic can. Method, life, convention and in-service date have to be read against the source. What can be done is to refuse to guess at them — a field the document did not print is more useful marked unknown than filled with a plausible value nobody downstream can trace.