In version 5.16, while creating 'budget report' the maximum period allowed is 60 months. Why can't that be for say, 66 months or (in the alternative) 'any contiguous 60 months specified by user as 'from date' and 'to date' ?

Suddenly I am getting an error:

Finance::quote reported failure with error: Error-failed to retrieve fund data : HTTP status = 403 Forbidden.

It has been working just fine. Any clues?

I have been working on scripts to preprocess bank statements into the format needed for ingesting into gnucash. Here are the scripts (and instructions) for two of the biggest banks in India: State Bank of India (SBI) and Canara Bank:

https://github.com/abhijit86k/gnucash_statement_preprocessors

Needs Python. Tested on Ubuntu but should work on any platform.

Comments are welcome.

Hey folks! I'm working on figuring out the best format for GnuCash tutorials, would love input from people who actually use this software.

I tried longer-form (~10 min): example.  Average watch time landed around 2-4 min.

Tried a shorter, more focused format as a test: example. It's early days, but retention looks even shorter, though the sample's still tiny so I'm not reading much into it yet.

Curious what people actually prefer here
A. longer walkthroughs,
B. or quick focused "here's one fix" style videos?

And tone-wise: more casual/joking, or straight and to-the-point? Trying to figure out what's useful vs. what's just noise.

Like a lot of people here, I ran into the fact that GnuCash doesn't have direct bank integration for most banks, and manually logging into my bank's website every time to download a CSV/export got old fast, especially since I use multiple banks (ING, N26, Revolut).

Recently I put together a Python script that pulled transactions via the GoCardless Bank Account Data API (the former Nordigen open banking API) and converted them straight into OFX files for GnuCash. Since I discovered GoCardless stopped accepting new signups for Bank Account Data (from July 2025 onwards) — existing users still work, but nobody new can sign up anymore — that version isn't really usable for anyone starting from scratch. So I rebuilt it on top of Enable Banking instead, which is currently the closest self-serve open banking API for personal/hobby use in Europe.

What it does:

• Pulls transactions from your bank(s) via the Enable Banking API (PSD2 open banking, free "Restricted Production" tier for your own accounts, 2000+ banks across Europe)
• Converts them directly into OFX files (no dependency on ofxstatement or other libraries — it builds the OFX itself)
• Writes one .ofx file per account, ready to import straight into GnuCash
• Only fetches transactions since your last import, and dedupes automatically, so no duplicate transactions when you run it repeatedly
• Lets you search and add any Enable Banking-supported bank interactively (not hardcoded to a fixed list)
• Available in English and Dutch (asks once, remembers your choice)

Setup is a bit more involved than the old GoCardless version: you need a free Enable Banking developer account, and for personal use you have to register an application and explicitly link your own bank account(s) to it in their Control Panel before the script can use them — that part's a one-time thing per account, not per run. After that, authorising a bank is still just a one-time browser login per bank (that part isn't optional, it's how open banking consent works) — the only quirk is that instead of the script polling automatically, you paste the redirect URL back into the terminal once you're logged in.

After the one-time setup it's the same as before: run the script, get your .ofx, import into GnuCash.

Code + setup instructions here: https://github.com/AfwasSysteem/Enablebanking-to-ofx

It's a fairly small, single-purpose script. No GUI, just something you run when you want to sync. Feedback and PRs welcome, and curious if others have solved this differently now that GoCardless is closed to new users.

Not sure how or where I pulled & installed v5.5. I had assumed (until 30 minutes ago) that 5.5 was newer than 5.16.

• Is 5.16 is the latest stable version?
• How do I get from 5.5 to 5.16? Just install 5.16 and open the XML data files? Or do I have to jump through hoops of fire?

I could not find an upgrade path. Actually, I cannot find much about v5.5 -- did it really exist?

Edit: I found out GoCardless does not accept new users anymore. I have had an account for years, therefore the script works perfectly for me. But new users can't use it. I made a new version of the script to use the Enable Banking API. That service is also free and accepts new users for personal use.
https://www.reddit.com/r/GnuCash/comments/1uucems/script_to_pull_eu_bank_transactions_automatically/

Like a lot of people here, I ran into the fact that GnuCash doesn't have direct bank integration for most banks, and manually logging into my bank's website every time to download a CSV/export got old fast, especially since I use multiple banks (ING, N26, Revolut).

So I put together a Python script that:

• Pulls transactions from your bank(s) via the GoCardless Bank Account Data API (the former Nordigen open banking API, free tier available, works with hundreds of European banks)
• Converts them directly into OFX files (no dependency on ofxstatement or other libraries it builds the OFX itself)
• Writes one .ofx file per account, ready to import straight into GnuCash
• Only fetches transactions since your last import, and dedupes automatically, so no duplicate transactions when you run it repeatedly
• Lets you search and add any GoCardless-supported bank interactively (not hardcoded to a fixed list)
• Available in English and Dutch (asks once, remembers your choice)

You'll still need a (free) GoCardless account and to authorize access via a one-time browser login per bank (that part isn't optional, it's how open banking consent works), but after that it's just: run the script, get your .ofx, import into GnuCash.

Code + setup instructions here: https://github.com/AfwasSysteem/Gocardless-ofx-gnucash

It's a fairly small, single-purpose script. No GUI, just something you run when you want to sync. Feedback and PRs welcome, and curious if others have solved this differently.

NOTE: It's not AI-slop. Just documenting what I learned from speaking many people over the last couple years. Proof. Also removed all the links to my app since it applies to any app.

---

Hi! It's been two years of development my own GnuCash companion app I needed to carry a GnuCash book in my pocket.

Since then, I have come to know many people and their setups. And boy, are they different! In this article, I cover common mistakes and pitfalls of accessing a shared GnuCash book using multiple computers and companion apps on Android and iOS.

The basics

First, let's set the stage and expectations.

Unlike cloud-based solutions, GnuCash is a single-user system. Practically, it means that only a single user can access your accounting book at a time.

Also you own your data. It's a blessing and a curse. On one side, your data is visible only to you, on the other side, you carry the responsibility of handling data corruption, conflicts, and simultaneous access.

GnuCash does its best to help you avoid problems. It has locking mechanisms to prevent multiple users in one book. However it's not a bulletproof solution and you still carry a responsibility of backing up your books.

GnuCash can store data in multiple ways.

• XML - in a text format (it's compressed, though, so not readable out of the box)
• SQLite3 - a database in a file
• Hosted database - a database on a computer network or even on the Internet

Who are "the users"

The users can be real people needing access to a shared GnuCash book. Or it can be you accessing your file from multiple devices. So from now on let's not care how many users access the book, but rather how many devices access it.

An important thing here is that GnuCash is inherently a desktop software. However, there are enthusiasts (including yours truly) who develop companion software to access the book from mobile platforms. So the "device" could be a laptop with GnuCash installed or a mobile app.

But before we discuss the mobile apps, let's only consider GnuCash running on multiple devices.

Expectations

If you are a new GnuCash user coming from a cloud-based solution, you are likely used to software that does a lot of things seamlessly.

However, GnuCash perks come at the cost of:

• Different instances of GnuCash have different data, and you are responsible for merging them semi-automatically
• Devices take turns accessing the software.
• Supporting your devices to run the same version of GnuCash.

Ratings

Each solution has its rating on different dimensions.

The paranoid way - safest yet most painful

Workflow

1. Make a copy of your book on each device.
2. Work on your books however you want (in parallel, offline, however you want)
3. When ready, merge the books.
4. Distribute the "master" book among devices.

How to merge books

Good thing - you don't have to manually merge books, transaction-by-transaction. GnuCash gives you a specific format to export and import data while taking care of duplicates.

1. Choose one book as "master". For other books export transactions using File -> Export -> Export Transactions as CSV…
2. Open your "master" book.
3. For every CSV file you have, go to File -> Import -> Import Transactions from CSV … Do not forget to select "GnuCash Export Format" – this turns on a native GnuCash mechanism to work with splits.
4. Work out any conflicts should they pop up on the last import screen.

The Great File in the Cloud - just a file in a Dropbox

It's 2026, Dropbox is 17 years old. A good age to give it a small job to do before graduation. Of course you can choose your tool of preference - iCloud, Google Drive, Syncthing.

One liability that comes with a file in the Cloud is a potential file conflict. There is absolutely no magic behind any Cloud - each device has its own copy of the GnuCash file. If accessed simultaneously, you will have two copies. To add insult to injury, some cloud providers make things obscure and you may not see the issue when it occurred but rather see it so late in the game that it will mean a manual reconciliation of transactions. And last but not least, technical glitches (Cloud process crash, GnuCash crash) happen, and it is totally possible to end up with a corrupted book. Glitches are not unique to this synchronization way, but amplified by a human factor and the frequency of synchronizations.

Workflow

1. Put your file in a Cloud - Dropbox, iCloud, Google Drive, etc.
2. Instruct users to never ever access the file simultaneously. If you are the only user, stop being sloppy and forgetting to close GnuCash before closing the lid of your laptop.
3. Always wait for the cloud provider to synchronize files. If Cloud allows forcing a sync, always use it before opening a GnuCash book.
4. Be proactive about backups. Do not expect GnuCash mechanisms to save you - you are using an extra piece of software that GnuCash does not know about.

Privacy & security

There is no rating because your privacy and security depend on your choices. Choose a provider that gives away your information without any questions, and you effectively have no privacy. Choose an offline tool like rsync or Syncthing - and you can disconnect from the Internet. As usual, the more privacy and security you want, the more friction you have.

Look ma I'm a DBA! Hosting data in the database

If you are handy enough and can host a Postgres/MySQL database. This is likely the best option for you.

Instead of storing the accounting book in a file, you can store it in the database. As usual, there are a few tradeoffs - you have to install additional software (Postgres or MySQL), set up the server, connections, and manage security and privacy yourself.

The workflow is pretty much like the previous, with a small exception. The internal GnuCash lock mechanism works much better. Still, GnuCash maintainers are explicitly stating that the lock mechanism is a weak protection:

Also, privacy and security is your job. Open your database to the world with a default password - and just wait for someone to delete all the tables. Or air-seal it in a local network without Internet access - and enjoy peace.

Companion apps

There is no official GnuCash app for Android or iOS.

However, there are decent alternatives that you can use as your companion app. You can find more here

All of the apps support only two ways:

• CSV sync (thus manual merge)
• Automatic sync via SQLite3 or XML file

It's virtually our first two solutions. So you can confidently use the first two workflows when using the companion app. However, you shall read the disclaimer from GnuCash carefully:

While the workflow stays the same, there is one more risk to consider - data corruption by the companion app itself.

The reason here is simple: GnuCash does not provide any official library to work with data files. So every implementation that works with the file directly may not know something and unintentionally corrupt the GnuCash book.

But since there is already a Cloud at play and you are likely backing up your data often (don't you?), you should be good enough to restore from any potential disaster.

Small business: What's the easiest way to explain this line on the Balance Sheet report to an auditor?

The Gnucash file has various transactions for FX and stock purchases.

Question is what the title says, when should I record P&L?

These numbers are not real but illustrate the scenario: say my GNUCash account for my TFSA says $30,000, which is the amount put in, and now I want to take out $1,000 to pay for a big purchase, and the TFSA is currently worth more than $31,000.

Do I debit $1,000 to Cash and credit $1,000 to an income account called "Realized Gain on Investments" (or something), and not touch the TFSA in GnuCash?

The concern is that I also use the Budget feature and I don't want realized gains on investments to be mistaken for monthly contributions I make from my income, or for withdrawals to be counted against them. But I am also planning to pay this back to the savings account later, so does that change the consideration?

Thanks!

I started using GnuCash about 17 years ago (with 2.x), OFX Direct Connect was a quiet pillar of the GnuCash experience — point GnuCash's Online Banking dialog at your bank, and live transactions flowed in. Then most major US banks discontinued it (Chase, Bank of America, Wells Fargo, Citi, and many others have all retired their public OFX endpoints over the last several years), and GnuCash users including myself were left falling back on CSV exports, QIF imports, and a lot of manual cleanup.

Hi all — I built gnucash-connect to bring that workflow back. It's a small self-hosted server that speaks OFX Direct Connect to GnuCash on one side and SimpleFIN to your bank(s) on the other. No CSV exports, no QIF imports, no copy-pasting.

The whole setup is one Docker volume, one command, and one paste:

docker run -d \
  --name gnucash-connect \
  -p 127.0.0.1:8080:8080 \
  -v gnucash-connect-data:/var/lib/gnucash-connect \
  ghcr.io/stevel408/gnucash-connect:latest

Then open http://localhost:8080/activate, paste a SimpleFIN setup token, and point GnuCash's Tools → Online Banking Setup → Start AqBanking Setup at http://localhost:8080/ofx. That's it.

How it works

• SimpleFIN handles the bank connection (~$1.50/month).
• gnucash-connect caches normalized transactions locally in plain JSON inside one Docker volume you control.
• GnuCash speaks OFX Direct Connect to it — the exact same dialog you'd use with a real bank, just pointed at loopback.
• Fetches are lazy: SimpleFIN is contacted at most every 8 hours, and only when GnuCash actually asks for data. If SimpleFIN is down, you get the cached data with a warning, not an error.

Privacy & security

• Nothing is exposed to the public internet. The container binds to 127.0.0.1:8080 on the host loopback. The only outbound calls go to the SimpleFIN Bridge; nothing reaches your bank directly, and nothing reaches any third party I run (because I don't run anything).
• Your bank credentials never touch GnuCash, this app, or your disk in plaintext. SimpleFIN owns the bank login; what gets persisted on your machine is the long-lived access URL it hands back, written to the Docker volume at mode 0600.
• Docker isolates the app from your host. No files outside the named volume, no daemons, no startup-script weirdness. The container runs as a non-root user (uid 1000) inside the container, so even a worst-case bug can't write outside the cache volume.
• Uninstalling is three commands and leaves nothing behind: docker stop gnucash-connect && docker rm gnucash-connect && docker volume rm gnucash-connect-data && docker rmi ghcr.io/stevel408/gnucash-connect. No leftover files in $HOME, no system services, no registry entries.

Data + persistence layer

The bank-data and on-disk persistence side is provided by finstore — an open-source Python package I developed alongside this project. It's published on PyPI (pip install finstore) so you can use it standalone if you want the cache + SimpleFIN client without the OFX server, or build your own tools on top of it. Source is on GitHub: https://github.com/stevel408/finstore.

Notes

• Loopback-only by design — the OFX endpoint has no auth. Don't expose it.
• The dashboard at http://localhost:8080/ shows accounts, last-fetch time, an Activate / Deactivate / Fetch surface, and a built-in cache validator.
• v0.1.0 — works for me, may have rough edges. Bug reports + suggestions welcome.
• License is PolyForm Noncommercial 1.0.0 (free for personal / non-profit / academic use; commercial use needs a separate license).
• License Source: (available upon request)

One question for the room

If many people are interested in this and do not want to run Docker, I may consider offering a cloud service, with some privacy/security implications. If there's enough interest, I'd be happy to discuss further.

Happy to answer other questions in the comments also.

P.S. I posted an early notice about 10 days ago, and would like to express my appreciation for the encouragement I received: https://www.reddit.com/r/GnuCash/comments/1tx1hfp .

So I created a category/account that I labeled “cash” and in that category I labeled entries as “paper cash” and “Venmo.” I realized now that I should’ve created a “cash” category and a “Venmo” category.

Can I create a Venmo category and then go into the cash category and select an option to cut it from the original category and paste it to the new Venmo category?

Alternative would be manually reentering all the info to the new one and deleting all the info from the old one which feels more tedious.

I hope that makes sense…thanks

At one point I decided to switch over to Firefly 3 as I am adding stuff to myself host. I really liked the mobile client for FF3. Recently I discovered that GNU Cash also has a mobile app. I figured I would be cleaver and have my Nextcloud just sync the relevant files. It seems tho that once it caches things rather than read the file as it changes, so I have to keep re-opening the file.

Any work flow that does not involve re-opening the files in desktop and mobile?

Just curious what everyone’s GNUCash preferences and setup look like. What settings, views, reports, shortcuts, or customizations do you use that make GNUCash easier or more efficient for you?

Since last month (most likely after Windows 11 patching), my Gnucash will most likely fail (1 out of 20 times) to start with the following error (ID 1000). Wondering if anyone else has a similar issue and if there is any resolution? Or, did the developer did anything to address this?

-----

Faulting application name: gnucash.exe, version: 5.14.0.0, time stamp: 0x69475b85

Faulting module name: gnucash.exe, version: 5.14.0.0, time stamp: 0x69475b85

Exception code: 0xc0000005

Fault offset: 0x00022cf0

Faulting process id: 0x8248

Faulting application start time: 0x1DCF90903AD8081

Faulting application path: C:\Program Files (x86)\gnucash\bin\gnucash.exe

Faulting module path: C:\Program Files (x86)\gnucash\bin\gnucash.exe

Report Id: 87e3282d-77aa-4b7e-8cfe-6d7f7cb61a08

Faulting package full name:

Faulting package-relative application ID:

TLDR: Spanish traders in the 1600s did not want to count their thumbs, which influenced GnuCash's database design choices in 1997. Much like a horse's arse set the standard for railways. How seemingly odd design turns out to be a genius solution that serves people pretty well.

It's one of those nights. A cup of hot coffee is on the table. I'm implementing a commodities support in HandsOnMoney which looks absolutely trivial on the surface, but is quite deep in reality. After all, what can be simpler than currency - there are dollars and cents. What can be simpler than storing a number and calculating totals?

Wait for it. There are multiple layers in this…

Layer one. Cultural.

There is not always 100 cents in a dollar. Well, there is. But other currencies may have no "cents" or have a thousand "cents". Those "cents" are generally called "minor units".

Here are a few concrete examples:

1. Japanese Yen has no minor units (due to post-WWII inflation)
2. The Kuwaiti Dinar has a thousand minor units (this allows the country to use smaller increments of value and maintain precise pricing for trade)
3. And Bitcoin has 100 million Satoshis!

But wait for it. There are even historical currency- real de a ocho that could be divided into 8 pieces! So 1/8th of a coin was the smallest indivisible unit!

Which brings us to the next layer - how in the world do we store it?

Layer two. Software.

Computers are not good with fractions. There are abstractions: float and doubletypes. But they are approximations rather than real fractional numbers. The late 90s and early 2000s brought us decimal, which is a much better type; however, it was likely not available when GnuCash was released.

There is a lot written about it. Usually, developers use a double numeric type to record and store the floating-point numbers. But this solution for recording floating-point numbers does not play well with money.

For example, it is possible that.

1.03 - 0.42 = 0.6100000000000001

Which seems like a trivial rounding error. But over a large number of transactions, the rounding error will accumulate, and you'll eventually see a weird account balance.

In addition, money has a fixed precision and specific rounding rules. So software engineers stepped on this landmine so many times that they developed a common pattern - Money. Which, in a nutshell, is just storing minor units in whole numbers since computers are pretty good with them. So instead of recording $5.23, the money is stored as 523 cents.

Problem solved? As you'd expect - no.

Layer three. Historical.

It's not about money. Well, it is. But it is not only about money. It's also about commodities. In a nutshell, money is a commodity. People trade various commodities - currencies, stocks, and funds.

This generalization needs us to go back in the past. And…

Party like it's 1998

It's 1998. The year of the first release of GnuCash (xacc at that time). Dotcom money is pouring from the firehose, party everywhere…

But the most important thing - NYSE quotes are not decimal. They are fractional!

GnuCash was released before the decimalization of US exchanges was completed in 2001.

Why? Get back into the time machine and …

… trade like it's the 16th century

When the NYSE launched over 200 years ago, it adopted the Spanish trading system from the 1600s, based on fractions because traders counted gold doubloons on their fingers, skipping their thumbs. That's why the smallest stock increment was 1/8 of a dollar. Not a technical decision. A thumb decision. (source - Investopedia)

Okay, enough of counting fingers in the 16th century. Let's get back to 2026.

Layer four. Data Engineering.

In 2026, everything is traded in decimals. We are counting fingers and thumbs.

Is GnuCash's design decision to store fractions an artifact from the past?

It already caused a bug

Mostly yes. GnuCash is full of little quirks from the past (it still supports Italian Lira, which was replaced with Euro in 1999!).

But this seemingly outdated design decision to store fractions works extremely well in a modern world.

Consider this example: if I bought 1 Bitcoin in 2011 for 90 cents. In my GnuCash book, I recorded

Now in 2026. I can sell a fraction of my holdings and price it in Bitcoin's minor unit - Satoshi.

I can easily flip the Bitcoin precision in the commodities editor from 1 to 100,000,000, and GnuCash will still calculate the balance without any issues.

For example, here I'm selling 3 Satoshis in 2026:

It's simple, and that's why it's genius!

However. None of the modern systems work this way. Why?

Layer five. Scalability.

Keeping every amount as a fraction is an extremely flexible solution. However, it is slow.

Adding or subtracting? You need to find a least common denominator.

You need to reduce the results back, or you are risking blowing up past type boundaries.

The complexity and performance at scale are much worse. And considering the fact that everything is traded in decimal fractions now, it's much easier computationally to do: 1150 cents + 1075 cents rather than 11 1/2 dollars + 10 3/4 dollars.

Is there a way to add a stock transaction to a scheduled transaction (i.e. regular 401k contributions).

I can set the correct accounts for the debit/credit ledgers, but there doesn't seem to be a way to put in a default stock price / quantity for the transaction. So when the transaction actually runs I'm given a prompt which says "Needs Value", which I take to mean the value of the stock at purchase date.

Anyone have any ideas? I realize that I would have to update the actual value of the stock on the purchase date (instead of just using a default), but at least the majority of the entry would be created for me.

I've been a long time GnuCash user for about 15 years now, I found no alternative over the years with proper double-entry structure and multi-currency handling.

The shutdown and phase-out of OFX/DirectConnect was a major bummer for me, as reconciliation through downloaded files is a major pain.

I finally had enough and built a OFX/DirectConnect bridge myself, providing a URL for the "online banking" feature in GnuCash, which fetches all the bank accounts I have through a bank API aggregator (at a very low cost). Here's a screenshot of how it's working for me:

I'm perfectly happy using this myself, but if there are enough people in the community interested, I'd be happy to publish this somehow and let others enjoy the same benefit too.

I'm experimenting with Postgres backend and Grafana. My question is: What kind of diagrams would you like to see? Which ones do you think are meaningful?

Can also be tables.

My bank recently shut down download of OFX files, indicating that I can sync my accounts with the bank directly through Quicken.

Have you experienced this? Thoughts?