Read the table well enough to catch the column that landed in the wrong field, before it becomes part of your asset register.
The mapping table shows your actual data, not just column names. Real cells from your file sit under each header, so you can see what a column contains while you decide what it is.
Up to fifty rows are shown. The row count above the table tells you how many the file really has.
Where this is in the app
Dashboard → Import assets — or, from a return, Assets tab → Add assets → Bulk import
The table is the Map Columns step of the import: step 2 with your own file, step 3.5 on the vendor route. See Mapping columns, and what the step does.
Two ways to look at the same mapping
By File Columns
The default. One column per column in your file, in file order, with a dropdown under each header naming the field it maps to.
This is the view for "here is my file, what is each of these?", and it's the natural one when you're looking at a file you know.
By Standard Fields
The same mapping from the other end. One column per DepreciationPro field, with a dropdown naming which of your file's columns feeds it.
This is the view for "is anything I care about not getting filled?" The fields are grouped into tabs, so you can look at just the ones that matter to this file.
Tab | What's in it |
All | Every field, in one list |
Required | Just the three that must be mapped |
Tax Depreciation | Recovery period, method, convention, §179, and the prior-depreciation figures |
Book Depreciation | Book useful life, salvage, accumulated |
AMT/ACE Depreciation | The AMT and ACE method, life and depreciation fields |
Vehicle | Business-use percentage, GVWR, VIN |
Organization | GL account, activity, state, allocation percentage, source category |
Disposal | Disposal date and sale proceeds |
The toggle changes how the mapping is displayed, never what it is. Switch views mid-edit and your work is intact, because there is only one mapping underneath.
Two fields for amortizing intangibles
Two more targets are in the All list if your file carries them:
Field | What it takes |
Code section | "Code section the costs are amortized under (Form 4562 Part VI, column (d)) — recorded as written; not a tax input" |
Date amortization begins | "Date amortization begins (Form 4562 Part VI, column (b)) — recorded separately from the placed-in-service date; not a tax input" |
Both are recorded on the asset and reported on the Form 4562 Part VI workpaper. Neither changes what an asset computes, and neither is used to work out a property type, method or recovery period. Map them or leave them; the import works the same either way.
What the badges mean
Each header carries more than a name. The annotations are there so the decisions worth a second look announce themselves.
These are the badges on your own spreadsheet. A vendor export uses a different scale, covered in Mapping columns, and what the step does.
What you see | What it means |
HIGH | A confident match. Usually nothing to do. |
Suggested | A reasonable guess. Read its reasoning in the "…" popover before you accept it. |
A dimmed header | This column isn't mapped to anything, so it won't import. |
"3 of 214 have values" | A sparse column, mostly empty. That may or may not be what you expect. |
The "…" popover
Every mapped header has one. It gives the field the column is mapped to, the AI's reasoning where there was any, and how many rows actually carry a value.
That last count is across your whole file, not just the rows on screen. A column that looks empty in a fifty-row window may be filled further down, and this is where you find out.
Sparse columns
A column filled on fewer than a fifth of your rows says so under its header.
That's reporting, not a complaint. A disposal date on three rows of two hundred is exactly right for a file with three disposals. It's shown because the alternative is a column that looks broken when it isn't, or an empty one that looks fine when it isn't.