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 _______________________________________________ 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.
