Skip to end of banner
Go to start of banner

2019Financial Transactions - R18

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


Overview

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


Setting Up Financial Transactions 

Configuration > Finance > Set up Financial Transaction Settings

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

Categories 


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

Rejection Reasons 


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

Payment Methods 


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

Refund Methods 


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

Financial Transaction Types 


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

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

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

Currencies 


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

Taxation Settings 


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

Tax Codes 


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

Tax Rates 


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

Processing Automation & Rules 


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

Recommended additional setup

In addition to the Financial Transactions specific settings, the following may be configured for the Financial Transactions to operate at its full capacity.

  • In Account Settings 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.

 73695269

Using Financial Transactions

Finance > Financial Transactions

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

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

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

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

Financial Transaction Classification


Uses 


Processes which generate transactions


Invoice

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

For example create an invoice for something the customer has purchased.

  • The normal billing run generates invoices when executed, charging customers for goods and services rented or purchased through subscriptions.
  • 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.


Credit Note

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

  • To credit customers for returned physical goods. 
  • To refund services that do not meet customer expectations.
  • As a discount for marketing purposes.
  • 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 cancelled the associated account 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


Payment

Payments are used to credit the customer accounts. They can be generated by system processes or manually by the user.
  • 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 73695269 for more information.


Refund

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

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 73695269 for more information.

Write Off Write-offs are used to cancel a bad debt and deduct the total unsettled amount of an invoice from the account balance. When a credit wallet transaction (which resulted in the generation of an invoice in the account) is voided, an invoice cancellation transaction is created to cancel the debited amount.


Invoice Cancellation

Invoices can be cancelled 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.


Invoice cancellation is manually created by using the Cancel action available on the invoice's data entry page.  

Payment Cancellation

Payments can be cancelled 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.


Payment cancellation is manually created by using the Cancel action available on the payment's data entry page.  

Posting a draft financial transaction


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

Rejecting a financial transaction


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

Cancelling invoices and payments


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

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

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


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

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

Moving a payment between accounts


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

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

Once the payment is moved:

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

Writing off an unsettled invoice


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

Once written off:

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

 

Paying an invoice using Quick Pay


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

Discounting invoices


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

Applying taxes on invoices and credit notes based on location


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

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

Allocation of financial transactions


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

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

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

FIFO

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

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

    • The payment is de-allocated

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

FIFO & Against Item

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

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

  • If an already allocated invoice is cancelled, then

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

    • The payment is allocated against the payment cancellation.

Working with invoice due dates


What are invoice due dates?

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

How is the due date calculated?

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

73695269 

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 reward platform for set up instructions and for more information on back-end reduction.

Communicating a financial transaction


A Financial Transaction can be communicated through the communications page, by adding the transaction in the 'Referring to Entities'. It is also possible to automate the communication setting by setting up 'Event Based Communication Definition' accordingly.

You can use tags related to transactions (text that is automatically replaced by values specific to selected records) when creating communications. Tags are available for selection by typing '#'. 
Refer to the Communications manual for a complete list of transaction related tags.


73695269  


Understanding allocations

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

  1. Invoice 1: €20
  2. Invoice 2: €10
  3. Credit Note 1: €20
No.
Action
Intended Invoices
Allocations
Allocation Type
Allocation amount
Unallocated Amount
1Creation of Invoice 1N/AN/AN/A--
2Creation of Invoice 2N/AN/AN/A--
3Creation of Credit Note 1N/ACredit Note 1 allocated on Invoice 1FIFO20-
4Cancellation of Invoice 1Invoice 1




--
4a

Credit Note 1 de-allocated from Invoice 1

N/AN/ADe-allocation20-
4b

Creation of Cancellation Invoice 1

N/AInvoice 1 allocated on Cancellation Invoice 1Against Item20-
4cCredit Note 1 allocated on Invoice 2N/ACredit Note 1 allocated on Invoice 2FIFO1010


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

  1. Invoice 1: €10
  2. Invoice 2: €20
  3. Invoice 3: €20
  4. Credit Note 1: €10 (Intended invoice: Invoice 1)
  5. Credit Note 2: €20 (Intended invoice: Invoice 2)
No.
Action
Intended Invoice
Allocations
Allocation Type
Allocation amount
Unallocated Amount
1Creation of Invoice 1N/AN/AN/A--
2Creation of Invoice 2N/AN/AN/A--
3Creation of Invoice 3N/AN/AN/A--
4Creation of Credit Note 1Invoice 1Credit Note 1 allocated on Invoice 1FIFO and Against Item100
5Creation of Credit Note 2Invoice 2Credit Note 2 allocated on Invoice 2FIFO and Against Item200
6Cancellation of Invoice 1




--
6a

Credit Note 1 de-allocated from Invoice 1


N/ADe-allocation100
6b

Creation of cancellation Invoice 1


Invoice 1 allocated on Cancellation Invoice 1Against Item100
6cCredit Note 1 allocated on Invoice 3
Credit Note 1 allocated on Invoice 3FIFO1010

On this page

  • No labels