Skip to end of banner
Go to start of banner

Understanding Financial Transactions

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

« Previous Version 3 Next »

What does this section cover?

What are Financial Transactions?

Financial Transactions are statutory transactions, governed by the accounting standards of the country, carried out between two parties, the business and the customer, to exchange services or physical goods. The transaction’s nature is differentiated by its type (invoice, credit note, payment, refund etc.). Financial Transactions impact the balance of the customer's accounts receivable and the information kept on each of them depends on their type.

Financial Transactions Glossary

TermsDescription
Draft Financial TransactionDraft financial transactions are transactions which were not posted yet, and can be edited posted or rejected. Draft financial transactions do not affect accounts receivable balances.
Posted Financial TransactionPosted financial transactions are permanent and cannot be edited by any means. Posted financial transactions affect accounts receivable balance. The credit period of an accounts receivable starts from the date that the financial transaction is posted.
Rejected Financial TransactionRejected financial transactions are transactions that were draft and were rejected instead of being posted. Rejected financial transactions cannot be edited. Rejected financial transactions do not affect accounts receivable balances.
Issued DateThe date that a financial transaction was created, either in draft or posted life cycle state. The credit period of an accounts receivable is not calculated based on the issued date.
Posted DateThe date that a financial transaction was posted and started to affect the accounts receivable balance. The credit period of an accounts receivable starts from the date that the financial transaction is posted.

Financial Transactions Key Processes and Concepts

Processes / ConceptDescription
Cancelling Versus Rejecting Financial Transactions

Financial Transactions cannot be deleted. If they have been erroneously created then you can correct them by using either the Cancel or Reject action. Both actions will not be taken into consideration by any financial process of the system.

  • Use the Cancel action of you have already posted the invoice or the payment
    • Cancel action is available for Invoices and Payments
  • Use the Reject action if the transaction is still is Draft state
    • Reject action is available for all Financial Transaction Classifications
Posting of Financial TransactionsFinancial Transactions belong to an account of a customer or to a system account. In order for a Financial Transaction to affect the balance of the account, it needs to be Posted (Life Cycle State). The Posting process can be done directly when creating the Financial Transaction by using the SAVE button, or you have the option to create the financial transaction in state Draft, by using the Save as Draft button and use the Post action at a later stage.
Allocation of Credit Transactions on Invoices 

Financial Transactions Network Characteristics

Network Characteristics define the level of access for each record. i.e. Whether it will be available for selection, for viewing or editing etc.

EntityNetwork Characteristics

Financial Transaction Types

Financial Transactions

Financial Transactions Related Modules

Interaction EntityHow
Accounts ReceivableFinancial Transactions Posted against Accounts Receivable
BillsFinancial Transactions Included in Bills
Customer EventsFinancial Transactions can automatically purchase Customer Events (if configured accordingly)
Wallet TransactionsFinancial Transactions can be related with Wallet Transactions via the Wallet related to the Accounts Receivable

Financial Transactions  - Business Examples

The following section provides business examples to help you understand how CRM.COM Financial Transactions  module is used.

Posting Refunds after Bank payment confirmation

Posting Refunds after Bank payment confirmation

Business Requirement

Company ZX would like to create Refunds once a month for any customers with negative outstanding balance. The Refunds are paid out to the customers via their bank account. Once the bank makes the payment out to the customer's account, sends a file back to Company ZX with all the successful payments. Only then will Company ZX would like to update the customer's accounts balance.

CRM.COM Solution

  • User Process
    All the Refunds should be created in life cycle state Draft and sent out to the bank. Once the file with the successful payments, is received from the bank then each of those refunds should be accessed and updated to Posted. In this way the balance of the account will be automatically updated taking into consideration the Refund amount

More Information on Posting Refunds can be found at: Posting Draft Financial Transactions

Cancelling erroneously created Invoices

Cancelling erroneously created Invoices

Business Requirement

Company ZX would like to cancel any invoices that are already posted and have been erroneously created.

CRM.COM Solution

  • Configuration
    An operations user should be responsible for cancelling such invoices. Admin users can configure different types of Invoice Cancellation classified transactions, in order to differentiate between different reasons for cancelling an invoice. For example, Cancellation Error Invoices & Cancellation Complain Invoices.
  • User Process

    The user should select the invoice to be cancelled and create a Financial Transaction of the respective type.

    In this way the invoice will be available for future reference but it will not affect the account's balance, while any user can have a clear picture of why it was cancelled based on the FT Invoice Cancellation type and if more information is needed, then the Cancellation's transaction Issue Reason may be accessed by the detail page to get extra information.

 

More Information on Cancelling Invoices can be found at: Cancelling Invoices

 

Cancelling erroneously created Payment

Provide a title for the business example. (Keep simple and short)

Business Requirement

Company ZX would like to cancel any payments that are already posted and have been erroneously created.

CRM.COM Solution

  • Configuration
         An operations user should be responsible for cancelling such payments. Admin users can configure different types of Payment Cancellation classified transactions, in order to differentiate between different reasons for cancelling a payment. For example, Erroneous Cancellation Payments& Erroneously Allocated Cancellation Payments
  • User Process

    The user should select the invoice to be cancelled and create a Financial Transaction of the respective type.

    In this way the payment will be available for future reference but it will not affect the account's balance, while any user can have a clear picture of why it was cancelled based on the FT Payment Cancellation classification and if more information is needed, then the Cancellation's transaction Issue Reason may be accessed by the detail page to get extra information.

 

More Information on Cancelling Payments can be found at: Cancelling Payments


Move Payments from Suspense Account to customer accounts

Move Payments from Suspense Account to customer accounts

Business Requirement

Company ZX imports payments from the bank through an import. If the destination account is not found then the payment will be created in Company ZX system Suspense account. Back office personnel are responsible to manually check and move the payments to the correct customer account.

CRM.COM Solution

  • User Process

    BackOffice operators should follow the process described below:

    Company's ZX backoffice personnel should daily access Company's ZX suspense account. For each of the payments which the correct account has been found the action "Move to Account" should be executed.

     

More Information on Move Payments from Suspense Account to customer accounts can be found at: Moving Payments to another Accounts Receivable


Company ZX issuing an invoice with Discount

Company ZX issuing an invoice with Discount

Business Requirement

A customer of Company ZX has bought 2 Cards. For both of the cards he received a discount, 15% for the first one and 20€ discount from the other one. One of the cards would be charged with 0 VAT

CRM.COM Solution

  • User Process

    Create a new Financial Transaction of type Invoice. In the Items tab add 2 lines with the following information

    1. Card 1
      • Cost: 100
      • Quantity: 1
      • Discount
        • Discount Percentage: 15%
      • VAT Rate
        • VAT rate:15%
    2. Card 2
      1. Cost: 100
      2. Quantity: 1
      3. Discount
        • Discount Amount: 20€
      4. VAT Rate
        • VAT rate:0%

    System Calculations:

    1. Card 1
      1. VAT Amount: (100-15)*15/100 = 12.75
      2. Subtotal: (100-15+12.75) = 97.75
    2. Card 2
      1. VAT Amount: 0
      2. Subtotal: 80

 

Company ZX - Invoice Due Dates - Fixed Date

Company ZX - Invoice Due Dates - Fixed Date

Business Requirement

Company ZX would like to have the Due Date always fixed to the 15th of the next month.

CRM.COM Solution

  • Configuration 

    The Accounts Receivable Credit Rule should be set up defining the xth day to be equal to 15 after x months to be equal to 1.

  • User Process
    When Posting the Invoice:

    • If the user defined the date then according to the date provided the system will validate accordingly. For example if the Date of Posting is 20th of May
      • Due Date Set: 21/05
        • System Message: Invalid Due Date
      • Due Date set: 16/06
        • System Message: Invalid Due Date
      • Due Date set: 15/06
        • Due Date Saved
    • If the user leaves the Due Date empty then the system will set the Due date automatically to 15/06

 

Business Requirement

Company ZX would like to have the Due date to always be set 10 days after the Posted date

CRM.COM Solution

  • Configuration
         The Accounts Receivable definition Credit Rule should be set up defining X Days after transaction's Posted Date: X= 10
  • User Process 

    When Posting the Invoice:

    • If the user defined the date then according to the date provided the system will validate accordingly. For example if the Date of Posting is 20th of May
      • Due Date Set: 28/05
        • System Message: Invalid Due Date
      • Due Date set: 31/05
        • System Message: Invalid Due Date
      • Due Date set: 30/06
        • Due Date Saved
    • If the user leaves the Due Date empty then the system will set the Due date automatically to 30/06

Business Requirement

Company ZX would like to allow agents to set the due date max to 10 days after the Posted date but the system should automatically set the due date to 5 days after posted date

CRM.COM Solution

  • Configuration

    The Accounts Receivable definition Credit Rule should be set up defining X Days after transaction's Posted Date: X= 10

    Proximity range should be set to -5

  • User Process

    When Posting the Invoice:

    • If the user defined the date then according to the date provided the system will validate accordingly. For example if the Date of Posting is 20th of May
      • Due Date Set: 28/05
        • Due date saved
      • Due Date set: 31/05
        • System Message: Invalid Due Date
      • Due Date set: 30/06
        • Due Date Saved
    • If the user leaves the Due Date empty then the system will set the Due date automatically to 25/05 (The smallest allowed dua date based on the Proximity Range set)


More Information on Invoice Due Dates can be found at: Handling Invoice Due Dates

 

FIFO Versus FIFO & Against Item Principle

FIFO Versus FIFO & Against Item Principle

FIFO Principle

In the following example, we have one invoice which has already been allocated to a credit note using the FIFO model. A second invoice is created and then 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

In the following example, we have 3 invoices of which the 2 first are allocated from Credit Notes that were intended for them. Then the first invoice is cancelled.

  1. Invoice 1: $10
  2. Invoice 2: $20
  3. Invoice 2: $30
  4. Credit Note 1 : $20 (Intended Invoice: Invoice 2)
  5. Credit Note 1 : $10 (Intended Invoice: Invoice 1)
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 2N/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
4Cancellation of Invoice 1 

 

 

   
4a

Credit Note 1 de-allocated from invoice 1

 N/ADe-allocation100
4b

Creation of Cancellation Invoice 1

 Invoice 1 allocated on Cancellation Invoice 1Against Item200
4cCredit Note 1 allocated on Invoice 3 Credit Note 1 allocated on Invoice 3FIFO1010

More Information on FIFO Versus FIFO & Against Item Principle can be found at: Using the Allocation Principles

 

Restrict rights to cancel Payments to certain users

Restrict rights to cancel Payments to certain users

Business Requirement

Company ZX would like to be able to cancel payments due to user errors, however only Operation users should be allowed to make this cancellations. However all users should be allowed to make cancellations of payment.

CRM.COM Solution

  • Configuration

    2 Financial Transaction Type of Classification Payment Cancellation will need to be configured in the system.

    • Payment Cancellation
    • Payment Cancellation Special

    Both types will be configured in exactly the same way apart from the "Allow Selection only for Units" tab.

    For the Payment Cancellation Special the "Operations" Unit will be added.

    In this way, when cancelling a payment the Payment Cancellation Special type will only be available to users that belong to the Operations unit; type: Payment Cancellation on the other hand will be available for all users to select

 

More Information on Restrict rights to cancel Payments can be found at: Configuring Financial Transaction Types

Payment Methods accepted by Company ZX

Payment Methods accepted by Company ZX

Business Requirement

Company ZX only allows its customers to pay using Cash and Credit Cards. A new way of payment will be introduced to allow customers to pay via PayPal and these type of payments would need to be distinguished on the Payment level as in the future more ways might be added for online payments apart from Paypal.

CRM.COM Solution

  • Configuration

    3 Payments will need to be configured in the system

    • Cash
    • Credit Card
    • PayPal

    On the Financial Transaction Types configuration module 2 different Payment Types should be created.

    • Normal Payment
    • Online Payment

    For each of the 2 Payment Types different Allowed payment Methods will be configured:

    • Normal Payment
      • Cash
      • Credit Card
    • Online Payment
      • Paypal

More Information on Payment Methods can be found at: Configuring Payment Methods


Rejecting Payments Options 

Rejecting Payments Options

Business Requirement

Company ZX allows rejection on payments on the following occasions:

  • Agent Error
  • System Error
  • On customer Request

CRM.COM Solution

  • Configuration

    In CRM.COM 4 different rejection reason should be setup in the system and to be used by the personnel when rejecting a payment

    • Agent Error
    • System Error
    • On customer Request
    • Other (in this case the user can write the related information in the "Issue Reason free text"

 

More Information on Rejecting Payments Options can be found at: Configuring Rejection Reasons

Related Areas

Popular Labels

  • No labels