Kalpesh, If it has changed it will be relatively recent. There was a fair bit of discussion at various times in the archive pointing out that if you didn't complete the import process the data wasn't added into the frequency tables. Some people were not assinging accounts in the import letting it all go to the Imbalance accounts and then manuallly assigning accounts after the import. I haven't had a look at the code in that area recently but AFAIK it was the case when I was documenting the importer after Geert had rewritten the CSV importer which may be close to 10 years ago now.If I get a bit of free time I'll take a look at the code.
David On Wed, 2026-03-11 at 16:54 -0400, Kalpesh Patel wrote: > David, > > I'll have to test it to get to bottom of that mystery -- it is easy > enough -- but I vaguely recall able to do that and exploiting it > during bulk imports. I'll grant that it was in 3.x version when I > migrated back in 2020 so likely things may have changed since then > and I might have discovered a short lived bug that might have gotten > abused, or I used some other flow and conflating them. > > > -----Original Message----- > From: David Cousens <[email protected]> > Sent: Monday, March 09, 2026 10:12 PM > To: Kalpesh Patel <[email protected]>; 'Byron Bray' > <[email protected]>; [email protected] > Subject: Re: [GNC] Banking Account - Imported QIF data and Opening > Balances > > > > Kalpesh, > > If you don't complete the import the matching data and the frequency > data for the probability calculation is not saved. I have often > thought it would be good to be able to use the existing data in the > file to train/retrain the matcheralthough that is of little use for a > new file. > > David > > On Mon, 2026-03-09 at 21:17 -0400, Kalpesh Patel wrote: > > Byron - > > > > 1 - The short answer is no. Reconciliation has no effect on > > matcher. > > Only previously encountered transactions and its disposition is > > memorialized for next time. The matcher is also imprecise because > > multiple variables are involved so it getting 100% right is very > > remote in a bulk import. Matcher may minimize how much labor of > > clicks > > you will have to do, but you will still have to review each and > > every > > transactions in the matcher validation window after the import to > > make > > sure that it makes it to correct second leg of the transaction. > > BTW, > > there was a very good insight few weeks back as to how matcher > > works > > so if you are interested in in-depth details then search the > > archives > > of the list. > > > > 2 - Once you export into QIF file from Quicken, open up the file in > > your favorite text editor and look for 'CR' string on a line by > > itself. There should be one for each transaction that is > > reconciled. > > Remove that line in its entirety from the entire file so when > > importing those transactions it won't overwrite reconciled setting > > in > > gnucash. Do make sure you also set 'Not cleared' preference flag > > setting underneath 'Default transaction status' text in 'Edit' --> > > 'Preferences' --> 'Import' setting page before importing. > > > > 3 - You can create the top most accounts manually and then let the > > gnucash create other account during import. You can always rename, > > move, consolidate and re-parent account somewhere else so don’t get > > too much hung up on getting tree set up correctly; in gnucash it > > is > > way-way easier to move all transactions from an account. Create the > > critical accounts manually so you know where they are and be able > > to > > specify them during import match validation to assign if matcher > > didn't match them correctly. Worse case is move Quicken on left > > half > > of the screen and gnucash on the right half of the screen. Then use > > cut-&-paste facility of the MS Windows to copy name of the critical > > account from left half to right half. > > > > > > The key, though, to remember here is that *categories in Quicken* > > will > > end up being same named *accounts in gnucash* when importing. > > Anything other than pre-created accounts for Quicken transfers, you > > will end up telling the importer to create those categories into > > account in the import matcher. By pre-creating your critical > > accounts, > > and importing small number of repeated transactions, it will train > > the > > matcher to match bulk of it as possible and improve itself. > > However, > > the ones that are not matched properly, you still will have to > > guide > > the matcher to the proper ones from the pre- created accounts. > > Whatever you do, do *not* import more than one accounts at a time. > > The > > reason is that once you import the large account (which creates all > > necessary account in gnucash), the majority of the transactions > > from > > the smaller account should be nothing but second leg against the > > larger account that were already imported, so matcher should be > > able > > to do better job matching -- and the ones it doesn't you can guide > > it > > to tell it what the match should be for next time while minimizing > > how > > much you do so manually. > > Essentially goal is breaking import into three camps to get > > transactions into gnucash intact in any which way you can: one > > large > > camp that you will import as-is; second camp is you will manually > > tweak to match; and third camp is to chip at the second camp by > > letting matcher do the work by breaking up imports in batches and > > training. > > > > I vaguely recall that you can train the matcher without importing > > transactions by doing all the steps of the import except the last > > step > > of the actual import and canceling it. But I am not too sure of it > > at > > this point, though. > > > > HTH > > > > -----Original Message----- > > From: Byron Bray <[email protected]> > > Sent: Sunday, March 08, 2026 8:42 PM > > To: [email protected] > > Subject: Re: [GNC] Banking Account - Imported QIF data and Opening > > Balances > > > > Kalpesh, > > > > Thanks for those observations; they add some welcome perspective … > > and, of course, stimulate more ideas and questions. > > > > 1 - I didn’t realize that transfers might be the a source of > > problems; > > I assumed that all transactions for a given account would be > > imported > > and that the matcher would match them up when the corresponding > > accounts (with transfers to/from) were imported. I’ve only read > > about > > the matcher, so far, and have concentrated on only one bank account > > (the business account; the most critical), so your perspective is > > most > > helpful. Is there any benefit to importing the accounts with > > transfers > > between them at the same time and then reconciling? Would that > > mitigate this behavior? > > > > 2 - I did not know that QIF files could be edited with a text > > editor; > > silly man that I am (and with a good deal of database programming > > background that involved text-file parsing and processing) somehow > > it > > never occurred to me to crack one open and look. I would very much > > appreciate any advice that you would care to offer. I’ve been going > > through the “Previous Statements” window in Quicken and un- > > reconciling month by month but that is tedious and there are quite > > a > > few accounts to process and import. My Quicken file contains all of > > my > > financial activity going back a good 25 years but I only want to > > move > > records for the last 7 to 10 years into Quicken (basically > > audit-proofing myself). > > > > 3 - With regard to account tree creation, I had come to the same > > conclusion; again, tedious but probably necessary. I tried > > exporting > > just “accounts” in the Quicken export window but the accounts in > > GnuCash were empty after importing. I’ll keep tinkering with it. > > > > You suggested choosing a date after which transactions were of > > current > > importance and importing from there, leaving Quicken in place for > > consultation of older data. I will do that, using the 7-10 year > > timeframe suggested above. My versions of Quicken is, of course, > > 32- > > bit but the OS version on my new machine is 64-bit only; hence the > > need for the move to GnuCash in the first place. But I can keep my > > older machine around to house the 32-bit version for historical > > queries. I may well follow your path by constructing the account > > tree > > manually and then, as you, Liz and others have suggested, importing > > a > > few months at a time, saving a version of the GnuCash file each > > time. > > The part should be easy as the MacOS’ Time Machine does saves on > > hourly, daily, weekly and monthly bases. > > > > Again, Kalpesh, thanks for that information and insight and many > > thanks to all of you who have offered so much good information and > > advice. I very much appreciate it. > > > > - Byron > > > > ================ > > > > > > > On Mar 3, 2026, at 2:44 PM, Kalpesh Patel <[email protected]> > > > wrote: > > > > > > Byron: > > > > > > You are correct in what you stated below. > > > > > > Couple of additional suggestions ... > > > > > > 1- If there are transfers in Quicken (say between bank account to > > > a > > > bank account) then those are the types of transactions that are > > > likely to error during import. When I imported almost 3 decades > > > of > > > transactions in thousands, transfers of these type where the most > > > pain (besides the brokerage accounts). > > > > > > 2 - Assuming you are importing QIF format from Quicken to > > > GNUCASH, > > > you can hand edit the QIF file before importing to remove the > > > reconcile flag with any editor's search and replace operation. > > > QIF > > > files are in plain text. Let me know if you need these details on > > > what to remove. > > > > > > 3 - You may have to create the Quicken Account in GNUCASH > > > manually > > > if the import of just the account tree from Quicken is not > > > working. > > > > > > By any chance are you using year end copies for your Quicken > > > books? > > > Sounds like no. > > > > > > The other suggestion I can make is that if the prior transactions > > > in > > > Quicken are not that important than you can start afresh with > > > closing balance of Quicken as the Opening balance of GNUCASH and > > > go > > > forward from there on. You can keep Quicken around to consult for > > > old transactions if need be. This only can be done if it is 2017 > > > or > > > prior version, though, as Quicken really insist on you paying > > > them > > > their due homage after that version. You can do year end copies > > > and > > > then start a fresh for the following year in GnuCash. > > > > > > Reconciling imported transactions is multi-month effort and even > > > then it is trial-and-error basis. I am still doing clean up now- > > > and-then from when I imported back in 2020, and I had few > > > transaction that would refuse to import so had to hunt in the QIF > > > file using plain text editor. Nonetheless, it is best conquered > > > in > > > pieces as GNUCASH isn't designed to be able to import everything > > > correctly in one fell swoop. It is not because GNUCASH is bad but > > > it > > > because QIF format is imprecise so it has to be helped to clarify > > > things. As I stated earlier, I ultimately ended up importing in > > > batches few months of transactions from one account at a time > > > after > > > creating the account tree first. As others have mentioned, when > > > you > > > are at the right place -- the balances are correct, and it > > > reconciles correctly -- make a backup of the file before moving > > > onto > > > the next batch of import so that you don’t have to start from > > > scratch. > > > > > > HTH. > > > > > > -----Original Message----- > > > From: Byron Bray <[email protected]> > > > Sent: Monday, March 02, 2026 8:10 PM > > > To: [email protected] > > > Subject: Re: [GNC] Banking Account - Imported QIF data and > > > Opening > > > Balances > > > > > > > > > Kalpesh, > > > > > > Thank you! It is not too late. I had just finished un-reconciling > > > the main account (my business account) in a copy of my QIF file, > > > going back to 2020. > > > > > > > 1) It allows you to review in small batches to make sure that > > > > import is correct and reconcile them before importing next > > > > batch > > > > > > I was just about to try that but will heed your advice and do a > > > few > > > months at a time. > > > > > > > 2) It also helps trains the matcher algorithm and lesson the > > > > effort if there are any re-import of the same transactions. > > > > > > I was unaware of the Bayesian matcher algorithm but some research > > > has been enlightening; thanks for mentioning that. > > > > > > > Are you importing multiple accounts at a time or one account at > > > > a > > > > time? If you are doing multiple account at a time then you want > > > > to > > > > start first with bringing just the account tree and then > > > > starting > > > > with importing largest account first moving down to smaller > > > > ones > > > > for matcher to match them up as the second leg that might be in > > > > the largest account for transfers. > > > > > > > > > Thank you, thank you, thank you! I was unaware of (and had > > > wondered > > > about) GnuCash’s ability to handle the many account transfers in > > > my > > > data. I had tried to export just the account structure from > > > Quicken, > > > but found that that did not produce any result whatever. > > > Unless GnuCash can match them in subsequent imports > > > automatically, I > > > expect that I would need to: > > > 1) Import the business account transactions and their associated > > > accounts and then > > > 2) Manually construct any additional accounts in gnu cash, and > > > then > > > 3) Use the matching phase of the import process to match the > > > quicken > > > account transfer to the appropriate gnu cash account. > > > > > > Please correct me if I am wrong in any particular. > > > > > > Many thanks, > > > > > > - Byron > > > > > > ===================== > > > > > > > On Mar 2, 2026, at 1:39 PM, Kalpesh Patel > > > > <[email protected]> > > > > wrote: > > > > > > > > I am not sure if this is too late or not but recommendation is > > > > to > > > > import limited se of transactions at a time (perhaps 1 to 3 > > > > months > > > > at a time depending on number of transactions) for few > > > > reasons: > > > > > > > > 1) It allows you to review in small batches to make sure that > > > > import is correct and reconcile them before importing next > > > > batch > > > > which can help you flag down import error which is going to be > > > > in > > > > the non-reconciled transactions. It is a lot easier to flag > > > > down > > > > an errant import entry in a small set of transactions then all > > > > in > > > > one fell swoop. > > > > > > > > 2) It also helps trains the matcher algorithm and lesson the > > > > effort if there are any re-import of the same transactions. > > > > > > > > Are you importing multiple accounts at a time or one account at > > > > a > > > > time? If you are doing multiple account at a time then you want > > > > to > > > > start first with bringing just the account tree and then > > > > starting > > > > with importing largest account first moving down to smaller > > > > ones > > > > for matcher to match them up as the second leg that might be in > > > > the largest account for transfers. Keep in mind that in Quicken > > > > Categories are Accounts in GNUCash so you have to have them > > > > setup > > > > before importing if you have transfers in Quicken, and are > > > > likely > > > > to error when you bring them over. > > > > > > > > Worth case scenario is to reconcile month by month which will > > > > help > > > > narrow down where the transactions might have been imported > > > > incorrectly. You can always reconcile same set of time periods > > > > in > > > > GNUCash without any adverse impact. > > > > > > > > HTH to get your account reconciled. > > > > > > > > -----Original Message----- > > > > From: Byron Bray <[email protected]> > > > > Sent: Sunday, March 01, 2026 8:46 PM > > > > To: [email protected] > > > > Subject: [GNC] Banking Account - Imported QIF data and Opening > > > > Balances > > > > > > > > Friends, > > > > > > > > I need some guidance as to the proper setup and handing of > > > > banking > > > > accounts (at least) in GnuCash. I have spent the better part of > > > > two days, read dozens of postings to the GnuCash lists and > > > > watched > > > > dozens of videos, trying to resolve the issue I am seeing but, > > > > bright as I like to think I am, I am clearly missing something; > > > > it > > > > is my hope that you can help me. > > > > > > > > I am trying to shift my accounting data from Quicken to > > > > GnuCash. > > > > My operating environment: > > > > Computer: Mac Pro (2019) > > > > OS Version: MacOS 15 (Sequoia) > > > > GnuCash version: Version: 5.14 Build ID: 5.14+(2025-12-20) > > > > > > > > I imported a Quicken QIF bank account, after making sure that > > > > the > > > > account was accurately reconciled for the period of the import. > > > > Having completed the import, the Reconciliation window reported > > > > a > > > > Starting Balance, Reconciled Balance and Difference of almost > > > > $1,000. I had read that the way to overcome this was to simply > > > > enter an opening balance transaction in Equities and reconcile > > > > the > > > > first month, entering the accurate Ending Balance and > > > > performing > > > > the reconciliation; subsequent months should, I read, display > > > > the > > > > correct information. > > > > > > > > I created an “Opening Balance” transaction to take place on the > > > > last day of the month prior to the imported data, entering the > > > > balance as of that date and linking it to “Equities:Opening > > > > Balances”. I entered the Reconcile window, set it for that > > > > previous month, made sure the “Ending Balance” was correct and > > > > checked the box for that “Opening Balance” transaction. The > > > > “Finish” button was disabled because it didn’t take into effect > > > > the erroneous ≈$1,000 Starting Balance. > > > > > > > > Then, I created a balancing transaction and dated it the month > > > > before the first transaction in the imported data and attempted > > > > to > > > > reconcile that month. This time it DID enable the Finish button > > > > and completed the reconcile. When I opened the Reconcile window > > > > for the following month (the first imported month), the window > > > > for > > > > the following month reported that the Starting Balance, the > > > > Ending > > > > Balance, the Reconciled Balance and the Difference were all > > > > $0.00 > > > > … which was just what one would expect. > > > > The only problem is that the running balance for the entire > > > > account, as shown in the register, is almost $1,000 less than > > > > the > > > > actual balance. > > > > > > > > I’m hopeful that you know a better solution than this but at > > > > this > > > > point, the only way I can see to arrive at a ledger whose > > > > balance > > > > and reconciliation data are accurate is to go back to Quicken, > > > > un-reconcile all of the thousands of transactions in this > > > > account, > > > > export the data, import it into GnuCash and then reconcile them > > > > all again. I fervently hope that there is a better solution > > > > than > > > > this. > > > > > > > > Any advice you can give me would be gratefully received and > > > > carefully considered. Whether you can suggest a solution or > > > > not, I > > > > want to thank you, in advance, for your time and energy. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > gnucash-user mailing list > > [email protected] > > To update your subscription preferences or to unsubscribe: > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > ----- > > Please remember to CC this list on all your replies. > > You can do this by using Reply-To-List or Reply-All. > > -- > David Cousens > > -- David Cousens _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
