Depreciation Computation

By Nupur Mittal

Co-founder at OCTA — works with accounting firms on month-end close and reconciliation automation.

Depreciation computation is the process of calculating the periodic depreciation expense for every asset on a fixed asset register, using the method and useful life the entity's policy assigns to that asset class, then reconciling the result to what's actually posted in the general ledger. It confirms that depreciation expense — and the net book value it drives — is accurate, policy-compliant, and free of assets that are over-depreciated, under-recorded, or still expensing after disposal. This page walks through the full process, the standard methods, a worked example, and how firms run it faster with OCTA Flow while a human signs off on every adjustment.

Why depreciation computation matters, and where it goes wrong

Every fixed asset — machinery, vehicles, computers, buildings, furniture — loses value over its useful life, and accounting rules require that loss to be recognized as an expense in a systematic, policy-consistent way rather than all at once or on a whim. Get depreciation wrong and two things break at the same time: the income statement misstates the period's expense, and the balance sheet misstates net book value — an error that compounds every period it goes uncaught, because each year's depreciation builds on the last.

The mechanical difficulty is scale and drift. A mid-size company's fixed asset register can run to hundreds of line items across half a dozen classes, each with its own acquisition date, method, useful life, and salvage value. Multiply that by every period, and small errors accumulate: a useful life typed wrong, a disposed asset that keeps depreciating because nobody flagged it, a fully-depreciated asset still carrying an expense line, a new addition that missed the current run entirely. None of these are dramatic on their own — but a register that's quietly drifted from policy for two years is a real problem when an auditor, a buyer, or a lender asks for it. The goal is a schedule that ties to the GL exactly, follows policy consistently, and flags every exception the moment it happens — not a spreadsheet nobody has re-verified since it was built.

The depreciation computation process, step by step

A rigorous depreciation run follows the same sequence every period, regardless of company size or asset mix. The steps below are the full procedure OCTA Flow executes; they also stand alone as a best-practice process for anyone computing depreciation by hand.

1. Load the depreciation policy. For each asset class, confirm the assigned method — Straight-Line (SL), Declining Balance (DB/DDB), or Sum-of-Years-Digits (SYD) — the useful life in years or months, the salvage value (if any), and the pro-ration convention (full-month, half-year, or similar) used for assets acquired or disposed mid-period. The policy is the single source of truth every asset should be checked against.

2. Process every asset using its assigned method.

• Straight-Line — Annual depreciation = (Cost − Salvage Value) ÷ Useful Life. The expense is identical every period.
• Declining Balance (Double-Declining Balance) — Annual depreciation = Net Book Value × (2 ÷ Useful Life). The expense is highest in early years and shrinks as NBV falls; depreciation stops once NBV reaches salvage value — it should never be forced below it.
• Sum-of-Years-Digits — Annual depreciation = (Cost − Salvage) × (Remaining Life ÷ Sum of the Years' Digits). Like DDB, this front-loads expense but on a different curve.

Apply the pro-ration convention for any asset with a partial first or last year, then compute year-to-date depreciation expense, accumulated depreciation, and net book value for every asset.

3. Reconcile the computed total to the general ledger. Sum the actual depreciation entries posted to the GL, by month and in total for the period, and compare that figure to what was computed in step 2 — by asset and in aggregate. Any difference, however small, is a flag: it means the books and the schedule disagree about what depreciation expense should be.

4. Verify continuity with the prior period. Where a prior-period asset register is available, confirm that last period's ending accumulated depreciation for each asset matches this period's beginning balance. A break here usually means a manual adjustment, an asset transfer, or a data error that was never explained.

5. Identify departures from policy. For every asset, check: is the depreciation method actually the one the policy assigns to that class? Is the useful life within the policy's stated limits? Is a fully-depreciated asset still recording expense it shouldn't be? Is a disposed asset still depreciating after its disposal date? Each of these is a policy exception that needs a documented reason or a correction.

6. Build the asset roll-forward. Summarize the register in roll-forward form for both cost and accumulated depreciation: beginning balance, additions, disposals, and ending balance for cost; beginning balance, current-period expense, disposals, and ending balance for accumulated depreciation. Net book value falls out as ending cost minus ending accumulated depreciation. This roll-forward is the schedule's backbone — it's what ties current-period activity back to where the register started.

Book vs. tax depreciation, and a worked example (SL vs. DDB)

Depreciation is computed on two distinct bases, and mixing them up is one of the most common errors in a fixed asset file.

Book (financial-reporting) depreciation is what's recognized under the entity's accounting framework — the SL, DDB, and SYD methods above, following the useful life and salvage value the company's own policy sets. This is the depreciation that flows through the financial statements.

Tax depreciation is computed separately, under a jurisdiction's statutory tax law, and frequently uses a different method, rate, and grouping than book depreciation — which is exactly why the two produce a temporary difference that flows into deferred tax. In the United States this is commonly MACRS; other jurisdictions have their own statutory frameworks. The tax-basis method OCTA Flow has fully implemented today is India's Income Tax Act, 1961, §32 — the block-of-assets Written-Down-Value (WDV) method.

Under §32 WDV, assets aren't tracked individually for tax purposes — they're grouped into blocks by asset class, each with a prescribed rate (for example, buildings at 5–10%, furniture at 10%, plant and machinery at 15–30%, computers and peripherals at 40%, motor vehicles at 15%, intangibles at 25%). The rate is applied to the block's opening WDV plus additions, less disposal proceeds. An addition used for fewer than 180 days in its acquisition year gets only half the normal rate. If disposal proceeds exceed the block's value, the excess is treated as a short-term capital gain and the block's WDV is floored at zero — it's never allowed to go negative. Because the block method and the book method (SL/DDB/SYD) rarely agree in any given year, running both side by side is how a company tracks its book-tax depreciation difference. Flow flags this distinction explicitly on the schedule it produces, so a tax-basis schedule can never be mistaken for a book-basis one — and if a jurisdiction's tax method isn't yet supported, Flow raises that as a finding rather than quietly substituting book depreciation for the answer.

A worked example — Straight-Line vs. Declining Balance (book basis):

Take a CNC milling machine: cost $150,000, salvage value $15,000, useful life 10 years, placed in service at the start of the year (no proration needed).

Straight-Line: Annual depreciation = ($150,000 − $15,000) ÷ 10 = $13,500 every year, until NBV reaches $15,000 in year 10.

Double-Declining Balance: Rate = 2 ÷ 10 = 20%, applied to the beginning net book value each year:

Notice DDB front-loads roughly 2.2x the SL expense in year one, then tapers — depreciation continues to decline each year and is capped so NBV never falls below the $15,000 salvage value. Same asset, same useful life, materially different expense in early years — which is exactly why the method assigned to each asset class has to match policy, not be picked ad hoc.

Asset roll-forward, aggregated across the register (illustrative, FY2025):

If the GL shows a current-period depreciation expense of, say, $305,200 against the computed $310,000, that $4,800 gap is a variance the schedule flags for investigation rather than a rounding error to ignore.

Key controls and red flags

Computing depreciation correctly and computing it reliably are different things. A rigorous review checks for:

• Computed depreciation that doesn't match GL-recorded depreciation — by individual asset and in total for the period
• Assets depreciated below their salvage value — net book value should never fall below salvage, and never below zero
• Fully-depreciated assets still recording expense — a policy violation that overstates the current period's cost
• Disposed assets still generating depreciation — expense recorded after an asset's disposal date shouldn't exist
• Useful lives that exceed the policy's stated maximum for that asset class
• New additions with no depreciation recorded for the period they were placed in service
• A depreciation method that doesn't match the policy assigned to that asset class — e.g., an asset on DDB when policy calls for SL
• A tax-basis schedule requested for a jurisdiction with no implemented statutory method — this should be escalated, never silently answered with book depreciation

Catching these every period, across every asset class, is what separates a genuine fixed-asset control from a spreadsheet that only gets checked when something looks wrong.

What a completed depreciation schedule produces

A finished depreciation run isn't just a recalculated spreadsheet — it's a documented workpaper a controller can sign off on and an auditor can trace end to end. A complete package includes:

How OCTA Flow automates depreciation computation

OCTA Flow runs the calculation and reconciliation for every asset, and leaves the judgment calls — and every sign-off — with your team. The workflow mirrors the process above:

1. Pick the Depreciation Computation Skill. Flow already knows the full procedure: apply the correct method and useful life per asset class, reconcile to the GL, verify continuity from the prior period, and flag policy departures — on a book basis by default, or a statutory tax basis (such as India §32 WDV) when the request calls for it.
2. Connect your data. Point Flow at the fixed asset register and the general ledger, or upload the period's files — the asset register, the GL depreciation entries, the depreciation policy, and last period's register if you have it.
3. Run. Flow calculates SL, DDB, or SYD depreciation for every asset per policy, reconciles the total to what's posted in the GL, and builds the roll-forward.
4. Review findings by severity. Instead of re-checking every line, Flow surfaces only what's wrong — ranked by severity, each with a plain-English explanation and a recommended action: post a correcting entry, route a policy exception to the controller for approval, or escalate an unsupported tax-basis request. Your team works the exceptions, not the whole register.
5. Sign off. Once the schedule ties to the GL and every exception is resolved or approved, Flow assembles the workpaper with the full audit trail intact.

The result: the asset-by-asset recalculation happens in a fraction of the time, and your team spends its hours on the handful of assets that actually deviate from policy.

Control and trust: Flow proposes, you approve

This matters most on a fixed asset register that feeds directly into the financial statements: OCTA Flow never writes to your books on its own. Every correcting entry and every policy exception is a proposal that a person on your team reviews and confirms before anything is posted. Flow runs the calculation and shows its reasoning; a person makes the call.

That control model runs through the whole process:

• Findings, not silent changes. Flow raises what it computed and what it recommends — you decide whether to resolve, override, or escalate.
• Severity and escalation built in. An asset depreciated below salvage or a GL variance is flagged as critical and routed to a manager rather than buried in a spreadsheet.
• A complete audit trail. Every calculation, proposed entry, approval, and override is logged, so the schedule is fully traceable — which matters as much to an auditor as it does to your own review.

You get the speed of automated calculation with the accountability of human sign-off — exactly what a register feeding the balance sheet requires.

What the depreciation schedule draws on

To compute depreciation, Flow uses the same inputs a preparer already works from:

• Fixed asset register — every asset with its acquisition date, cost, accumulated depreciation, and useful life (required)
• GL depreciation accounts — the period's depreciation entries as actually posted in the general ledger (required)
• Depreciation policy — the method, useful life, and salvage value assigned to each asset class (required)
• Prior-period fixed asset register — to verify continuity between last period's ending balances and this period's opening balances (optional)

Flow works from whatever your client has connected — it identifies each file by its purpose, so it doesn't matter what the files are named or which system they were exported from.

Related skills and terms

Frequently Asked Questions

How do you calculate depreciation? Take the asset's cost, subtract its salvage value, and apply the method your policy assigns to that asset class over its useful life. Straight-line spreads the expense evenly; declining balance and sum-of-years-digits front-load more expense into earlier years. The result should reconcile to what's actually posted in the general ledger.

What's the difference between straight-line and declining balance depreciation? Straight-line depreciation is the same dollar amount every period: (cost − salvage) ÷ useful life. Declining balance applies a fixed percentage to the asset's remaining net book value each period, so the expense is highest early on and shrinks over time — it never reduces net book value below salvage value.

What's the difference between book and tax depreciation? Book depreciation follows the company's own accounting policy (straight-line, declining balance, or sum-of-years-digits) and flows through the financial statements. Tax depreciation follows a jurisdiction's statutory tax rules — for example, India's Income Tax Act, 1961, §32 written-down-value block method — and frequently produces a different expense than book depreciation in any given year, creating a temporary difference used in deferred tax calculations.

What is the written-down-value (WDV) method under India's §32? Assets are grouped into blocks by class rather than tracked individually. A prescribed rate is applied to each block's opening WDV plus additions, less disposal proceeds, with a half-rate for additions used less than 180 days in the year they're acquired. It's a statutory tax-depreciation method, distinct from whatever book method the company uses for its financial statements.

What causes a depreciation schedule to not reconcile to the GL? Common causes are a period where depreciation wasn't posted for a new addition, a disposed asset still generating expense after its disposal date, a useful life or method that was changed without updating the schedule, or a manual GL entry that never made it into the fixed asset register.

Can depreciation computation be automated? The calculation, GL reconciliation, and policy-exception detection can be automated and reviewed, while decisions like approving a policy exception or writing off an impaired asset stay with your team. That's the model OCTA Flow uses.

Does OCTA Flow post depreciation entries directly to my accounting system? No. Flow proposes every correcting entry; a person on your team reviews and approves before anything is posted to the books. Nothing is written automatically.

See how firms run faster, fully-reconciled depreciation schedules with human sign-off → start a 30-day OCTA Flow trial.