Learn to work with Financial Transactions |
On this page |
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.
Transactions that are not yet posted can be rejected. Posted transactions can be canceled.
Configuration > Finance Application > Financial Transactions |
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.
Configure a default financial transaction type for each classification and add it to the financial transaction definition.
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 | |
---|---|
| |
(Visible for the payment classification) | |
The predetermined ways to make a payment in the system. At least one method must be defined. | |
(Visible for the refund classification) | |
The predetermined ways to issue a refund in the system. At least one method must be defined. | |
Predetermined categories that can be used in financial transactions of each type. |
Definitions regarding:
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
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). | |
Select the reasons for which financial transactions in a 'Draft' state can be rejected. |
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 |
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 are used to debit customer accounts and can be generated by system processes or manually by the user.
Invoices can be created by using the New > Invoice action available from the financial transactions Summary page.
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).
Life Cycle State (set by the system and depends on whether the user selected 'Save as Draft', 'Save', 'Reject' or ' Write off')
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. | |
Individual line items in the invoice (at least one must be provided). The following aggregated amounts are calculated dynamically:
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:
| |
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 are used to credit customer accounts and can be generated by system processes or manually by the user.
Credit notes can be created manually:
Create a credit note by using the New > Credit Note action, available from the financial transactions Summary page.
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).
Life Cycle State (set by the system and depends on whether the user selected 'Save as Draft', 'Save' or 'Reject')
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. | |
Individual line items in the invoice (at least one must be provided). The following aggregated amounts are calculated dynamically:
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:
| |
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 are used to credit the customer accounts. They can be generated by system processes or manually by the user.
Payments to credit a customer account can be created manually, by using the New > Payment action available from the financial transactions Summary page.
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).
The Currency of the accounts receivable (default).
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')
Issued On (date/time) Posted On (set by the system) Voucher (number) available when a voucher was used to create and post the payment. 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 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 Instant discount refunds for more information.
Refunds to debit a customer account can be created by using the New > Refund action available from the financial transactions Summary page.
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).
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')
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 are used to cancel a bad debt and deduct the total unsettled amount of an invoice from the account balance.
Write-offs are created against unsettled invoices. Access the Invoice Data Entry page and click Write Off from the Actions menu.
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) Life Cycle State: Can only be 'Posted'. Transactions are permanent, cannot be edited and affect the account's balance).
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:
| |
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. |
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.
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 |
Invoices can be canceled by using the Cancel action available on the invoice's Data Entry page.
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.
The Currency in which amounts are expressed is set on the accounts receivable.
Life Cycle State: Can only be 'Posted'. Transactions are permanent, cannot be edited and affect the account's balance).
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. | |
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:
| |
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. |
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.
Cancel a payment by using the Cancel action available from the payment's Data Entry page.
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.
The Currency in which amounts are expressed is set on the accounts receivable.
Life Cycle State can be one of the following:
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. |
Validations take place before an action is initiated (prerequisite) or after it is submitted (postcondition). |
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
SAVE (POSTED)
|
Credit Note | SAVE AS DRAFT
SAVE (POSTED)
|
Payment | SAVE AS DRAFT
SAVE (POSTED)
|
Refund | SAVE AS DRAFT
SAVE (POSTED)
|
Transactions can be edited until they are posted. Enter EDIT mode from the Actions menu.
Prerequisites | The transaction must be in a 'Draft' state. |
---|
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'. |
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 |
|
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 |
|
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 |
|
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 |
|
|
System Processing |
|
|
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 |
|
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 |
|
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. |
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.
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 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.
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.
Allocation takes place using FIFO.
If an already allocated invoice is canceled, then
The payment is de-allocated and the invoice is allocated again using FIFO
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.
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 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.
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.
To conduct payments and refunds through the payment gateway:
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.
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.
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 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.
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.
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.
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.
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.
The report displays a list of all invoices, credit notes and invoices cancellations that were posted within a specific period of time.
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.
The report displays a list of all financial transactions that were posted within a specific period of time.
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 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.
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 |
Scenario 2. Company ZX would like to cancel 'Posted' invoices that were created by error. Solution Configuration 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. |
Scenario 3. Company ZX imports payments from the bank using an import file. 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. |
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:
System Calculations:
|
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 nth 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 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 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 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 user leaves the due date empty, it is automatically set to 25/05 (the earliest allowed due date according to the proximity range).
|
Scenario 6a. Company ZX wants to enable its customers to make payments using an online payment gateway. Solution Configuration
User process
|
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.
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.
|
|
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. |
Related Links |