Usually abbreviated/referred to/as ‘BHrs’. |
The working hours on a working day associated with a payment type.
| | Buyer |The TL entity Buying product/services associated with a transaction.
NOTE:- An entity can be a Buyer only, a Seller only, or both
| | Buyer Acceptance Window | The minimum number of hours that a Buyer must have to review their transactions in a Settlement cycle. | | Buyer Collection day/time |Often referred to simply as ‘Collection day
The Date/time on which Buyer Collections are initiated (and seller refund collection in a ‘Smart float’ configuration)
| | Collection | Collecting of funds using a specified payment method | | Commit | The action (most often undertaken by a Seller after they have reviewed transactions they have loaded on to TL ) that causes a transaction to be ‘active’ on the TL system and, if eligible, to be assigned to a Settlement cycle. | | Commercial Link |Usually abbreviated/referred to/as ‘CL’.
This is the collection of rules – including Business Terms, Payment Type(s) and (optionally) Settlement schedules - that regulate a relationship between 2 (or 3 if a PE is involved) entities.
| | Disbursement | See Payment | | Financial Float |In a PE environment, a monetary amount or ‘float’ in the PE’s Bank account that allows the netted collections to take place.
TL supports two options at launch – ‘None’ and ‘Smart’
| | Financial Float – ‘None’ |This setting represents the standard collection logic used by the Virgin Media platform
The PE provides the float, but also takes on the financial risk should collections fail.
| | Financial Float – ‘Smart’ |Also referred to as ‘Smart Float’
This setting represents alternative (configurable) collection logic supported by the TL platform
The float is provided by collecting funds from Buyers whose sales > refunds ( i.e. they have a nett positive position) and from Sellers for any of their buyers whose refunds >sales (i.e. they have a nett negative position).
This arrangement helps reduce the financial risk to the PE should collections fail
| | Funds clearing period |Payment type specific. The total number of hours between submitting a payment request and the cleared funds being available in the recipient’s account.
This period includes BACS pre-processing, BACS processing, BACS collection, and actual clearing days
| | Indirect Commercial Link | A special type of Commercial Link between more than 2 Entities. Only “Processing Entities” can create Indirect Commercial Links | | Direct Debit |Usually abbreviated/referred to/as ‘DD’
An instruction sent to the DD platform to perform a collection
| | Direct Credit |Usually abbreviated/referred to/as ‘DC’
An instruction sent to the DD platform to perform a payment
| | DD managed platform | The PTx platform from Bottom Line Technologies interacting with the BACS Banking platform to perform operations | | DD Mandate | The agreement (with a unique ID) between two parties to collect funds or make a payment using the BACS platform | | DD Profile | This is the profile for each TL Entity, “in” the DD managed platform, to which a DD mandate is associated | | Due date | If supplied – the date that cleared funds should be available in a Seller’s account. | | KYC | Know your clients | | Manually added/forced Collection |An extra collection day/time that the PE Admin chooses to add – for instance to compensate for a previously skipped collection or to deal with exceptional circumstances.
See Also skipped Collection & Skipped days
| | Matched | The status of a transaction after seller loading where the information in the transaction – Buyer/Seller/Commercial link/etc – has been fully matched with corresponding records in TL | | Non-Banking Day |Usually abbreviated/referred to/as ‘NBD
A public/Bank holiday or a weekend day
OR/ (optionally) any other day that has been manually designated (by skipping in the settlement schedule) as such by the PE Admin’.
NOTE:- Depending on the Payment method/country, weekends and public holidays may be auto-defined.it
| | Payment | The paying/disbursing of funds (mostly from a previous collection) using a specified payment method | | Payment Gateway | The collection of rules and API calls that interact with a specific payment method or supplier (i.e.. “DD payment gateway” will be the module interacting with the DD managed platform) | | Payment Types |The methods for collecting funds or making payments.
NOTE:- An Automated Payment types requires a settlement schedule.
| | Processing Entity |Usually abbreviated/referred to/as ‘PE’
A third party – for instance ABTA - managing the CL under which specified Sellers and Buyers trade with each other on the TL platform
| | Reject Transaction |The action (most often undertaken by a Buyer after they have reviewed their transactions) that indicates that the Buyer wishes to exclude it from further processing, as well as specifying a reason code.
Rejected transactions are not eligible for settlement once the Buyer Acceptance Window closes
| | Remittance |The record (with a status) associated with a transaction indicating that payment for it has/or will take place. Remittances are automatically created used as the basis to collect or disburse fund for an Automated Payment type
If permitted, offline Remittances (fulfilled/paid offline) can be manually created
A remittance can be positive or negative.
| | Seller |A TL entity Selling product/services associated with a transaction.
NOTE:- An entity can be a Buyer only, a Seller only, or both
| | Settlement Cycle |Collectively, all the events and dates associated with a specific collection date/time, either before or after which, together, make up the entire load/review/collection/payment cycle.
Settlement cycles will overlap for different CL/Payment type combinations. They will also commonly overlap within a CL/Payment type combination where the payment takes time to process and/or clear.
Settlement cycles can be displayed from within the dashboard.
NOTE:- Only applies to an automated Payment type
| | Settlement Routine | An automated routine running multiple times a day that will use configuration in the prevailing CL to assign transactions to a settlement cycle and – if relevant - initiate any collections/payments that are due to be processed | | Settlement Schedule |The Collection dates/times calculated by the TL platform based on the configuration of the CL.
Collection dates are displayed in a calendar format from within a Settlement Schedule record.
NOTE:- Only applies to an automated Payment type
| | Skipped Collection | A calculated Collection date/time that the PE Admin chooses to ‘skip’ – for instance if it falls too close to a public holiday, etc. See Also manually added/forced Collections | | Skipped day | Any other date that the PE Admin chooses to ‘skip’ | | Submission | Sending data to BACS via the DD managed platform to initiate a direct debit or direct credit. | | SUN | Service User Number – It is the number used by BACS to identify and validate the company that is submitting Direct Debit transactions for processing | | TL Administrator | TL customer service member responsible for activating new Entities after KYC and accreditation | | Trade organisation or Indirect Processing Entity |This is a special type of “Entity” in TL that can create Commercial Links where more than two parties are involved (primarily to process payments).
This Entity controls the “Indirect Commercial Link” and performs the role of clearing house
| | Transaction | Synonymous with an invoice or credit note. A transaction can be positive or negative. | | Un-accepted Transaction |The status of a transaction that the TL platform will automatically assign if, at the end of a Buyer Acceptance Window, the transaction is not Accepted, Amended, or rejected.
Un-accepted transactions are not eligible for settlement once the Buyer Acceptance Window closes and they will have to be re-submitted into a future settlement cycle to be collected.
| | User | A user of the Travel Ledger platform | | ‘X’ Hours |The configurable time delay between collecting funds from Buyers and disbursing them to Sellers.
Referred to as Forward funds to Seller after (hours)”.
| | ‘Y’ Hours |In a ‘Smart float’ configuration, the configurable time delay between collecting refunds from Sellers and disbursing them to Buyers.
Referred to as Forward funds to Buyer after (hours)”.
|