Chapter 3. Accounting with Eqonomize!

The basics principle behind accounting in Eqonomize! is the idea of money flowing through transactions between accounts as reservoirs. A transaction represents a gain (you receive money), loss (you buy something), or transformation (you withdraw from or deposit in a bank account) of money.

A transaction always means that money is moved from one account to another. An expense (something is bought) can for example mean that you pay with cash from your cash account. The money is then put in an expense account. This account represents the products and services you pay for. It represents the money that you do not have as a result of expenses, and is therefor useful for record keeping.

Incomes is usually put in a bank account and withdrawn from an income account. This means that income accounts will have a negative value, but to avoid confusion, the value of income accounts are shown as positive values.

Different income and expense accounts are used for categorisation, and are therefor more naturally referred to as categories. Other accounts, which represents the money you actually have and often are real world bank accounts, are simply referred to as accounts.

Eqonomize! has three different basic transactions types – expenses, incomes, and transfers. Securities uses some special transactions which are described in the section called “Securities”. The account types debt and credit card are used for lialibilities, the rest for assets. The securities type represents special accounts that are the only ones that can be associated with securities and only supports security transactions.

Expenses represents a loss of money, a transaction where you give away money, mostly in return for something else. This can be a payment for products and services, or a gift (or you lend someone money).

Incomes represents a gain of money; when you are given money. This is when your at the other end of an expense, when you receive payment for products and services you provide (often as salary for your regular job), or when someone gives you money as a gift or loan.

The third transaction type, the transfer, represents neither a loss nor gain, but a transfer of money from one account to another. This can for example be when you withdraw money from your bank account as cash, or you transfer money to a savings account.

Each transaction has a number of mandatory or optional properties. All the basic transactions have four mandatory properties – value, date, and from and to accounts/categories. Value represents the amount of money that is affected by the transaction, date when the transaction occurred, from account where the money was taken from and to account where money was put. These are the generic property names, which shows that all transaction types basically are the same.

For expenses the value is a cost, a positive value representing a loss of money and the to account/category is called category and the from account/category is the account that the expense is paid from. The category is always an expense category and the from account/category an account.

For incomes the value is an income, a positive value representing a gain of money and the from account/category is called category and the the to account/category is the account that the income is deposited in. The category is always an income category and the to/from account an account.

For transfers the value is called amount, and the to and from accounts/categories are both accounts.

All transactions do in addition have three optional properties. The description property provides information about the nature of the transaction. For expenses and incomes this can be considered a flexible subcategory. The comment property is used for any additional information, not used for categorisation, about the transaction. If you for example buy a pair of shoes, you might create an expense in a clothing category, with the description “Shoes” and comments “Shiny red Pradas”. The third property, “Associated File”, allows you to specify a link to file on the computer which will be connected to the transaction. This will typically be receipt, invoice or payslip, but any file can be selected. The file will not be moved, copied or modified. If the file is moved or renamed outside of Eqonomize!, the file will not be accessible from within the program.

Expenses have two additional properties which can be show or hidden using Settings → Use Additional Transaction Properties (deactivating this option will not permanently remove any properties from already entered transactions). The quantity property denotes how many entities was involved in the transaction. This can be a whole number, as in two CD's, or a fraction, as in 0.56 kg apples (units are not included). This property is by default set to 1 and does not affect the value (the value per entity equals the value divided by the quantity). Expenses also have a payee property for the person or entity, for example the store where goods where bought, which receives the money. Incomes also have the payer property for the one who gives you the money, for example your employer.

Split transactions are used when a single transfer to/from an account is used for multiple transactions. This is not when money is withdrawn from a bank account through an ATM and you go shopping (that is first a transfer from a bank account to cash, then multiple regular expenses). A split transaction will for example be appropriate when you make a single payment for multiple products (especially if they are categorised differently), or when you pay with your credit card in a store and tell them to withdraw some extra money, which you get as cash in your hand.

It is up to you how and when you want to use split transactions, as multiple ordinary transactions can be used with the same end result, even though one way might represent what happened in reality better.

You can create a split from scratch with Transactions → New Split Transaction... or from the context menu. It is however often more efficient to use the join action. This way you can enter transactions the usual way and later join them in a split transactions. Select the transactions to join and activate Join Transactions... from the Transactions menu or the context menu, and enter a description. All transactions in a split transaction have a common date and account.

To reverse the action and transform transactions in a split transaction to ordinary transactions, select a transaction and use Split Up.

In transaction list (ledger) for the account associated with the split, the split will be shown as only one transaction, but everywhere else the parts of the split will appear as ordinary transactions. You cannot edit a transaction that is part of a split transaction directly from the fields below the transaction lists. Instead you should press Edit... to edit the whole split transaction, or double click the transaction in the list to edit the separate transaction (excluding the common date and account of the split transaction).

Expenses with multiple payments are similar to split transactions, but instead of using a common date and account, they share description, category, quantity and comments. The intended usage is for when multiple payments, primarily from different accounts, are made for a single product/service. They should not be used for payment plans/loans, although an expenses with multiple payments is created for expenses with a downpayment.

Expenses with multiple payments will show up single transaction in the expenses, but as multiple transactions in the account ledgers. Similarily to split transactions they cannot be edited directly from the fields under the expenses list.

Loan payments are a third kind of combined transaction. These group together payments on loans (reductions), interest and fees. Ordinary transactions can also be used for these purposes. Interest and fee are expenses and loan reductions are transfers.

Loans → New Unpaid Interest... also creates loan payment transactions but provides a simplified dialog when the debt has increased because of added interest.

Transactions in a loan payment can not be edited separately.

A scheduled transaction is a transaction that is planned to occur, thus it has not occurred yet. It is basically just a transaction, of any type, that has a date set in the future. When a scheduled transaction has occurred, it becomes a regular transaction. Scheduled transactions makes it possible to keep track of and be reminded of future transactions. Eqonomize! will request for a confirmation when the transaction is expected to have occurred.

A scheduled transaction can be recurring, thus it will regularly occur on a certain date or with a certain interval. This is useful mostly for bills and salaries, which then need not be entered manually each time and you can check Eqonomize! for upcoming payments. When a scheduled recurring transaction has occurred, a regular transaction is created, the occurrence date is removed from the recurrence, and the scheduled transaction date is moved forward to the next occurrence. A scheduled transaction with no occurrences left is removed.

Single occurrence scheduled transactions are create just like ordinary transactions, except with a future date. Recurring transactions can only be created from the dialogs, with recurrences specified in the second tab.

The next occurrence of each scheduled transaction is displayed in the schedule view. You can edit or delete either the single occurrence or all future recurrences. If a single occurrence is edited, it will be created as a separate transaction, and any changes made to all recurrences will not affect this occurrence. If the date is changed to the current or a past date, the scheduled transaction becomes an ordinary transaction.

When a scheduled transaction is due, when the current date has gone past the date of the occurrence (or same date after 6 pm), Eqonomize! will ask you to confirm that the transaction really has occurred. You are then given the option to accept the transaction as it is, make some changes (for example the cost of your telephone bill might vary slightly), or postpone it. If the scheduled transaction is not postponed, it will become an ordinary transaction.

Securities represents money invested in stock, bonds and mutual funds. Eqonomize! does not differentiate between different kinds of securities, even though the terminology used is better suited for some. Securities and associated statistics are displayed in the securities view (accessed using the icons on the left).

The create a new security in Eqonomize! use Securities → New Security... or the New Security... button. First select account. Securities are associated with an account of securities type, which cannot be associated with ordinary transactions. Enter name of the security and select type. Specify initial shares if you do not want to back-track all transactions (it is always preferred to use transactions instead, for better statistics). Specify then also date and quotation.

The Securities View

Statistics displayed for each security:

Value

Value at period end date date (quotation * shares).

Quotation

Price per share at period end date.

Shares

Shares at period end date.

Cost

Total price paid for all buys minus sells, at end date.

Profit

Profit during the period (value + dividends - cost).

Yearly Rate

Percent increase of value per share (for a share bought at the beginning of the period), during the period on a yearly basis. Includes dividends.

In the total statistics displayed below the security list, quotation and yearly rate are weighted based on the value of each security.

Predictions are simplistic and base on previous development, with respect to dividends and quotations, only. Future quotations are calculated using quotations during the nearest past time. The quotation one month from current date is assumed to have increased at the same rate as during the past month (or the date before with a specified quotation). Dividends are always predicted using full past years (they are assumed to occur on a yearly basis).

Eqonomize! support per account currencies. A different currency can be selected for each account (for assets and liabilities).

The sum of values from accounts in different currencies and the total value and change of categories (for example in the accounts view, or in the statistical reports and diagrams) will be shown in the main currency. By default the main currency is set to the currency of the system default location, but this can be changed from the settings menu, or in the edit dialog of each currency.

For transfers between accounts with different currencies both withdrawn and deposited amount must be specified. The same is true for loan payments (reductions) where the loan is in a different currency from the account used for the payment.

Included exchange rates support automatic exchange rate updates using data from the European Central Bank. If multiple currencies are in use, the exchange rates are automatically updated once every week, but they can also be updated using the File → Update Exchange Rates.

If a currency you use is not available you can add it manually using the top item in currency menu when creating a new or editing a present account (it can also be done from main currency selection window). You must specify the three letter code of the currency and you should enter an exchange rate in European euros. The currently selected currency of the account can be edited using the button directly under the currency menu.