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.
