Frequently Asked Questions
Everything below is about how Beanie Budgets actually works. Can't find what you're after? Send a note, we read every message.
Privacy & data
Is my financial data really private?
Yes. Beanie Budgets has no servers, no accounts, and no analytics. There's nothing set up to receive your data, so there's nothing for us to see.
What happens to my data if I stop using the app or delete it?
Your ledger is a plain text file that lives wherever you chose to keep it, not inside the app. Deleting Beanie Budgets doesn't touch it. Your data is always yours, and it opens in plenty of other beancount tools too.
Do you ever see my transactions or balances?
No. Everything is processed on your device only. We couldn't see your data even if we wanted to.
Is iCloud sync private too?
iCloud Drive encrypts your files in transit and at rest. By default, Apple holds the encryption keys for standard iCloud Drive, so Apple could technically access it if legally required to. Advanced Data Protection for iCloud, in your Apple ID settings, can make it end-to-end encrypted so not even Apple can read it, though it isn't available to everyone; check your own device to see whether it's offered to you. Either way, Beanie Budgets is never part of that sync path and never sees your data regardless.
Is my data backed up?
Yes, in two ways. Beanie Budgets automatically saves a backup of your ledger before every change, stored privately on your device (not visible in the Files app, but included in your regular iPhone backup to iCloud or your computer). Settings > Restore Backup lets you roll back to any of them. If you also keep your live ledger in iCloud Drive, Apple syncs and backs that up too.
How do I take my own copy of my ledger folder?
Your ledger is an ordinary folder of text files, so copy it the way you'd copy any folder. Where it lives depends on what you chose when you set up: iCloud Drive, on your device only, or a folder you picked yourself, which might be on the device, in Dropbox, or anywhere else. Settings shows which file is currently loaded.
On your phone, open the Files app, find the folder, press and hold it, and choose Copy. An on-device ledger is under "On My iPhone", then "Beanie Budgets". Wherever you put the copy, prefer somewhere that isn't the same place as the original: a copy sitting beside the thing it's backing up shares whatever happens to it.
On a Mac, drag the folder out to your Desktop or Downloads. If it's in iCloud Drive, don't duplicate it where it sits: that often fails with "The operation can't be completed because an unexpected error occurred (error code -8062)". Nothing is wrong with your ledger. Items in iCloud Drive are managed by macOS rather than being ordinary files on disk, and duplicating a folder in place asks the system to recreate every item's identity, which can fail for reasons Finder has no useful message for. Copying it somewhere outside iCloud Drive avoids the whole problem, and so does zipping it first, by right-clicking and choosing Compress, then moving the zip.
If you're comfortable in Terminal on a Mac, this copies your ledger to Downloads with the date in the name, and works when Finder won't. Type the first word and a space, then drag your ledger folder onto the Terminal window, which fills in its real path for you:
ditto <drag your folder here> ~/Downloads/ledger-backup-$(date +%Y%m%d)
The result is a plain folder you can open, zip, or copy anywhere. Run it again whenever you want a fresh snapshot, and the date in the name keeps them apart.
Getting started & beancount
What is beancount, and do I need to already know it?
Beancount is a plain text format for double-entry accounting. Every transaction is a simple line recording where money came from and where it went. You don't need to know it already. Onboarding gets you a working ledger with no beancount typing required.
Can I use my existing beancount ledger?
Yes. Point Beanie Budgets at the folder that contains it and it reads and writes that file directly. No import, no conversion.
What files and folders does Beanie Budgets add to my ledger?
Nothing at all, until you save something. Opening a ledger, reading it, drilling into balances and running every report in the app creates no files and changes nothing: the folder and its contents only appear the first time you use Beanie Budgets to write something, and then only the file that particular thing belongs in. Add a transaction and a year file appears; add a note and a notes file appears; set a budget and a budgets file appears. Use the app purely to look at a ledger you keep by hand and you will find no "beanling" folder there at all.
What appears once you do save something is a "beanling" subfolder alongside your main file. Most of what lives there is genuine beancount: transactions grouped by year, budgets, balance corrections, accounts, notes, and credit card auto-pay, all fully readable by any beancount tool, nothing proprietary. A few plain JSON files sit there too, for things beancount itself has no syntax for: Plan Assumptions, saved Financial Planning scenarios, and, if you share a ledger, the recent-activity log behind the "also open on..." warning. Those JSON files, and only those, are safe to delete on their own: they hold no transactions and affect no balance, so you would simply lose whatever each was storing.
Worth stating plainly, because it means your own file changes: to make those files part of your ledger, Beanie Budgets appends include lines to your main beancount file, one per file, each added the first time that file is needed rather than all at once. Over time you may see any of these:
include "./beanling/2026.bean", and one more for each year you record transactions ininclude "./beanling/accounts.bean"include "./beanling/balance-corrections.bean"include "./beanling/budgets.bean"include "./beanling/credit-card-autopay.bean"include "./beanling/notes.bean"
Appending those lines is the only change made to your main file. Nothing already in it is altered or reordered, and a backup of the whole folder is taken just before each of those writes, ready to roll back to from Settings, Restore Backup. Backups are made before changes, not when a folder is first opened, so a brand new ledger you have not saved anything into yet correctly shows none.
Those lines are ordinary beancount, so your ledger keeps working the same way in Fava or at the command line, and you can move them wherever you like within the file.
The one thing not to do is delete the "beanling" folder, or the .bean files inside it. They hold real transactions, and your main file now points at them, so removing them both loses those entries and leaves an include pointing at a file that no longer exists, which stops the ledger loading in every beancount tool. If you genuinely want rid of them, delete the matching include lines from your main file at the same time, and accept that whatever those files contained goes with them. Taking a copy of the folder first is the safe way round.
Can I share a ledger with someone else so we can both input transactions?
Yes, a beancount ledger is just a folder of plain text files, and since Beanie Budgets has no accounts or servers of its own, sharing that folder via iCloud Drive works the same way sharing any folder does. It isn't built for real-time collaboration though: each device only picks up the other's changes when the app comes back to the foreground, or you tap Refresh Ledger in Settings, not live while both are open, and there's no merging if you both happen to edit the exact same entry at once, that's governed by iCloud Drive itself, not the app. Beanie Budgets does let you know if the ledger is genuinely open on another device too, so coordinating who's adding what is easier than it sounds, see the next question. Works well for taking turns, not for editing at the exact same moment.
Can I edit my ledger by hand while Beanie Budgets is open?
Edit it by hand as much as you like, that's rather the point of plain text files. Just not at the same moment the app has the same ledger open somewhere else, because nothing can reconcile the two.
The "also open on..." warning below only knows about other copies of Beanie Budgets. A text editor, Fava's own editor, or any other beancount tool is completely invisible to it, so you will get no warning at all in that case.
What goes wrong is worth understanding, because it isn't a clean failure. iCloud Drive resolves a clash one file at a time, and the last save wins. So if the app has just renamed an account across your whole ledger, and you then save a file your editor opened before that happened, the app's changes to that file are replaced while its changes to every other file survive. You are left with a half-renamed ledger rather than an obviously broken one: balances look wrong, the same account appears under two names, and nothing announces that anything happened.
The habit that avoids it entirely: close Beanie Budgets before you start hand-editing, let your files finish syncing, then reopen it. If you only need to look rather than change, opening the files read-only is always safe. And every write the app makes takes a backup of the whole folder first, so Settings, Restore Backup is there if a clash does catch you out.
What's the "also open on..." warning about?
A gentle nudge if you're sharing a ledger: if it's genuinely open on another device right now, Beanie Budgets lets you know so you can check with whoever else has it open before you both add or edit something at once. It's advisory only, not a lock, there's no server behind it to actually enforce one, so treat it as a heads up rather than a guarantee nothing will conflict. It also relies on each device's own clock being roughly accurate, which is normally automatic, but worth knowing if either device has manually set the wrong time or date.
What if I don't have one yet?
Choose "New to plain text accounting" during onboarding and Beanie Budgets sets up a starter ledger for you, ready to build on.
Does it work with beancount v2 or v3?
Both. Beanie Budgets reads the beancount file format rather than running beancount itself, so there is no Python, no plugins and no version of the tool bundled inside the app, and nothing to keep in step when you upgrade.
That is checked rather than assumed. The app is held to real beancount's own answers by a set of test ledgers covering costs, price annotations, lot selection, foreign currencies, holdings established by pad and balance, and holdings with no price at all. Those answers are generated by beancount itself and compared against what the app computes, and the same comparison has been run under both 2.3.6 and 3.2.3, which agree on every case. What changed in version 3 was the surrounding tooling, with bean-query moving out to the separate beanquery package and bean-web being dropped, rather than the ledger syntax this app reads.
The official project lives at github.com/beancount/beancount. Worth naming, because a web search can land you on other sites that are not the project itself.
Does it support multiple currencies?
Up to a point, and it's worth being precise about where that point is. Every account can hold its own currency, and a ledger using several loads perfectly well. Balances and the Journal each show one currency at a time, with a currency button in the top left to switch between them, and the heading names the one you're looking at so a total can't be mistaken for everything you own. If your file declares an operating currency, with a line like option "operating_currency" "USD", that is the one every screen opens on, the same as Fava does. Without it the app picks the first alphabetically, which is fine on a single-currency ledger and worth declaring on any other. What Beanie Budgets never does is add your currencies together: it will never tell you that your dollars and your pounds come to one combined figure. Financial Planning scenarios work the same way, each scoped to a single currency.
There is one deliberate exception, and only for what an investment is worth. If you hold something priced in another currency, a US fund in a sterling ledger say, and your file states the exchange rate as an ordinary price directive, that rate is followed so Holdings can show the holding in the currency your ledger counts in. Only rates you have written yourself are ever used, nothing is fetched, and it only happens when your file declares an operating currency, so the app is never deciding which currency your money is in.
Balances deliberately stay out of it. That account keeps showing what it cost in the currency it was bought in, because the cost went in at the exchange rate of the day it was converted while a value would be measured at today's, and adding the two would count the rate moving between those dates twice. So a foreign holding reads as its cost on Balances and as its value in Holdings, which is the honest split rather than a single figure that is neither.
Will it read my ledger, whatever I've written in it?
Probably, and here's how that's been checked rather than assumed. Beanie Budgets' parser is tested against the valid syntax in beancount's own parser test suite, with every case confirmed independently with bean-check first. It's also checked against a 6,600 line ledger generated by beancount's own bean-example tool, which it parses to exactly the same 1,207 directives beancount counts. Speed is tested separately, against a made-up ledger of 39,000 transactions spanning 21 years, so that a long history stays quick to open rather than only being correct. The most useful testing has come from people running their own real ledgers and telling us what broke, which is how most of the fixes so far were found.
Which beancount syntax does it actually understand?
Transactions with payees, narrations, tags, links and metadata. Postings with amounts, or with the number or currency left out for beancount to infer. Arithmetic in an amount, like "100.00 + 5.00" or "(4.00 + 1.00) * 3". Cost bases and price annotations, preserved exactly as written and used to value a holding in money rather than in units. Account open and close, including a booking method like open Assets:Brokerage "FIFO", balance assertions including ones with a tolerance, pad, and note. Repeating transactions written the forecast plugin's way, as a "#"-flagged transaction tagged [MONTHLY UNTIL 2027-01-01] or [WEEKLY REPEAT 12 TIMES]. Splitting a ledger across files with include, wildcards included. pushtag, poptag, pushmeta and popmeta. Fava's budget and fava-option custom directives. Windows line endings, a byte order mark, tabs and comma thousands separators are all handled. Price directives, used to value holdings at what they're worth. Commodity directives, for a holding's name and asset class. Document directives, which aren't displayed yet but are kept correct if you rename an account. Event and query directives, and custom directives of a type the app doesn't define, are recognised and skipped, so a file containing them opens normally and nothing is lost.
Nothing here refuses your whole file. A line the app can't read is skipped rather than treated as a reason not to open the ledger. Where that line was something the app was trying to read, a budget most likely, Settings lists it with the file and line number, so a skip is quiet rather than silent. Directives it skips on purpose aren't listed, since burying the one line that needs attention under a hundred that don't would defeat the point.
If I wrote an amount as a sum, does it stay a sum?
Yes, as long as you don't change that amount. An amount written as "100.00 + 5.00" shows as 105.00 in the app, and if the app rewrites that transaction for any reason, it writes your sum back exactly as you typed it. The arithmetic is usually the reason the figure is what it is, so replacing it with the total would lose something real even though the number is identical.
If you do edit that amount, the sum is dropped and replaced by the figure you entered. It has to be: an expression that no longer produces the value beside it would either contradict it or quietly undo your edit. Beanie Budgets never rewrites or rebalances an expression, and never guesses at what a new one should be.
One thing to know: you can read and keep arithmetic, but you can't type it. Amount fields in the app take digits only, so writing sums is something you do in a text editor, and the app's job is to leave them intact.
The same applies to ordinary figures. An amount you haven't edited is written back exactly as you typed it, decimal places and all, so a holding of "40 VTI" comes back as "40 VTI" rather than being padded to "40.00 VTI".
What doesn't it handle yet?
A few things, worth knowing before you rely on it. Balance assertions are compared exactly, where beancount allows a small tolerance based on the decimal places you wrote, so Beanie Budgets can flag a difference beancount would accept. Close is read but doesn't hide the account. Document directives are read, and kept correct if you rename an account, but the file they point at isn't shown yet. A price is followed through at most one other price to reach your ledger's own currency, so a chain longer than that leaves the holding in the currency it was quoted in. A holding you transferred in with no cost recorded shows its value in Holdings, but contributes nothing to the money total on Balances, because there is no cost for it to contribute. And a foreign-currency holding's balance stays in the currency it was bought in, as described under multiple currencies.
Transactions that don't add up to zero are shown rather than refused, since a file you're midway through editing shouldn't lock you out of your own data. You are told about them though: a warning appears, and Settings lists each one with the amount it's out by and the file and line to find it at.
Where does the app tell me something's wrong with my ledger?
Settings, under Ledger, is the one place that collects it. It shows which file is loaded and how many directives were parsed, and then a row for each kind of problem, but only when you actually have one:
- Transactions that don't balance. Beancount refuses a file with one of these, so any total including it disagrees with what beancount or Fava would say. Tap through for the list, each with the amount it's out by and the file and line to find it at.
- Lines that couldn't be read. Something Beanie Budgets tried to read and couldn't, most often a budget written in a form it doesn't recognise. The line doesn't appear in the app, and nothing else in the file is affected.
- Accounts that open later than a transaction in them. Beancount treats that as an error. The row offers to move those opening dates earlier, tells you how many will change before it does anything, and takes a full backup first.
- Balance assertions that don't match, and any error from loading the file itself.
The first two also show a dismissible notice at the top of the app the first time, so a real problem doesn't sit in Settings waiting to be discovered. Nothing here interrupts you with a pop-up, and nothing changes your files on its own.
What if my ledger won't open?
Please tell us. The error names the exact line in your file, and that line, with the amounts changed if you'd rather, is usually all it takes to reproduce and fix. Every compatibility fix so far has come from someone doing exactly that.
Do I have to record every single transaction?
No. Beanie Budgets can detect recurring transactions automatically and offers to turn them into a series, plus Auto-Clear settings handle predictable ones like credit card payments. The more complete your ledger, the more accurate your reports, but nothing forces manual entry of everything.
How can I start my ledger again?
Head to Settings and tap Re-run Account Setup. It walks you back through the account setup wizard on your existing ledger, so you can rework your account structure without losing any transaction history.
How do I delete an account I no longer need?
Head to Settings and tap Re-run Account Setup, then swipe that account left and tap Delete. This removes the account and everything ever posted to it, so only use it for an account you're sure you don't need.
Pricing & Pro
What's the difference between free and Pro?
The line is about what the app is doing with your numbers. Free covers everything that reads your ledger back to you: balances, budgets, recurring transactions, reports, loans and mortgages, your savings rate, and your holdings with what they cost and what they're worth. All of that comes from your own file, so it stays free for good.
Pro is where the app adds something that isn't in your ledger, because you decided it. That's the full Financial Planning suite and the years-to-independence projection. Pro also covers multi-account budgets, custom datasets, multiple ledgers, more themes, and Stealth Mode.
Is Pro really one-time, not a subscription?
Yes. Pay once and keep it. No subscriptions, ever.
What happens to Pro if I get a new phone?
Sign in with the same Apple ID and tap Restore Purchases in Settings. Your Pro unlock comes straight back, no need to buy it again.
Everyday features
Why did a "Balance Padding" transaction appear dated the day before I corrected my balance?
That's a real beancount rule, not a bug. A padding entry has to be dated before the balance it's fixing, or it's silently ignored. Dating it one day earlier is what makes the correction actually work.
What's the difference between a correction and a real transaction?
A correction squares your recorded balance with the real one, useful for an opening balance or a gap you didn't track. A real transaction records an actual event: money genuinely moving between accounts. Corrections should be occasional, not a substitute for recording real activity.
I already use the forecast plugin for repeating transactions. Does that still work?
Yes, and you don't have to convert anything. A transaction flagged "#" whose narration ends with a bracketed tag is read as a template rather than as a single entry, and Beanie Budgets generates the occurrences from it, exactly as the forecast plugin does. DAILY, WEEKLY, MONTHLY, QUARTERLY and YEARLY are all understood, with either UNTIL 2027-01-01 or REPEAT 12 TIMES, and a five-year window if you give neither, matching the plugin's own default.
The generated occurrences appear throughout the app, in balances, reports and charts, but they are never written to your file. Your template stays the single line you wrote. If a tag would generate an implausible number of occurrences, the series is capped and you're told, rather than quietly producing an incomplete set of figures with nothing to explain why.
This is a different mechanism from the app's own Recurring toggle, which writes real dated transactions into your ledger. Both work, and they can coexist in the same file.
How do I set up a recurring transaction?
Add a transaction as normal, then turn on Recurring before saving. That reveals four controls: Start Date, End Date, Frequency (Daily, Weekly, Monthly or Yearly), and Every, which repeats at a multiple of that frequency. Quarterly is Monthly with Every set to 3. There's also Weekend Adjustment, which moves any occurrence landing on a Saturday or Sunday to the preceding Friday or following Monday, so a payment that really leaves your account on the Monday is dated the Monday and matches your bank statement.
Picking a frequency resets End Date to something sensible for that cadence, until you set one yourself, at which point it's yours. If a range would generate more occurrences than can be written at once, you're told so rather than quietly getting a shortened series.
What this writes is the part worth understanding. Beanie Budgets generates real, individually dated transactions, one per occurrence, not a single rule your ledger has to be taught to interpret. Every one is ordinary beancount that any other tool reads, and you can edit or delete any single occurrence like any other transaction.
To manage a series afterwards, open any transaction in it. Show Series lists every occurrence, Edit Series changes this one payment, every upcoming one, or the whole series including past payments, Extend Series adds more occurrences continuing the same pattern, and Delete This Series removes it entirely or from a date you choose forward.
If you already have repeating transactions in your ledger, you don't have to rebuild them. Open one and choose Make Recurring, or let detection find them for you, which the next answer covers.
How does recurring-transaction detection work?
Beanie Budgets looks for transactions with a similar payee and amount repeating on a regular cadence and offers to turn them into a proper recurring series, so future occurrences are generated automatically.
My investments are recorded in stock symbols rather than money. Does that work?
Yes. A holding written the usual beancount way, like 10 VTI {50.00 USD}, counts as 500.00 USD and sits alongside your cash instead of appearing as ten of something called VTI. Totals, charts and reports all use the same figure. Underneath the amount you'll see a line reading "10 VTI at US$50.00", so the number of units and the price are never lost.
The other legal ways of writing a purchase work too, which matters because plenty of real ledgers use them. A purchase carrying a price rather than a cost, like 10 BND @ 20.00 GBP, is a holding. So are units that simply arrived, bare on both legs of a transfer from another provider. A cost written as a calculation, like {20.00 / 2 USD}, is read as the 10.00 it works out to. Units transferred in carry no cost at all, so that row shows what it's worth and says plainly that there's no gain to show, rather than treating the cost as zero and calling the whole value profit.
Sales are handled properly too. If a sale names the lot it came from, that is the cost used. If it doesn't, the booking method decides, and that is read from your own file rather than set in the app: either on the account, as open Assets:Brokerage "FIFO", or for the whole ledger with option "booking_method" "FIFO". All five of beancount's methods are read, FIFO, LIFO, HIFO, AVERAGE and NONE, and with nothing declared the oldest lot is used. AVERAGE collapses your lots into one, which is the one place Beanie Budgets is more forgiving than beancount itself: beancount refuses a sale it can't match to a specific lot, and this works out the average rather than refusing your file. Your file is never rewritten by any of this: what you typed stays exactly as you typed it.
Add price directives and the same holdings are also shown at what they're worth today, with the gain between cost and value. Those prices come from your own file, usually written there by beancount's own beanprice tool. Beanie Budgets never fetches a price: there's no network request anywhere in the app, so nothing about your portfolio leaves your phone to get one. Where a holding is priced in a currency your ledger doesn't count in, a US fund in a sterling ledger say, an exchange rate stated in your own file is followed to reach your currency here, and your file has to declare option "operating_currency" for that to happen, so the app is never choosing which currency your money is in. Balances leaves that account at what it cost, for the reason given under multiple currencies above.
The Holdings report builds on this. It's free, and it lists everything you hold with its cost, its value and the gain between them.
What are unrealised and realised capital gains?
An unrealised gain or loss is the on-paper change in something you still hold, like an investment that's gone up but hasn't been sold. A realised gain or loss is the actual profit or loss once you sell it. Beanie Budgets can track both separately so your income reports only count what you've actually locked in.
Where does Beanie Budgets record capital gains, and does it work with how I already do it?
There are two established ways to handle investment gains in beancount. Beanie Budgets uses one of them by default and reads both, so a ledger built either way works here.
The way Beanie Budgets records them. A gain is written into a sub-account of the holding itself, funded from a matching account:
Assets:…:<your account>:Capital-Gains-Unrealised, funded fromEquity:Unrealised-GainsAssets:…:<your account>:Capital-Gains-Realised, funded fromIncome:Capital-Gains-Realised, orIncome:Capital-Loss-Realisedwhen it's a loss
Gains and losses get separate accounts when realised, so one can't quietly cancel out the other on an income statement. Unrealised uses a single account whichever way it moves, because it's an ongoing mark-to-market adjustment rather than a one-off event, and it's booked to Equity rather than Income because a paper valuation swing isn't money you've earned.
This shape isn't a Beanie Budgets invention. Beancount ships a plugin, beancount.plugins.unrealized, that posts unrealised gains into exactly that kind of sub-account. The difference is only the label, which the plugin leaves up to you and defaults to Unrealized. Beanie Budgets recognises that spelling and the British one too, so a ledger built with the plugin needs no renaming.
The other way: holdings at cost, with prices. If you record investments the beancount way, as 10 VTI {50.00 USD} with price directives to say what they're worth, then unrealised gains aren't recorded anywhere at all. They're worked out whenever you look: today's value less what you paid. Realised gains aren't recorded separately either, they come out as the balancing leg of the sale itself, usually into an income account. Beanie Budgets reads all of that and values your holdings from your own prices.
Can a ledger use both? Yes, and plenty do, usually part way through changing from one to the other. Different accounts can use different approaches quite happily, and the Unrealised Gains report simply shows a row from each. The one combination to avoid is a single account doing both at once, a gains sub-account and a cost basis with prices, because then the same paper profit is counted twice. Beanie Budgets won't silently pick one for you, since they're both things you wrote, but it does name the account so you can decide.
Which should you use? If your investments are recorded as a cash figure, a balance you update rather than a number of units, the sub-account approach is your only option: there are no units and no price for anything to be computed from. If you hold actual units at cost, the second approach is less work, because nothing has to be maintained by hand. One thing to know before choosing it: amount fields in the app can't type a cost basis, so purchases and sales in that style are written in a text editor. Beanie Budgets reads them, values them and never alters them, but it won't create them for you.
How do I record something that needs more than two accounts, like moving an investment to a new provider?
Most entries are simply one account paying another, which is what "Paid From" and "Paid To" are for. Some genuinely need more legs: a pension contribution split between employer and employee, a mortgage payment split into interest and principal, or an investment moving to a new provider. On Add Transaction, open Advanced and tap "Add Another Posting" to switch to a flexible list where every line carries its own account and its own signed amount. The running Balance at the bottom has to reach exactly zero before it can be saved, which is your check that nothing has been lost or invented along the way.
A provider transfer is a good worked example, because it is not a sale. Nothing is realised, so the unrealised gains you have built up travel across with the holdings instead of vanishing and reappearing. Suppose the old account holds 40,000.00 of contributions with 10,000.00 of unrealised gains recorded beside it, and you move everything except 100.00:
- ISA, new provider: + 39,900.00
- ISA, old provider: − 39,900.00
- Capital Gains Unrealised, new provider: + 10,000.00
- Capital Gains Unrealised, old provider: − 10,000.00
Every line is one of your own accounts, so nothing touches income or equity. That is the point: this is a move, not a gain. You may need to create the new provider's own Capital Gains Unrealised sub-account first, either from Manage Accounts or with the "Add New Account" shortcut in the account picker.
If your new provider's own figure differs a little once the transfer lands, that gap is real market movement rather than part of the transfer, so record it on its own with Correct Balance on the new account and "Track as Unrealised Capital Gains". Following the example above, if the provider says 49,880.00 where your ledger now says 49,900.00, set the new gains account to 9,980.00 and the 20.00 difference is recorded as an unrealised loss.
One handy trick if the Balance refuses to reach zero: when it lands on exactly twice one of the amounts you typed, that line has the wrong sign.
How do you auto-populate a figure like my monthly savings and investments?
By reading your own real ledger: a Financial Planning scenario's starting balance comes from whichever real accounts you select, and your average monthly contribution from what you've actually been paying into them. The same one-time-prefill principle shows up all over the app, current loan terms from a mortgage account's own balance and saved details, target spending from your real average Expenses, quick account suggestions from what you use most. Every one of these fills in a normal, editable field you can see and change before anything is saved, nothing gets written to your ledger on its own.
Financial Planning & backtesting
Is any of this financial advice?
No. Every mortgage overpayment, remortgage, growth, FIRE, guardrails, drawdown tracker, bridge to pension, and retirement plan scenario is for informational and educational purposes only, built from your own real ledger figures and real historical data, but never a guarantee. Speak to a qualified, independent financial adviser before making any real decision, especially anything involving a mortgage, a pension, or retirement income.
Are the figures in today's money, or what I'd actually see in the future?
Today's money. Every Financial Planning projection is adjusted for inflation throughout, so a portfolio shown reaching £500,000 in twenty years means £500,000 of today's buying power. The statement that year would print a larger number, but it would buy the same things. The historical datasets are already expressed as real returns, and if you import your own series as nominal figures they are converted year by year using that market's own CPI.
Why didn't my savings grow when I left the rate at 0%?
They did, in the only sense the projection measures. A rate of 0% doesn't mean the money sits still, it means it grows at the rate of inflation, so its buying power stays where it is. That's why 0% is the default for cash, which over the long run tends to track inflation and not much more. Anything above 0% is what you expect to earn above inflation, so if prices rise 3% and your investments return 8% on paper, the figure to enter is 5%.
Do I need to increase my target retirement income for inflation?
No. Enter what you'd want to live on if you retired today, and leave it there. The projection holds that amount level with prices across every year it models. Inflating it yourself applies the adjustment twice and makes the plan look far worse than it is.
Does anything work in future money instead?
One thing, deliberately: the Portfolio Drawdown Tracker's recommendation, which is an amount you are about to withdraw and spend rather than a projection. It asks you for published inflation since your last check-in and raises the recommendation to match. Guyton-Klinger is the exception to that, skipping the increase after a year the portfolio fell, which is a real cut in buying power, intended, and never made up later. If you specifically want a future-money forecast, the Investment Growth report lets you enter a rate before inflation, and says so on the field itself.
What's the difference between Safe Withdrawal and Guardrails models?
A Safe Withdrawal Rate keeps your spending fixed, adjusted only for inflation, for the whole plan. Guardrails models review your spending each year and adjust it up or down based on how your portfolio is actually doing, so you spend more in good years and cut back in bad ones instead of sticking to one number regardless.
What do "Single Path" and "All Sequences" mean?
All Sequences runs your plan against every real historical starting year at once, showing the full spread of outcomes. Single Path lets you pick one specific year and follow exactly how that one history would have played out.
What does a percentile, like the 50th percentile, actually mean?
It's a ranking of every historical outcome from worst to best. The 50th percentile is the middle result, half of history did better, half did worse. The 5th shows a genuinely rough outcome, the 95th a strong one.
How is each row of Model Data actually worked out?
The first row starts from your portfolio as it stands on the day you begin drawing on it, after every year of contributions and growth up to that point. That figure counts only what you can actually spend, so a pension pot you can't touch yet is left out until it unlocks, at which point it joins the balance and the Note column says so.
From there the model works a month at a time, not a year at a time. Each month it takes that month's withdrawal first, then applies that month's growth to whatever is left, twelve times over. Working it out in one annual step instead gets you close, but not to the penny, because a withdrawal taken in January doesn't earn the year's returns.
Two things catch people out when checking a row by hand. The Withdrawal column is what you receive, so if you've set a Tax Adjustment the portfolio is drawn down by more than that to cover it. And a plan year runs from the month you start drawing, not from January, so a row headed with a span like 1989/90 covers parts of both years rather than either one alone: that's why there are two return columns. Calendar Return is the calendar year's own figure, which you can look up against published history, and Period Return is the one actually compounded across that row's own twelve months. Use that one when reconciling.
The Note column explains anything unusual in a row: a mortgage being paid off, a pot becoming accessible, a guaranteed income starting, or a withdrawal held back by a rule.
Why is the Period Return so different from the Calendar Return beside it?
Because a row is not a calendar year. A plan year runs from the month you start drawing, so unless that is January each row spans parts of two calendar years, and the Period Return combines both. How much of each depends on your own start month: begin drawing late in the year and most of every row belongs to the year after the one it is labelled with, begin early and the labelled year dominates. Whenever two consecutive years disagree sharply, the two columns can look nothing alike.
To put rough numbers on it, take a plan that starts drawing in September, so roughly a third of each row belongs to the year it is labelled with. If that year gained 25% and the next one lost 25%, the row shows a healthy Calendar Return next to a Period Return that is clearly negative, because most of the row is the year that fell. It works in reverse after a bad year, where a row labelled with a heavy loss can show a Period Return near zero because the recovery that followed makes up most of its months. Change the starting month and the weightings change with it, so the same market history produces different Period Returns for different plans.
Where consecutive years are similar the two columns nearly agree, which is why most rows look unremarkable and a handful look startling. Nothing is wrong in either case: Period Return is what actually happened to the portfolio across that row's own twelve months, and it is the figure that reconciles the balances. Calendar Return is the calendar year's own number, kept so you can check the sequence against published history. If your drawdown does start in January the two are identical, and the Period Return column stays empty.
Why might a strategy's "recommended" withdrawal not match what my plan actually withdrew that year?
Usually because a real rule stepped in, like an Essential Income floor, a spending cap, or simply running low on portfolio. When that happens, Model Data's Note column tells you exactly why.
What's the "Essential Income" floor?
It's the minimum you've said you need to live on. Beanie Budgets never lets a guardrail cut take your withdrawal below this floor, even in a bad year, on top of whatever guaranteed income like a pension is already coming in.
Where does the historical market data come from, and how far back does it go?
From real, published market return series, for example the S&P 500 back to the late 1920s. Every backtest replays your plan against every real historical starting point available, not a simulation.
Can I bring my own market return data?
Yes, with Pro. Import your own historical series, or build a synthetic market with booms and crashes to stress test a plan.
Troubleshooting & support
My balance looks wrong, what should I check first?
Check that account's Balance Padding history first, it shows exactly when and why a correction was applied. Then look for a missing or duplicate transaction around the date things look off.
I found a bug or have a feature request, how do I reach you?
Email contact@beaniebudgets.com. We read every message.