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 receivable (and finances) of the parties. 

Setting Up Financial Transactions and Core Processes

Image RemovedImage Added

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

Anchor
type type

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.  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 type in the respective section Default System Financial Transaction Types

The following classifications are available

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

Configure the following entities before setting up types and then add the entities you want to have available in the system for each financial transaction type.

• 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.

• Payment Methods are the options available to customers for compensating sellers. The method is defined 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 are the options available for reimbursing customers. The refund method is defined 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. 
• Rejection Reasons are the options available to justify a declined transaction.  Only transactions in a 'Draft' state can be rejected. 
• Settings select the rejection reasons (from the ones configured) which will be available to be used.

 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 NEW > financial transaction type  from the Actions' Menu to create a new Financial Transaction. Provide the mandatory information before you SAVE the transaction. You can either Save as Draft or Save in which case the transaction will be saved and posted. A posted transaction cannot be amended in any way while a transaction can be edited as long as it was saved as Draft. Use EDIT from the Actions Menu to enter edit mode.

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

In the following table you can see 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 and thus taken into account by financial processes, by using POST from the Actions menu of the transaction's Data Entry page. In 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 posted (still in 'Draft' state) can be rejected and not taken into account by financial processes.  Click on REJECT from the Actions menu of the Data Entry page, selecting a reason from the drop-down list.

Anchor
cancel_inv cancel_inv

Canceling invoices and payments

Invoices or payments that were posted by error can be canceled. 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 case 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 case that 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 accounts receivable and click SAVE. 

Once the payment is moved

• A payment cancellation equivalent to the original payment is created against the initial accounts receivable, in a 'Posted' life cycle state, and referencing the original payment.
• An identical payment (of same amount and method) is created against the destination accounts receivable, 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 added 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 accounts receivable. As with discounts taxes are applied per product added (invoice or credit note line). In case where multiple taxes are applicable for a product, the system identifies only the valid 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 was 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 receivable definitionsettings, 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 un-allocated 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 canceled, then
  • 'Against Item' allocation takes place (i.e., the invoice cancellation transaction is allocated against the canceled invoice)

• If a payment was allocated against an invoice and then canceled, 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 canceled, 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 canceled, 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 accounts receivable 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 accounts receivable, 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  

Business Flows