Overview

A financial transaction is an event carried out between a buyer and a seller to exchange services or physical goods for payment.  The classification of a transaction (such as Invoice, Credit Note, Payment, Refund) determines its inherent features and its notation in the double-entry accounting system (debit or credit). Transactions are reflected in the accounts (and finances) of the parties.

Setting Up Financial Transactions 

Before you start using Financial Transactions you set up the system to reflect your own business needs.

Categories 

Categories are used to label financial transactions in a meaningful way. Categories indicate how the transaction was handled and can be used by the business for transaction analysis purposes.

Rejection Reasons 

Define the options available to justify a declined transaction. Only transactions in a 'Draft' state can be rejected. 

Payment Methods 

Payment methods define how a customer can pay for products or services purchased. The method is specified when the financial transaction is created. If the method involves using a payment gateway (such as PayPal or Stripe) also add the method as 'supported' in the configuration of the payment gateway provider so that the system can identify the payments that it should process.

Refund Methods 

Define the options available for reimbursing customers. The refund method is specified when the financial transaction is created. If the method involves using a payment gateway (such as PayPal or Stripe) also add the method as 'supported' in the configuration of the payment gateway provider so that the system can identify the refunds that it should process. 

Anchor
type type

Financial Transaction Types 

Classifications define the operational characteristics of each transaction. User-definable types are used to distinguish between financial transactions of the same classification. There are seven classifications that can be used to create financial transaction types. The following classifications are available

• Invoice
• Invoice Cancellation
• Credit Note
• Payment
• Payment Cancellation
• Refund
• Write-off

Multiple types can be created for each classification, such as a payment type for voucher payments and another type for cash payments.  When a payment is created, the most suitable type can be selected. Types can also be used by system processes as conditions. For example:  Void a wallet transaction when a financial transaction of type 'wallet payment cancellation' is created. Once financial transaction types are configured, set the system's default financial transaction types in the respective section by selecting the Set default types menu option.

Currencies 

Select the Currencies that will be available to be set as Account currencies. In order to do so, set the required currencies as Life Cycle State 'Effective' and set the exchange rates over the system's default currency for each one.

Taxation Settings 

Taxation Settings define general business rules that will be applied when creating and maintaining Tax Codes and Rates (based on address criteria), as well as rules on whether taxation will be applied by an external system or not.

Tax Codes 

Tax Codes are used to group together taxation rules and policies that will be applied in various Financial Transactions. Define the various types of tax codes to be applied based on your business needs.

Tax Rates 

The Tax Rate includes the tax percentage that will be applied when invoicing products throughout the software. You can define the tax periods, as well as the location conditions and on which products the tax rate will be applied.

Processing Automation & Rules 

Define the processing automation and rules that will be applied on posting financial transactions.

 Back to top

Using Financial Transactions

Financial transactions are used to debit or credit customer accounts. CRM.COM provides seven different transaction classifications to select from when creating a new transaction. Transactions can be created manually or by the system. Refer to the 'Debit and Credit Classifications' diagram below to find out which transaction classifications debit or credit the account, and whether the user or system generates each classification. The following sections provide more details on the processes that generate each transaction. 

Specify the criteria that match the transactions you are interested in, or use the NEW menu option and then select the financial transaction type to create a new Financial Transaction. Provide the mandatory information and then choose either SAVE AS DRAFT (to be completed and posted later), or SAVE in which case the transaction will be saved and posted. A 'posted' transaction cannot be amended in any way, whereas, a 'draft' transaction can be edited for as long as it is n this state. Use the EDIT option to make changes to the draft transactions. 

Financial Transactions cannot be deleted. If a payment or invoice has been mistakenly created you can cancel it through the Actions > CANCEL menu option while the rest of the transaction classifications cannot be cancelled.

The following table shows each of the available transaction classifications, how and where they can be used, and how they can be created (either manually or automatically)

Posting a draft financial transaction

Draft transactions can be posted at any time by using POST from the Actions menu of the transaction's data entry page, and thus taken into account by financial processes. In the case of invoices if a due date is provided then it is checked against the account's credit terms, while in refunds a warning is displayed if the refund causes the account balance to exceed its credit limit.

Rejecting a financial transaction

A transaction that is not yet posted (still in 'Draft' state) can be rejected and not taken into account by financial processes. Select the REJECT option from the Actions menu of the data entry page, selecting a reason from the drop-down list.

Anchor
cancel_inv cancel_inv

Cancelling invoices and payments

Invoices or payments that were posted by error can be cancelled. The action results in a new transaction of classification 'invoice cancellation' or 'payment cancellation' respectively, which credits the associated account with the total amount of the invoice or debits the account with the total amount of the payment.

Click on Cancel from the Actions menu of the invoice's data entry page.

Making a payment for specific services or bills and invoices (mostly used for prepaid subscriptions)

Payments can be made against specific bills and invoices, or used to settle either all or specific subscription services.

In cases where the amount should be used for specific services then the payment amount is transferred to the customer wallet and allotted to the requested services. In cases where the payment is made for a specific bill or invoice then the payment is allocated against the designated bill or invoice if the allocation principle is set to 'FIFO & Against Item'. Otherwise, it is allocated using 'FIFO', regardless of the designated bill or invoice.

Moving a payment between accounts

Funds can be transferred between accounts belonging to different customers or the system. For example, if the system cannot identify a destination account while processing a bank payment, it can temporarily move the funds to a suspense account.

Click on MOVE TO ACCOUNT from the Actions menu of the payment's data entry page. Select the destination account and click SAVE.

Once the payment is moved:

• A payment cancellation equivalent to the original payment is created against the initial account, in a 'Posted' life cycle state, and referencing the original payment.
• An identical payment (of same amount and method) is created against the destination account, in a 'Posted' life cycle state.

Writing off an unsettled invoice

Unpaid posted invoices can be written off (to avoid taxation). Click on WRITE OFF from the Actions menu of the invoice's data entry page. Select a type of write-off (mandatory) and issue reason (optional) and SAVE. 

Once written off:

• A write-off invoice is created for the unsettled amount and allocated against the invoice to be written-off. The account is credited accordingly.
• A new invoice identical to the one being written-off is created in the write-off account.

Paying an invoice using Quick Pay

The Quick Pay process supplements transaction payments and is used to swiftly settle outstanding invoice amounts. Access QUICK PAY from the Actions menu of the data entry page of the invoice you wish to settle. Modify information as necessary (amount cannot be changed) and click on SAVE. By using Quick Pay a new payment is created and allocated against the invoice.

Discounting invoices

If you would like to provide a discount to your customer when creating an invoice you have the option to either provide a fixed discount amount or a discount percentage which is applicable for each line of the invoice. The total amount will be calculated taking into consideration the discount defined on the invoice lines. You can provide different discounts for each item on the invoice.

Applying taxes on invoices and credit notes based on location

Taxes are automatically applied on invoices or credit notes (whether they are created automatically or manually) against an account. As with discounts, taxes are applied per product added (invoice or credit note line). In cases where multiple taxes are applicable for a product, the system identifies only the valid one taking the following into consideration:

• The customer's location which is represented by the customer's account billing address
  • Account owners are billed based on their billing address for termed services included in their subscriptions, i.e. specific services which are included in a contract and the company agreed with the customer to provide and bill these services based on a pricing agreement. 
• The location at which the services were consumed or physical goods were bought
  • Customers are billed based on the location at which the service was consumed. This applies for expense and usage services, i.e services which are not specifically included in a contract
  • In the case of physical goods, customers are again billed based on the location of the merchant, i.e. the location from which they bought the physical goods.
• The Organization's Address
  • The address of the company that owns CRM.COM

Anchor
allocation allocation

Allocation of financial transactions

Allocations are used by the system to settle the outstanding balance of an account, by assigning credit financial transactions (customer payments or credit notes) towards debit transactions.

Allocations follow the 'FIFO' (First-In, First-Out) or 'Against Item & FIFO' principle, as specified on the Accounts Settings, and take place automatically when a financial transaction is posted.

• If 'FIFO' is selected then a specific invoice should be not defined when creating a credit transaction. 
• If 'FIFO & Against Item' is selected and a specific invoice(s) is defined when the credit transaction is created, then the credit is allocated towards the invoice(s). 
  
  • If the invoice is already allocated by another credit transaction then allocation works as 'FIFO'.

FIFO

All unallocated transactions (e.g. payments, credit notes), regardless of the one currently being posted, are taken into consideration. The credit transaction with the earliest posting date is allocated against the invoice with the earliest due date.

• If an invoice is cancelled, then
  • 'Against Item' allocation takes place (i.e., the invoice cancellation transaction is allocated against the cancelled invoice)

• If a payment was allocated against an invoice and then cancelled, then

  • The payment is de-allocated

  • The invoice is re-allocated by a credit financial transaction following the same principle.  

FIFO & Against Item

Against Item allocation takes place when the credit financial transaction (e.g. payment, credit note) addresses a specific invoice. If the credit financial transaction (payment) addresses more than one invoice, then consequent allocations are made with FIFO. 

• If an amount to be allocated towards an invoice is greater than the un-allocated amount (of the invoice) AND other credit transactions are already allocated against the invoice using FIFO, then 
  
  • The credit transactions are de-allocated and re-allocated on other invoices (using FIFO). 
    
  • If the amount to be allocated is still greater than the un-allocated amount of the invoice, the remaining amount is allocated on other invoices (using FIFO). 
• If the credit transaction does not address specific invoices, then

  • Allocation takes place using FIFO. 

• If an already allocated invoice is cancelled, then

  • The credit transactions are de-allocated and allocated again using FIFO, 
  • The invoice is allocated by the invoice cancellation.
• If an already allocated payment is cancelled, then

  • The payment is de-allocated and the invoice is allocated again using FIFO

  • The payment is allocated against the payment cancellation.

Working with invoice due dates

What are invoice due dates?

The due date is the day by which an invoice must be settled. The due date is mandatory and can be entered by the user or calculated and set by the system.  In either case, when a financial transaction is saved, the due date is validated against the credit period of the account.  If the user does not specify a due date when posting an invoice, the credit period is calculated following the due date rules of the account definition.

How is the due date calculated?

Depending on the value of the credit period field, the system sets the due date either on a fixed number of days after the posted date or on the 'n^th day, X months after the Posted Date'.  If the rule allows a proximity range and a credit period is set on the corresponding account, then the due date is set a specific number of days before or after the calculated due date, depending on the credit period.

Back to top 

Applying business flows on financial transactions

Back to top