Excerpt | ||
---|---|---|
| ||
Understand the usage of Financial Transactions within CRM.COM |
Back to Financial Transactions Main Page
Panel | ||||
---|---|---|---|---|
| ||||
Table of Contents
|
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 A Financial Transaction is an agreement between a buyer and a seller to exchange Services or Physical Goods for payment. The transaction’s nature is differentiated by its type Type (invoiceInvoice, credit noteCredit Note, paymentPayment, refund Refund etc.). Financial Transactions impact the balance of the customer's accounts receivable and the information kept on each of them depends on their typeIt involves a change in the status of the finances of the businesses or individuals involved, which is directly reflected on the customer's Accounts Receivable by updating its Balance.
Financial Transactions Glossary
Terms | Description |
---|---|
Financial Transaction | Draft 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 Transaction | Posted 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 Transaction | Rejected 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 Date | The 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 Date | The 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 / Concept | Description |
---|---|
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.
|
Posting of Financial Transactions | Financial 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 | Allocation of Credit Invoices is always done based on the Allocation Principle of the account. Check out Understanding Accounts Receivable Key Processes and Concepts section for a description of how allocation works in CRM.COM |
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.
Entity | Network Characteristics |
---|---|
Financial Transaction Types | |
Financial Transactions |
Financial Transactions Related Modules
Interaction Entity | How |
---|---|
Accounts Receivable | Financial Transactions Posted against Accounts Receivable |
Bills | Financial Transactions Included in Bills |
Customer Events | Financial Transactions can automatically purchase Customer Events (if configured accordingly) |
Wallet Transactions | Financial 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
name | blue |
---|---|
title | 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
Note |
---|
More Information on Posting Refunds can be found at: Posting Draft Financial Transactions |
Cancelling erroneously created Invoices
name | blue |
---|---|
title | 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.
Note |
---|
More Information on Cancelling Invoices can be found at: Cancelling Invoices |
Cancelling erroneously created Payment
name | blue |
---|---|
title | 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.
Note |
---|
More Information on Cancelling Payments can be found at: Cancelling Payments |
Move Payments from Suspense Account to customer accounts
name | blue |
---|---|
title | 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 accountClassification | The Classification determines the nature of the Financial Transaction, including its notation in the double-entry accounting system (debit or credit). Financial transaction type classifications are predefined in the system and cannot be overridden. The following Classifications are available:
|
---|---|
Payment | A Payment is a financial document issued by a customer to a business to settle an outstanding balance. Payments are crediting Accounts Receivable |
Invoice | An Invoice is a financial document that shows a list of services or physical goods and the prices to be paid for them. Invoices are debiting Accounts Receivable |
Credit Note | A Credit Note is a financial document issued by a business to a customer to correct mistakes or adjust the amount that the customer was invoiced. Credit Notes are crediting Accounts Receivable |
Refund | A Refund is a financial document issued by a business to a customer in order to pay back a specific amount of money. Refunds are typically issued to customers who are not satisfied with the Services or Physical Goods that were provided to them and not to adjust or cancel specific Invoices. Refunds are debiting Accounts Receivable |
Invoice Cancellation | An Invoice Cancellation is a financial document which is issued to cancel a specific Invoice. Invoice Cancellations are crediting Accounts Receivable |
Payment Cancellation | A Payment Cancellation is a financial document which is used to cancel a specific Payment. Payment Cancellations are debiting Accounts Receivable |
Financial Transaction Life Cycle State: 'Draft' | A 'Draft' Life Cycle State represents a Financial Transaction which is not yet posted, and can still be edited, posted or rejected in the future. Financial Transactions in a 'Draft' Life Cycle State do not affect the Accounts Receivable Balance. |
Financial Transaction Life Cycle State: 'Posted' | A 'Posted' Life Cycle State represents a Financial Transactions that can no longer be edited. Financial Transactions in a 'Posted' State affect the Accounts Receivable Balance. |
Financial Transaction Life Cycle State: 'Rejected' | A 'Rejected' Life Cycle State represents Financial Transactions that went from being 'Draft' to being ''Rejected'' instead of being 'Posted'. 'Rejected' Financial Transactions cannot be edited and do not affect Accounts Receivable Balance. |
Due Date | The date by which an Invoice must be settled. Due Date is set either manually or automatically and must always meet predefined configurable system rules. |
Issued Date | The date on which a Financial Transaction is issued, either in a 'Draft' or 'Posted' Life Cycle State. |
Posted Date | The date on which a Financial Transaction is 'Posted'. |
Financial Transactions Key Processes and Concepts
Processes / Concept | Description |
---|---|
'Cancelling' Vs 'Rejecting' Financial Transactions | Financial Transactions cannot be deleted. If they have been created accidentally, then this can be corrected by using the 'Cancel' or 'Reject' action. Neither action will be taken into consideration by any of the system's financial processes.
|
Posting of Financial Transactions | Financial Transactions created in 'Draft' Life Cycle State by using the Save As Draft button can be posted at a later stage by using the ' Post' action.Alternatively, you can set the Life Cycle State of a Financial Transaction directly to 'Posted' by using the SAVE button instead of Save as Draft
|
Allocation of Credit Transactions on Invoices | Allocations are used to allocate Credit Financial Transactions against Invoices, in order to settle any outstanding amount. Allocations are applied automatically by the System based on the allocation principle specified on the active Accounts Receivable Definition. View Accounts Receivable as well as Understanding the Allocation Principles for a description of how the allocation principle works in CRM.COM |
Financial Transactions Access & Viewing Controls
Business Network Characteristics define the level of access for each record. i.e., whether the record will be available for selection, viewing or editing.
Entity | Network Characteristics | Description |
---|---|---|
Financial Transaction Types |
| |
Financial Transactions |
|
Financial Transactions Related Modules
Entity | Interaction with the Entity |
---|---|
Accounts Receivable | Financial Transactions are Posted against Accounts Receivable. The balance of the account is updated when Financial Transactions are posted |
Bills | Financial Transactions are included in the Bill as Bill Lines |
Wallet Transactions | Financial Transactions can be related with Wallet Transactions via the Wallet related to the Accounts Receivable. i.e. if configured accordingly, whenever a Financial Transaction is created against the Accounts Receivable, a respective Wallet Transaction can be created against the Wallet. |
Financial Transactions - Business Examples
The following section provides business examples of how the Financial Transactions module is used in CRM.COM.
Posting Refunds after Bank Payment confirmation
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX would like to create Refunds once a month for its customers with a negative outstanding balance. The Refunds are paid out to the customers through their bank account. Once the bank makes the Payment to the customer's account, the bank sends a file back to Company ZX with all the successful Payments. Company ZX can the update the customer's accounts balances. CRM.COM Solution
|
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.
Note |
---|
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
|
Cancelling Invoices created by Error
Panel | ||||
---|---|---|---|---|
| ||||
Business RequirementA 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 Company ZX would like to cancel 'Posted' Invoices that were created by error. CRM.COM Solution
|
|
Cancelling Payments created by Error
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX would like to cancel Payments that are already 'Posted' that have been created by error. CRM.COM Solution
|
Move Payments from Suspense Account to Customer Accounts
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX imports Payments from the bank through an import file. CRM.COM Solution
|
Company ZX issuing an Invoice with a Discount
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX would like to have the Due Date always fixed to the 15th of the next monthA customer of Company ZX purchases 2 Cards. He gets a discount for both, 15% for the first one and €20 for the other one. One of the two cards is charged a VAT rate of 0%. CRM.COM Solution
Business Requirement Company ZX would like to have the Due date to always be set 10 days after the Posted date CRM.COM Solution
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
|
Company ZX - Invoice Due Dates - Fixed Date
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX wants the 15th day of the month as the Invoice 'Due Date'. CRM.COM Solution
|
FIFO Versus FIFO & Against Item Principle
Panel | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
FIFO & Against Item
Business Requirement Company ZX would like to have the 'Due Date' always set 10 days after the 'Posted Date'. CRM.COM Solution
Business Requirement Even though Company ZX would like to allow agents to set the 'Due Date' at a maximum of 10 days after the 'Posted Date', it requires the System to set the 'Due Date' to 5 days after the 'Posted Date'. CRM.COM Solution
|
FIFO Versus FIFO & Against Item Principle
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
FIFO 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 one Invoice which has already been allocated to a Credit Note using the FIFO model. After a second Invoice is created the first Invoice is cancelled.
| ||||||||||
No | Action | Intended Invoice | Allocations | Allocation Type | Allocation amount | Unallocated Amount | 1 | Creation of
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 | N/A | De-allocation | 20 | ||||
24b | Creation of Cancellation Invoice | 21 | N/A | N/A | N/AInvoice 1 allocated on Cancellation Invoice 1 | Against Item | 20 | 3 | Creation of||
4c | Credit Note 1 allocated on Invoice 2 | 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 | 20 | 0 | |||||
4c | Credit Note 1 allocated on Invoice 3 | Credit Note 1 allocated on Invoice 3 | FIFO | 10 | 10 |
Note |
---|
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
Panel | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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
Note |
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 the invoices in question. The first Invoice is then cancelled.
|
Payment Methods accepted by Company ZX
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX only allows its customers to pay using Cash and Credit Cards. |
It wants to introduce a new way of |
Payment in order to allow customers to also pay via PayPal |
. This type of |
Payments would need to be distinguished on the Payment level as |
more types of online Payment other than Paypal might be added |
in the future. CRM.COM Solution
|
|
|
|
|
Rejecting Payments Options
Panel | ||||
---|---|---|---|---|
| ||||
Business Requirement Company ZX allows rejection on payments on Payments to be rejected in the following occasionscases:
CRM.COM Solution
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Related Areas
|
|
name | grey |
---|