Overview

A Financial Transaction is an event carried out between a buyer and a seller to exchange services or physical goods measured in terms of money. The transaction’s nature is differentiated by its classification(Invoice, Credit Note, Payment, Refund etc.). It involves a change in the status of the finances of the businesses or individuals involved, which is directly reflected on the customer's Accounts Receivable by updating its balance.

Major features

• The classification determines the nature of the Financial Transaction, including its notation in the double-entry accounting system (debit or credit). Financial transaction type classifications are predefined in the system and cannot be overridden. The following Classifications are available:
  • Payment : Used to credit the account. i.e. deduct money from balance
  • Invoice: Used to debit the account. i.e. add money to balance
  • Credit Note: Used to credit the account. i.e. deduct money from balance
  • Refund: Used to debit the account. i.e. add money to balance (Can only be created if a negative account balance exists)
  • Invoice Cancellation: Used to credit the account. i.e. deduct money from balance
  • Payment Cancellation: Used to debit the account. i.e. add money to balance
  • Write Off
• Financial transactions that are not already posted can be rejected. Posted transactions can be cancelled.
• Posting of financial transactions depicts that the transaction is taken into consideration by system financial processes, such as its inclusion in the account's balance. Once posted the transaction can no longer be updated.
• Transactions can be created with an intermediate step (before being posted) giving you the ability to make subsequent changes before posting.
• Allocations are used to allocate credit financial transactions against invoices, in order to settle any outstanding amount. Allocations are applied automatically by the system based on the allocation principle specified in the system.
• Invoices which are not expected to be settled, due to customer's inability to proceed with the settlement can be written off.
• Payments can be moved between accounts

Setting Up Financial Transactions

Categories

Financial Transaction categories are used to provide a business classification to the transaction such as user-input, automated, call centre. These classifications provide the user with input on how the transaction was handled, and can also be used by the business to analyse the type of calls they receive. Once categories are configured you can add the ones you would like to make available from each financial transaction type.

Payment Methods

Payment Methods are the options available to customers for paying for products. The payment method is defined during the creation of payments.  Once configured you can add the ones you would like to make available from each financial transaction type. Payment methods related to payment gateways, such as PayPal or credit card, once configured must also be added to the payment gateway providers so that the system can identify how the payment will be received. 

Refund Methods

Refund Methods are the options available to for refunding a customer's account. The refund method is defined during the creation of refunds. Once configured you can add the ones you would like to make available from each financial transaction type. Refund methods related to payment gateways, such as PayPal or credit card, once configured must also be added to the payment gateway providers so that the system can identify how the refund to the customer will be made.

Rejection Reasons

Rejection Reasons is the explanation for rejecting a financial transaction.  Only Financial Transactions in a 'Draft' state can be rejected. Once configured you can add the ones you would like to make available to use in the system in the financial transaction definition.

Types

Financial Transaction Types determine the behaviour and nature of each financial transaction, which is according to the classification set on the Financial Transaction Type. There are seven classifications that can be used to create financial transaction types and multiple types can be created for each classification, such as a payment type to be used for voucher payments and another type for cash payments. On creating a payment you can select the type that it best fits the purpose. 
Types can also be used by different processes in the system as conditions. For example, you can set up the system to void a wallet transaction when a 'wallet related' payment cancellation type is created.

Once configured the default financial transaction types (one from each classification) must be added to the financial transaction definition

Type fields

The table describes the sections of Financial Transaction Type Data Entry page, and explains how the fields in the page are used.

 Mandatory   Configurable

Main Information
Classification: Determines the nature of the transaction, including its notation in the double-entry accounting system (debit or credit). Classifications are predefined in the system and cannot be overridden.The supported Classifications are: Invoice Invoice Cancellation Credit Note Payment Payment Cancellation Refund Write off
Allowed Payment Methods
The predetermined ways to make a payment. Available and Mandatory on Conditions only if the Classification if set to Payment.
Allowed Refund Methods
The predetermined ways to make a refund. Available and Mandatory on Conditions only if the Classification if set to Refund.
Allowed Categories
Predetermined categories which can be used in Financial Transactions of each Type.

Back to top 

Business Definitions

Financial Transaction Definition  includes the default financial transaction types which will be used when transactions of each classification are automatically generated as well as the reasons which can be used by agents when rejecting a financial transaction.

Definition fields

The table describes the sections of Financial Transaction Definition Data Entry page, and explains how the fields in the page are used.

 Mandatory   Configurable

System Generated Financial Transaction Settings
Determines the financial transaction types that will be selected automatically (i.e. by default) when a financial transaction of each classification is created. Invoice Invoice Cancellation Credit Note Payment Payment Cancellation Refund Write off Default Write Off Product: The product which will be
Available Rejection Reasons
Defines the reasons for which financial transactions in a 'Draft' state can be rejected.

Back to top 

Related configuration areas

The following modules are related to Financial Transactions and they must or may be configured for the Financial Transactions module to operate at its full capacity.

Using Financial Transactions

Use financial transactions to debit or credit the customer's account. CRM.COM provides seven different classifications of financial transactions, each with its distinct characteristics and behaviour.  The classification is set on the financial transaction type which will in turn be selected when creating a new financial transaction. 
Transactions are either manually created or generated by the system. Refer to figure 1 to find out which classifications debit and credit the account as well as information on whether the transaction is created through user intervention or generated by the system. Refer to each classification section below to find out which processes generate each transaction.

Figure 1.

Back to top 

Invoices

Invoices are used to debit the account. They can be generated either by system processes or manually by the user.

System processes generating invoices

• When Normal Billing Run is executed to charge customers for goods and services rented or purchased through subscriptions and jobs, invoices are generated.
• Wallets which are used to fund prepaid subscriptions and redeem awards for reward participants, can be directly related to an account in which case a credit transaction taking place in the wallet can be reflected as a debit in the account by the generation of an invoice.
• When a debit wallet transaction is voided, crediting the wallet, then the account can be debited accordingly by the generation of an invoice.
• Quick Sales a process used to easily and quickly sell physical goods to customers, generates invoices to charge the customer's account.

User actions generating invoices

Invoices to charge an account can be created manually by using the New > Invoice action available in the Summary page of Financial Transactions.

Invoice fields

 The table describes the sections of Invoice classification Financial Transaction Data Entry page, and explains how the fields in the page are used

 Mandatory   Configurable

Main Information
Number The transaction number of the invoice which is automatically generated on posting the invoice. Reference Number: The reference number of the invoice which is automatically generated by creating the invoice (before posting). Accounts Receivable: The Accounts Receivable that the Invoice is created for. Currency: The currency with which the account owner chose to be charged and pay (Set on the account). Financial Transaction Type: Select the financial transaction type of classification invoice for which the invoice will be created with Life Cycle State: The life cycle state of the invoice which can be any of the following and will be set by the system according to your actions (save as draft, save, reject) : Draft: transactions can be 'Posted',  'Rejected' and edited and do not affect the account's balance. Posted: transactions are permanent, cannot be edited and affect the account's balance. Rejected: transactions cannot be edited and do not affect the account's balance. Written Off: transactions cannot be edited and they affect account's balance (the invoice debit amount is taken into consideration as well as the credit amount of the write off ). Rejection Reason: The reason selected when rejecting the transaction. Is available only if the transaction is rejected. Category: Select the category of the invoice. Only categories listed as 'Allowed' on the related financial transaction type can be applied. Issued On: The date that the invoice was issued on. Posted On: The date that the invoice was 'Posted' on, which is set by the system. Due On: The date on which the credit period for a 'posted' invoice ends. If not defined then it is automatically set by the system based on the credit period allowed for the account. If defined then it will be validated against the credit period set on the account.
Items
A list of items which are invoiced; at least one item must be provided. The following aggregated amounts are also calculated dynamically: Net amount Discount amount VAT amount Tax amount Total amount Outstanding amount (AVAILABLE AFTER SAVING) Unsettled amount (AVAILABLE AFTER SAVING) Once the transaction is saved 'VIEW APPLIED TAX RATES' link is available in items section which displays the Tax Rates that were applied per item.
Log Information
Shared Notes: Provide notes for the invoice. Each time the notes are amended, the user and the date are logged. Back Office Code: Set a code which is used by external systems to refer to a specific financial transaction. The Back Office Code is not mandatory, but if specified then it should be unique.

Back to top 

Credit Notes

Credit notes are used to credit the account. They can be generated either by system processes or manually by the user.

System processes generating credit notes

• When Normal Billing Run is executed to charge subscriptions and jobs for rented or bought services and goods, credit notes are also generated for periods that were erroneously charged or charged are regretted. 
• Wallets which are used to fund prepaid subscriptions and award reward participants, can be directly related to an account. If the wallet of the account owner is about to be cancelled and there is money in the wallet then the amount can be reimbursed in the account so it won't be lost by the generation of a credit note
• When a credit wallet transaction is voided, debiting the wallet, then the account can be credited accordingly by the generation of a credit note.

User actions generating credit notes

Credit notes can be manually created to credit customers for returned bought physical goods or services which the customer has complained about or just provide a discount to a customer for marketing or customer care issues. To create a manual credit note click on  New > Credit Note action available in the Summary page of Financial Transactions.

Credit Note fields

The table describes the sections of Credit Note classification Financial Transaction Data Entry page, and explains how the fields in the page are used

 Mandatory   Configurable

Main Information
Number The transaction number of the credit note which is automatically generated on posting the credit note. Reference Number: The reference number of the credit note which is automatically generated by creating the credit note (before posting). Accounts Receivable: The Accounts Receivable that the credit note is created for. Currency: The currency with which the account owner chose to be charged and pay (Set on the account). Financial Transaction Type: Select the financial transaction type of classification credit not for which the credit note will be created with. Life Cycle State: The life cycle state of the credit note which can be any of the following and will be set by the system according to your actions (save as draft, save, reject) :  Draft: transactions can be 'Posted',  'Rejected' and edited and do not affect the account's balance. Posted: transactions are permanent, cannot be edited and affect the account's balance. Rejected: transactions cannot be edited and do not affect the account's balance. Rejection Reason: The reason selected when rejecting the transaction. Is available only if the transaction is rejected. Category: Select the category of the credit note. Only categories listed as 'Allowed' on the related financial transaction type can be applied. Issued On: The date that the credit note was issued on. Issue Reason: The reason that a credit note was manually issued. Posted On: The date that the credit note was 'Posted' on, which is set by the system.
Items
A list of items which are credited; at least one item must be provided. The following aggregated amounts are also calculated dynamically: Net amount Discount amount VAT amount Tax amount Total amount Once the transaction is saved 'VIEW APPLIED TAX RATES' link is available in items section which displays the Tax Rates that were applied per item.
Invoices to Credit
The invoices that are intended to be credited. If the allocation principle is set to FIFO then the invoices added in this section are ignored. However if the allocation is Against Item & FIFO then the invoices added here will be allocated against the credit note and if they were already settled by other credit notes or payments then those will be de-allocated. Refer to Allocations section below to find out how CRM.COM handles allocations.
Log Information
Shared Notes: Provide notes for the credit note.Each time the notes are amended, the user and the date are logged. Back Office Code: Set a code which is used by external systems to refer to a specific financial transaction. The Back Office Code is not mandatory, but if specified then it should be unique.

Back to top 

Payments

Payments are used to credit the account. They can be generated either by system processes or manually by the user.

System processes generating payments

• Payments in CRM.COM can be done by using vouchers. When a voucher is used then a payment is generated to credit the account with the amount of the voucher
• A process to pay unsettled bills with credit cards registered through STRIPE or any other payment gateway, results in the generation of payment transactions. The process can be configured to be automatically run daily, weekly or monthly and collects all credit cards of account owners which choose to pay their bills through the registered credit card and settles them by creating a payment in CRM.COM and sending a request to Stripe to withdraw the money from the customer's back account.
  • In case the payment is done through Stripe then the payments created are directly posted
  • In case the payment is done through any other payment gateway then the life cycle state remains as 'Pending Verification' and must be manually updated or through a WEB API, as soon as the gateway provides confirmation that the payment has been successfully processed.

User actions generating payments

Payments to credit a customer's account can be created manually by using the New > Payment action available in the Summary page of Financial Transactions.

Payment fields

The table describes the sections of Payments Data Entry page, and explains how the fields in the page are used

 Mandatory   Configurable

Back to top 

Refunds

Refunds are used to refund customers, as in, give them back cash, in case that they have unused money in their account (i.e. the account balance is below 0). Therefore, a refund will debit the account. 

User actions generating payments

Create a refund to debit the account with the amount refunded to the customer by using the New > Refund action available in the Summary page of Financial Transactions.

Refund fields

 The table describes the sections of Payments Data Entry page, and explains how the fields in the page are used

 Mandatory   Configurable

Back to top 

Write-off

Write -off are used to remove an amount owed to the account if the account owner is unable and will never pay for that amount. Write offs are used to remove a whole invoice.

User actions generating write-off

Write-offs are explicitly created against invoices. To write off an invoice access the Data Entry page of the invoice and click on Actions > Write off from the Action menu. Only invoices which are not settled can be written off.

Write-off fields

The table describes the sections of Write Off Data Entry page, and explains how the fields in the page are used

 Mandatory   Configurable

Back to top 

Invoice Cancellation

Invoice Cancellation are used to credit the account when the full amount of an invoice must be cancelled due to an error or a customer changing their mind about a buy. They can be generated either by system processes or manually by the user.

System processes generating invoice cancellation

Wallets which are used to fund prepaid subscriptions and redeem awards for reward participants, can be directly related to an account in which case a debit transaction taking place in the wallet can be reflected as a credit in the account. When a credit wallet transaction that had previously caused the generation of an invoice in the account, is voided, crediting the wallet, then an invoice cancellation is created to cancel the amount that previously debited the account.

User actions generating invoice cancellation

Invoice cancellation, to deduct an amount that an account was mistakenly charged with or for the return of items, can be created by cancelling the related invoice by using the Actions > Cancel action available in the Data Entry page of the invoice you wish to cancel

Invoice cancellation fields

 The table describes the sections of Invoice Cancellation classification Financial Transaction Data Entry page, and explains how the fields in the page are used

 Mandatory   Configurable

Main Information
Number The transaction number of the invoice cancellation which is automatically generated on saving the cancellation action. Reference Number: The reference number of the invoice cancellation which is automatically generated on saving the cancellation action. Accounts Receivable: The Accounts Receivable that the invoice cancellation is created for. Currency: The currency with which the account owner chose to be charged and pay (Set on the account). Financial Transaction Type: Select the financial transaction type of classification invoice cancellation for which the invoice cancellation will be created with Life Cycle State: The life cycle state of the invoice cancellation which can only be Posted. Posted transactions are permanent, cannot be edited and affect the account's balance. Category: The category of the invoice cancellation which was set when cancelling the invoice. Only categories listed as 'Allowed' on the related financial transaction type can be applied. Issue Reason: The reason that the invoice cancellation was created, defined when cancelling the invoice. Issued On: The date that the invoice cancellation was issued on. Posted On: The date that the invoice cancellation was 'Posted' on, which is set by the system. Cancelled Invoice: Information related to the invoice that was cancelled.
Items
A list of items which were included in the invoice that was cancelled.
Log Information
Shared Notes: Provide notes for the invoice cancellation. Each time the notes are amended, the user and the date are logged. Back Office Code: Set a code which is used by external systems to refer to a specific financial transaction. The Back Office Code is not mandatory, but if specified then it should be unique.

Back to top 

Payment Cancellation

Payment Cancellation are used to debit the account when the full amount of a payment must be cancelled due to an error. They can only be generated by user intervention.

User actions generating payment cancellation

Payment cancellation, to debit back an account for the full amount of a payment that did not pass through, can be created by cancelling the related payment by using the Actions > Cancel action available in the Data Entry page of the payment you wish to cancel

Payment cancellation fields

 The table describes the sections of Payment Cancellation classification Financial Transaction Data Entry page, and explains how the fields in the page are used

 Mandatory   Configurable

Back to top 

Creating and processing Financial Transactions

Selecting and creating a/an Financial Transactions

Navigate to Financial Transactions and specify the criteria that match the Financial Transactions you are interested in, or click on NEW from the Actions Menu to create a new Financial Transactions. Proceed by providing the mandatory information as defined in the tables above before you SAVE

Modifying a financial transaction

As long as a transaction has not been posted it can be edited by using the EDIT from the Actions Menu to enter edit mode.

Additional Information

Rejecting a financial transaction

If transactions have not yet been posted (i.e. draft life cycle state) and they should not be taken into account by financial processes then they can be rejected. To reject a transaction click on Actions > Reject from the Actions menu of the transactions Data Entry page. The reason for rejecting the transaction must be selected from the drop-down list.

Additional Information

Posting a draft financial transaction

If a transaction was created in a Draft state then it can be posted at any point by using the ACTIONS > POST action available in the Data Entry page of the transaction.

Additional Information

Back to top 

Cancelling an invoice 

Invoices that have already been posted can be cancelled. Cancel invoices that were erroneously created to credit related account  with the full amount of the invoice. The result of the action is the creation of a new financial transaction of classification, Invoice Cancellation. To cancel, click on Actions > Cancel from the Action menu in the Data Entry page of the invoice you wish to cancel.

Additional Information

Cancelling a payment

Payments that have already been posted can be cancelled. Cancel payments that were erroneously created to either Debit the related account with the full amount of the payment. The result of the action is the creation of a new financial transaction of classification Payment Cancellation. 
To cancel click on Actions > Cancel from the Action menu in the Data Entry page of the payment you wish to cancel.

Additional Information

Moving a payment between accounts

You can transfer money from one account to another even between different account owners. Moving Payments can also be accomplished from system accounts to customer accounts. For example, if while processing bank payments the system cannot identify an account that the payment was made for, the payment can be moved in the suspense system account. Once the customer that made the payment is identified then the payment can be moved from the suspense account to the customer account.

To move payments click on Actions > Move to Account from the Actions menu of the Data Entry page of the payment you wish to move. Select the Destination accounts receivable and click on SAVE. 

Additional Information

Writing off an unsettled invoice

There are cases where debts owed by customer will not be paid due to various reasons, such as a diseased customer. In such cases, the invoices can be written off so that they can be excluded by taxes paid from your company. To write off an invoice click on Actions > Write Off from the Actions menu of the Data Entry page of the invoice you wish to write off. Select the Type of write off that will be created and the issue reason and click on SAVE. 

Additional Information

Back to top 

Paying an invoice using quick pay

The Quick Pay process supplements the usual method of creating payments (through Financial Transactions) and is used to quickly settle outstanding invoice amounts.

You can access Quick Pay through Actions > Quick Pay found at the Actions Menu in the Data Entry page of the invoice. The amount for which the payment is made cannot be modified however the rest of the information can be amended. Once all the information is provided click on SAVE.  

Additional Information

Allocation of financial transactions

Allocations are used in order to settle the outstanding balance of accounts by assigning credit financial transactions against invoices. Allocations are applied automatically by the system following the Allocation Principle specified on the Accounts Receivable Definitions.

Two possible allocation principles are supported by CRM.COM but only one can be selected by the system at a time.

• FIFO: First In First Out
  • Allocation occurs at posting
  • All unallocated transactions are taken into consideration, regardless of which one is being posted
  • The oldest credit transaction is allocated against the oldest invoice. 
  • The oldest credit transaction is identified by comparing the Posting Date. 
  • The oldest invoice is identified by comparing the Due Date. 
  • The Allocation Type is set to FIFO
• FIFO & Against Item
  • Allocation occur at posting
  • Allocations are always performed Against Item when the credit Financial Transaction refers to one or more specific (Intended) invoices. 

  • If the credit Financial Transaction refers to more than one invoice, then the Allocation is applied on those invoices using the FIFO principle. 
    
    

Allocating a Financial Transaction

Allocations are performed automatically during the posting of a financial transaction and according to the selected principle. If the selected principle is FIFO & Against Item, then it is necessary to define the intended invoices or Bills when creating the payment. If no intended invoices are defined, then the system will apply the FIFO principle.  If the selected Principle is FIFO, it is not necessary to define any invoices for which a payment is conducted.

How does the FIFO Allocation Principle work?

Allocations based on the FIFO Principle follow these rules:

• Allocations are always performed first in first out. 

  • The oldest credit transaction is identified by comparing the Posting Dates. 

  • The oldest invoice is identified by comparing the Due Dates.

  • The oldest credit transaction is allocated against the oldest invoice. 

• Allocations are performed Against Item only when an invoice cancellation is posted

  • In the case of an invoice cancellation, the cancellation transaction is always allocated against the selected invoice and the Allocation Type is set to 'Against Item'

  • If there are other transactions which are already allocated against the selected invoice, then they are de-allocated and allocated again using 'FIFO'

• If a payment which was already allocated against an invoice is cancelled, then the payment is de-allocated and the invoice is re-allocated following the same principle

• The de-allocation is performed by creating an Allocation record with negative amount and setting the Allocation Type to 'De-allocation'

• The de-allocated record keeps a reference to the Allocation record that resulted in its de-Allocation. 

The system always keeps a record of the Type of Allocation that has been performed.

How does FIFO and Against Item Principle work?

Allocations based on FIFO & Against Item Allocation Principle are performed using the following rules:

• Allocations are always performed Against Item when the credit Financial Transaction refers to one or more specific invoices. 

  • If the credit Financial Transaction is referring to more than one invoice, then the Allocation is applied on those invoices using FIFO

  • If the amount to be allocated to the invoice is more than the un-allocated amount then
    • If there are other transactions which are already allocated against an invoice using FIFO, then they are de-allocated and re-allocated based on 'FIFO'
    • If the amount that should be allocated is still more than the unallocated amount of the invoice, then an amount equal to the unallocated amount is allocated against that invoice, setting the Allocation Type to 'Against Item' and the remaining amount of the credit Financial Transaction is allocated using FIFO.

  • Otherwise, "If the credit Financial Transaction amount is just enough to cover the invoice  then the whole amount of the credit Financial Transaction is allocated against the invoice, setting the Allocation Type to 'Against Item'

• Allocations are always performed on a FIFO basis if the credit Financial Transaction is not referring to specific invoices.

• Allocations are always performed on an Against Item basis when an invoice cancellation is posted.

  • In the case of an invoice cancellation, the cancellation is always allocated against the referred invoice and the Allocation Type is set to 'Against Item'

  • If other transactions were already allocated against the invoice, then they are de-allocated and allocated again based on 'FIFO'

• When cancelling a payment already allocated against an invoice, the cancelled payment is de-allocated and the invoice is allocated again based on 'FIFO'
• De-allocation is performed by creating an Allocation record with a negative amount and setting the Allocation Type to 'De-allocation'
• The de-allocated record keeps a reference to the Allocation record that resulted in its de-Allocation. 

Working with invoice due dates

What are Invoice Due Dates?

Financial Transactions classified as invoices must have a Due Date when they are posted. The Due Date is the date by which an invoice or a bill must be settled. It can be either added by the user or calculated and set by the system.  In both cases, when saving a financial transaction the due date will be validated against the credit period of the account which is calculated based on the Due Date rules of the accounts receivable definition.

How does the Due Date Calculation work?

If a user does not specify a due date when posting an invoice, then the date is generated by the system based on the accounts receivable credit period , using the calculation below:

1. If the rule is set to fixed number of days, then the Due Date is set equal to the Posted Date plus the specified number of days
2. If the rule is set to the n^th day, X months after the Posted Date, then the Due Date is set on the n^th day, X months after the Posted Date
3. If the rule allows a proximity range and a Credit Period is set on the corresponding Accounts Receivable then:
   
   1. If the Credit Period is set to plus X days, then the Due Date is set X days after the calculated Due Date
   2. If the Credit Period is set to minus X days, then the Due Date is set X days before the calculated Due Date

Back to top 

Applying business flows on Financial Transactions

Financial Transactions Analytics

Segmenting Financial Transactions

You can group payments with common characteristics, such as payments conducted in the last week. Use the lists in system business processes such as notifying customers for payments made or for simple statistical calculations. 
For more information on Segmentation and how you can create Financial Transactions lists refer to Segmentation.

Dashboards 

Dashboards make information regarding the key performance indicators of the progress of the Financial Transactions available from a single integrated view. Dashboards are made up of components such as charts and summary tables. Refer to Dashboards for information on their use and set-up.

Dashboard components

Average Product Revenue per Unit per Month 

The component displays the average product revenue for a specific period sold by a specific unit in a bar chart, grouped by product. In the absence of a date range, the average revenue of products within the current month will be displayed. You can select the products whose revenue is displayed through the settings.

Receipts per Month

The component displays the receipts (Receipts = Payments total - Payment Cancellations total - Refunds total) of the last 12 months, in a bar chart, grouped per month. For the calculation of the receipts only 'posted' transactions are considered

Revenue per Month 

The component displays the revenue within last 12 months, in a bar chart, grouped by month. In the absence of a date range, the average revenue of products within the current month will be displayed.

Back to top 

Reports

Financial Transactions information can be extracted in a structured format for analysis by using reports. The Financial Transactionsincluded in the report are selected and grouped based on user defined criteria. The user can select the fields displayed in the report.
Refer to Reports for information on their use.

Financial Revenue List Report

The report displays all the Invoices, Credit Notes and Invoices Cancellations that were posted within a specific period of time. 

Financial Summary by accounting type report

The report displays:

• total revenue amounts grouped by transaction type, including Net, VAT, Tax and Discount amounts
• receipts by payment type

Financial Transactions List Report

The report displays all the financial transactions that were posted within a specific period of time. 

Monthly recurring revenue (MRR) & Monthly recurring revenue growth (MRR Growth) report

MRR is a report that displays the monthly recurring revenue for all types of subscriptions, per subscription type or per normal or prepaid subscribers. It always displays the results of the last 12 months by default. The monthly recurring revenue growth is also available for all types of subscriptions, per subscription type or per normal or prepaid subscribers. 
In order for the results of the report to be populated the MRR utility must be executed. The utility calculates the existing and growth revenue per month derived from rated termed (recurring) services up until the last day of the month before the current month.

Back to top 

Printouts

Financial transaction printouts displays all the information contained in a Financial Transactions. It is available through the Financial Transactions Data Entry page in one of the following formats: HTML, XLS, CSV, RTF, PDF.

Refer to  Printouts for information on how they can be created, printed and sent.

Credit note details printout

A Credit Note Details printout provides information in the selected credit note.

Invoice details printout

An Invoice Details Printout displays information regarding a selected Invoice.

Invoice cancellation details printout

An Invoice Cancellation Details Printout provides the information of an Invoice Cancellation.

Payment printout

A Payment Printout provides the information of a payment.

Back to top 

Financial Transactions Business Examples

Back to top