---
title: "Ageing Periods | GTX Payments"
slug: "ageing-periods"
description: "Learn about Ageing Periods in Marlin GTX trusted automotive software by Megabus."
updated: 2025-12-07T22:41:28Z
published: 2025-12-07T22:41:28Z
canonical: "help.megabus.com.au/ageing-periods"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://help.megabus.com.au/llms.txt
> Use this file to discover all available pages before exploring further.
# Ageing Periods
{{snippet.legacy inform}}
{{variable.GTX Bold}} enables you to define flexible Payment Terms, calculate transaction due dates accurately, and manage both customer and supplier payments with greater control.
## Payment Terms Options
A Payment Period must be specified to control calculation of the Due Date.
The Payment Period options are:
* **COD**: Payment Due Date is today
* **Weekly**: Payment Due Date is calculated in relation to multiples of weeks
* **Monthly**: Payment Due Date is calculated in relation to multiples of months
* **Transaction Date**: Payment Due Date is calculated in relation to the transaction date
To edit or add new Payment Terms, select **System > System Files > Banking and Payments > Payment Terms** from the Marlin GTX menu.
### COD
If selecting COD, the Payment Due Date is always today.
If the transaction remains unpaid before the End of Month (EOM), it remains in the Current Age Dissection.
### Weekly
Selecting a Payment Period of Weekly enables you to set the Payment Due Date by specifying a number of full payment periods (weeks) and the day number in the last week.
Note: The remaining portion of the week in which the transaction occurred is not a full week and can be thought of as Period 0. It is not included in the calculation. The first week (Period 1) commences on the first Monday after the transaction date.
### 7 Days
To set up 7 Day terms, select **Day 7 of 1 Payment Period**.
### 14 Days
To set up 14 Day terms, select **Day 7 of 2 Payment Periods**.
### Monthly
Selecting a Payment Period of Monthly enables you to set the Payment Due Date by specifying a number of full months and the day number in the last month.
Note: The remaining portion of the month in which the transaction occurred is not a full month and can be thought of as Period 0. The first month (Period 1) commences on the first day of the month after the transaction date.
### 30 Days
To set up 30 Day terms, select **Last Day of 1 Payment Period**.
### 45 Days
To set up 45 Day terms, select **Day 15 of 2 Payment Periods**.
### 60 Days
To set up 60 Day terms, select **Last Day of 2 Payment Periods**.
## Transaction Date
This Payment Period type enables you to specify the Due Date as a number of days after the Transaction Date.
Note: There is no Period 0. The Due Date will simply be the specified number of days after the transaction date.
The example below shows that the Due Date will be 7 Days after the Transaction Date.
## Payment Schedules
Payment Terms can be defined that allow a customer to pay the invoice in installments.
In this case, there will be multiple payments due for a single invoice. You are also able to specify the percentage of the invoiced amount to be paid by each installment.
It is not included in the payment terms calculation, the first payment will be due on the 10th day of the month after the transaction date).
:::(Error) (Example)
In the example below the remaining portion of the month in which the transaction occurred is not a full month and can be thought of as "Period 0".
You have allowed the customer to pay off the invoice in 3 (almost) equal installments, each due on the 10th day of subsequent months.
In this case, the Invoice has multiple due dates.
:::
:::(Info) (Note)
This option requires a system switch to be activated.
:::
## Payment Terms on Customers and Suppliers
The ability to add enhanced Payment Terms definitions allows for much more flexible calculations of the dates transactions are due to be paid.
This Payment Terms calculation is applicable to both Customers and Suppliers and is a mandatory field on the Options tab of Customer Maintenance and Supplier Maintenance.
A Supplier is required to have ONE Payment Terms assigned to them.
A Customer is required to have ONE OR MORE Payment Terms assigned to them.
The Payment Terms for any particular transaction can be selected at the Finalise step.
On a Customer Invoice, only allowable Payment Terms can be selected. The default is the "Preferred" Terms.
On a Supplier Invoice, any of the defined Payment Terms can be selected.
## Transactions Due Date
Every transaction entered against a Customer or Supplier will have a Payment Due Date calculated.
In the case of Customers that have multiple allowable Payment Terms, the user can select the Payment Terms per transaction.
A Customer Payment Due report will indicate what amounts are due from each customer and the date the payment is due.
A Supplier Payment Due report will indicate what amounts are due to each supplier and the date the payment is due.
## Customer Statements
A list of future dates with total amount due by that date is shown after the last transaction on the statement.
Any transactions where the Due Date is prior to the Statement Date will be grouped under an "Overdue" item, then each individual date and due amount will be listed after this.
## Aged Balance Dissection
The Aged Balance Dissection will no longer be related to the Payment Terms. Instead, the dissection will be based on a fixed 30 day age grouping.
This was already the case for the Supplier Aged Balance report and now becomes the case for the Customer Aged Balance report as well.
This is necessary because customers can have multiple payment terms and so each transaction becomes due at different dates, even when they were created on the same date.
In addition, the offering of a Payment Schedule means that there will be multiple due dates for a single invoice.
All screens and reports will reflect Current, 30 Days, 60 Days, 90+Days regardless of what payment terms the customer is on. These buckets are aged ONLY at EOM.
This applies regardless of customer payment terms because customers can have multiple terms and invoices may have multiple due dates.
## Customer Enquiry
The Header Detail view shows the Payments Due.
## Customer Receipt Entry
New fields show the number of payments, the next Due Date, and the Amount Due.
The Original Transaction and Balances are as before, but now there are the number of payments, the next Due Date and the Amount Due.
When finalising a Customer Receipt, if there is any unallocated amount, the Payment Due date will be prompted for with a default of Today.
## Supplier Enquiry
The Header Detail view shows the Payments Due.
## Supplier Payments
New fields are shown during Payment Entry in the transaction list.
The Original Transaction and Balances are as before, but now there are the number of payments, the next Due Date and the Amount Due.
When finalising a Supplier Payment, if there is any unallocated amount, the Payment Due date will be prompted for with a default of Today.
## Bulk Supplier Payments
New fields are shown during Payment Entry in the transaction list.
The Original Transaction and Balances are as before, but now there are the number of payments, the next Due Date and the Amount Due.
## Journals
Payment Terms are not used to calculate Due Dates.
**Instead, the Due Date is prompted in Journal Entry under these conditions:**
* Debit Posting to Customer Control Account: Defaults to Customer Preferred Payment Terms Calculation
* Credit Posting to Customer Control Account: Defaults to Today
* Credit Posting to Supplier Control Account: Defaults to Supplier Payment Terms Calculation
* Debit Posting to Supplier Control Account: Defaults to Today
## Credit Notes and Payments
Any transaction which reduces the balance of either a Customer or Supplier, sets the Due Date to today by default but you can change this using the Due Date picker if required.
**This includes:**
* Customer Credit Notes
* Unallocated Customer Receipts
* Credit Journal to a Customer
* Supplier Credit Notes
* Unallocated Supplier Payments
* Debit Journal to a Supplier
This allows the credit to be used immediately in determining an amount that still needs to be paid.
## Customer Statements (Layout Changes)
Part of a sample statement has been included below to demonstrate the layout changes:
* Debit and Credit columns are combined into a single Amount column
* New Amt Due and Date Due columns show expected payments
* A list of amounts due by date is displayed below transactions
* The Remittance section includes Balance Ageing dissection based on transaction date
