Can I define custom keybindings in Moneydance?

jimrh's Avatar


03 Apr, 2020 09:37 AM


  1. If this has already been answered, accept my apologies. I looked and did not find it.
  2. If it's so obvious even Stevie Wonder would see it, again, my apologies. I looked in all the obvious places and did not see it.

Is it possible to create custom keybindings for various functions within Moneydance?

As I check transactions against a bank statement, I would like to leave "breadcrumbs" to let me know what I've already checked. To do this, I would like to use the "Reconciling" mark as it is easy to see, has a uniform meaning, and is easy to select by.

The problem is that the key-combination to select "Set Resolving" is ALT-CTL-R, a three armed paperhanger of a keyboard shortcut. In order to use it, I have to stop what I am doing, reposition my hands, mark the transaction, and then reposition my hands again to continue. It breaks up my workflow as badly as using the mouse would.

I would like to re-define this as either a single keystroke, (the ideal), or a shifted keystroke, using a key not normally used in Moneydance - perhaps "Pause/Break" or SHIFT-Pause/Break This would give me a "type-type-type-WHAP! - type-type-type-type-WHAP!" keyboard workflow.

Can this be done, or am I smoking dope?

  1. Support Staff 1 Posted by Ethan on 03 Apr, 2020 03:31 PM

    Ethan's Avatar


    No, it is not possible to change the keyboard shortcuts for the program.

    Is there a reason you're reconciling from the register instead of using the reconciliation function ( That would involve even fewer clicks or keystrokes. Let me know if I'm misunderstanding your process.

    Infinite Kind Support

  2. 2 Posted by jimrh on 03 Apr, 2020 04:17 PM

    jimrh's Avatar

    Maybe I'm doing things the "stupid" way - probably am! - but I tend to work on my banking in LARGE chunks instead of month-by-month, as I have too many other things on my plate. (Translation: Once or twice a year. . .)

    (As my brother says, I really need a bookkeeper!)

    Credit card transactions with my bank, (almost), never agree on the date - the transaction posts at my bank on date "x", but the transaction posts to the credit card's bank a day or three later on date "y". As a result, the transactions never bind together correctly and I have to manually go through each and every transaction to link them.

    As mentioned in a previous post about BOA's QFX files, the OFX standard that QFX is based on, is rather vague about how a transaction should be styled - formatting is also left to the option of the bank's developers as well. The result is that if you download four or five QFX files from four or five different places, it's an even money bet that there will be differences in the way they import.

    Because of #1, when I import my bank data, and then import all my credit card data, there are a lot of duplicated transactions in both the bank's register and the credit-card register that require manual fixups - which I do when I go through all the registers and link transactions.


    Because of the amount of manual rework needed, my last step is to "walk" the registers and compare them, line by line, with the associated statement printouts. Along with satisfying my obsessive/compulsive paranoia, (wink!), it gives me another chance to verify that transactions are correct and categorized properly. (And it helps me find data I inadvertently didn't download when I grabbed the bank's data - or forgot to import!)

    Unlike you wiz-bang professional accountants out there, I'm a total tyro at this - I'm more comfortable with a computer's parts scattered in front of me than at the keyboard working with bank data. . .

    Since I do this line-by-line, it would be nice if I could do it this way.

    Unfortunately, even M$ can't help me with this - their ability to remap keys is limited to the main keyboard keyset - and hand-editing DLL files using a HEX editor is not high on my list of things to do either - so I guess I'm sunk.

  3. Support Staff 3 Posted by Ethan on 03 Apr, 2020 04:38 PM

    Ethan's Avatar


    Thanks for the descriptions. For many things like this, there isn't necessarily a right or wrong way, just what works best for your workflow.

    To clarify a few things:

    You can use the Account -> Reconcile function over any period of time. It will always bring up all uncleared transactions. You could do this once a week, month, year, etc. Again, your way is fine if that works for you; you just seemed to be suggesting that the reconciliation system was made for monthly reconciliations, which isn't the case.

    I'm a bit unclear from what you describe if you are going through the confirmation process after you download your data from your bank. I ask because a difference of only a few days between when a credit card payment is posted at your bank versus credit card accounts shouldn't be so large that it affects the confirmation processes matching and merging of transactions functions. A difference of something like three days seems pretty standard. If those transactions are not being suggested to merge, then you perhaps have your day difference settings for this set too low. Go to File -> Preferences, click on the Network tab, and increase the number for the "Only match downloaded transactions when they are at most X days apart" field.

    Infinite Kind Support

  4. 4 Posted by jimrh on 03 Apr, 2020 04:49 PM

    jimrh's Avatar

    Actually, I'm not that stupid. :wink:

    What I do is look at a known transaction - say the end of one statement period and verify that it agrees with the ending balance. Then I go to the end of the next statement and check to see if the ending balance matches my register.

    If it does, Everything is marked "Reconciling"
    If it doesn't, I walk that particular statement looking for issues.

    That gets me through the data much faster - especially since I've done 99% of the fixups anyway.

  5. 5 Posted by jimrh on 03 Apr, 2020 05:29 PM

    jimrh's Avatar

    Actually, what I get is a bunch of duplicates.

    I import the data from my bank, (without the credit-card data import yet) and it assigns all the credit card transfers to some pre-defined "default" category - let's call it "???".

    When I import each of the credit card's data files, transactions that should go back to the bank don't match anything and - ergo they are automagically classified as "???"

    So, I have a bunch of transactions that go to Zombie Land.


    Because the descriptions are never in "plain English" - but rather in "Financial Gibberish" I have to hand-edit every transaction. (Find and Replace is your Friend!)

    A typical transaction looks something like this:
    POS Withdrawl (FIS) SISTEMA SAADOVYH CBA Fee:0.05 SISTEMA SADOVYHCENT SHCHERBINKA RU(1756) followed by whatever the transaction amount is.

    In most cases, I recognize the transaction and re-type it because it's butt-ugly. In some cases, it's TOTAL gibberish - "GELMGOLTSA" anyone? - so I have to research it. This one turns our to be a doctor's visit at the Helmholtz National Research Laboratory of Audiology and Visual Sciences. Sheesh!

    I end up doing this five mortal times - and then I have to LINK transactions between the accounts.

    As I discovered in a previous posting, (from last year when I started all this), Moneydance is much more strict about "proper accounting practices" than Quicken was. Quicken didn't care if the $257.44 payment to credit card "X" "left" the bank on one day and "arrived" at the other bank a few days later.

    Moneydance, on the other hand, absolutely stomps its feet, refuses to recognize the relationship between the two transactions, and assigns them to bogus categories.

    Since I assume the credit card bank's date is The Word Of God, I link that transaction back to the main checking account by going to the "bogus" category's "register" and re-assigning the category to the proper account.

    Eventually, at the credit card side, "show other side" now matches a corresponding transaction in the checking account's register.

    NOW there's a lot of duplicated transactions and balances are all over Hell and Half of Texas. So, I go through all the accounts and "de-dupe" them by comparing them to their associated printed statement.

    Then there's this special transaction step that removes the big blue dot - I forgot what it's called - which resets all the transaction data that I have carefully crafted back to the original financial gibberish, so I have to go back and do it all over again.

    Eventually. . . . . :swear:

    I get all the data into recognizable English, categorized correctly and - when necessary - linked to the correct transaction in the corresponding matching register.

    Now, having sent something like five complicated financial registers through my Ronco Mangle-O-Matic, (As Seen On TV!), "But wait - there's MORE!!" - I have to walk through the registers to make sure absolutely everything has fallen back into its appropriate pigeon-holes. Which it usually hasn't. Ergo, more rework.

    Finally, finally, I get all five accounts and all their transactions to line up straight and tall like so many wooden soldiers. At this point in time what I really want to do is get drunk - but instead I run a series of reports.

    Then I look at the distribution of the data to make sure it makes sense, (what's this $572.53 transaction for "Incidental Meals"?), make whatever changes are necessary, and (eventually), send it all off to my accountant to munge into the proper form for tax purposes.

    Once that's all done, then I get drunk! :wink: Just kidding, but I really need a vacation by then.

  6. Support Staff 6 Posted by Ethan on 03 Apr, 2020 06:22 PM

    Ethan's Avatar

    I think you're actually creating a lot of extra work for yourself with what you describe. I'd recommend trying to go through the confirmation process (what you describe as the "big blue dot") first after importing data from your bank before making these changes. The confirmation process is where you should be doing things like setting the correct category, merging transactions, and so on. After you do that, if you need to change anything else in the transaction, like making the descriptions clearer, go ahead. And only after that should you do a reconciliation.

    While you eventually get the desired outcome with your workflow, it sounds like you're having to set the categories at least twice, and some of the manual changes you're making early on are interfering with Moneydance's ability to suggest transactions to merge. The confirmation process is what's supposed to make a lot of what you describe easier, but you seem to be dismissing it as something you just need to bypass after you've made all these manual changes.

    Infinite Kind Support

  7. 7 Posted by jimrh on 03 Apr, 2020 08:51 PM

    jimrh's Avatar


    I guess I'm still "unlearning" a lot of the Quicken workflows. . .

    In Quicken, what you call "confirmation" was part of the import process - data didn't end up in the register until you "approved" it - I forget their term for it. Since Moneydance moved the data directly into the register, it appeared that this "confirmation and merging process" wasn't there.

    Stupid question time:
    Given I have one "master" checking account that - like the doxology - "from whom all blessings flow" - and several subsidiary credit-card accounts that report back to the checking account.

    Assume that I am at a stable state and all data is present and accounted for as of a point in time and everything is "cleared".

    I then import a huge chunk of checking account data that has no corresponding credit-card data to link transactions to. . . What happens? In my case, the checking account debits that should link to the (nonexistent as of yet) corresponding credit-card account credits, end up being classified as a bogus category.

    Then, when I import the credit-card data, the credits from the checking account have nothing to bind back to, since the dates are different, and they end up being assigned to the same bogus category.

    In fact, virtually everything, when initially imported, gets assigned to that bogus category and I have to manually re-assign the transactions to the category they belong to.

    In Quicken, the import process consisted of "renaming rules" that - when a match was found, the payee name and category were automagically updated. The nifty part of that was that you could decide how much of the transaction data had to match.

    Given three transactions from the same chain of gas stations:
    (POS) TATNEFT 117235 (etc)
    (POS) TATNEFT-VS3343-81

    I could set a renaming rule to match a transaction of type "payment" (debit), that contains "TATNEFT", and it would correctly rename each transaction, regardless of the branch, location, routing code, or transaction type code.

    As far as I know, in order for a transaction to auto-categorize in Moneydance, the entire transaction has to match in every particular. (i.e. Every time I stop and get gas at a different Tatneft station, or if the POS system gets upgraded, renaming doesn't match.)

    How do I get this to work without hideous amounts of rework?

    Thanks for your patience!

  8. System closed this discussion on 03 Jul, 2020 09:00 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac