The schedule is only as good as two numbers
Whatever depreciation method a business uses — straight-line, declining balance, units of production — every schedule ultimately depends on getting two numbers right for every single asset: what it cost, and when it went into service. Get either one wrong, and the depreciation calculation that follows is wrong too, no matter how carefully the method itself is applied.
This page describes how those two numbers — cost and date — get read directly from the source documents, instead of retyped from a register that may itself contain a typo, or estimated from memory for an older asset nobody double-checked. The result doesn't calculate depreciation; it's the organized, sourced input a depreciation calculation actually needs.
Why schedules drift from the register
A depreciation schedule is often built once, early in an asset's life, and then left to run — updated for new additions but rarely re-verified against the original purchase invoice. Over time, small discrepancies accumulate: a cost figure that was rounded during entry, an in-service date that was estimated because nobody checked the actual delivery date, a component cost that got bundled into the main asset instead of tracked separately.
None of those discrepancies are dramatic individually. Across a schedule with hundreds of assets, accumulated over years, they add up to a depreciation expense that's technically calculated correctly from inputs that were never quite right in the first place.
What gets read for the schedule
| Field | Notes |
|---|---|
| Asset cost | The exact amount, per component where itemised |
| In-service date | Read from delivery or installation documentation where it differs from the invoice date |
| Description | As written on the invoice, for identification against the register |
| Supplier and reference | For traceability back to the source document |
| Disposal date and value | Where a disposal document exists, for the asset's final period |
Five fields, read from every source document — not a figure carried forward from a spreadsheet nobody has checked against the original invoice in years.
Different methods, same underlying data
Straight-line depreciation, declining balance, units of production — every method takes cost and in-service date as its starting inputs, then applies a different formula on top. The reading step described on this page is identical regardless of which method your business or your accountant ultimately applies.
That separation matters more than it might seem. It means switching depreciation methods, or applying different methods for tax and book purposes, doesn't require re-reading a single invoice — the underlying cost and date data stays the same; only the calculation built on top of it changes.
Additions and disposals mid-year
An asset purchased partway through a fiscal year needs a partial-period depreciation calculation, not a full year's worth applied from the start of the period. Getting that right depends entirely on having the precise in-service date, not an approximate one.
The same applies at the other end — an asset disposed of mid-year needs its final period calculated up to the actual disposal date, not the end of the fiscal year. Reading the exact date from the purchase and disposal documents, rather than defaulting to period boundaries, is what makes a partial-year calculation possible in the first place.
Reconciling against the register
The fixed asset register says what the business owns. The invoices say what was actually paid and when. The two should agree, but confirming that means reading both, not assuming the register was entered correctly the first time.
Reading directly from invoices, then checking each entry against the corresponding register line, catches exactly the kind of small discrepancy that compounds silently over years — a cost that was rounded during entry, a date that was approximated, a component that was bundled instead of separated.
A year of additions, organized
A mid-sized business, one fiscal year, 28 capital additions ready for the depreciation schedule.
| Category | Additions | Total cost |
|---|---|---|
| Machinery | 9 | $318,000 |
| Vehicles | 4 | $142,000 |
| IT equipment | 15 | $61,200 |
28 additions, three categories, all read with precise in-service dates including six mid-year purchases that would have been assigned a full year's depreciation by mistake under a simpler, date-blind approach.
How it works
Upload capital invoices
PDF, scan or photo — for the assets you're building the schedule from.
Cost and dates are read
Per asset, per component where itemised, with disposal data where it exists.
Consistency is checked
Line items confirmed against the invoice total before being considered reliable.
Export
Excel, CSV or JSON, organized and ready for your depreciation calculation.
From one asset to a full schedule
Reading one asset's invoice is a quick task by hand. Reading every capital addition across a full year, for a business with hundreds of assets on its schedule, is a different problem — not because any single invoice is harder, but because the volume changes what's actually practical to verify manually alongside a full close.
At that volume, the value isn't only time saved — it's that every addition, regardless of size or category, gets the same level of scrutiny, instead of large purchases getting careful attention while small ones are entered quickly and never double-checked.
Into your depreciation calculation
The read data has to land somewhere. For a fixed asset module inside your accounting software, exporting to Excel or CSV with stable columns lets you import without reshaping the file every time a new batch of additions comes through.
For a dedicated depreciation system or a custom calculation built in-house, JSON via API is the more direct route — cost, date and description kept as distinct, machine-readable fields rather than concatenated into a single description line.
Who this is for
Finance teams
Schedule inputs sourced from real invoices, not carried forward from a spreadsheet nobody has re-checked.
Accountants and bookkeepers
Clean, traceable cost and date data to build or verify a client's depreciation schedule.
Controllers
Confidence that partial-year additions and disposals are dated precisely, not defaulted to period boundaries.
Auditors
Every schedule input traceable back to the invoice it came from, ready for testing.
Different sources, one method
Capital invoices rarely all arrive in the same format. A large equipment supplier might send a clean digital PDF with a clearly stated delivery date. A smaller contractor might send a scanned invoice with a single date and no separate delivery documentation. Both need to feed the same schedule.
None of that variation requires separate configuration. The reading is based on the structure and meaning of the invoice, not a fixed layout tied to one supplier — a clean digital PDF and a scanned invoice are read the same way, because both follow a recognisable invoice structure underneath their surface formatting.
Scans and photographs pass through OCR first, and automatically receive a closer level of scrutiny — fields on a photographed invoice get flagged more often than the same fields on a clean digital export, which is the expected behaviour, not a flaw in the reading itself.
A schedule that spans years
Reading one year's additions is a contained exercise. Building a schedule that spans several years of acquisitions changes what becomes possible with that data, because a genuinely useful depreciation schedule almost always covers assets acquired across multiple years, not just the current one.
A multi-year schedule built with consistent, sourced data makes it straightforward to answer questions that would otherwise mean reopening old invoices — how much depreciation expense is coming due next year as older assets reach the end of their useful life, which category of asset is aging fastest, whether spend on a particular category has been trending up or down.
That multi-year view also makes budgeting for future capital replacement more grounded — a schedule that shows a wave of assets all reaching the end of their useful life in the same year gives finance real advance notice of a coming replacement cycle, instead of that cycle arriving as a surprise in next year's capital budget request.
Seeing that wave coming a year or two in advance is often the difference between a planned, staggered replacement programme and an unplanned spike in capital spend that competes with every other priority in the same budget cycle.
A staggered plan, negotiated calmly with suppliers over months, also tends to land on better pricing than a rushed replacement forced by equipment failing all at once with no advance warning to soften the negotiation.
None of that planning advantage is available without knowing, well in advance, exactly which assets are approaching the end of their useful life in the same window — which is precisely what an organized, sourced schedule makes visible, months before the actual replacement decisions need to be made and budgeted for, not the week they become urgent and every remaining option costs more than it reasonably should.
Tax and book depreciation, kept as separate outputs
Many businesses run two depreciation calculations side by side — one for financial reporting, following the company's book depreciation policy, and one for tax purposes, following whichever accelerated or specific method the applicable tax code allows. The two produce different numbers for the same asset, and both need to be right at the same time.
Because the underlying cost and date data is read once and kept consistent, both calculations can be built from the same source without re-reading a single invoice twice. What differs between the two outputs is entirely the method and useful life assumptions applied on top — never the underlying facts about what was purchased and when.
That separation matters most at exactly the moment it's easiest to get wrong: when a business changes its book depreciation policy, or when a tax rule changes retroactively. Neither event requires touching the underlying invoice data — only the calculation layer that sits on top of it needs to change.
Building a roll-forward, not just a snapshot
A depreciation schedule that only shows the current period's figures answers an immediate question. A schedule built to roll forward — opening balance, additions, disposals, depreciation charge, closing balance — answers the question an auditor or a controller actually needs answered every period: does this number tie out to last period's closing balance plus what changed.
Building that roll-forward is straightforward once cost and date data is read consistently for every addition and disposal — the roll-forward is simply the same organized data, viewed period over period, rather than a separate calculation exercise built from scratch each time.
An auditor testing fixed assets almost always asks for exactly this roll-forward first, because it's the single view that ties the opening balance, every movement, and the closing balance together in one place, ready to be checked line by line against supporting documentation.
Having it ready before it's requested turns what's often the first, tone-setting question of a fixed asset audit into a quick, confidence-building start rather than a delay before the real testing even begins in earnest.
What this doesn't do
Doesn't calculate depreciation
It provides cost, date and description. The depreciation method, useful life and calculation stay with your accounting system or accountant.
Doesn't decide useful life
Useful life assumptions are a policy decision, often set by asset category, not something read from an invoice.
Doesn't replace your fixed asset system
It's the layer that turns invoices into organized inputs — not the schedule engine, the register, or disposal tracking itself.
Doesn't apply tax-specific depreciation rules
Book and tax depreciation can differ significantly. This provides the underlying facts; applying the right rules for each stays a separate determination.
This boundary is deliberate. A tool that guessed at useful life or depreciation method would be making an accounting policy decision on your behalf without anyone noticing — organized, sourced data is less convenient than a finished calculation, and for exactly that reason more trustworthy.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Invoices are never used to train AI models.
For a business tracking capital assets across multiple categories and years, that isn't a footnote — the details are on the security page.