On this page

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.

Financial transaction features

The transaction classifications available in the system either credit the accounts receivable (Payment, Credit Note, Invoice Cancellation and Write-off deduct funds from balance) or debit it (Invoice, Refund, and Payment Cancellation add funds to balance).
Transactions that are not yet posted can be rejected. Posted transactions can be canceled.
Posted transactions have been processed by the system, included in the account's balance and can no longer be updated.
Draft transactions can be created and modified before they are posted.
Credit financial transactions are allocated against invoices to settle an outstanding amount. Allocations are applied automatically by the system following the specified allocation principle (FIFO or Against Item &FIFO).
Invoices that are not considered as collectible can be written off.
Payments can be transferred between accounts.

Setting Up Financial Transactions

Configuration > Finance Application > Financial Transactions

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.

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.

Configure a default financial transaction type for each classification and add it to the financial transaction definition.

Type fields

The table describes the sections of the Financial Transaction Type Data Entry page and explains how the fields on 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 fixed and are the following: Invoice Invoice Cancellation Credit Note Payment Payment Cancellation Refund Write-off
Allowed Payment Methods (Visible for the payment classification)
The predetermined ways to make a payment in the system. At least one method must be defined.
Allowed Refund Methods (Visible for the refund classification)
The predetermined ways to issue a refund in the system. At least one method must be defined.
Allowed Categories
Predetermined categories that can be used in financial transactions of each type.

Business definitions

Definitions regarding:

The default financial transaction type used to create transactions of each classification.
The rejection reasons that agents can use.

Definition fields

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

Mandatory Configurable

System Generated Financial Transaction Settings
Determine the default financial transaction type that will be selected when creating a financial transaction of each classification. For the Write-off classification also define a Default Write-off Product (used in the write-off financial transaction items when an invoice is written off).
Available Rejection Reasons
Select the reasons for which financial transactions in a 'Draft' state can be rejected.

System Generated Financial Transaction Settings

Determine the default financial transaction type that will be selected when creating a financial transaction of each classification.

For the Write-off classification also define a Default Write-off Product (used in the write-off financial transaction items when an invoice is written off).

Available Rejection Reasons

Select the reasons for which financial transactions in a 'Draft' state can be rejected.

Related configuration areas

Mandatory modules must be configured for the financial transactions module to work.

Optional modules may be configured for the financial transactions module to operate at its full capacity

Module Link	Area	Description	Configuration Type
Accounts Receivable	Accounts Receivable Definitions	Define the allocation principle for allocating credit to debit transactions, the credit period rules to be applied on accounts (to calculate the invoice due date) and create the system write-off account for writing off invoices.	Mandatory
Wallets	Configuring Wallet Definitions	Define the types of wallet transaction and the events that should trigger a financial transaction and the types of financial transaction that should trigger wallet transactions and events.	Optional
Payment Gateways	Payment Gateway Provider	Define payment gateways (e.g., PayPal account or credit card) for handling payments, payment cancellations and refunds occurring in CRM.COM. Define the payment and refund methods that the gateway should handle.	Optional

Using Financial Transactions

Finance > Financial Transactions > Manage 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.

Debit and Credit Classifications

Invoices

Invoices are used to debit customer accounts and can be generated by system processes or manually by the user.

System processes and entities which generate invoices

The normal billing run generates invoices when executed, charging customers for goods and services rented or purchased through subscriptions and jobs.
The wallet funds prepaid subscriptions and redeems awards for reward participants.
- When a credit transaction takes place in the wallet, an invoice can be created to reflect a debit in the associated account.
- When a debit wallet transaction is voided, crediting the wallet, an invoice can be created to debit the account.
Quick Sale (a process used to swiftly sell physical goods to customers) generates invoices that charge customer accounts.

User actions that generate invoices

Invoices can be created by using the New > Invoice action available from the financial transactions Summary page.

Invoice fields

The table describes the sections of the Invoice Data Entry page and explains how the fields on the page are used.

Mandatory Configurable

Main Information
Number: The transaction number is automatically generated on posting the invoice. Reference Number: Automatically generated by creating the invoice (before posting). Accounts Receivable (for which the invoice is created) Type: Select most suitable for the particular invoice. Life Cycle State (set by the system and depends on whether the user selected 'Save as Draft', 'Save', 'Reject' or ' Write off') A 'Draft' transaction can be posted, rejected and edited and does not affect the balance. A 'Posted' transaction is permanent, cannot be edited and affects the balance. A 'Rejected' transaction cannot be edited and does not affect the balance. A 'Written Off' transaction cannot be edited and affects the balance (Invoice debit and write-off credit amounts are taken into consideration). Rejection Reason Category (Only 'Allowed' can be applied) Issued On (date/time) Posted On (set by the system) Due On: The date on which the credit period for a 'Posted' invoice ends. If not defined, it is automatically set by the system based on the credit period allowed for the account. If defined, it is validated against the credit period set on the account. Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.
Items
Individual line items in the invoice (at least one must be provided). The following aggregated amounts are calculated dynamically: Net Discount VAT Tax Total Outstanding (available after saving) Unsettled (available after saving) The Currency in which amounts are expressed is set on the accounts receivable. Once the transaction is saved, a 'View Applied Tax Rates' link becomes available in the items section, which displays the tax rates that were applied to each item. Financial Transaction Line Applied Taxes Details: A list of applied taxes for each item. Only applicable for taxes applied by a third-party taxation service that is integrated with CRM.COM. The following applied tax detail fields retrieved by the taxation service are kept in CRM.COM in XML: Tax name Tax code Taxed amount Tax rate percentage Tax details (any other details sent by the taxation service)
Log Information
Shared Notes: Notes regarding the invoice can be entered here. Each time the notes are amended, the user and the date are logged.

Credit Notes

Credit notes are used to credit customer accounts and can be generated by system processes or manually by the user.

System processes and entities which generate credit notes

The normal billing run generates credit notes when executed for periods that were erroneously charged or regretted.
The wallet funds prepaid subscriptions and redeems awards for reward participants.
- When a wallet is canceled the associated accounts receivable is reimbursed and wallet funds are preserved.
- When a credit wallet transaction is voided, debiting the wallet, a credit note can be created to credit the account

User actions that generate credit notes

Credit notes can be created manually:

To credit customers for returned physical goods.
To refund services that do not meet customer expectations.
As a discount for marketing purposes.

Create a credit note by using the New > Credit Note action, available from the financial transactions Summary page.

Credit note fields

The table describes the sections of the Credit Note Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Number: The transaction number is automatically generated on posting the credit note. Reference Number: Automatically generated by creating the credit note (before posting). Accounts Receivable (for which the credit note is created) Type: Select most suitable for the particular credit note. Life Cycle State (set by the system and depends on whether the user selected 'Save as Draft', 'Save' or 'Reject') A 'Draft' transaction can be posted, rejected and edited and does not affect the balance. A 'Posted' transaction is permanent, cannot be edited and affects the balance. A 'Rejected' transaction cannot be edited and does not affect the balance. Rejection Reason Category (Only 'Allowed' can be applied) Issued On (date/time) Issue Reason Posted On (set by the system) Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.
Items
Individual line items in the invoice (at least one must be provided). The following aggregated amounts are calculated dynamically: Net Discount VAT Tax Total The Currency in which amounts are expressed is set on the accounts receivable. Once the transaction is saved, a 'View Applied Tax Rates' link becomes available in the items section, which displays the tax rates that were applied to each item. Financial Transaction Line Applied Taxes Details: A list of applied taxes for each item. Only applicable for taxes applied by a third-party taxation service that is integrated with CRM.COM. The following applied tax detail fields retrieved by the taxation service are kept in CRM.COM in XML: Tax name Tax code Taxed amount Tax rate percentage Tax details (any other details sent by the taxation service)
Invoices to Credit
If the allocation principle is set to 'Against Item & FIFO', invoices added here will be allocated against the credit note. If the invoices were previously settled by credit notes or payments then the particular credit notes and payments will be de-allocated. If the allocation principle is set to FIFO, invoices added in this section are ignored. Refer to the Allocations section for information on how CRM.COM handles allocations.
Log Information
Shared Notes: Notes regarding the credit note can be entered here. Each time the notes are amended, the user and the date are logged.

Payments

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

System processes and entities which generate payments

Vouchers used in CRM.COM generate payments that credit the recipient account with an equivalent amount.
Settling bills through an automated process (daily, weekly, monthly) using credit cards registered with Stripe or other payment gateways creates a payment transaction in CRM.COM. Customer credit cards are identified by their number and used to settle bills.
- Payments effected through Stripe are created and posted directly.
- Payments effected through other payment gateways remain in a 'Pending Verification' life cycle state; the state must be updated manually or through a WEB API, once the gateway confirms that the payment has been successfully processed.
  Refer to Making payments and refunding customers through online accounts for more information.

User actions that generate payments

Payments to credit a customer account can be created manually, by using the New > Payment action available from the financial transactions Summary page.

Payment fields

The table describes the sections of the Payment Data Entry page and explains how the fields on the page are used.

Mandatory Configurable

Main Information
Number: The transaction number is automatically generated on posting the payment. Reference Number: Automatically generated by creating the payment (before posting). Accounts Receivable (for which the credit note is created) The Currency of the accounts receivable (default). Type: Select most suitable for the particular payment. Payment Method (Only 'Allowed' can be applied) Amount: The currency in which amounts are expressed is set on the accounts receivable. Reference Number of the payment. The field identifier of the payment preference is displayed and used to search and retrieve the accounts receivable payment preference. Life Cycle State (set by the system and depends on whether the user selected 'Save as Draft', 'Save' or 'Reject') A 'Draft' transaction can be posted, rejected and edited and does not affect the balance. A 'Posted' transaction is permanent, cannot be edited and affects the balance. A 'Rejected' transaction cannot be edited and does not affect the balance. A transaction 'Pending Verification' (set when a payment is created involving a generic payment gateway) does not affect the balance. Rejection Reason Category (Only 'Allowed' can be applied) Issued On (date/time) Posted On (set by the system) Voucher (number) available when a voucher was used to create and post the payment. (Payment) Received On (date) / By User / By Unit (unit of the user) Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.
Bills / Invoices To Pay
If the allocation principle is set to 'Against Item & FIFO', invoices or bills added here will be allocated against the payment. If the invoices were previously settled by credit notes or payments then the particular credit notes and payments will be de-allocated. If the allocation principle is set to FIFO, then invoices added in this section are ignored. Refer to the Allocations section for information on how CRM.COM handles allocations.
Products to Pay
If the account is associated with a wallet, services added on the prepaid or normal subscription owned by the account are displayed. The user can select to settle specific or all subscription services with the payment.
Log Information
Shared Notes: Notes regarding the payment can be entered here. Each time the notes are amended, the user and the date are logged.

Refunds

Refunds are used to return money to customers. A refund debits customer accounts.

System processes and entities which generate refunds

Instant discounts earned from reward offers can be applied through 'back-end reduction', a process where the customer pays the regular price at the point of sale and is refunded by CRM.COM (through a payment gateway). Funds are returned to the customer's bank or online account (e.g., PayPal).

Refer to Instant discount refunds for more information.

User actions that generate refunds

Refunds to debit a customer account can be created by using the New > Refund action available from the financial transactions Summary page.

Refund fields

The table describes the sections of the Refund Data Entry page and explains how the fields on the page are used.

Mandatory Configurable

Main Information
Number: The transaction number is automatically generated on posting the refund. Reference Number: Automatically generated by creating the refund (before posting). Accounts Receivable (for which the refund is created) Type: Select most suitable for the particular refund. Amount: The currency in which amounts are expressed is set on the accounts receivable. Refund Method (e.g., cash or credit card) Payment Preference: The customer's preferred method of payment from the accounts receivable, which must be applied if the selected payment method is processed by a generic payment gateway. The field identifier of the payment preference is displayed and used to search and retrieve the accounts receivable payment preference. For example, if the customer is reimbursed through a PayPal account, then the PayPal account number (i.e. email address) is displayed. Life Cycle State (set by the system and depends on whether the user selected 'Save as Draft', 'Save' or 'Reject') A 'Draft' transaction can be posted, rejected and edited and does not affect the balance. A 'Posted' transaction is permanent, cannot be edited and affects the balance. A 'Rejected' transaction cannot be edited and does not affect the balance. A transaction 'Pending Verification' (set when a payment is created involving a generic payment gateway) does not affect the balance. Category (Only 'Allowed' can be applied) Issued On (date/time) Issue Reason Posted On (set by the system) Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.
Log Information
Shared Notes: Notes regarding the refund can be entered here. Each time the notes are amended, the user and the date are logged.

Main Information

Number: The transaction number is automatically generated on posting the refund.

Reference Number: Automatically generated by creating the refund (before posting).

Accounts Receivable (for which the refund is created)

Type: Select most suitable for the particular refund.

Amount: The currency in which amounts are expressed is set on the accounts receivable.

Refund Method (e.g., cash or credit card)

Payment Preference: The customer's preferred method of payment from the accounts receivable, which must be applied if the selected payment method is processed by a generic payment gateway.

The field identifier of the payment preference is displayed and used to search and retrieve the accounts receivable payment preference. For example, if the customer is reimbursed through a PayPal account, then the PayPal account number (i.e. email address) is displayed.

Life Cycle State (set by the system and depends on whether the user selected 'Save as Draft', 'Save' or 'Reject')

A 'Draft' transaction can be posted, rejected and edited and does not affect the balance.
A 'Posted' transaction is permanent, cannot be edited and affects the balance.
A 'Rejected' transaction cannot be edited and does not affect the balance.
A transaction 'Pending Verification' (set when a payment is created involving a generic payment gateway) does not affect the balance.

Category (Only 'Allowed' can be applied)

Issued On (date/time)

Issue Reason

Posted On (set by the system)

Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.

Log Information

Shared Notes: Notes regarding the refund can be entered here. Each time the notes are amended, the user and the date are logged.

Write-offs

Write-offs are used to cancel a bad debt and deduct the total unsettled amount of an invoice from the account balance.

User actions that generate write-offs

Write-offs are created against unsettled invoices. Access the Invoice Data Entry page and click Write Off from the Actions menu.

Write-off fields

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

Mandatory Configurable

Main Information
Number: The transaction number is automatically generated on posting the write-off. Reference Number: Automatically generated by creating the write-off (before posting). Accounts Receivable (for which the write-off is created, set by the system) Type: Select most suitable for the particular write-off. Life Cycle State: Can only be 'Posted'. Transactions are permanent, cannot be edited and affect the account's balance). Category (Only 'Allowed' can be applied) Issued On (date/time) Issue Reason Posted On (set by the system) Invoice Written Off: Information supplied by the system regarding the invoice. The write off will credit the account by the amount of the invoice. Write-Off Account Invoices: Information supplied by the system regarding the new invoice created in the company's write-off account. Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.
Items
A single item that includes the default write-off product, as defined in the financial transaction definition. The line item's total amount is equivalent to the remaining unpaid amount of the written-off invoice, but also includes other amounts (such as Net and VAT amount), subject to VAT rates that apply to the written-off product. The Currency in which amounts are expressed is set on the accounts receivable. Financial Transaction Line Applied Taxes Details: A list of applied taxes for each item. Only applicable for taxes applied by a third-party taxation service that is integrated with CRM.COM. The following applied tax detail fields retrieved by the taxation service are kept in CRM.COM in XML: Tax name Tax code Taxed amount Tax rate percentage Tax details (any other details sent by the taxation service)
Log Information
Shared Notes: Notes regarding the write-off can be entered here. Each time the notes are amended, the user and the date are logged.

Invoice cancellations

Invoices can be canceled in case of an error or change of mind, for example when an item is returned.

Invoice cancellations credit the customer's account and can be generated by the system or the user.

System processes that generate invoice cancelations

When a credit wallet transaction (which resulted in the generation of an invoice in the accounts receivable) is voided, an invoice cancellation transaction is created to cancel the debited amount.

Wallets fund prepaid subscriptions and redeem awards for reward participants

User actions that generate invoice cancellations

Invoices can be canceled by using the Cancel action available on the invoice's Data Entry page.

Invoice cancellation fields

The table describes the sections of the Invoice Cancellation Data Entry page and explains how the fields in the page are used.

Mandatory Configurable

Main Information
Number: The transaction number is automatically generated on saving the cancellation action. Reference Number: Automatically generated on saving the cancellation action. Accounts Receivable (for which the invoice cancellation is created) The Currency in which amounts are expressed is set on the accounts receivable. Type: Select most suitable for the particular invoice cancellation. Life Cycle State: Can only be 'Posted'. Transactions are permanent, cannot be edited and affect the account's balance). Category (Only 'Allowed' can be applied) Issue Reason: The reason that the invoice was canceled, provided when canceling the invoice. Issued On (date/time) Posted On (set by the system) Cancelled Invoice (set by the system) Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.
Items
Individual line items in the canceled invoice. Financial Transaction Line Applied Taxes Details: A list of applied taxes for each item. Only applicable for taxes applied by a third-party taxation service that is integrated with CRM.COM. The following applied tax detail fields retrieved by the taxation service are kept in CRM.COM in XML: Tax name Tax code Taxed amount Tax rate percentage Tax details (any other details sent by the taxation service)
Log Information
Shared Notes: Notes regarding the invoice cancellation can be entered here. Each time the notes are amended, the user and the date are logged.

Payment cancellations

Payments can be canceled in case of an error. Payment cancellations debit the customer's account for the total amount of the payment and can only be generated by the user.

User actions that generate payment cancellations

Cancel a payment by using the Cancel action available from the payment's Data Entry page.

Payment cancellation fields

The table describes the sections of the Payment Cancellation Data Entry page and explains how the fields on the page are used.

Mandatory Configurable

Main Information
Number: The transaction number is automatically generated on saving the cancellation action Reference Number: Automatically generated on saving the cancellation action. Accounts Receivable (for which the payment cancellation is created) The Currency in which amounts are expressed is set on the accounts receivable. Type: Select most suitable for the particular payment cancellation. Life Cycle State can be one of the following: A 'Posted' transaction is permanent, cannot be edited and affects the balance. A transaction 'Pending Verification' (set when a payment is created involving a generic payment gateway) does not affect the balance. Category (Only 'Allowed' can be applied) Amount (to be deducted from the account, equal to canceled payment) Issue Reason: The reason that the payment was canceled, provided when canceling the invoice. Issued On (date/time) Posted On (set by the system) Cancelled Payment (set by the system) Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.
Log Information
Shared Notes: Notes regarding the payment cancellation can be entered here. Each time the notes are amended, the user and the date are logged.

Main Information

Number: The transaction number is automatically generated on saving the cancellation action

Reference Number: Automatically generated on saving the cancellation action.

Accounts Receivable (for which the payment cancellation is created)

The Currency in which amounts are expressed is set on the accounts receivable.

Type: Select most suitable for the particular payment cancellation.

Life Cycle State can be one of the following:

A 'Posted' transaction is permanent, cannot be edited and affects the balance.
A transaction 'Pending Verification' (set when a payment is created involving a generic payment gateway) does not affect the balance.

Category (Only 'Allowed' can be applied)

Amount (to be deducted from the account, equal to canceled payment)

Issue Reason: The reason that the payment was canceled, provided when canceling the invoice.

Issued On (date/time)

Posted On (set by the system)

Cancelled Payment (set by the system)

Back Office Code: Set a code for use by external systems to refer to a specific financial transaction. The code is not mandatory but should be unique if specified.

Log Information

Shared Notes: Notes regarding the payment cancellation can be entered here. Each time the notes are amended, the user and the date are logged.

Creating and processing financial transactions

Validations take place before an action is initiated (prerequisite) or after it is submitted (postcondition).

Selecting and creating financial transactions

Specify the criteria that match the financial transactions you are interested in or click on NEW from the Actions menu to create a new transaction. Provide the mandatory information and SAVE.

Classification	System Processing
Invoice	SAVE AS DRAFT Life cycle state is set to 'Draft'. Issued date is set. Reference number is set. Invoice items sub amounts and total amounts are calculated. SAVE (POSTED) If the invoice is created and posted at the same time: Life cycle state is set to 'Posted'. Posted date is set. Transaction number is set. Due date is calculated and set, if not already defined by the user. Un-allocated credit notes are allocated against the invoice based on the allocation principle specified in the accounts receivable definition. Invoice items sub amounts and total amounts are calculated.
Credit Note	SAVE AS DRAFT Life cycle state is set to 'Draft'. Issued date is set. Reference number is set. Credit note items sub amounts and total amounts are calculated. Invoice items sub amounts and total amounts are calculated. SAVE (POSTED) If the credit note is created and posted at the same time then: Life cycle state is set to 'Posted'. Posted date is set. Transaction number is set. Credit note is allocated against any un-allocated invoices based on the allocation principle specified in the active accounts receivable definition. Invoice items sub amounts and total amounts are calculated.
Payment	SAVE AS DRAFT Life cycle state is set to 'Draft' Issued date is set. Reference number is set. Invoice items sub amounts and total amounts are calculated. SAVE (POSTED) If the payment is created and posted at the same time then: Life cycle state is set to 'Posted'. Posted date is set. Transaction number is set. Payment is allocated against any un-allocated invoices based on the allocation principle specified in the active accounts receivable definition. Invoice items sub amounts and total amounts are calculated.
Refund	SAVE AS DRAFT Life cycle state is set to 'Draft' Issued date is set. Reference number is set. SAVE (POSTED) If the refund is created and posted at the same time then: Life cycle state is set to 'Posted'. Posted date is set. Transaction number is set.

Modifying a financial transaction

Transactions can be edited until they are posted. Enter EDIT mode from the Actions menu.

Prerequisites	The transaction must be in a 'Draft' state.

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.

Prerequisites

The transaction must be in a 'Draft' state.

Postconditions

A reason for the rejection must be specified.

The associated account must not be in a 'Terminated' state.

System Processing

The life cycle state of the transaction is updated to 'Rejected'.

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.

Prerequisites

The transaction must be in a 'Draft' state.

Postconditions

Invoices

If a due date is defined, it is validated against the account's credit term period.

Refunds

A warning is displayed if the refund causes the account balance to exceed its credit limit.

System Processing

Posted date is set.
Transaction number is generated (a reference number is available until 'Posted').
Allocations take place.
If the transaction is a payment, payment cancellation or refund in which a payment gateway is involved, then the life cycle state is set to 'Pending Verification' (not 'Posted') until it is handled by the gateway.

Canceling an invoice

Invoices that were posted by error can be canceled. The action results in a new transaction of classification invoice cancellation, which credits the associated account with the total amount of the invoice.

Click on CANCEL from the Actions menu of the invoice's Data Entry page.

Prerequisites	The transaction must be in a 'Posted' state.
Postconditions	The accounts receivable for the invoice should not be in a 'Terminated' state.
System Processing	A new transaction is created with an invoice cancellation classification. Life cycle state of the invoice cancellation is set to 'Posted'. Posted date is set equal to the current date. Transaction number is set. Invoice cancellation is allocated against the canceled invoice. Payments or credit notes that are already allocated against the canceled invoice are de-allocated.

Canceling a payment

Payments that were posted by error can be canceled. The action results in a new transaction of classification payment cancellation, which debits the account with the total amount of the payment.

Click on CANCEL from the Actions menu of the payment's Data Entry page.

Prerequisites

The transaction must be in a 'Posted' state.

Postconditions

The accounts receivable for the payment should not be in a 'Terminated' state.

System Processing

A new transaction is created with a payment cancellation classification.
Life cycle state of the payment cancellation is set to 'Posted'. If a payment gateway is involved, then the life cycle state of the payment is set to 'Pending Verification' (not 'Posted') until it is handled by the gateway.
Posted date is set to the current date.
Transaction number is set.
Invoice cancellation is set against the canceled invoice.
If the payment is allocated against one or more invoices, then it is de-allocated.

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.

	Services (Products to Pay)	Bills/ Invoices
Prerequisites	The accounts receivable is associated with a prepaid or normal subscription The accounts receivable is associated with an effective wallet The payment type is included in the wallet definition as a wallet credit cause.	The accounts receivable is associated with a normal subscription.
System Processing	The payment amount is transferred to the customer wallet and allotted to the requested services.	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.

Prerequisites	The payment must be in a 'Posted' state.
Postconditions	The destination accounts receivable for the payment should not be in a 'Terminated' state.
System Processing	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 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.

Prerequisites	The invoice must be in a 'Posted' state (not available for 'Settled' invoices).
System Processing	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.

Back to top

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.

Prerequisites	Invoices that are not in a 'Settled' state.
System Processing	A payment is created and allocated against the invoice.

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 definition, 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 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.

Applying business flows on financial transactions

Making payments and refunds through online accounts

Payments and refunds can be made through online accounts such as PayPal and Stripe or other payment gateways with which CRM.COM can integrate.

If you already use a payment gateway, CRM.COM can be configured to create payments and refunds for the gateway. Once the transactions are processed, CRM.COM must be updated accordingly.

By using Stripe, the user can make direct payment and refund requests which once completed update CRM.COM automatically.

In either case, the system must be set up to support each method, by configuring the financial transactions module and payment gateway provider.

Create the payment and refund methods that will be used to distinguish the payments and refunds which should be handled by the payment gateway.
Set up a provider, either Stripe or other and add the associated payment and refund methods.
Set up the account payment preference associated with the payment gateway.

To conduct payments and refunds through the payment gateway:

Set the gateway related payment preference on the account and provide account details.
When creating a financial transaction, select the method which is related to the payment gateway and payment preference, as defined in the account from which the transaction is effected.
For transactions handled through Stripe, the system will automatically send transaction requests.
For transaction handled through other gateways, the user will have to export the requests and send them to the gateway, using WEB APIs.

Instant discount refunds (back-end reduction)

Rewards participants can earn awards from a purchase and use them for an instant discount, usually applied at the point of sale (POS) as a front-end reduction.

Back-end reduction can be offered through a payment gateway, where the customer pays the regular price at the POS and is refunded the discount amount by CRM.COM (through the gateway). Funds are returned to the customer's bank or online account (e.g., PayPal). In order to apply this option, a refund method that will trigger the refund in the gateway provider must be selected and the back-end reduction settings of the merchant must be configured.

Refer to multi-merchant rewards platform for set up instructions and for more information on back-end reduction.

Communicating a financial transaction

The Communicate action available through the Actions menu in the (invoice, payment or refund) transaction's Data Entry page can be used to convey information regarding financial transactions.

You can use tags (text that is automatically replaced by values specific to selected records) related to financial transactions when creating communications. Tags are available for selection by typing '#'.

Refer to the Communications manual for a complete list of financial transactions tags.

Financial Transaction Analytics

Segmenting financial transactions

Transactions with common characteristics (e.g., which occurred in a specific period) can be grouped together. The resulting segments can be used in system business processes, such as for notifying customers regarding payments or for simple statistical calculations.
For more information on segmentation and how you can create financial transaction lists refer to Segmentation.

Dashboards

Dashboards make information on key performance indicators 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

The component displays the average product revenue from various products in a specific period, in a bar chart, grouped by product. If a date range is not supplied, the component uses data from the current month. The products can be selected through the settings () accessed from the top right corner of the component. Only 'Posted' transactions are used and taxes are not included in calculations.

Product revenue = total invoiced amount - total credited amount - total invoice cancellation amount
Average product revenue = total product revenue in a specific period/number of distinct accounts receivable resulting in the revenue (through financial transactions)

Receipts per Month

The component displays the receipts from the last 12 months, in a vertical bar chart, grouped by month. Only 'Posted' transactions are used in calculations.

Receipts = total payments - total payment cancellations - total refunds

Revenue per Month

The component displays monthly revenue for the last 12 months, in a vertical bar chart. Only 'Posted' transactions are used and taxes are not included in calculations.

Revenue = total invoiced amount - total credited amount - total invoice cancellation amount

Reports

Information on financial transactions can be extracted in a structured format for analysis. The fields displayed in a report and the included transactions are selected and grouped based on user-defined criteria. Refer to Reports for more information.

Financial Revenue List

The report displays a list of all invoices, credit notes and invoices cancellations that were posted within a specific period of time.

Financial Summary by Accounting Type

The report displays revenue totals, grouped by transaction type, including net, VAT, discount and total amount without VAT, as well as receipts by payment type.

Financial Transactions List

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

Monthly Recurring Revenue (MRR) and MRR Growth

The report displays the MRR and MRR Growth for all subscriptions in the last 12 months.

The report is generated by executing the MRR utility, which calculates existing and growth revenue per month, taking into consideration rated termed services up until the last day of the previous month.

Taxes, expenses, and usage-based services are not included in revenue calculations.

To execute the utility, navigate to Foundation > Analytics > Run Reports. Under Finance Application > Financial Transactions locate an Update link on the right of Monthly Recurring Revenue. Click to update the information in the report to be extracted.

Once the update is completed the option to update the report will disappear. Access and extract the report.

Printouts

Printouts display all the information contained in a financial transaction. They are available through the financial transactions Data Entry page, in one of the following formats: HTML, XLS, CSV, RTF, and PDF.

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

Find examples of financial transaction printouts below:

A Credit Note Details Printout displays information on a selected Credit Note.

An Invoice Details Printout displays information on a selected Invoice.

An Invoice Cancellation Details Printout displays information on a selected Invoice Cancellation.

A Payment Details Printout displays information on a selected Payment.

Financial Transactions Business Examples

Posting refunds after bank confirmation

Scenario 1.

Company ZX would like to refund customer accounts with a negative balance on a monthly basis, by transferring funds to their bank accounts. Once the payments are processed, the bank sends ZX an import file with the successful payments, which it can use to update customer account balances.

Solution

User Process
Refunds should be created in a 'Draft' life cycle state and sent to the bank. Once the file is received from the bank, the successful refunds should be updated to 'Posted' and the balance of the account automatically updated.

Cancelling erroneously created Invoices

Scenario 2.

Company ZX would like to cancel 'Posted' invoices that were created by error.

Solution

Configuration
Admin users can configure different types of invoice cancellation (classification) transactions, in order to be able to differentiate between reasons for canceling an invoice. E.g., 'Cancellation Error Invoices' and 'Cancellation Complaint Invoices'. An operations user should be responsible for canceling invoices created by error.

The user should select the invoice to be canceled and create a financial transaction of the appropriate type. The invoice will be available for future reference without affecting the account's balance. The financial transaction type indicates the reason the invoice was canceled. More detailed information can be obtained from the cancellation issue reason.

Move Payments from Suspense Account to customer accounts

Scenario 3.

Company ZX imports payments from the bank using an import file.
If the intended recipient account is not found, the payment is created in the company's suspense account. Back office personnel is responsible to manually check and move the payments to the correct customer account.

Solution

User Process

ZX back office personnel should access the suspense account on a daily basis. The MOVE TO ACCOUNT action should be executed for each payment, once the intended account is confirmed.

Company ZX issuing an invoice with Discount

Scenario 4.

A customer of Company ZX purchases two cards, granting a 15% and €20 discount, respectively.

Solution

User Process

Create a new financial transaction of type 'Invoice'. In the items tab, add two lines with the following information:

Card 1
- Cost: 100
- Quantity: 1
- Discount Percentage: 15%
Card 2
1. Cost: 100
2. Quantity: 1
3. Discount Amount: €20

System Calculations:

1. Card 1: Subtotal: (100-100*15%) = 85
2. Card 2: Subtotal: (100-20) = 80

Company ZX - Invoice Due Dates - Fixed Date

Scenario 5a.

Company ZX wants the 15th day of the month to be the invoice due date.

Solution

Configuration

The accounts receivable credit rule should be set up defining the n^th day (n=15), X months (X=1) after the posted date.

User Process

If the user defines a due date when posting an invoice, the system either validates the date or returns an error message. For example, assuming the date of posting is 20/05:

If the due date is set to 21/05 or 16/06, an 'Invalid Due Date' message is returned from the system.
If the due date is set to 15/06, it is saved successfully (no error message is returned).

If the user leaves the due date empty, it is automatically set to 15/06.

Scenario 5b.

Company ZX wants to have the due date always set to 10 days after the posted date.

Solution

Configuration
The accounts receivable definition credit rule should be set up defining X days (X = 10) after the transaction's posted date.

User Process

If the user defines a due date when posting an invoice, the system either validates the date or returns an error message. For example, assuming the date of posting is 20/05:

If the due date is set to 28/05 or 31/05, an 'Invalid Due Date' message is returned from the system.
If the due date is set to 30/06, it is saved successfully (no error message is returned).

If the user leaves the due date empty, it is automatically set to 30/06.

Scenario 5c

Company ZX requires agents to set the due date a maximum of 10 days after the posted date but requires the system to set the due date to 5 days after the posted date.

Solution

Configuration

The accounts receivable definition credit rule should be set up defining X days (X = 10) after the transaction's posted date.

Proximity range should be set to -5 (days)

User Process

If the user defines a due date when posting an invoice, the system either validates the date or returns an error message. For example, assuming the date of posting is 20/05:

If the due date is set to 28/05 or 30/06, it is saved successfully (no error message is returned).
If the due date is set to 31/05, an 'Invalid Due Date' message is returned from the system.

If the user leaves the due date empty, it is automatically set to 25/05 (the earliest allowed due date according to the proximity range).

Make an online payment

Scenario 6a.

Company ZX wants to enable its customers to make payments using an online payment gateway.

Solution

Configuration

Financial Transaction Payment Methods: Configure the method that will be used for making payments through the gateway.
Financial Transaction Payment Type: Configure a transaction type and add the payment method as 'allowed'.
Generic Gateway Provider: Configure the provider and select the allowed payment methods and the payment types that will trigger payments to the specific provider.
Accounts Receivable Payment Preference: Configure a payment preference and relate it to the gateway. Select the fields that will be available and/or mandatory when selecting the payment preference on an accounts receivable. Set one of the selected fields as a unique identifier (this could be an account or card number).
Accounts Receivable Definition: Add the payment preference in the allowed preferences of the account.

User process

Accounts Receivable: Enable the gateway payment preference. Provide the unique identifier and any other required information, as configured in the payment preference
Financial Transactions:
1. Create a transaction and select the configured payment type that was added as allowed.
2. Select the payment method that is related to the payment gateway.
  The system will load the identifier provided in the accounts receivable payment preference.
3. Select the identifier (i.e. the card number) and save the payment.

Refer to Generic Gateways and Accounts Receivable manuals for more information.

FIFO Versus FIFO & Against Item Principle

FIFO Principle

In the following example, one invoice has already been allocated to a credit note using the FIFO principle. Once a second invoice is created, the first invoice is canceled.

Invoice 1: €20
Invoice 2: €10
Credit Note 1: €20

No.	Action	Intended Invoices	Allocations	Allocation Type	Allocation amount	Unallocated Amount
1	Creation of Invoice 1	N/A	N/A	N/A	-	-
2	Creation of Invoice 2	N/A	N/A	N/A	-	-
3	Creation of Credit Note 1	N/A	Credit Note 1 allocated on Invoice 1	FIFO	20	-
4	Cancellation of Invoice 1	Invoice 1			-	-
4a	Credit Note 1 de-allocated from Invoice 1	N/A	N/A	De-allocation	20	-
4b	Creation of Cancellation Invoice 1	N/A	Invoice 1 allocated on Cancellation Invoice 1	Against Item	20	-
4c	Credit Note 1 allocated on Invoice 2	N/A	Credit Note 1 allocated on Invoice 2	FIFO	10	10

FIFO & Against Item Principle

There are three invoices in the following example. The first two are allocated from credit notes that were intended for the invoices. The first invoice is then canceled.

Invoice 1: €10
Invoice 2: €20
Invoice 3: €20
Credit Note 1: €10 (Intended invoice: Invoice 1)
Credit Note 2: €20 (Intended invoice: Invoice 2)

No.	Action	Intended Invoice	Allocations	Allocation Type	Allocation amount	Unallocated Amount
1	Creation of Invoice 1	N/A	N/A	N/A	-	-
2	Creation of Invoice 2	N/A	N/A	N/A	-	-
3	Creation of Invoice 3	N/A	N/A	N/A	-	-
4	Creation of Credit Note 1	Invoice 1	Credit Note 1 allocated on Invoice 1	FIFO and Against Item	10	0
5	Creation of Credit Note 2	Invoice 2	Credit Note 2 allocated on Invoice 2	FIFO and Against Item	20	0
4	Cancellation of Invoice 1				-	-
4a	Credit Note 1 de-allocated from Invoice 1		N/A	De-allocation	10	0
4b	Creation of cancellation Invoice 1		Invoice 1 allocated on Cancellation Invoice 1	Against Item	10	0
4c	Credit Note 1 allocated on Invoice 3		Credit Note 1 allocated on Invoice 3	FIFO	10	10

Notes

If you are using a previous release, view CRM.COM Release Changes.
Use the WEB API to create and manage financial transactions from an external system, such as a customer portal. Refer to credit note, refund, payment, and invoice WEB APIs for a comprehensive list of available actions.

Glossary

CRM.COM Term	Definition
Accounts Receivable	A ledger of the financial transactions carried out between a company and its customers, such as invoices and payments.
Payment Gateway	A service provided by a third-party system that authorizes credit card or direct payment processing for e-business.
Stripe	A merchant payment gateway for processing online payments.
Wallet	A customer account whose credit balance is used to fund transactions within CRM.COM.
Wallet Transaction	A financial transaction that debits or credits the wallet.
Normal Billing Run	A process that is used to charge customers for goods and services provided over a period of time. Each run is usually performed on a monthly basis and issues a bill including the invoices and credit notes associated with customer subscriptions or jobs.
Rewards Participant	A customer who can be awarded offers provided through the rewards program.
Quick Sale	A process used to swiftly sell physical goods to customers - generates invoices to charge the customer's account.
Voucher	An alternate form of payment across CRM.COM modules. Customers buy vouchers and use them for payments within the system.

Overview

Financial transaction features

Setting Up Financial Transactions

Types

Type fields

Business definitions

Definition fields

Related configuration areas

Using Financial Transactions

Invoices

System processes and entities which generate invoices

User actions that generate invoices

Invoice fields

Credit Notes

System processes and entities which generate credit notes

User actions that generate credit notes

Credit note fields

Payments

System processes and entities which generate payments

User actions that generate payments

Payment fields

Refunds

System processes and entities which generate refunds

User actions that generate refunds

Refund fields

Write-offs

User actions that generate write-offs

Write-off fields

Invoice cancellations

System processes that generate invoice cancelations

User actions that generate invoice cancellations

Invoice cancellation fields

Payment cancellations

User actions that generate payment cancellations

Payment cancellation fields

Creating and processing financial transactions

Selecting and creating financial transactions

Modifying a financial transaction

Rejecting a financial transaction

Posting a draft financial transaction

Canceling an invoice

Canceling a payment

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

Moving a payment between accounts

Writing off an unsettled invoice

Paying an invoice using Quick Pay

Allocation of financial transactions

FIFO

FIFO & Against Item

Working with invoice due dates

What are invoice due dates?

How is the due date calculated?

Applying business flows on financial transactions

Making payments and refunds through online accounts

Instant discount refunds (back-end reduction)

Communicating a financial transaction

Financial Transaction Analytics

Segmenting financial transactions

Dashboards

Dashboard components

Average Product Revenue per Unit

Receipts per Month

Revenue per Month

Reports

Financial Revenue List

Financial Summary by Accounting Type

Financial Transactions List

Monthly Recurring Revenue (MRR) and MRR Growth

Printouts

Financial Transactions Business Examples

Glossary

Related Links

Browser not supported