Fixed Asset Management Tool
AI Tool Basics for CA

Fixed Asset Management Tool

Author : CA Harshal Vibhakar Anjaria

Watch on Youtube

FIXED ASSET MANAGEMENT TOOL

Single-file, browser-based, zero-installation, fully offline

Use-Case Submission by: CA Harshal Vibhakar Anjaria

ICAI AI Hackathon (Season 6 Episode 1)

1. Problem Statement

Every company in India must compute depreciation twice over the same assets, on two incompatible bases: Schedule II of the Companies Act 2013 (useful lives, componentisation, shift working, residual value) and section 32 of the Income-tax Act 1961 (block of assets, written-down value, the half-year rule, section 50 on transfer). Ind AS 36 adds impairment testing at cash-generating unit level, Ind AS 105 adds held-for-sale measurement, and Schedule III adds a capital-work-in-progress ageing disclosure. The same register must then support deferred tax by block and a physical verification the auditor can rely on.

In practice this is done in spreadsheets. A mid-sized company with two thousand assets maintains several linked workbooks that take five to ten days each year-end, break silently when a row is inserted, carry no audit trail, and cannot show who verified which asset or when. Enterprise fixed-asset modules inside an ERP are priced and scoped for large installations and are not configured for Indian dual-basis depreciation without substantial implementation effort. Between the spreadsheet and the ERP there is nothing: no affordable, auditable, India-specific tool that a practising Chartered Accountant or a mid-sized finance team can simply open and use.

2. Solution Overview

The Fixed Asset Management Tool is a single HTML file that delivers a complete fixed-asset system — register, dual depreciation engines, impairment, deferred tax, capital work in progress, physical verification, journal entries, reports and a year-end close — with no server, no installation, no subscription and no internet connection. It is opened by double-clicking the file.

The register is stored as a real SQLite database in a folder beside the tool (Data/<Entity>.famt.db), so the client’s data is an ordinary file that can be copied, archived, filed in a document management system, or opened in DB Browser, Excel or Power BI entirely without this tool. One file per entity; unlimited entities on one computer. A register of one thousand assets computes three financial years in under a second.

3. Core Features

  1. Companies Act engine (Schedule II): Straight-line and written-down-value methods, the full Schedule II useful-life master, componentisation, residual value, double and triple shift working pro-rated by actual shift days, change in accounting estimate applied prospectively under Ind AS 8, change of method, revaluation (proportional and elimination), and consolidated opening-balance rows for legacy registers.
  2. Income-tax engine (section 32): Block of assets on written-down value, the complete Income-tax rate master including date-qualified blocks such as the enhanced 2019 motor-vehicle rates, the 180-day half-rate rule, additional depreciation under section 32(1)(iia) and section 33, moneys payable on transfer under section 43(6), short-term capital gain and loss under section 50, and block cessation.
  3. Change in law, handled correctly: A statutory rate change is entered once on the block, with the date it takes effect. The first financial year beginning on or after that date carries the new rate; earlier years are left exactly as reported, so a comparative is never silently restated.
  4. Ind AS 36 impairment: Testing at cash-generating-unit level, recoverable amount as the higher of value in use and fair value less costs of disposal, the loss allocated pro-rata across the unit’s assets on pre-impairment carrying amount, with reversal logic and the carrying-amount cap.
  5. Ind AS 105 and revaluation: Held-for-sale measurement at the lower of carrying amount and fair value less costs to sell, with depreciation ceasing on classification; revaluation surplus and deficit routed correctly between other comprehensive income and profit or loss.
  6. Deferred tax: Computed by tax block from the timing difference between the two engines, so the deferred tax figure reconciles to the same register that produced both depreciation charges.
  7. Capital work in progress: Projects with booking dates, part-capitalisation into named assets in the register, write-off of abandoned cost to profit or loss, a movement statement, and the Schedule III ageing in the four prescribed buckets, reconciled to the movement.
  8. Physical verification: A mobile-first field mode: QR tags generated and printed from the tool, scanned on a phone browser with no app installed, recording sighting, condition, GPS coordinates with accuracy, verifier, date and photographs. Records are append-only evidence — a correction is a new record, never an edit — so two verifiers can never conflict, and inconsistent records are quarantined rather than merged.
  9. Multi-team field deployment: An optional Google Apps Script endpoint shares one engagement’s register across a team. The owner publishes the asset list; verifiers record sightings; everyone’s records return to everyone, merged field by field with conflicts reported rather than overwritten. Devices are individually enrolled, carry entry or view-only rights, and can be revoked mid-engagement.
  10. Governance and audit trail: A hash-chained audit trail of every change, period locks archived with a SHA-256 digest, optional reviewer approval for a lock, an eight-step year-end close with sign-offs, an exception centre consolidating every control the engine runs, an asset recycle bin, transfers with effective dates, and archived read-only engagements.
  11. Access control: Each engagement can require its own passphrase before it will open, so a person on a shared computer reaches only the clients they are assigned. Only a PBKDF2-SHA-256 verifier is stored; the passphrase itself is never written anywhere.
  12. Outputs: Fixed asset register, Companies Act and Income-tax depreciation schedules, CGU impairment working, deferred tax statement, CWIP movement and ageing, journal entries, comparison across years, a portfolio explorer, and a presentation mode for the audit committee. Exports to Excel and PDF, with encrypted AES-256-GCM backups.
  13. Demonstration register: A seeded one-thousand-asset register across six cash-generating units, with impairment inputs, capital work in progress, disposals, revaluations, held-for-sale assets and shift working — loaded with one click to show behaviour at scale.

4. Technology Stack

LayerComponents
ArchitectureA single self-contained HTML file of approximately 25,000 lines, carrying a 17,000-line computation engine inlined in readable form. Vanilla JavaScript, no framework, no build step at run time, no network calls. A release manifest records the SHA-256 of every file the tool loads, so a recipient can prove the copy they hold is the one that was tested.
ComputationDeterministic and reproducible by design: no model, no randomness, no external service. The same register produces the same figures on any machine, which is what makes the output defensible in an audit file. A seeded generator is used only to build the demonstration data.
PersistenceReal SQLite via sql.js, carried inside the file as WebAssembly so it works from file:// with no download. Written to Data/<Entity>.famt.db through a local helper process or the File System Access API, and mirrored to IndexedDB for crash recovery. Reporting fields are promoted to queryable columns so the database is useful in DB Browser, Excel or Power BI.
Visualisation and exportHand-written SVG for charts and the heat views; SheetJS for Excel export; jsPDF with html2canvas for PDF; a local QR generator for asset tags. All libraries are carried in the file — there is no content delivery network, by design.
SecurityCredentials held on the device only and never written into the register or a backup; the publish key held for the session only. Encrypted backups use AES-256-GCM with PBKDF2-SHA-256 key derivation at 310,000 iterations. Period locks and engagement passphrases use the Web Crypto API. A Content-Security-Policy meta restricts connections, objects, base URI and form action.
IntegrationOptional Google Apps Script endpoint for shared physical verification and full register synchronisation, with server-side protocol versioning, device enrolment, append-only verification records, quarantine of inconsistent rows, optimistic concurrency and a server sequence on every write.
AssuranceAn automated test suite of 592 checks across 20 suites — figures, interface, storage, synchronisation, scale, mobile, colour contrast, upgrade from older registers, and a digest comparison that proves the computed figures are unchanged after any code change.


5. Methodology

Workflow: create the engagement → import or enter the register (guided CSV import with column mapping, validation and correction before anything is committed) → enter tax block opening written-down values → define cash-generating units and impairment inputs → Calculate → review the exception centre → lock the period → export the schedules and the journal.

Computation discipline: every input that drives money is range-checked before the engine runs. An impossible state stops the computation and names the rows rather than producing a schedule that looks finished — a negative opening written-down value, a tax rate outside nought to a hundred per cent, two different rates inside one block, a capitalisation dated before its project was booked, an abandoned project still carrying a balance, a duplicate row identifier, or any result that comes out as not-a-number. Judgemental matters are raised as reviewer exceptions instead, so the distinction between an error and a question of judgement is preserved.

Reproducibility: every mutation increments a revision; a computation records the revision it was produced from; and anything that consumes the result — a report, a PDF, the dashboard, a period lock — checks that the two still agree. A figure that no longer matches the register on screen cannot be exported or locked.

Verification as evidence: a physical verification record is never edited, only added. A correction is a new record carrying its own date, verifier and reason, so the history of what was sighted and when survives intact and records from different verifiers never conflict.

Change in law: a rate change is entered as a rate and the date it takes effect. Because a block carries one rate for a whole previous year under section 43(6), a date falling inside a year takes effect from the next one. Years that closed before the change keep the rate they were reported at.

6. Differentiation

  1. Against spreadsheets: Both depreciation bases, impairment and deferred tax from one register that cannot silently break; a hash-chained audit trail; period locks; and physical verification evidence that a workbook cannot hold at all.
  2. Against enterprise modules: No licence, no implementation project, no server, and no configuration effort for Indian statutory requirements — they are the tool’s native basis rather than a customisation.
  3. No vendor lock-in: The register is an ordinary SQLite file the client can read without this tool, now or in twenty years. That is a deliberate design decision, stated openly, and it is what makes the tool safe for a professional to put a client’s asset register into.
  4. Works where the assets are: The plant floor, the basement, the depot. No signal, no installation, no application store — a phone browser and a printed QR tag are enough.

7. Conclusion

The Fixed Asset Management Tool turns fixed-asset accounting from an annual spreadsheet exercise into a maintained, auditable record. It removes the cost barrier entirely, produces figures that are reproducible and defensible, carries the evidence of physical verification alongside the numbers it supports, and leaves the client owning their data in an open format. It is built for the Indian statutory position as it actually is — two bases, one register — and for the practitioner who has to sign the result.