A net worth spreadsheet doesn’t stop working because it got too big. Four hundred rows and a dozen tabs is a small file by any measure, and the format will carry that for decades without complaining.
It stops working the first time you need a figure from the past and find that you typed over it.
The layout is what does it, and it’s the layout nearly every free template ships with: accounts down the left, a column of current values beside them. Updating a sheet built that way means selecting a cell and replacing what’s in it. March 2023’s balance was overwritten by April’s, April’s by May’s, and no amount of formula work brings any of them back. The file answers what is this worth today with total precision, and what was this worth in March 2023 not at all.
Which of those you needed isn’t something you get to know in advance.
What the format gets right
Most of what follows criticises one design decision, so it’s worth being exact about what isn’t being criticised.
A spreadsheet will model anything. No feature request, no roadmap, no argument with somebody else’s idea of what an asset category ought to be called. A share in a family property, a director’s loan, Premium Bonds, a buy-to-let and the remains of a peer-to-peer lending account can sit in one file under headings that make sense to exactly one person, which is the correct number of people for them to make sense to.
Every figure is auditable. Click a cell and the derivation is in the formula bar, which is more than most financial software will show you. There’s no subscription, no third party holding the data, and no vendor whose survival the record depends on. A CSV opens anywhere, forever, without anyone’s permission.
None of that is throat-clearing before a pitch. A well-built spreadsheet is a good answer to this problem. The rest of this is about what well-built turns out to mean once the file is in its fourth year.
Three layouts, and what each can answer
There are three ways to arrange a net worth history, and the choice is fixed on the day the file is created rather than at the point the limitation bites.
Accounts as rows, one value column. The template default. It holds exactly one observation per account, and updating destroys the previous one. A snapshot generator rather than a record.
Snapshots as rows, accounts as columns. Dates run down the left, one column per account, and a new month means a new row at the bottom. Nothing is overwritten, because the update is an insertion.
Observations as rows. One row per account per date, so a snapshot of eleven accounts adds eleven rows. Least pleasant to look at, most durable once the account list starts changing.
The second is the one to build. It’s a transpose of what most people already have, it takes an afternoon to restructure, and it converts every future update from a destructive edit into an append.
Naming the columns
Two sheets. The first is the log, and it grows downwards forever:
date · recorded · one column per account · total · note
date is the date the figures describe; recorded is the date you typed them, which is what gives corrections somewhere to live. A wrong February balance becomes a second February row with today’s date in recorded, and you read the log by taking the latest recorded for each date. The original stays, the way a ledger posts an adjustment rather than erasing an entry. Where each figure comes from in the first place is a separate problem, and the note column is where that answer belongs.
The second sheet is reference data, one row per account, holding what doesn’t change monthly:
account · provider · wrapper · opened · closed · acquisition date · acquisition cost · notes
This is the sheet almost nobody builds and the one that turns out to matter. Twenty minutes to populate, then untouched for years.
Freeze the schema early, because adding a column in year three leaves every earlier row blank underneath it, and a blank is ambiguous in a way that costs you later: it can mean the account didn’t exist, or that it did and you weren’t tracking it. Decide which and write the convention down. Deciding what gets a column at all is a separate question, and one worth settling deliberately, since what net worth actually measures sets the boundary of the file. Putting a pension into the figure is the decision most likely to be revisited, and revisiting it is far cheaper when the pension always had its own column.
Why the past is worth more than it looks
Keeping history sounds like tidiness. For anything held outside an ISA or a pension, it isn’t.
Verdly publishes for education, not financial advice. Tax treatment depends on your circumstances, so an accountant or a regulated adviser is the right person for anything specific to you. The record-keeping requirement itself, though, is published fact rather than interpretation. HMRC expects you to keep the contracts for buying and selling an asset, copies of any valuations, and receipts for costs such as professional fees, Stamp Duty and improvement costs. Those records must be kept for at least a year after the Self Assessment deadline if you’re not self-employed, and longer if the return went in late or HMRC has opened a check. Business records run to a different and longer schedule, so the one-year figure doesn’t generalise.
Every item on that list is a historical fact. What something is worth today has no bearing on a gain calculation. What matters is what was paid, when, and what was spent on it since.
More people are in that position than used to be. The Capital Gains Tax annual exempt amount is £3,000 for the 2026/27 tax year, well below where it sat earlier in the decade, which pulls a much larger number of ordinary investors holding assets outside a tax wrapper into having gains to report at all. That’s what the wrapper column is for: growth inside an ISA or a registered pension isn’t subject to Capital Gains Tax, so it tells you at a glance which rows need care and which can stay half-finished.
The error surface, and what it’s actually about
There is a research literature on spreadsheet errors, and the numbers in it are worse than most people would guess.
Field audits of real organisational spreadsheets found errors in between 24% and 94% of the files examined, with the more recent audits, using better methodology, finding errors in at least 86%. At the level of a single cell the rate is low: uncorrected errors in roughly 2% to 5% of formulas. Those are the same fact stated twice: a small per-cell rate becomes near-certainty across a large enough sheet.
What was audited matters. These were professional financial models, built at work by people who build models for a living. Nothing in the finding is specific to personal finance, and nothing in it says anything about how careful the reader is.
The more interesting result is about confidence. Asked to estimate the chance they’d made an error in a sheet they had just finished building, participants gave a median answer of 10% and a mean of 18%. Eighty-six per cent of them had made one. The problem isn’t that spreadsheet errors are common; it’s that they’re silent. A wrong number renders identically to a right one, which is why “I’d have noticed” is not evidence, and why the defence has to be structural rather than attentional.
Where the discipline has to come from
The structure above solves the history problem completely. What it doesn’t solve is the part it depends on most.
Every rule in that build is one you enforce on yourself. Append rather than overwrite. Don’t edit a written row. Keep the schema frozen. Record the wrapper before you need it. None of it is checked by anything, and the file will let you type over March 2023 at any moment and look exactly the same afterwards.
That holds fine for a while. It holds less well in year five, on a Tuesday evening, with a figure that looks wrong and a four-second fix available.
This is the structural difference between a record kept by convention and one kept by construction. Where snapshots are stored as dated records, append-only stops being a rule you follow and becomes a property of how the data is held. There’s no cell to overwrite because nothing ever offers you one. A correction is an event with its own date rather than a silent replacement, so what you believed in March and what turned out to be true both survive.
Several of the spreadsheet’s awkward edges are downstream of that same distinction.
Blank and zero stop being ambiguous: a period either has a recorded value for an account or it doesn’t, and the convention you wrote in a cell somewhere becomes a fact about the data instead. Adding an account stops leaving history ragged, because an account exists from a date rather than needing a column stretched back across years it didn’t. Historical exchange rates stop being a formula you hand-roll, where a snapshot dated last March needs March’s rate and the built-in functions for fetching one are limited and inconsistent between Excel and Sheets. Entry stops depending on being at a desk. And backups stop being your problem, which matters because a file living in one place is one accident from gone.
That is the descriptive case for a purpose-built net worth tracker: not that spreadsheets are bad at arithmetic, which they plainly aren’t, but that the properties you were maintaining by hand become properties you can’t accidentally break. What’s given up is the arbitrary-formula freedom that made the spreadsheet worth using in the first place. That’s a real trade, not a rounding error, and which side of it you land on depends mostly on which of the two you’ll still be updating in five years.
What a continuous record makes answerable
The reason any of this matters is that a history changes the questions available to you.
A single current figure can be compared with one thing: somebody else’s single current figure. That’s most of why how the figure compares by age is the question people reach for first, and it’s a reasonable question. It’s also the only one a snapshot can support. A continuous series compares against itself, which opens a different class of question.
Extending a line forwards requires the line to exist. A projection built on four years of your own recorded figures describes your trajectory; one built on a single figure and an assumed growth rate describes the assumption. A target expressed as a number by a date is only measurable against a series, because with one observation there’s no rate of approach to measure. Which period did the pension actually move in, and what did the mortgage look like the month before the rate changed, are pivots you rebuild by hand in a spreadsheet and views over already-shaped data anywhere the history is stored properly. And a total that grew tells you less than knowing which of eleven lines grew, a decomposition that only exists if each line was recorded separately at each date.
None of these are exotic. They’re the ordinary questions people already ask about their own money, and they share one prerequisite: the past has to still be there.
If you do move
Carry the history first and treat everything else as replaceable.
Categories can be rebuilt in an afternoon and account names retyped. The dated series of values can’t be reconstructed from anything, which makes it the only genuinely irreplaceable thing in the file. Export it as a CSV in the observation-per-row shape, because date, account, value is the closest thing to a universal import format and survives contact with almost any destination, including the Verdly dashboard. Keep the original file rather than deleting it, and reconcile the imported total against your own last figure before trusting it. Import errors are silent in exactly the way spreadsheet errors are.
The layout outlives the tool
The framing this subject usually gets is spreadsheet against app, and it’s the wrong axis. What separates a record that’s useful in year five from one that isn’t is whether it was destructive or append-only on the day it was built. Software that lets you edit history is no better than a sheet that does, and a sheet built as a dated log beats most software. The other axis worth getting right is the interval, and how often you should check your net worth sets that from what the underlying assets can actually tell you.
What differs is who holds the rule. In a file, it’s you, every month, for as long as you keep it up. In a system built around dated records, it’s the storage. Both work. Only one of them keeps working on the evening you can’t be bothered.
The awkward part is that this gets decided before anyone knows it’s a decision. Nobody sits down to choose between a snapshot and a record. They copy a template, start typing, and find out four years later which one they built, usually at the moment they wanted the other.
