[GNC] Why I create a new datafile each year for GnuCash

Adrien Monteleone adrien.monteleone at lusfiber.net
Mon Oct 21 13:08:26 EDT 2019


Certainly, to each their own. I enjoy reading of other’s process and workflows and why they make certain decisions. Thanks for offering yours.

My own experiences are in-line:

> On Oct 21, 2019 w43d294, at 2:15 AM, James Thorpe <James at fusionsystems.co.za> wrote:
> 
> In another discussion "How to set a customer opening balance for the Customer Report" which has been satisfactorily resolved, Derek Atkins asked why I am creating a new data file. I did pose the original question as if moving from a different system so as to avoid the discussion of why I'm creating a new data file but since Derek asked, I do in fact create a new data file in GnuCash for each financial year for the following reasons-
> 
> a) Fear of corrupting previous year's transactions
> 
> Once my financials are done for the year and reported on, I do not wish to inadvertently enter or modify a historical transaction that will result in the same reports producing different results. It is easy in GnuCash to enter a transaction with a date for a previous financial year or, mistakenly change the date of an existing transaction without noticing it.
> 
> I enjoy the fact that I have the power to do this but fear making a change by mistake
> 
> A way to combat this could be to just make a copy of the file at the end of each FY as an "archive" file that I use for reporting and/ or checking the current file in case there are historical corruptions. In combination, I could perhaps also enter a "closing balance" entry on all accounts at year end that records the closing balance in the description that could then be checked from time to time to ensure all is in order.

As Stan noted, the read-only threshold setting could be used here, and as I replied, this would be much more useful as a date entry rather than a ‘days old’ entry.

But your suggestion of an archive file is something others have discussed here before. They keep one file, but archive it at year end along with all of their formal reports. If they ever need to run a different report again ‘officially’ they do so from that archived copy.

Some benefits to keeping that single ongoing file are below.
> 
> b) Size of file / speed of access
> 
> I know there have been discussions regarding this but I am concerned that with 10+ years of data things will slow down, especially if the entire file is read into memory. I like being able to access gnucash from low powered machines.

I think that tends to be more of a problem with reports left open than data file size. If you leave a report tab open when closing GnuCash, it will dutifully restore all of your tabs when you re-open. Some reports, like the Average Balance report need some speed optimization. (it has been known to take many minutes to complete) The larger the data file, the longer that report takes to finish. Thus it looks like GnuCash is choking on a large data file. The real culprit is just that one report. (though there may be others)

Two possible solutions are:

1) close all report tabs when exiting. Registers are fine.

2) don’t close GnuCash unless you really have to. This is what I do. I’m on an OS that has virtual desktop spaces (not sure if Win ever implemented this) but even with it minimized this would still work fine. I have accounting entries to make on nearly a daily basis, so it makes sense for me. (and I’m lucky enough to have plenty of RAM not to worry) So this likely wouldn’t work with low powered machines, but option 1 certainly would work fine.

> 
> c) Complexities with reports that don't look at date ranges (eg. Trial Balance)
> 
> Certain reports just look at the final balance in the account - eg. the Trial Balance report. This means that if I draw a TB the expenses, income etc will report the total for the entire period for which I've been using GnuCash. What my accountant wants in my Trail Balance report is my total expenses for the year, not forever. I gather that the "Close books" function may be able to resolve these issues but have not looked into this further.

I don’t close books, but I also don’t use that report. So I can’t speak from experience, but even with closing the books, I think the report will still look at all transactions. The Close Books procedure simply makes two multi-split transactions, which zero all expenses and income accounts to Equity:Retained Earnings. Your assets (including AR), liabilities (including AP), and other Equity accounts are unaffected.

The historical transactions are still there with amounts. The report will just get to the closing transactions and subtract them all out again.

Perhaps this would be a good RFE for that report to allow specifying a date range.

> 
> d) Refinement of my accounting process
> 
> Being a complete noob to accounting, I've been slowly improving (hopefully) the way I do things from year to year as I learn. As a result I may create new accounts and delete others from year to year and starting a fresh file each year allows me to have the chart of accounts better reflect my latest process. In addition, the entries will be more consistent in each file - representing the way I currently process transactions.

I refactored my account tree quite a bit during my first 6-9 months of GnuCash. (I had used Quicken years before, but was never very diligent, and didn’t even bother importing, I just started fresh.)

I refactored again about a year or two later as I started using the budget module and running comparison transaction reports. Thankfully, during my first refactoring, I learned that I need to put as much detail and breakdown receipt line items rather than consolidate them. I still have a few transactions I have to leave as ‘generic’ expenses, but for the most part I now have a better grasp on where, what and why I’m spending.

I’m in the middle of refactoring some accounts again as I’m refining some newer types of expenses.

If I had started a new book each year, and I wanted to compare spending across periods apples:apples, I wouldn’t be able to do so without refactoring EACH file. By having everything in one file, each refactor happens only once. If I move transactions from one account to another, they all move - not just the current year.

It doesn’t bother me that now last year’s expenses look different then it did on Jan 1. It is just my organization that changed, the money spent did not. And if I did make an error with a transaction in how it was recorded, I’d rather it be fixed. Any need for ‘official’ numbers that were tied to any ‘official’ filings can be preserved in an archived pdf version of said reports. Otherwise, if I want to change my apples to oranges, I need that to happen across the board so period comparisons are meaningful and don’t require additional mental gymnastics, or trying to remember old ways of organization in my chart that I haven’t used for years.

These period comparisons are another reason I don’t close my books even with the same file. I’d lose some of that reporting ability because the closing transactions would interfere with them.


> 
> Having said all of this - there are certainly downsides to creating a new file each year as the previous question highlighted. Firstly, the business features don't translate well year to year and then, of course, it's a labour intensive manual process to set up a new file and get all the opening account balances right, re-create the customers, re-set up the business information and counters etc.

Yup. GnuCash was designed to keep one file forever. Closing Books was a requirement based on the limitations of paper volumes. Computers have no real limit here, at least not one most people are going to encounter.

Some features have been added to accommodate those who still prefer the old paper processes, but as you’ve found, this is a bit incomplete.


Regards,
Adrien



More information about the gnucash-user mailing list