Importing and ExportingTable of Contents
The KMyMoney GnuCash importer handles direct reading of standard (XML) files as produced by GnuCash versions 1.8 and 2.0. The following are not supported:
import of database (Postgres) data
import of 'multi-book' files
import into an existing KMyMoney file
import of small-business specific features (Employees, Invoices, etc.)
export to GnuCash files.
The import will probably only work correctly if presented with a valid file. It is recommended that the → menu item of GnuCash be run before attempting to import.
Files can be opened by specifying the filename on the command line (kmymoney <path to file>), or by means of the KMyMoney → (Ctrl+O) or → menu items.
The similarity between the two products means that much day-to-day data can be imported in a straightforward fashion. However, there are some areas where differences arise, and various options are provided to deal with these. The following sections will describe some of these differences; understanding them should lead to a smoother importation.
It should be noted that KMyMoney is a personal finance manager, and as such, does not directly support any of the business features of GnuCash, such as tax tables, payroll, and tracking of lots. Any Accounts Payable or Receivable accounts found in a file will be imported as Liability or Asset accounts respectively.
For both products, the highest level of structure in the file is the account. KMyMoney supports 5 main types of account: Asset, Liability, Income, Expense and Equity, each of which may have various subtypes, e.g., Checking, Credit Card, etc. KMyMoney includes a 'standard' account for each of these five types, and all other accounts are held subordinate to one of these. KMyMoney enforces more consistency (or less flexibility, depending on your point of view) between account types than does GnuCash, and the importer will correct any inconsistencies it detects. This may result in a slightly different account structure, though this can, within reason, be amended after the import is complete.
KMyMoney uses the term Category to denote an account of an Income or Expense type. Unlike GnuCash, these are not considered as 'ledger' accounts, and entry of transactions folder into categories is not supported; allocations are made during transaction entry into other account types.
GnuCash supports the use of Placeholder accounts. In effect, these are just read-only accounts into which no transactions can be entered, but which function in an analogous fashion to folders in a folder structure, as a holder for other accounts. Though KMyMoney does not support this feature as such, it does provide a parent/child account relationship, so the importer simulates placeholders by creating empty accounts.
As with GnuCash, data is entered in the form of transactions, each generally consisting of 2 or more split entries. In fact, valid GnuCash transactions will always contain at least 2 splits, and to conform to GnuCash's double-entry bookkeeping standard, these must be in monetary balance (i.e., they must balance out to zero). KMyMoney encourages, but does not enforce, this standard, but any imported transaction which is not balanced will be marked in the ledger view as having a problem.
KMyMoney prefers that all transactions have a Payee (a generic term that encompasses both payees and payers), and unlike GnuCash, a list of these payees is maintained. Payee names are generated by the importer from the GnuCash transaction's Description field.
KMyMoney uses the term Transfer to describe a transaction which does not involve a Category, but only transfers money between Asset and/or Liability accounts.
GnuCash uses the term Commodity to cover both currencies and non-currency assets. These are treated separately in KMyMoney.
KMyMoney has built-in support for all foreign currency types. KMyMoney also requires that the user specify a base currency, this being the default currency for new accounts. The importer will attempt to determine the most likely base currency, though this choice may be rejected in favor of an alternative.
Note
KMyMoney does not currently support accounts denominated in 'defunct' currencies (except those replaced by the Euro). At present, it will be necessary to remove any such accounts from your GnuCash file before importing. We hope to improve on this situation in a future release.
Non-currency assets (normally stocks and bonds) are called Securities by KMyMoney, and represent the main difference between the two products, in that KMyMoney requires any account denominated in a security to be subordinate to an Investment Account. This is described in more detail in the chapter on Investments. Though users may have implemented such a relationship, GnuCash imposes no defined structure on it, so the importer is unable to detect it and perform an automatic conversion. Three options are therefore made available:
Create a separate Investment account for each security, with the same name as the security
Create a single Investment account which will act as 'parent' for all security accounts
Create several Investment accounts, and assign securities to them as directed by the user.
It depends entirely on user requirements which of these options is relevant in each situation, and in some cases, manual restructuring of accounts after importation may be necessary.
Security prices and currency exchange rates as displayed in the GnuCash Price Editor will be imported. In addition, price and rate entries will be generated from all transactions involving securities and multiple currencies.
For obtaining online price and currency rate quotations, GnuCash uses a
package called Finance::Quote. Recent versions of KMyMoney
contain support for this package for obtaining stock quotes, and this will be
used by default when importing data. You may however select to convert to the
native method used by KMyMoney which is covered in more detail in
online quotes.
If you choose to do so, the following dialog will allow selection of a
'native' KMyMoney price source, or a user-defined source, for each account
for which online quotes are required. However, the stock (ticker) symbol will
be imported unchanged. Since this symbol will almost certainly be different in
the two packages, it will need to be manually edited after completion of the
import process. Future currency rate updates will not use Finance::Quote,
and will always use the native retrieval method.
KMyMoney does not retain the separation made in GnuCash between template transactions and their frequency of occurrence. Transaction data will be duplicated if the same template is used in different schedules, but this is not likely to be of great significance.
KMyMoney classifies all schedules as one of three types, Bills, Deposits, or Transfers. Since GnuCash does not make such a distinction, the importer attempts to determine the classification from the accounts and direction of money movements. It may be that in some cases incorrect assumptions are made, and these will need manual correction.
Some features of GnuCash scheduled transactions are not available in KMyMoney, so the importer tries in each case to reach a reasonable compromise in converting the data. These transactions will be flagged as suspect, and the user will be given the option of editing them directly during the import process. Examples of situations which may cause this are:
some frequency intervals supported in GnuCash are not currently available in KMyMoney
KMyMoney does not support the use of formulae and variables in amount fields
complex cases which have not yet been identified for import.
Despite best efforts, it is possible that, due to the many options involved, a scheduled transaction may cause a fatal error within KMyMoney. If this sort of problem seems to be occurring, the importer offers the option to drop all suspect schedules.
KMyMoney provides a comprehensive selection of configurable reports, described in more detail in Reports. These will not necessarily, however, match precisely those reports available in GnuCash.
See "Securities and Investments" above.
Turn this off if you wish to use the native method for future online price quotes.
See "Online Quotes" above.
See "Scheduled Transactions" above.
If your native language is written in letters or symbols which are different from those used in the 'Latin' languages (i.e., generally Western European), these are represented in a special fashion ('encoded') in your GnuCash file. If these letters are not displayed correctly on your screen, then they must be decoded. Currently, it is often not possible to detect accurately which form of decoding must be used, so you may need to set this option and select an entry from the list. In general, the first item in the list will be that which is considered appropriate for your locale (i.e., the country and language which was selected as native when your operating system was installed), so this should be tried first. Since the import process does not overwrite your GnuCash file, you are free to experiment with any of these selections.
Under some usage conditions, non-split GnuCash transactions may contain residual, often incorrect, memo data which is not normally visible to the user. When imported into KMyMoney however, due to display differences, this data can become visible. Often, these transactions will have a Notes field describing the real purpose of the transaction. If this option is selected, these notes, if present, will be used to override the extraneous memo data.
These need only be used in the event of import problems. If you have such
problems, you should also report them to the KMyMoney developer list
(kmymoney-devel kde.org). Note that the traces produced by these options may contain data of
a confidential nature, and the Anonymize data option
should be used if they are to be made publicly available.
At the end of processing, the importer produces a report showing the number of different entities processed, and any errors or anomalies encountered. This report will be displayed on screen, and may be saved to a file for later review. A full report may contain the following sections:
Record counts
Inconsistencies in account types and actions taken
Details of suspect schedules
