The first bank files it as Restaurants. The second calls it Entertainment. The third does not categorise card payments at all, so it arrives as Card payment and nothing else.

None of them is wrong. They were never trying to agree.

That is fine while you only have one account. The moment you have three, your eating-out total is not slightly off — it is unknowable, and nothing on screen tells you so. You are adding up three vocabularies as though they were one.

Every bank has its own opinion

A bank's categories exist for the bank. They are tuned to its own product analytics, its own merchant relationships, its own idea of what a customer looks like. They were never designed to be reconciled with another institution's, because no institution has ever needed to do that.

Two consequences follow, and both are structural rather than accidental.

The taxonomy stops at that bank's accounts. It cannot see the card you keep elsewhere, the crypto exchange, the brokerage — so it can never produce a total that means anything about your money as a whole, only about the part of it that happens to sit there.

And the taxonomy is not yours to keep. It lives in that bank's app. Close the account and the labels go with it; the history survives as amounts and dates with the meaning stripped out.

A mapping is one stored line

The fix is unglamorous. A mapping is a stored line between what the institution called a row and what you call it. Entertainment at that bank means Personal → Eating out in your books. Made once, kept against that institution, applied to every import afterwards.

That is the whole mechanism, and its value is entirely in the second half of the sentence. The first time you see a merchant you make a decision. The second time, and every time after, nobody asks you anything. An importer that does not accumulate your decisions costs the same amount of work every month forever, which is precisely the point at which people stop.

Merchant category codes do the boring majority automatically — the four-digit number the payment networks attach to card transactions, which is stable in a way merchant text never is. But an automatic guess is labelled as a guess and shown to you in its own pile, and it never overwrites a decision you made yourself. Your answer always wins.

Personal and business, on the same card

Categories here are settings, not code. Rename them, add your own, hide the ones you never use, split them the way your accounts actually need to be split.

Two expense trees ship by default — Personal and Work — and that single line at the top of the tree is what turns a spending chart into a profit-and-loss view. Below it, the sub-categories are yours to invent. Pet care and client entertainment are not in anybody's standard list, which is exactly why you should be able to add them.

The important case is the boring one: most people run personal and business spending through the same physical card. The bank sees one card and one stream. The mapping decides, row by row, which side of the line each purchase falls on — so the pet groomer and the contractor stop appearing in the same total.

A category does not say who

The part that has no equivalent at a bank at all.

A mapping carries more than a category. It can attach the person, the company or the project behind the row — so the same import that decides what kind of expense something was also decides who it involved.

Pay a car-painting service by card and it becomes an expense and the company that did the work. Tip a waiter or a barber and it becomes Eating out or Beauty and the person who received it. A card number already saved against somebody fills the counterparty in on its own, without being asked twice.

Your bank has a merchant string and a card number. There is no field for who, because a bank has no concept of your suppliers, your clients or your household. However good its categories become, it cannot tell you what one person or one company cost you this year, and it cannot tell you whether a project made money.

A bank categorises your spending for its own purposes and lends you the result. The categories were never yours, and they were never portable.

Why every consolidation attempt starts here

What a bank cannot do

Not an oversight it could fix in the next release — a consequence of what a bank is.

One lunch, three banks, three answers, and none of them yours. Everything else follows from fixing that.

That afternoon never comes. So the question stays unanswered for years, and every decision that depends on it — can we afford the deposit, should I take the lower-paid job, is the business actually carrying us — gets made on feel instead of on a number.

This guide is the afternoon, compressed. It covers what net worth is, why yours is genuinely harder to calculate than the personal-finance blogs admit, and a four-step method that works when your money is spread across several banks, more than one currency and at least one thing that is difficult to value.

What net worth actually is

Net worth is one subtraction: everything you own minus everything you owe. That is the whole definition. It is not your salary, not your savings rate, and not your bank balance.

Assets are anything that could be turned into money: current accounts, savings, cash, deposits, investments, crypto, property, the money a client owes you, the loan you made to your brother. Liabilities are anything you would have to pay back: mortgage, car finance, credit-card balances, tax owed but not yet paid, the money you owe a contractor.

The subtraction is trivial. Assembling the two lists honestly is the work.

Why yours is hard to calculate

Standard advice assumes one bank, one currency and one household. If that describes you, this takes ten minutes. Most people we talk to are in a messier position, and the mess is usually one of four kinds.

• The money is scattered. A salary account, a card you actually spend on, a savings account at a different bank, a brokerage, an exchange wallet, and physical cash. Six apps, six logins, six moments to forget one.
• More than one currency. Income in one, spending in another, savings in a third. Any total requires a conversion, and conversions are where honesty quietly leaks out.
• Personal and business are tangled. If you are a sole trader or run a small company, some of the money in your accounts is not really yours — it is tax, or it is float.
• Some things resist valuation. Property, an unlisted stake, a deposit you cannot touch for a year, an invoice that may or may not be paid.

The reason most people cannot state their net worth is not arithmetic. It is that nobody has ever written the list down in one place.

The actual problem

Step 1 — list every account, including the embarrassing ones

Open a blank page and write down every place money sits, including the ones with £14 in them and the ones you have been meaning to close. Completeness matters more than precision here: a forgotten account is a permanent error in every future number, whereas a balance that is a few pounds stale corrects itself next month.

For each account, note four things: what it is called, which currency it holds, roughly what is in it, and how quickly you could spend it. That last one is the field most people skip, and it is the one that makes the total useful rather than decorative.

Sort by liquidity, not by bank

A useful split is four buckets:

• High liquidity — spendable today. Current accounts, cash, instant-access savings.
• Medium — days to weeks. Brokerage holdings, most crypto, notice accounts.
• Low — months. Property, fixed-term deposits, private stakes.
• Frozen — money that is nominally yours but committed. Tax reserves, a deposit held by a landlord, funds locked until a maturity date.

Now you have two numbers instead of one: what you are worth, and what you could actually put your hands on this week. In our experience the second number is the one that stops people making bad decisions.

Step 2 — value the awkward things once, then leave them alone

Property, private stakes and anything without a live market price cause more abandoned net-worth spreadsheets than any other single factor, because people try to be exact and then give up.

Use a conservative figure you can defend, write down the date and the basis, and revisit it once a year. A flat valued at what a comparable one sold for last spring is fine. Precision here is false comfort — the number moves in ways you cannot observe anyway.

Money owed to you is an asset, but a discounted one. A client invoice 30 days overdue is not worth its face value. Track it at full value and flag the age, or haircut it — either is defensible, as long as you are consistent.

Step 3 — pick one currency, and store the rate you used

If you hold more than one currency you must choose a reporting currency. Usually that is the one you spend in, not the one you earn in.

Here is the part that goes wrong. If you convert your whole history at today's rate, then every time the rate moves, your past changes. Last January's net worth is different this morning than it was yesterday, which makes the trend line meaningless and quietly destroys your ability to tell whether you are making progress.

Store the rate that applied on the date of each snapshot, and convert historical figures at their historical rate. Today's total uses today's rate; January's total keeps January's. Your history stops moving.

Step 4 — choose a cadence you will actually keep

Monthly is right for most people. Weekly is noise unless you are actively trading; quarterly is too slow to catch a drift before it becomes a problem.

Pick a fixed day — the last day of the month is easiest to remember — and snapshot on that day whether or not the number is flattering. The value of the series comes entirely from its consistency. Six honest monthly points beat two years of sporadic optimistic ones.

How to read the number once you have it

A single net-worth figure tells you almost nothing. The second one tells you a lot. Once you have three or four, look for three things:

• Direction and slope. Is the line rising, and is it rising faster than inflation where you live?
• What is driving it. Growth from saving is repeatable. Growth from an asset revaluation is not — a rising portfolio can hide the fact that you have been spending more than you earn for four months.
• The liquidity mix. If the total is rising but the high-liquidity band is shrinking, you are getting richer and more fragile at the same time.

Spreadsheet or app

A spreadsheet is a genuinely good place to start and we will not pretend otherwise. It stops being good at a fairly predictable point.

The honest test: if you have not updated the spreadsheet in two months, the tool is not the problem you think it is — the friction of manual entry is. That is the specific friction Capital Wizard was built to remove.

It goes like this. You have savings in euros and dollars. You want one number, so you put today's EUR/USD rate in a cell and multiply the euro column by it. Clean, simple, and wrong in a way that only shows up months later — when you look at your trend line and cannot work out why it never seems to say anything.

The problem is that one rate cell is doing two different jobs, and only one of them is legitimate.

The two ways to convert, and only one is right

There are exactly two things you can do with a foreign-currency balance from January.

Convert it at the rate that applied in January. This tells you what that money was worth, in your reporting currency, at the moment you are describing. January's number is then a permanent fact. It will read the same in five years as it does now.

Convert it at today's rate. This tells you what January's balance would be worth if you held it today — which is a strange, hypothetical quantity that nobody actually wants, and which changes every time the market moves.

The second is the default in every spreadsheet, because a spreadsheet has one rate cell and multiplies everything by it. So your entire financial history silently re-prices itself every morning.

What today's-rate-everywhere does to a trend line

Here is the smallest example that shows the damage.

You hold €40,000 and $30,000, and you report in dollars. In January the rate was 1.0250; today it is 1.1400. Nothing moved in or out of either account all year.

• Converted at stored rates. January: €40,000 × 1.0250 = $41,000, plus $30,000 = $71,000. Today: €40,000 × 1.1400 = $45,600, plus $30,000 = $75,600. You are up $4,600.
• Converted at today's rate throughout. January: €40,000 × 1.1400 = $45,600, plus $30,000 = $75,600. Today: also $75,600. You are up nothing.

The euro leg genuinely gained $4,600 of dollar purchasing power this year. The second method erases it — not by rounding it away, but by retroactively pretending you always had it. And the error runs both ways: had the euro fallen, the same method would have invented a gain you never made, and it would have shown up in the month you were trying to evaluate a completely unrelated decision.

A financial history that changes overnight is not a history. It is a live re-rendering of the present, wearing dates.

Why the trend line never says anything

Which rate, exactly

Once you accept that you need a rate per date, the next question is which one — and here the honest answer is that it depends on what the number is for.

Mid-market rate on the date. The midpoint between buy and sell, the rate you see on a search engine. Right for valuing a balance you are holding. You are not selling those euros today; you just want a fair common unit.

The rate you actually got. Right for valuing a transaction. When you moved €5,000 and $5,340 arrived, your rate was 1.0680, whatever the mid-market said. That is not an approximation of the true rate — for that transfer it is the true rate, and the gap between it and mid-market is a real cost you paid.

Mixing these up is how people end up with a portfolio that quietly disagrees with their bank statements. Balances get the market's rate; movements get the rate the movement actually happened at.

Conversion loss is an expense, not a rounding error

Follow the money through a single transfer. €5,000 leaves one account. $5,340 arrives in another. If you record only those two lines, your books say you spent €5,000 and received $5,340, and the difference between what those two are "worth" has to go somewhere — usually into a mysterious drift that you correct by hand once a quarter.

It belongs in a third line. Value the outgoing leg at the mid-market rate for that day (€5,000 at 1.0850 = $5,425), compare it to what actually landed ($5,340), and the $85 difference is an expense with a name: conversion loss. Book it and three things become true at once. Both account balances reconcile exactly. Your annual total for "money lost to moving money" becomes a real, quotable figure. And your net worth stops drifting for reasons you cannot explain.

Capital Wizard books that third row automatically on every cross-currency transfer, because the alternative — a transfer that silently changes your net worth — is the single most common source of "the numbers don't add up" that we hear about.

Picking a reporting currency

You need one currency to think in. Two rules make the choice easy.

Choose the one you spend in, not the one you earn in. If you are paid in dollars and live in Poland, your financial position is a złoty question. "Can we afford this" is always asked in the currency of the thing you are buying.

Then leave it alone. Switching your reporting currency mid-history is the one operation that legitimately rewrites every past number, and after doing it once you will no longer trust any of them. If you genuinely need both views, keep both — but keep them as two full histories, each with its own stored rates, not as one history with a toggle.

What this costs you in each tool

None of this argues that you need software. It argues that you need one extra column — the rate, on the date — and the discipline to never overwrite it. A spreadsheet can do that perfectly well if you add the column now, while the history is short.

The reason it usually does not happen is that the column has to be filled in on the day, every day, forever, and the cost of forgetting is only discovered months later. That is precisely the sort of job worth handing to something that does not forget.

We have built importers for eight or so financial institutions now, across CSV, XLS, XLSX and PDF, in three languages and two alphabets. The interesting thing is how little variation there is in the problems. The formats differ wildly. The five decisions are always the same ones.

This is what they are, and what a good answer to each looks like — whether the tool doing the importing is ours, someone else's, or you and a spreadsheet on a Sunday.

The file is not a table

You would think a bank statement is rows and columns. Frequently it is not.

Real examples from real exports, all currently in production: a CSV encoded in Windows-1251 rather than UTF-8, so every Cyrillic name arrives as mojibake unless you detect the encoding before parsing. A file named .xls that is actually HTML with a table in it. An XLSX where the header row is row 4, because rows 1 to 3 are a logo, a title and the date range. A PDF certificate with the amounts right-aligned in a monospace column, where the only way to tell an amount from a balance is horizontal position on the page.

Then there is the column layout, which changes by institution, by product, and sometimes by the language you had selected when you clicked export. The same bank's personal and business exports may share no column names at all.

A statement importer is therefore not a CSV reader. It is a per-institution parser that knows the shape of that institution's export, plus a fallback for everything else. There is no clever generic solution here, and tools that promise one are usually asking you to map the columns yourself, every time.

Deciding what is the same transaction twice

This is the decision that separates tools you keep from tools you delete.

You import January. In February you import again, and — because the export dialogue defaulted to "last 90 days" — the file contains January as well. Naive import doubles your January. Do that once with three months of history and you have a mess whose only reliable fix is deleting everything and starting over.

So every row needs an identity that survives being re-imported. The good case is when the institution provides one: a document number, a reference, a transaction id. Store it, and re-importing becomes a no-op — you can pull the same file every day if you want.

The hard case is when it does not, which is common in personal-account exports. Then identity has to be synthesised from the row itself: timestamp, plus card or account, plus signed amount, plus the balance after the transaction. That last field is what makes the key trustworthy, because two genuinely separate coffees at 09:14 for the same amount will leave different running balances.

There is a subtler version of the same problem. Some of the rows in the file describe money movements you already entered by hand — the invoice payment you booked when the client told you it was sent, the transfer between your own accounts you recorded from both sides. The statement now carries the bank's version of an event you already have. A duplicate check based on the institution's own reference will not catch it, because your hand-entered row never had one.

That needs a second, looser match: same account, same signed amount, same currency, same day. One statement row may absorb at most one existing record. And when you confirm the match, the right move is to stamp the institution's reference onto the record you already had — so the next pull dedups it the fast, exact way.

An importer that never asks you anything is not cleverer than the others. It is making the same ambiguous decisions silently, and you will find out which ones about four months later.

On automation that will not admit uncertainty

Two rows, one event

Move money between your own accounts and both statements will show it. Import both and your records claim you spent the money and separately received it — a spending spike and an income spike in the same month, neither of which happened.

A transfer is one event with two legs, and it has to be stored that way: linked rows that share a group, excluded from spending and income totals, and — when the two legs are in different currencies — a third row for the conversion loss, so both balances reconcile without a fudge.

The awkward part is that an importer often cannot tell. "Payment to ACME LTD" might be a supplier you pay every month, or it might be your own company. The honest design is to require you to say so once, per counterparty, and remember the answer forever. Guessing a default here is how a tool ends up hiding real expenses inside "transfers", which is worse than asking.

Categorising on the right input

Most importers categorise by matching text in the description. It works about as well as you would expect for a field that contains SumUp *THE COFFEE, IZ *COFFEE LDN, and PAYPAL *COFFEEROASTE.

There is a better input sitting unused in most statements. Card transactions carry a merchant category code — a four-digit number the payment networks assign to the merchant. 5812 is eating places. 5411 is grocery stores. 4121 is taxis. It is assigned by the acquiring institution, not by the merchant's marketing department, and it does not change when they rebrand.

Rules built on merchant codes hold up over time in a way that text rules do not. Text matching still has a job — for bank-side operations that carry no code, and for the specific merchants you want split out from their category — but it should be the second input, not the first.

The rows you never want to see again

Every account has recurring rows that are noise: an internal sweep, a card-verification hold, a fee already accounted for elsewhere. A good importer lets you mark one and never asks again — the decision keyed to the row's identity, so it survives re-imports without hiding anything that merely looks similar.

The same applies to every other correction you make during an import. If you tell the tool that this counterparty is a transfer, or that this description means that subtype, that answer should be the last time you are asked. An importer that does not accumulate your decisions is one that costs the same amount of work every single month, forever — which is exactly the point at which people go back to not tracking anything.

What to look for

The test for any importer is not the first run. It is the fourth. If month four takes as long as month one, the tool is not learning, and no amount of automation elsewhere will make up for it.

Then the quarterly tax bill arrives, a supplier invoices for work you had forgotten was subcontracted, and the balance is back where it was. Nothing went wrong. The money was never yours. You just had no way of seeing that at the moment you were looking at it.

This is not a discipline problem, and it is not solved by being more careful. It is a measurement problem. A single balance is being asked to represent three completely different kinds of money, and it cannot.

Three kinds of money, one number

Take the balance in your business account and split it into three parts.

Money that is yours. Profit already earned on work already delivered, with the tax on it already set aside. You can spend this. In most small businesses it is a much smaller fraction of the balance than people expect.

Money that is held for someone else. Tax not yet due but already incurred — income tax, corporation tax, VAT or its local equivalent, payroll contributions. It is sitting in your account, it is spendable in the mechanical sense, and it is not yours. Depending on the country and the quarter, this is routinely 20–40% of what you are looking at.

Money that is float. A deposit for a project not started. A retainer covering work through November. Payment for a job where you still have to pay two subcontractors. This is revenue you have collected and obligation you have not yet discharged, and the gap between the two is where small businesses most often mistake cash flow for profit.

Every business that failed while profitable failed for the same reason: it spent money it was holding on behalf of someone else, and only found out at the deadline.

The oldest small-business failure mode

Why "I'll work it out at year end" fails

The year-end reckoning is not wrong. It is just far too late to be a decision tool.

Every meaningful choice a small business makes happens mid-year: whether to hire, whether to buy the equipment, whether to take the badly-paid project because January looks thin, whether to take money out. All of them need to know what is actually yours this week. An accountant's report in April tells you what was true last year, which is a compliance document, not a steering instrument.

The gap is worse the more variable your income is. Somebody on a salary can safely use their bank balance as a proxy for their position, because the corrections are small and regular. Somebody invoicing four clients on irregular terms cannot: their balance is a random walk over a real position that moves much more slowly, and reading the balance as the position means being alternately overconfident and panicked, both at the wrong times.

Doing it without a bookkeeping course

The full accounting answer is accrual bookkeeping, and if your business is big enough to justify it, do that. Below that size there is a version that takes about twenty minutes to set up and captures most of the value.

Separate the accounts, not just the records. One account for business income and expenses, one for personal. Not because the records cannot handle mixing — they can — but because a shared account makes every single transaction a decision, and a hundred small decisions a month is what makes people stop.

Move tax out on receipt, not at the deadline. When money lands, immediately move your tax percentage to a separate reserve account. Get the percentage roughly right and never touch it. This one habit does more than any software: it converts an invisible liability into a visible balance you cannot accidentally spend.

Pay yourself a fixed amount, on a date. Owner's draw as a scheduled transfer rather than a series of discretionary raids. Your personal budget then has a stable income, which is the thing that makes personal planning possible at all, and the business absorbs the variance — which is what a business is for.

Book the float as an obligation the day you receive it. A deposit is not income. Record it as money received against something you owe, and let it turn into income when the work is done.

Separate accounts, or separate books?

Once the accounts are split, the records question follows: do the business and personal numbers live in one place or two?

The argument for one is that the boundary is porous. You draw money out, you occasionally pay a business expense from a personal card, you want a household picture that includes what the business owes you. Keeping them together makes those links easy and the net-worth number complete.

The argument for two is that the two sets of numbers answer different questions and want different shapes. A business wants income and expenses by category and by project, invoices outstanding, and a margin. A household wants net worth, liquidity and spending. Forcing both into one view makes each of them worse, and it also means an accountant or a business partner sees your personal balances, which is usually not what you want.

Our answer in Capital Wizard is separate spaces under one login: independent sets of records, switchable in a click, with the option to give someone access to one and not the other. A business space starts configured for the business question — income, expenses, projects, invoices — and a personal one starts configured for net worth. Whichever tool you use, the property to look for is exactly that: separation of the data with a single door, rather than two logins or one merged pile.

What each approach actually costs

The one-sentence version: your bank balance is not a number about you, it is a number about several parties at once, and the only way to make it useful is to say which parts belong to whom before you look at it rather than after.

You covered the deposit on the flat and your flatmate is paying you back in pieces. A client paid a retainer in March that is being drawn down against work. Your brother borrowed money in a bad month two years ago and neither of you has mentioned it since. A contractor invoiced for more than you agreed, you paid the agreed amount, and the difference is technically still open.

None of these are disputes. They are ordinary, and they go wrong in the same way: two people carry slightly different mental balances, nobody wants to be the one who brings it up, and after a year the difference between the two versions is larger than either party's confidence in their own.

The fix is unglamorous. It is a running balance per person, updated when money moves, visible to whoever needs to see it.

When a running balance is the right shape

Not every relationship needs one. Three situations genuinely do.

Ongoing informal debt. Money lent to family, a shared deposit, one person always paying for the group. The amounts are usually small enough that nobody writes a contract and large enough that people remember them wrong.

Retainers and deposits. A client pays $6,000 up front and you bill against it. At any moment there is a real number — how much of their money you are still holding — and both sides need to agree on it. This is where "I thought that was covered by the retainer" comes from.

Recurring trade with a counterparty. A subcontractor you work with monthly, a supplier on account, a landlord with a deposit. Individual invoices come and go; what matters between you is the net position.

In all three, the useful object is not a list of transactions. It is a balance with a sign.

A transaction list is not a balance

You can, in principle, reconstruct what someone owes you by filtering your records to that person and adding up the amounts. In practice this fails for a reason that is easy to miss: not every transaction with a person changes what they owe you.

Say a client owes you $3,000 and pays it. Money arrives, and you now have income of $3,000 and a balance that has gone to zero. Both facts are true, and they are different facts. Now say the same client pays you $3,000 as a deposit on next quarter's work. Identical bank row, identical amount — but this time you owe them $3,000 of work, and the balance moves the other way.

The bank cannot tell these apart. Nothing in the transaction itself distinguishes them. The only thing that does is your intent at the moment you record it, which means the tool has to ask, and you have to answer.

Two identical rows, same client, same amount. One means they no longer owe you anything; the other means you now owe them a quarter of work. Nothing in the transaction can tell you which.

Why the tool has to ask

So each transaction involving a counterparty needs one extra field, with three possible values:

• Deposit — this increases what you are holding for them, or reduces what they owe you.
• Charge — this increases what they owe you.
• Neither — a plain sale, settled on the spot, with no standing position either way.

Three options, one click, at the moment you have the context. Getting this field is the entire difference between a person's balance that is trustworthy and one that is a rough guess derived from a filtered list.

The sign convention that decides everything

Pick one and write it down, because half the confusion in this area is two people using opposite conventions without realising it.

The one we use: positive means they are ahead of you — you are holding their money, or you owe them. Negative means you are ahead — they owe you. It reads naturally from the counterparty's point of view, which is the view you will be in when you are talking to them.

The opposite convention is equally defensible, and mixing the two within one set of records is how you end up confidently telling someone they owe you money that you in fact owe them. Choose, be consistent, and label the number in words as well as sign wherever it appears.

When one balance per person is not enough

Sometimes a single running total genuinely cannot express the relationship.

A contractor might have an ordinary invoice balance and a separate equipment advance that is being repaid over six months. Netting them into one number destroys real information — the advance is being repaid on a schedule and the invoices are not, and combining them makes both untrackable.

The general answer is named side balances: a main balance plus, where needed, additional named ledgers under the same person, each with its own running total, each summing into the overall position. "Main" plus "Equipment advance" plus, for people you employ by the hour, an accrual ledger where unbilled time accumulates before it becomes an invoice.

The rule for when to create one: split into a separate ledger when the two balances would be settled by different events. An invoice balance clears when they pay an invoice; the advance clears on its own schedule. Different clearing events, different ledgers. Same clearing event, one balance.

The currency trap

If you lend €2,000 and are repaid in dollars, what were you repaid?

There is no universally correct answer, only a choice you have to make explicitly. Either the debt is denominated in euros — in which case a dollar repayment is a conversion, and the rate on the repayment day determines whether it settled fully — or the debt is denominated in dollars at the rate on the day you lent it, in which case the euro figure was only ever a description.

Say which, in writing, at the moment the debt is created. It costs one sentence then and prevents an unpleasant conversation later, because in the absence of an agreement both parties will remember whichever interpretation favours them, entirely honestly.

For this reason accrual balances in Capital Wizard are held per currency rather than converted into one figure: a person can be owed 1,400 EUR and 900 USD, and those stay two facts. Converting them into a single number would make the display tidier and the underlying position less true.

What this replaces

The reason to do any of this is not distrust. It is the opposite: a written balance is what lets you stop keeping score in your head, which is the part of an informal debt that quietly costs a relationship something. Once the number exists somewhere neutral, neither of you has to be the one who remembers it.

But an invoice is not money. It is a claim on money, and the distance between the two is where small businesses lose both cash and time. Ask any freelancer what their annual revenue was and they can tell you within a few hundred. Ask what they were paid, in cash, in the bank, after everything — and the answer takes a week to assemble, if it can be assembled at all.

The gap has four causes, and none of them is a client refusing to pay.

Why "paid" is not a checkbox

Consider an invoice for $4,000. The following are all things that routinely happen to it:

• The client pays $2,000 now and $2,000 in six weeks.
• The client pays $3,960, because their bank took $40 in correspondent charges.
• The client pays in euros, and after conversion $3,987 arrives.
• The client pays $4,000, but you had agreed a 2% early-settlement discount, so $80 of it is arriving as a credit against the next one.
• The client pays $3,600 and, after two months of chasing, you agree to call it settled.

In every case a paid/unpaid flag forces a lie. Tick it and your records claim you received $4,000, which contradicts your bank. Leave it unticked and an invoice that is functionally closed sits in your outstanding list forever, polluting every report that depends on it.

The correct model is that an invoice's status is computed, never typed. It has a total, and it accumulates two kinds of things against it: cash that arrived, and non-cash amounts that close the gap. When those add up to the total, it is settled. Until then it is partially settled, by a specific amount, and the outstanding figure is a fact rather than an opinion.

One payment, several invoices

The second thing a checkbox cannot handle is the client who pays three invoices with one transfer. It is extremely common, and it breaks naive systems in both directions: either the payment gets attached to one invoice and the other two stay open, or someone edits the amounts to make things line up and the records stop matching the bank.

What is needed is an allocation: a link between a payment and an invoice, carrying its own amount. One payment can allocate across many invoices; one invoice can receive many allocations. The payment keeps its true bank amount; the invoices each receive their share; nothing is edited to make it fit.

This is standard practice in accounting — it is called cash application — and it is the single most useful idea to steal from proper bookkeeping if you are running a small operation without it. It is also what makes the awkward cases tractable: an overpayment leaves an unallocated remainder that you can carry to the next invoice, rather than an amount you have to reconcile by hand.

The gap that is not a payment

The residue after all cash has arrived needs somewhere to go, and it is not a payment. Give each of these a name, because the annual totals are worth knowing:

Bank and correspondent charges. Deducted in transit, especially on international transfers. Small individually. Across a year of cross-border invoicing they are frequently a four-figure number that nobody has ever added up.

Exchange differences. You invoiced in one currency, were paid in another, and the rate moved between issue and settlement. This is not a fee and not a loss of business — it is FX, and grouping it with charges hides both.

Discounts. Early settlement, a goodwill reduction, a rounding-down at the client's request. Deliberate, and worth tracking separately so you can see what your discounting actually costs.

Write-offs. The amount you decided to stop pursuing. Nobody enjoys recording these, which is exactly why they should be a named category — an untracked write-off is indistinguishable from an invoice you forgot about, and the two require completely different responses.

Four categories, all closing the same gap, each answering a different question at year end. In Capital Wizard these are invoice adjustments, sitting alongside allocations, and both feed the same computed status.

Revenue is what you agreed. Cash is what arrived. The difference is not an error — it is a number, and it deserves a category.

What a settled invoice actually looks like

Ageing is the only report that changes behaviour

Every invoicing system produces an ageing report: outstanding amounts bucketed by how overdue they are — current, 1–30 days, 31–60, 61–90, over 90. It is the plainest report in accounting and the only one that reliably changes what people do.

The reason is that overdue debt does not decay gracefully. Recovery rates fall sharply with age, and by the time something is a year old it is usually a conversation about how much you are prepared to write off. Ageing makes that visible while it is still cheap to act on.

A practical routine that costs about ten minutes a month:

1. Look at the buckets, not the total. A rising total with everything current is growth. A flat total with mass moving right is a problem.
2. Anything over 30 days gets a friendly, specific chase. Attach the invoice again. Most late payment is administrative, not adversarial — an invoice that landed in the wrong inbox or missed a payment run.
3. Anything over 60 days gets a person, not an email. A phone call to the individual who signs off payments, not a reply on the original thread.
4. Anything over 120 days gets a decision. Escalate, settle for part, or write it off and stop spending attention on it. Leaving it open is the one option that costs you every month and never resolves.

What each approach can represent

The point of all this is not bookkeeping neatness. It is that "we invoiced $180,000 last year" and "$171,400 arrived" are different sentences, and only one of them describes what you can actually spend. Most small businesses can say the first with confidence. The second is the one that pays the rent.

The number that is missing is the largest one. In any people-based business, labour is 60–80% of the cost of delivery, and it does not appear on a bank statement in a form that can be attributed to a project. Salaries leave your account in one monthly lump. Your own time leaves no trace at all.

So the profitability question gets answered with the only data that is easy to get, and the answer is systematically wrong in one direction: every project looks better than it was, and the worst ones look best of all, because the projects that consumed the most unbilled hours are exactly the ones whose costs are least visible.

Revenue is easy. Cost is where projects hide.

Project cost comes in three layers, in descending order of how often they are tracked.

Direct external costs. Subcontractors, licences, hosting, travel. These are on a statement with a supplier name, and most people capture them. This is the layer everyone does.

Labour. The hours your team and you spent, valued at what those hours cost the business. This is the big one, and it is missing from most small-company records entirely — not because anyone decided to omit it, but because there is no document that reports it.

Overhead. Rent, tools, admin time, the accountant, the half of the year that anyone spends on things that are not billable. Real, and much harder to attribute.

You can build a genuinely useful picture with the first two and a crude version of the third. What you cannot do is skip the second, because it is the layer where projects differ most.

The two rates

The mechanism that makes labour trackable is simple, and it is the standard model in staff augmentation and agency work: every person has two hourly rates.

The cost rate is what an hour of that person costs the business. Salary plus employer contributions plus benefits, divided by realistically available hours — not 2,080 a year, but something closer to 1,600 once holiday, sick leave, training and the general friction of employment are removed. Using the full-year figure understates the cost of every hour by roughly a quarter.

The bill rate is what you charge a client for that hour.

Once both exist, a time entry stops being a timesheet row and becomes two numbers: a cost to you and a value to the client. The difference, summed across a project, is your labour margin, and it is available continuously rather than at the end.

Rates change — people get raises, and you reprice clients. So a rate needs a date range, and a time entry must be valued at the rate in effect on the day it was logged. Applying today's rate to last year's hours produces the same class of error as converting your financial history at today's exchange rate: the past moves, and comparisons across time stop meaning anything.

A crude overhead loading beats none

Overhead attribution is where people give up, because doing it properly requires cost accounting that a ten-person company has no business attempting.

The pragmatic version: take last year's total overhead, divide by last year's total billable hours, and you have an overhead cost per billable hour. Add it to each person's cost rate. Recalculate annually. It is approximate, it treats an expensive person and a cheap one as carrying the same overhead, and it is enormously better than zero — because zero is not neutral, it is a claim that overhead is free, and it always flatters the projects that took longest.

Utilisation is not profitability

Two metrics get confused constantly, and treating them as the same thing is how a fully-booked business goes broke.

Utilisation is the share of available hours that were billable. It measures how busy you are.

Realisation is the share of billable hours that were actually invoiced and paid. It measures whether being busy turned into money.

A team at 90% utilisation and 65% realisation is working flat out and giving away a third of it — in scope creep, in rework, in hours written off at invoicing time because nobody wanted the conversation. That gap is invisible unless the hours are logged whether or not they get billed, which is the single most important rule in time tracking and the one most often broken. Log the hour that you know you will not bill. It is the only record you will ever have of what that client actually costs.

A project that came in at twice the estimate and was invoiced at the estimate did not "go slightly over". It halved its own margin, and nothing in your accounts will ever say so.

The cost of unlogged hours

Four questions worth being able to answer

Everything above exists to make these answerable in under a minute:

• Margin by project. Which work was actually worth doing. Expect a wider spread than you assume — a common shape is that the top two or three projects earn nearly all the profit and one or two are loss-making.
• Margin by client, across projects. More useful than per-project, because clients are consistent: the one who was difficult last time will be difficult again.
• Estimate versus actual hours. Your estimating error, per project type. Knowing you run 40% over on a particular kind of work is worth more than any pricing model.
• Revenue per available hour. The one number that combines rate, utilisation and realisation. If it is flat while you are getting busier, growth is costing you money.

What each level of tracking can tell you

None of this requires an ERP. It requires that hours get logged against a project, that people have a cost rate with dates on it, and that the arithmetic happens somewhere other than in a spreadsheet rebuilt each quarter. That is roughly a week of setup and a few minutes a day — and it is the difference between having opinions about which clients are worth keeping and having evidence.

The reason is not laziness and it is not volatility. It is that a crypto position quietly violates three assumptions that every other kind of record-keeping depends on: that money and assets are different things, that a trade has a price in your own currency, and that a balance shown by an institution is a balance you have.

Get those three straight and the rest is ordinary bookkeeping.

A stablecoin is not an investment

The first and most consequential decision: treat stablecoins as cash, and everything else as an asset.

If you hold 12,000 USDT, that is not a portfolio position with a price to track. It is a dollar balance in an unusual account. Modelling it as an investment produces a portfolio full of holdings whose value never moves, a "return" line that is permanently zero, and an allocation chart in which your cash is competing for space with your actual bets.

Modelled as cash, it behaves correctly everywhere: it is spendable, it counts toward liquidity, it belongs in the high-liquidity band of your net worth, and buying a coin with it is a purchase rather than a swap.

The same logic applies to the exchange itself. An exchange account holding several stablecoins and several coins is not one thing — it is a cash account and a set of asset positions that happen to live behind the same login. Splitting it that way is the single change that makes the rest of this tractable.

A coin-for-coin trade is two events

Here is the thing that breaks most people's records.

You swap 0.5 ETH for 0.017 BTC. No dollars are involved. No money enters or leaves. It feels like one action — a rebalance, a shuffle within the same pot — and the natural instinct is to record it as a transfer.

It is not a transfer. It is a sale of ETH followed by a purchase of BTC, and the two need a price. If you record it as a transfer, you carry your ETH cost basis onto a BTC position, and from that moment your records are describing a holding you never bought at a price you never paid.

The price to use is the one implied by the trade itself, denominated in the coin you gave up. You disposed of 0.5 ETH — value that at the ETH price at the moment of the trade, and that value is simultaneously the proceeds of the sale and the cost of the purchase. The two legs balance exactly, which is what makes it auditable.

Denominating from the outgoing side rather than the incoming one matters when the two exchange prices disagree slightly, which they routinely do. Pick the outgoing leg as the source of truth and every swap produces exactly one defensible number.

Which price is the price?

At any moment a coin has several prices: slightly different on each exchange, different again on aggregator indices, and different once more in the order book at the size you would actually trade.

For valuing a holding, use a broad reference price — an index or a large-venue price — and use the same source consistently. Consistency matters more than which one you pick, because a portfolio valued on a rotating cast of sources produces movements that are partly real and partly source noise, and you cannot tell them apart.

For recording a transaction, use the price you actually got. Same rule as foreign exchange: balances get the market's price, movements get yours.

There is an unglamorous engineering reality behind this. Price providers rate-limit, go down, and disagree about ticker symbols. A portfolio that silently shows yesterday's price as today's is worse than one that says it could not fetch a price, because the first is invisible. We ended up running a provider chain — a primary, then two fallbacks — with a shared cache and an explicit stale marker, after a stretch where a single provider's per-minute limit meant some assets simply never updated. If you are assembling this yourself from an API, assume the API will fail and decide now what the failure should look like.

Never invent a holding

When you import an exchange's trade history you will find gaps. A coin was deposited from a wallet you no longer use, an old trade predates the export window, a chunk arrived from a bridge. The trade history says you hold 0.41 BTC; the arithmetic of the imported trades says 0.33.

There are two ways to close a gap like that, and only one is honest. The wrong way is to synthesise a purchase — invent an opening trade at some plausible historical price so the numbers reconcile. It works instantly and it permanently contaminates your cost basis with a number nobody ever paid.

The right way is to report the discrepancy and make you resolve it: state what you actually paid, or explicitly record it as an opening balance with an unknown basis. It is more friction, and it is the difference between records you can rely on and records that merely add up. Capital Wizard reports the gap; it will not fill it in for you.

A reconciliation that always succeeds is not checking anything.

The rule that applies well beyond crypto

An unrealised gain is not income

A position that has doubled is worth more. It has not paid you anything.

This distinction is obvious stated plainly and remarkably easy to lose in a records system where everything is denominated in one currency and summed. Keep unrealised movement out of your income and expense totals entirely — it belongs to the asset, as a revaluation. Otherwise a good quarter in the market shows up as if you had earned it, your savings rate looks excellent, and you conclude that your spending is under control at exactly the moment it is not.

The same applies in reverse, and worse: a bad quarter makes a perfectly healthy income look like a loss, and people make cuts they did not need to make.

Tax treatment of all of this varies enormously by country — swaps are taxable events in some places and not others, and none of this is tax advice. But the record-keeping principle holds regardless of jurisdiction: a swap needs a price, a valuation is not a receipt, and your accountant will need the first far more than the second.

The short version

None of this is specific to crypto, which is the point. These are the same rules that apply to a brokerage account or a foreign currency balance; crypto just breaks them all at once, quickly enough that the damage shows up within a year rather than a decade.

The standard diagnosis is that the user gave up. The more accurate one is that the category set was never capable of producing an insight, so the effort of maintaining it earned nothing and stopped.

A category is not a filing system. It is a question you intend to ask about your money, written down in advance. If you cannot say what you would do differently depending on the answer, the category is decoration.

The test a category has to pass

Before creating one, finish this sentence: "If this doubled next month, I would ______."

• Groceries doubled → I would look at whether we are shopping differently, or whether prices moved. Actionable. Keep.
• Rent doubled → I would move, eventually, but nothing changes this month. Worth tracking as a committed cost, not worth reviewing monthly.
• Subscriptions doubled → I would find out which one and cancel something. Sharply actionable, and specific enough to act on within ten minutes. Keep.
• "Shopping" doubled → I would... look at the list of transactions to find out what it actually was. That category did no work. Its only function was to defer the question.

That last case is the one to watch for. Any category whose answer is "I would need to look at the individual transactions" is not a category — it is a folder, and you would have been equally well served by the search box.

Too many is the usual failure

There is an intuition that finer categories mean better information. In practice the opposite holds, for two reasons.

The first is statistical. Split spending finely enough and every category becomes small enough that ordinary variation swamps any trend. Coffee was $61 last month and $38 this month. Is that a change in behaviour or a month with a bank holiday in it? At that granularity you cannot tell, and a metric you cannot interpret is one you eventually stop reading.

The second is human. Every additional category is another decision at entry time, and the marginal ones are always ambiguous — is a work lunch Food or Business? Is a train to see family Transport or Family? Ambiguity is what fills the Miscellaneous bucket, because when the choice is unclear the fastest path is the catch-all.

The workable number for most households is eight to twelve top-level categories, with subcategories only where you have a specific recurring question. Twelve categories that are always filled in beat forty that are half-guessed.

The split that actually predicts behaviour

Beneath your categories, add one more dimension that most tools omit: how fast can this change?

Committed. Rent or mortgage, insurance, loan payments, school fees. Contractually fixed for months. You cannot alter these in response to a bad quarter, and reviewing them monthly is wasted attention — they get looked at once a year, on renewal.

Variable necessary. Groceries, fuel, utilities, childcare. You must spend something; the amount is influenced by behaviour and by prices. This is where a monthly review is genuinely worth doing, because it is the only band where attention changes the number.

Discretionary. Meals out, subscriptions, travel, things. Cuttable within a month if needed.

Two useful numbers fall out immediately. The proportion of income that is committed tells you how much shock your household can absorb — above roughly 55% and a bad month becomes an emergency rather than an inconvenience. And the discretionary total tells you what is genuinely available if income stops, which is a completely different figure from the total spending everyone quotes.

This split is also the one that survives contact with a real decision. When people actually need to cut, they do not cut "by category" — they cut the discretionary band and renegotiate the committed one, in that order.

A category set that cannot tell you what happens if your income stops for three months is a filing system, not a financial tool.

The question every budget is secretly about

Let the merchant code do the boring 80%

Most tools categorise by matching words in the transaction description. That field is a mess: the same coffee shop appears as SQ *THE COFFEE, IZ *COFFEE LDN and PAYPAL *COFFEEROAS, depending on which payment processor was in the middle.

Meanwhile, card transactions already carry a much better field that almost nothing uses: the merchant category code, a four-digit number assigned by the payment networks. 5812 is eating places. 5411 is groceries. 4121 is taxis and rideshare. 5541 is fuel. It is assigned by the acquiring institution to the merchant's business type, and it does not change when they rebrand, switch processors or get acquired.

Rules built on codes are stable in a way that text rules never are. Map codes to your categories once and the great majority of card spending files itself correctly and keeps doing so, including at merchants you have never visited before — which is the case text rules can never handle, because you cannot write a rule for a shop you do not yet know exists.

Where text rules still earn their place

Merchant codes handle card spending. They do not exist for bank-side operations — transfers, standing orders, fees, salary, tax payments — which arrive with a description and nothing else. That is exactly where text rules are strong, because those descriptions are machine-generated and stable: the same reference every month, for years.

So the sensible arrangement is layered. Merchant code first, where one exists. Text rules second, for bank operations and for the specific merchants you want split out of their code's default. Manual assignment last, and — this is the part that matters — every manual assignment you make should be offered as a rule so that you never make the same one twice.

What to do with the Miscellaneous pile

Delete it. Not the transactions — the category.

Miscellaneous is not a category, it is a queue that nobody processes. Its existence removes the pressure that would otherwise force you to either create a real category or admit that the spending belongs in one you already have. Every tool that ships with an "Other" bucket ends up with 15–20% of spending in it, which is enough to invalidate every proportion you might calculate from the rest.

If a transaction genuinely does not fit, that is information: either it is a one-off, in which case put it in the closest real category and move on, or it is the first of a recurring pattern, in which case name the pattern now while you still remember what it was.

What this looks like in practice

The goal is not a beautiful pie chart. It is to be able to answer, in about ninety seconds, what happens to your household if income stops for a quarter — and to know which specific line you would reach for first.

This is not a criticism of either of them. Specialisation is efficient, and most couples arrive at it without discussing it. The problem is narrower than "you should both be involved", and it is this: the arrangement has a single point of failure, and the failure mode is not hypothetical. Illness, a work trip during a payment deadline, a phone lost abroad, a bereavement. The moment the arrangement is tested is the moment the person who holds it is unavailable, by definition.

The usual response — "I should really write it all down" — never happens, because writing it all down is a two-hour job with no immediate payoff. What does work is smaller and structural.

The point is not fairness, it is redundancy

Shared visibility is often framed as a fairness question, and that framing is why it stalls. It becomes a conversation about trust and control, which is a hard conversation, and hard conversations get postponed.

Reframed as redundancy, it is much easier: if one of us cannot get to a phone for two weeks, can the other one keep the household running without ringing four institutions and guessing at passwords? That question has no emotional charge, has an obvious right answer, and can be solved in an afternoon.

The practical minimum for redundancy is short:

• Where the money is. Which institutions, which accounts, what each one is for. Not balances to the penny — the list.
• What leaves automatically, and when. Rent or mortgage, insurance, utilities, subscriptions, loan payments. Specifically, which account each one leaves from.
• What is owed, and to whom. Cards, loans, tax due. The uncomfortable one, and the one most often held by exactly one person.
• How to get in. Not a shared password — see below — but a documented path: which accounts exist, and how access would be recovered.

If both people can answer those four, the household is resilient. Everything past that is optional.

Three models, three different things to share

Couples arrange money in one of three ways, and each needs a different sharing setup. Trying to apply one model's answer to another is where most household finance tools become annoying.

Fully joint. One pot, both names, everything shared. Sharing is easy — the question is only whether both people actually look. In this model the risk is not access, it is that one person still does all the work and the other has a login they have never used.

Fully separate. Two independent sets of finances, expenses split by agreement. Here the shared object is small and specific: the split, what each has paid, and who is behind. Sharing everything is neither wanted nor necessary; sharing nothing means arguing from memory about who paid for the boiler.

Hybrid — the most common by far. Joint account for shared costs, individual accounts for everything else. The shared object is the joint pot plus each person's contributions to it, and the private object is each person's own money. A tool that cannot represent "shared" and "mine" as different things will be fought with constantly by anyone in this model.

Visibility and control are different permissions

A great deal of household friction comes from conflating two things that a good setup keeps apart.

Visibility is being able to see the position: balances, what is coming out, what is owed. It is what redundancy requires, and it is almost never the thing anyone actually objects to.

Control is being able to move money and change arrangements. It is a separate question with separate answers, and for some households — where one person has a compulsive spending problem, or where the money is genuinely one person's from before the relationship — visibility without control is precisely the right arrangement.

Most tools offer only "shared" or "not shared", which forces households into an all-or-nothing choice they did not want to make. When you can grant sight of a set of records without granting authority over the accounts behind them, the conversation gets much easier, because the ask is smaller.

Why sharing a password is the wrong mechanism

It is the default because it is the only thing that always works, and it is worth being explicit about what it costs.

A shared credential cannot be scoped — the person you gave it to sees everything, including the things you would not have chosen to share. It cannot be revoked without changing it and re-distributing it to everyone else who legitimately had it. It produces no record of who did what, which means an unexplained change has no author. It usually breaks two-factor authentication, or forces you to disable it. And it survives the relationship: people are still logged into ex-partners' accounts years later, not maliciously, just because nobody ever went through the list.

Separate accounts with granted access fix all five. Each person has their own login and their own second factor. Access is scoped to what you chose. Removing it is one action, immediately effective, with no effect on anyone else.

The test of a sharing arrangement is not how easily you can grant access. It is how easily you can withdraw it, on a bad day, without breaking anything else.

What to actually check before you set it up

The afternoon that makes it work

Concretely, for a household starting from nothing:

1. Write the list of accounts together. Every institution, what it is for, whose name is on it. Half an hour, and it is the single highest-value artefact in this entire article. Most people discover at least one forgotten account doing this.
2. Decide the model. Joint, separate, or hybrid — say it out loud, because a surprising number of couples have never confirmed that they are both assuming the same one.
3. Set up scoped access rather than shared credentials. A shared household view both people can reach with their own login; private things stay private.
4. Agree what happens if one of you is unavailable for a month. Who pays what, from where. Ten minutes, and it is the whole point of the exercise.
5. Put fifteen minutes in the calendar, monthly. Both of you, same time, look at the same screen. Not a budget meeting — a look. The value is that neither of you is ever surprised.

Step five is the one that gets dropped and the one that does the work. Everything else is setup; the monthly fifteen minutes is what keeps two people holding the same picture.

What each arrangement actually gives you

None of this requires a particular product — a shared folder and a written list gets you most of the redundancy. What it does require is deciding that the current arrangement, where one person is a single point of failure and the fallback is a password on a note, is a choice rather than the natural order of things.

Month one is enthusiastic — the accounts get set up, the history gets entered, everything reconciles. Month two is dutiful. Month three has a deadline in it, the review gets skipped, and by month four there is a backlog. A backlog converts a routine into a project, and projects get scheduled for a quieter week that does not arrive.

The failure is not discipline. It is that the review was designed as an audit, and audits are the wrong shape for something that has to happen twelve times a year forever. A routine that survives has to be short enough to do on a bad day, ordered so the valuable parts happen first, and specific enough that you never have to decide what to do next.

This is the version we use. It takes about eleven minutes and it is deliberately incomplete.

Why monthly, and why the same day

Weekly is noise. Most of what moves in a week is timing — when a salary landed relative to when the rent left. You will react to variation that is not signal, and reacting to noise is worse than not looking, because it produces changes that then have to be undone.

Quarterly is too slow. A drift takes about two months to become visible and about four to become expensive. A quarterly cadence reliably catches things one quarter after the point where acting would have been cheap.

Fix the day. Last day of the month, or the first Sunday — it matters far less which than that it is the same one every time. A fixed date removes the decision about when, which is the decision that actually kills routines. And a consistent snapshot date is what makes your history comparable: month-ends measured on wandering dates produce a series where some intervals contain two salary payments and some contain none.

Do it whether or not the number is going to be good. A series that only contains the months you felt like looking is worse than no series, because it will show a smooth upward trend regardless of what actually happened.

The eleven minutes, in order

The order matters more than the content. The first two steps are maintenance and must come first, because skipping them is what creates the backlog that ends the habit. The last three are the actual thinking.

1. Reconcile the balances — 3 minutes. Open each account, compare its real balance to what your records say. Not the transactions, just the closing number. If they match, you are done with that account in four seconds. If they do not, you have found the month's error while it is still one month old and therefore findable. This is the least interesting step and the one that keeps everything else trustworthy.

2. Clear the exceptions — 3 minutes. Whatever needs a decision: uncategorised transactions, imported rows that might be duplicates, a transfer that needs confirming. The rule is to empty the queue, not to do it well. A transaction in roughly the right category today beats a perfect one next quarter, because next quarter you will not remember what it was.

3. Net worth, and the change — 2 minutes. One number, and its movement since last month. Then the question that gives it meaning: is this month's change explained by what I saved, or by things changing price? Growth from saving is repeatable. Growth from a revaluation is weather. A month where the portfolio rose and you overspent looks identical to a good month unless you separate the two, and it is the single most common way people miss a developing problem for half a year.

4. The three-band check — 2 minutes. Committed, variable, discretionary. You are looking for one thing: has anything moved between bands? A new subscription is discretionary spending that has quietly become committed. A renegotiated contract moves the other way. The absolute amounts matter much less than the direction of travel, because the committed share is what determines how much shock the household can absorb.

5. Write one sentence — 1 minute. One decision or one observation, dated, kept somewhere you will see it next month. "Insurance renews in March, shop around in February." "Third month running that groceries are up; check whether it is prices or us." This is the step that makes the review compound rather than reset, and it is the first one people drop.

What to leave out, on purpose

Several things feel like part of a financial review, take a long time, and change nothing. They belong on an annual cadence or nowhere.

Line-by-line transaction reading. Absorbing, mildly guilt-inducing, and almost never productive. If a category is up, you will look at that category; reading everything is not analysis, it is browsing.

Revaluing illiquid assets. Property, private stakes, anything without a live price. Revalue annually. Monthly revaluation of things whose value you cannot observe adds noise that hides the trend you are looking for.

Budget-versus-actual, category by category. Ten comparisons produce ten small variances, most of which are timing, and the exercise reliably ends in adjusting the budget rather than the behaviour. The three-band check answers the same question in a fifth of the time.

Rate shopping. Switching a savings account or refinancing is a good idea and a terrible monthly ritual. It is an annual job, or a job triggered by a renewal date — which is exactly what step five's one sentence is for.

When the number is bad

At some point the review will produce a number you do not want. This is the actual test, and it is where most systems are quietly abandoned — not with a decision, just by not opening it that month, and then the next.

Two things help. The first is to have decided in advance that the review happens regardless, so that opening it is not a choice made in a bad mood. The second is to know what a bad month is allowed to mean.

A single bad month is usually timing: an annual insurance payment, a tax bill, a holiday booked in one lump. It means nothing on its own. Two consecutive bad months in the same band is a signal worth acting on. Three is a trend, and by then the action is larger than it needed to be.

That is the whole diagnostic. Not a threshold on any particular number — a rule about repetition, which is the only thing a monthly series is actually good at detecting.

The value of the series is entirely in its consistency. One honest number a month, including the months you would rather not look, beats any amount of analysis applied irregularly.

The only rule that matters

What eleven minutes a month buys

Eleven minutes twelve times a year is two hours and twelve minutes annually — less than a single proper audit, spread thin enough that no individual instance is ever worth postponing. That is the entire design goal. Not thoroughness, not insight per session, just a number small enough that it never competes with anything.