What happens to a client's depreciation schedule when you upload it

There is a hesitation that comes before any of the mechanics, and it is the right one to have. The document in front of you is a client's depreciation schedule. It carries their asset list, their basis, sometimes their name and their entity. Uploading it to a website you found last Tuesday is a decision about someone else's data, made by you, on their behalf.

Most writing about tax software skips straight past this. It is worth sitting in for a page, because the rules that govern it are specific, they are not the same rules as the ones governing your own files, and the answer is not automatically no.

The question is disclosure, not storage

The regulation in play is Treas. Reg. §301.7216, which governs what a preparer may do with return information. Its default is strict: disclosure without the taxpayer's written consent is prohibited, with the criminal provision at §7216 behind it.

The exception that most tooling lives inside is §301.7216-2(d)(1), which permits disclosure to a third party who provides auxiliary services in connection with preparing the return, without separate consent — provided that party makes no substantive determinations or advice affecting tax liability.

That last clause is the whole thing. A vendor that transcribes what a document says is auxiliary. A vendor that decides a recovery period, picks a convention, or fills in a figure the source never printed has made a substantive determination, and the exception it was relying on stops applying — not just to that document, but to the arrangement.

The same provision carries a second condition that is easy to miss: the services must be performed within the United States. A tool that routes documents to offshore keying or offshore inference is outside the exception regardless of how good its transcription is.

So the useful question to a vendor is not "is my data encrypted". It is: does this service decide anything, and where does the processing physically happen.

The Safeguards Rule puts the obligation on you

The second framework is the FTC Safeguards Rule, 16 CFR Part 314, which treats a tax preparer as a financial institution. It requires a written information security programme — the WISP the IRS has been asking about on the PTIN renewal — and, at 16 CFR 314.4(f), it requires you to select service providers capable of maintaining appropriate safeguards and to hold them to those safeguards by contract.

That obligation does not transfer. A vendor cannot be compliant on your behalf; it can only give you something to point at when you document the selection. Which means the practical artefact you need from any tool is not reassurance, it is a written description of retention, access and processing location, specific enough to attach to your own file.

Retention is the safeguard you can actually verify

Most security claims are unfalsifiable from the outside. Retention is not. It is a date, and either the data is gone after it or it is not.

Here, uploads and their extracted rows are deleted within 30 days, automatically, by a job that runs nightly. Every conversion page also carries a delete-now button that removes the uploaded file and the extracted rows immediately, without asking anyone. The promise is worth exactly as much as the job that enforces it, which is why it is a scheduled task and not a policy sentence.

The support side is held to the same window: what you write to us about a stuck conversion is deleted on the same clock as the upload it describes, because a preparer explaining why a row will not tie tends to quote the row.

Ask any vendor for the number, then ask what enforces it.

The identifiers you never needed to send

A depreciation schedule is a workpaper. To convert one, a tool needs descriptions, dates, dollar amounts, methods and lives. It does not need a Social Security number or an EIN — those appear on the page because the page came out of a tax return, not because the conversion uses them.

So they are stripped from the extracted text before it leaves the process, and never written into an export file. Formatted identifiers go unconditionally; a bare nine-digit run is only treated as an identifier when a label puts it in that context, because on a depreciation schedule an unlabelled nine-digit number is far more likely to be a cost, and redacting a cost would break the tie-out.

This is not a feature so much as an argument about blast radius. Data that was never transmitted cannot be part of an incident.

Local-only tools are a real answer, and worth being honest about

The strongest version of the privacy objection is not "use a more careful website". It is "do not upload at all" — run something on your own machine. Tabula and Camelot extract tables from PDFs locally, and for a preparer whose firm policy forbids third-party upload, that is the correct answer and no vendor page should pretend otherwise.

What they cost is worth stating plainly, in both directions.

They are generic table extractors. They find rectangles of text; they do not know what a depreciation schedule is. They will not distinguish the federal listing from the AMT copy in the same PDF, will not recognise that TOTAL SOFTWARE is the subtotal for the group headed SOFTWARE, will not know that a Lacerte summary variant folded prior §179 and bonus into one column, and will not produce a file in the 104-column positional layout a Drake import requires. They give you a grid, accurately, and everything after the grid is yours.

They also cannot tie out. What they hand back is a table, not a table checked against the totals the document printed — and the tie-out is the only independent evidence that a transcription is right at all. On a scanned schedule they do less again, because there is no text layer to find.

For a ten-asset schedule, that trade is often worth it. For a 200-asset book mid-migration, the grid is the easy part of the job.

Questions worth asking any vendor, including this one

These are the ones that produce a usable answer rather than a brochure sentence:

• Where does processing physically happen — including any AI inference, which is the part most commonly hosted somewhere other than where the company is.
• Is my client's data used to train a model. For any tool with AI in it, ask about the subprocessor too, not just the vendor.
• What is the retention window, and what enforces it — a job, or an intention.
• Can I delete on demand, and does that remove the source file or only the record of it.
• Does the tool decide anything, or does it only report what the document says. This is the §7216 question in plain form.
• Will you give me something in writing I can attach to my WISP vendor file.

Our answers to all six are on the security and §7216 page, and the written version for your own file is the vendor file. If a vendor cannot answer the sixth question, the first five do not matter much.

What we do with it

The short version of our own answers: transcription only, never a determination; processing in the United States; no training on client data; identifiers redacted before extraction; 30-day automatic deletion with delete-now on every conversion, and the totals must tie before a file can be downloaded at all.

The last one is the reason the rest is worth anything. A tool that guessed well would still be a tool that guessed — and the moment it fills in what a document did not print, the exception this whole arrangement sits inside stops describing it. That constraint is not a marketing position we adopted; it is the thing that makes the prior preparer's schedule safe to send anywhere at all.

FAQ

Does sending a client's depreciation schedule to a conversion service need written consent?

Treas. Reg. §301.7216-2(d)(1) permits disclosure to a third party providing auxiliary services in connection with preparing the return, without separate consent, where that party makes no substantive determinations or advice affecting tax liability and performs the services within the United States. Whether a particular arrangement meets those conditions depends on what the vendor actually does and where, which is why both are worth asking about directly.

What makes a vendor auxiliary rather than something else?

Reporting what the source document says keeps a service auxiliary. Choosing a method, life, convention or basis, or supplying a figure the document never printed, is a substantive determination and takes the arrangement outside the provision.

Is offshore processing a problem if the data is encrypted?

The condition in the regulation is about where the services are performed, not about how the data is protected in transit. Encryption is a separate and necessary safeguard; it does not substitute for the location requirement.

What do I need for my WISP about a vendor like this?

16 CFR 314.4(f) requires you to select providers capable of maintaining appropriate safeguards and to hold them to it by contract. In practice that means a written description of retention, access, processing location and deletion that you can file with your programme documentation.

Are local tools like Tabula safer?

Nothing leaves your machine, which removes the question entirely, and for a firm policy that forbids upload it is the right answer. The cost is that they are generic table extractors — no knowledge of schedule variants, no import formats, no reconciliation against the printed totals, and nothing at all on a scan with no text layer.

How long is an uploaded schedule kept?

Thirty days, after which the uploaded file and the extracted rows are deleted by a nightly job. Any conversion can also be deleted immediately from its own page.