Payment Times Reporting Australia: How to Prepare the Report

Australian entities with consolidated annual income of A$100 million or more, measured under Australian Accounting Standards, must report how quickly they pay their small business suppliers. Reporting periods run six months, and an entity has three months after each period closes to prepare and lodge. The report is built from an invoice-level trade credit payments dataset, which is then narrowed to small business suppliers by matching every payee ABN through the Regulator's Small Business Identification Tool. Entities that rank in the slowest 20 per cent of payers can be publicly named as slow small business payers, unless their 95th percentile payment time is 30 days or less.

That last sentence is where payment times reporting stops being an administrative task and starts being a reputational one. The figures an entity lodges are published on a public register, and the designations calculated from them are published too.

The Payment Times Reporting Regulator has specified what the report requires in considerable detail. Guidance materials, an information sheet series, a worked example spreadsheet modelling a fictional corporate group and education session recordings all sit behind the Regulator's guidance on preparing a report. What that index does not give you is a sequence: what to build first, what depends on what, and at which point in the cycle each step has to happen. This walkthrough is that sequence.

A query written against the accounts payable subledger by a competent finance analyst, filtering for supplier payments over the reporting period and calculating days between invoice date and payment date, produces a wrong report under the Payment Times Reporting Scheme (PTRS). Not marginally wrong. The scheme's rules on what counts as a trade credit payment, which payments are excluded, and when the payment clock stops all depart from the way the same transactions are treated for accounting and for tax. The dataset has to be reinterpreted rather than exported.

The Scope Test: A$100 Million on an Accounting Standards Basis

The obligation attaches to constitutionally covered entities, and to certain Corporate Commonwealth entities, with consolidated annual income of A$100 million or more.

The word doing the most work in that sentence is consolidated, and the second most is the basis on which it is measured. Since 1 July 2024 the threshold is tested on an Australian Accounting Standards consolidated-revenue basis rather than a tax basis. That change is not cosmetic. Entities whose tax-basis income sat below the line and who reasonably concluded they were outside the scheme can be inside it on an AASB measure, and the first sign of that is often a reminder from the Regulator rather than an internal assessment. According to the Regulator's information sheet on the Payment Times Reporting reforms, the reformed scheme applies to large businesses with annual consolidated revenue of $100 million or more under accounting standards, and the Regulator identifies reporting entities in the slowest 20 per cent of payers overall, or within their industry, as slow small business payers.

The test applies at group level. Revenue is aggregated across all subsidiaries under the head Australian entity, including entities held under de facto control rather than formal ownership thresholds. Controlled entities do not lodge separately. The controlling corporation lodges one consolidated report that covers them, which means the reporting burden lands on whichever finance function sits at the top of the structure, regardless of where the supplier invoices are actually processed.

Two mechanisms exist for structures where that default does not work. A reporting nominee can be appointed to lodge on behalf of the entities it represents, and a subsidiary reporting entity application allows a controlled entity to report in its own right. Joint ventures and groups with genuinely separate finance operations are the usual candidates. Both require application to the Regulator rather than an internal election.

Registered foreign entities operating in Australia report separately. ACNC-registered charities are excluded.

The case that catches teams most often is the entity in scope on group revenue alone. An organisation can clear A$100 million consolidated while its Australian supplier payments are modest, and the obligation still applies in full. Being in scope is a revenue test, not a procurement test.

The statutory basis for all of this is the Payment Times Reporting Amendment Act 2024, which commenced on 7 September 2024, and the Payment Times Reporting Rules 2024. The Rules are the operative document for anyone building a dataset. They prescribe both the information that must be reported and the aggregation methodology by which payment data is grouped into data sets for each report. The reformed framework applies to reporting periods starting on or after 1 July 2024, so any entity working from the Payment Times Reporting Act 2020 as it stood before the amendments is applying superseded requirements.

---

The Fields the Dataset Must Carry, Field by Field

A trade credit payment is a payment for goods or services supplied under an arrangement where the supplier delivers first and payment falls due afterwards. The trade credit payments dataset is a flat, invoice-level table of those payments. Every prescribed field, in the order the Regulator's guidance sets them out:

• Payer Name
• Payer ABN
• Payee Name
• Payee ABN
• Payment Date
• Payment Amount
• Credit Card Payment (Y/N)
• eInvoice enabled Payment (Y/N)
• Partial Payment (Y/N)
• Invoice Date
• Invoice Receipt Date
• Payment Terms
• RCTI (Y/N)
• Small business payee (Y/N)
• Payment Time (calendar days)

Run that list against your own AP extract before doing anything else. It takes five minutes and it tells you the size of the job. Most teams find three or four fields they do not currently hold in any system.

Invoice Date and Invoice Receipt Date are two separate prescribed fields. This is the single most common gap. An AP subledger typically stores one date, usually whichever one the entry clerk keyed, and the distinction between when the supplier dated the invoice and when the entity actually received it disappears at the point of entry. For invoice flows where documents arrive as emailed PDFs into a shared AP mailbox, the receipt date exists only as a mail server timestamp. It is not in the ledger, and once the invoice has been processed and the mailbox archived or purged under a retention policy, it may not be recoverable at all. The gap matters because the two dates can differ by days or weeks on posted invoices, and the payment time calculation is sensitive to which one is used.

The RCTI (Y/N) flag needs its own treatment. Recipient-created tax invoices, where the buyer rather than the supplier issues the invoice, have to be identifiable in the dataset. They are common in agriculture, mining services and some construction arrangements, and because the document originates inside the payer's own systems, the dates and terms attached to it follow a different path to the ledger than a supplier-issued invoice does. If you are unsure whether your arrangements qualify, the rules governing recipient-created tax invoices and when they apply determine which of your payables carry the flag.

The Credit Card Payment (Y/N) and eInvoice enabled Payment (Y/N) flags usually have to be sourced from outside the core AP ledger. Card and procurement card spend frequently arrives through an expense platform or a statement feed rather than as invoices in accounts payable, and whether an invoice came through a Peppol-enabled channel is a property of the receiving infrastructure, not of the accounting entry.

All amounts are reported in AUD inclusive of GST.

Where the native ERP path is the right one

This is worth saying plainly rather than hedging. NetSuite ships a Payment Times Report feature, and Microsoft Dynamics 365 carries a payment times reporting schema. If an entity's entire supplier-invoice flow sits inside one of those systems, with supplier ABNs captured cleanly and consistently, the native path is the correct answer and there is no reason to build anything.

The reader this walkthrough serves is the one whose flow is not wholly inside a single ERP. Multi-entity groups running different systems in different subsidiaries. Businesses where a material share of invoices arrive as emailed PDFs and are keyed by hand. Teams that assemble the dataset from three or four sources each cycle and rebuild the joins from memory every six months.

The invoice half of that job is a document-extraction problem. A six-month population of supplier invoices, arriving as PDFs across several entities and formats, has to yield a consistent field-level table: payee name, payee ABN, invoice value, invoice date, invoice receipt date and payment terms, one row per invoice, with the same columns every time. That is a task where it is possible to pull invoice fields into a structured spreadsheet automatically rather than keying them, including across batches of up to 6,000 files in a single job, with output as Excel, CSV or JSON, and a saved extraction prompt that produces the identical column structure each cycle.

The boundary matters more than the capability here, so state it precisely. Extraction gives you the invoice-side fields. Payment dates come from the ledger. The exclusion logic comes from the scheme rules, not from anything readable on the face of an invoice. The small business determination comes from the Regulator's tool. On a submission that carries a penalty measured as a percentage of total income, knowing which half of the dataset a tool actually produces is not a technicality.

Building the Dataset in the Right Order

The sequence matters because the steps are dependent, and running them in the wrong order means redoing work rather than correcting it. In order:

1. Build the trade credit payments dataset (TCP) from every trade credit payment made during the reporting period, with the fields above populated for each row.
2. Run every payee ABN through the Small Business Identification Tool to determine which payees are small business suppliers. The result populates the Small business payee (Y/N) flag and derives the small business trade credit payments dataset (SBTCP) as a subset of the TCP.
3. Apply the partial payment treatment, removing payments from the payment time calculation where the underlying obligation has not been fully discharged.
4. Compute payment time in calendar days for every remaining row, then derive the reportable statistics from the resulting distribution.

Step two carries a timing constraint that dictates the shape of the whole cycle. The Small Business Identification Tool match is run after the reporting period has closed and before submission. It cannot be run early and cached. Small business status changes as businesses grow, restructure or deregister, and the tool reflects the population as at a point in time. From the December 2024 guidance update the tool allows selection of the specific year, so the small business population you match against corresponds to the period being reported rather than to the date you happen to run the match.

The tool is reachable only through the Regulator's portal, and portal access is via myGovID. That is a practical constraint on who in the finance team can perform this step, and it should be resolved before the three-month window opens rather than during it.

Payment time is measured in calendar days. Weekends, public holidays and the entity's own processing calendar are not deducted.

Step three has a second-order effect that is easy to miss. Partial payments drop out of the payment time calculation, but they still count toward the small business procurement proportion, which is a value-based disclosure rather than a timing one. A row can be in scope for one statistic and out of scope for another, so the Partial Payment (Y/N) flag has to survive through to calculation instead of being filtered out at extract time.

Step two is why supplier master data quality is not a housekeeping concern on this report. Every statistic the submission publishes is calculated over the population the ABN match produces. Teams that already verify a supplier's ABN before paying the invoice as part of onboarding arrive at this step with a supplier master that matches cleanly; teams that do not are reconciling unmatched ABNs under deadline pressure, with no way to go back and ask a supplier who has since gone quiet.

For groups, there is a preparatory step that sits before step one. The consolidated report is assembled from extracts produced by different systems in different subsidiaries, and those systems name, format and populate the same field differently. One entity's payment terms field holds "30 days"; another holds "NET30"; a third holds a date. Invoice receipt date exists in one system and not in another. Aligning field definitions and formats across controlled entities is work that has to be agreed before extraction, because reconciling it afterwards means going back to each entity's finance team during the lodgement window.

Four Places Where the Scheme's Logic Departs from Accounting Logic

Each of these produces a dataset that passes internal review and still reports the wrong numbers. Test them individually against a draft extract.

The exclusions are narrower than "supplier payments"

Trade credit, as the scheme defines it, is a smaller category than the ledger's notion of a payment to a supplier. Payments to government entities come out. Employee payroll comes out. Payments to suppliers who have no ABN come out. Prepayments such as insurance premiums come out, because they are not extensions of trade credit even though they sit in accounts payable and are paid against a document that looks like an invoice.

A team that starts from the AP subledger and filters for supplier payments over-includes on every one of those categories. As RSM has put it, the payment data requires reinterpretation for scheme purposes that differs from both its accounting and its tax treatment. The dataset is not a view of the ledger with a date filter applied; it is a separately defined population that happens to be sourced from the ledger.

The no-ABN case is the one that produces confusion, because it sits at the intersection of two obligations. A supplier without a valid ABN triggers no-ABN withholding on supplier invoices at payment time, and the same supplier is excluded from the trade credit dataset at reporting time. Teams sometimes reason that because withholding was applied and the payment was clearly a supplier payment, it belongs in the dataset. It does not.

Partial and progress payments break the query everyone writes first

The natural query is days between invoice date and first payment. It is wrong, and it is wrong in a direction that flatters the entity, which is why it survives review.

Payment time is measured only once the obligation is fully discharged. On a progress-billed engagement paid in four instalments, the payment time is measured against the final balancing payment, not against the first. An extract that stops at the first payment date reports an entity paying substantially faster than it does, and the discrepancy is largest on exactly the high-value, long-running supplier relationships where accuracy matters most.

Construction retention distorts the clock in the wrong direction

Where invoices are dated at their original dates rather than at the retention-release trigger, the calculated payment time includes the entire retention period. A retention held for twelve months against a progress claim produces a payment time measured in the hundreds of days, on a payment that was made exactly in accordance with the contract.

The result is that construction is simultaneously the sector most exposed to being flagged and the sector most likely to be flagged unfairly by a mechanically correct extract. An entity with retention arrangements needs to establish how those invoices are dated in its own systems before it calculates anything. What separates a defensible number from a damaging one here is a data convention, not a payment practice.

ABN hygiene is a hard dependency, and it travels with company

KPMG identifies supplier ABN data quality as the blocker its clients hit most frequently. A supplier whose ABN is missing, transposed or attached to a deregistered entity does not fail loudly. It simply does not match, and that supplier's invoices leave the small business dataset without a warning anywhere. The report still calculates, still passes validation, and is still wrong.

An adjacent problem usually surfaces at the same time. Credit card and procurement card spend is captured inconsistently, often living in an expense system that was never designed to record a payee ABN, so the Credit Card Payment (Y/N) flag has to be reconstructed from a source that lacks the identifiers the dataset needs.

None of these are discovered by validating the dataset against itself. They are discovered by testing a sample of rows back to source documents, which is the check most teams skip and the one that finds all four of these divergences at once.

---

The Statistics the Submission Publishes

The submission carries nine statistical disclosures, and the dataset has to be capable of producing every one of them:

• The shortest, standard most common (mode) and longest payment terms offered to small business suppliers
• The average and median payment times
• The 80th and 95th percentile payment times
• The percentage of small business invoices paid within agreed terms
• The distribution of invoices paid 0 to 30 days, 31 to 60 days, and more than 60 days, reported both by number of invoices and by value
• Small business procurement as a proportion of total procurement value
• The proportion of small business payments, by volume, made through Peppol-enabled systems
• The estimated standard payment term for the next reporting period
• Whether the entity's own receivable terms are faster, slower or the same as the terms it offers its suppliers

The percentile disclosures deserve closer attention than the averages, because the 95th percentile is the figure the fast and slow payer designations are calculated from. An entity can report a comfortable median and still sit in the exposed band on its 95th percentile, and the two figures answer different questions: the median describes the typical invoice, the 95th percentile describes the tail.

The Peppol disclosure has a mechanical wrinkle that is best caught early. Peppol-enabled invoices must be flagged inside the small business payments dataset and again inside the small business trade credit payments dataset. It is the same underlying property recorded in two places, and it fails validation if the two disagree. Entities that have already worked through Australia's Peppol e-invoicing requirements will have the channel data available; those that have not usually have to derive the flag from their receiving infrastructure rather than from anything in the accounting record.

The estimated standard payment term for the next reporting period is a forward-looking disclosure rather than a calculation, and it is one of the few fields where the entity exercises judgement. The receivable terms comparison is similarly qualitative: faster, slower or the same, comparing what the entity asks of its own customers against what it offers its suppliers. Both are published alongside the statistics, and both invite the obvious question if an entity offers itself better terms than it extends.

There is a difference in kind between these figures and the payables metrics a finance team already tracks internally. How days payable outstanding is calculated is, within reason, a matter for the organisation: the formula, the inclusions and the reporting cadence are internal choices, and the number serves working capital management. The payment times statistics are prescribed. The calculation basis is mandated, the population is determined by an external tool, and the output is published on a register that anyone, including your suppliers and your competitors, can read. A DPO figure that looks healthy in a board pack tells you very little about how the 95th percentile will land.

Fast and Slow Small Business Payer Designations

Both designations turn on the 95th percentile payment time, and the numbers are specific enough to plan against.

Fast small business payer. An entity qualifies with a 95th percentile payment time of 20 days or less across two consecutive reporting periods. Qualifying entities appear on the Fast Small Business Payer List, which launched in January 2026 and is published on the interactive Payment Times Reports Register, updated daily. The designation expires nine months after the end of the qualifying period unless continued performance maintains it. It is a status an entity holds, not one it earns once. The United Kingdom runs much the same play through its own duty to report on payment practices, where the Fair Payment Code's tiers do the work the fast payer list does here.

Slow small business payer. An entity is identified as a slow payer if it ranks in the slowest 20 per cent of small business payers, measured either nationally or within its ANZSIC Division. Being in the slowest 20 per cent of your own industry is sufficient, which means an entity performing in line with its sector's norms can still be named where that sector pays slowly overall.

There is a floor beneath the ranking, and it is the most actionable number in the scheme: a 95th percentile payment time of 30 days or less gives automatic protection from the slow small business payer designation, regardless of where the entity ranks. An entity that holds its 95th percentile at 30 days cannot be named, whatever the distribution of its peers looks like. For a finance function deciding what to prioritise, that number is the target, and it is a more useful objective than a ranking the entity cannot observe or control.

The consequence escalates. After two consecutive reporting cycles carrying the slow small business payer designation, the Minister for Small Business may issue a direction requiring the entity to publish its slow payer status on its own website and in other documentation. That moves the disclosure from a government register that few people visit to the entity's own public-facing material.

The mechanics of the percentile cut against how most AP teams monitor performance. Both designations are calculated from the 95th percentile, not the average or the median. An entity paying the great majority of small business invoices within terms can still be exposed if a small tail of invoices runs badly late, and that tail is usually not random. It is disputed invoices, invoices held pending a purchase order match, invoices from a single supplier with a broken approval workflow, invoices lost in a mailbox during a staff transition. The tail is concentrated, which is inconvenient statistically and useful operationally: fixing a handful of specific failure modes moves the 95th percentile far more than a general improvement in average processing speed does.

Deadlines, the Portal and What Non-Compliance Costs

Reporting periods run six months, and the entity has three months after the period closes to prepare and lodge.

For an entity with a 30 June year end, that produces two fixed dates. The 1 July to 31 December period is due on 31 March. The 1 January to 30 June period is due on 30 September. Three months sounds generous until the sequence is laid out: the Small Business Identification Tool match cannot begin until the period has closed, and everything downstream of the match depends on it.

The portal as it stands in 2026

A new payment times reporting portal went live on 16 February 2026. It added automatic draft-saving, cleaner summary views of a submission before it is lodged, and pre-populated fields when an entity files a revision to a report it has already submitted. Portal access is via myGovID.

The change with the most practical consequence is the enhanced validation. The portal now blocks overlapping reporting periods and mathematically impossible entries at the point of entry. Under the previous system, a submission with an internal inconsistency, such as a median payment time that could not coexist with the reported distribution, would be accepted and queried afterwards. It is now rejected outright. A team that plans to lodge on the deadline and discovers a validation failure has no queue to sit in while it goes back to the dataset.

Penalties

• False or misleading submissions: up to 0.6 per cent of total income for the entity's most recent financial year.
• Failure to lodge by an incorporated entity: up to 300 penalty units.
• Civil penalties apply for failing to keep adequate records or failing to cooperate with the Regulator.

The record-keeping exposure is the one most often underestimated. The Regulator can issue notice-to-produce orders for the raw datasets underlying a submission. That reframes what the TCP and SBTCP extracts are: not working papers that can be regenerated if anyone asks, but evidentiary records that need to be retained in the form they were used, with the transformations applied to them documented. An entity that cannot reproduce the dataset behind a lodged report has a problem independent of whether the report was accurate.

All submissions are published on the public register.

The enforcement posture has firmed. The Regulator published a compliance update media release on 1 April 2026 covering enforcement action taken between 31 July 2025 and 31 March 2026, and its Newsletter No. 9, issued 7 August 2026, is the current edition. The scheme is no longer in the phase where a first-cycle entity can assume errors will be treated as teething problems.

---

What to Fix Before the Next Reporting Period Opens

The useful distinction is between work that can be done after a period closes and work that cannot. The three-month lodgement window is long enough for calculation and long enough for reconciliation. It is not long enough to recover data that was never captured.

Complete the ABNs on the supplier master first. This is the item with the shortest window and the least recoverable failure mode. An ABN missing today can be obtained from an active supplier with an email. An ABN missing for a supplier who has been deactivated, absorbed into another entity, or has simply stopped responding cannot be reconstructed after the fact, and every invoice from that supplier drops out of the small business population silently. Run a completeness check across the supplier master now, and validate the ABNs you do hold rather than assuming a populated field is a correct one.

Start storing invoice receipt date as a field. If invoices arrive by email and the receipt date currently exists only as a mail server timestamp, that date needs to be captured into the AP record at the point of processing. Mailbox retention policies, staff mailbox deletions and archive migrations all destroy it, and it cannot be derived from anything else once the period has closed.

Capture the flags at source rather than reconstructing them. Credit card and procurement card payments, Peppol-enabled invoices and recipient-created tax invoices all need identifying as they are processed. Each of these is trivial to record at the moment of transaction and expensive to reconstruct across a six-month population afterwards, because the reconstruction usually requires joining to a system that was not built to hold the identifier the dataset needs.

Agree field definitions across controlled entities before the period, not during the window. For a group, this is the item that consumes the most calendar time when it is left late, because it requires the cooperation of finance teams in each subsidiary who have their own close cycles running. Settle what each entity will provide, in what format, with what field names, and confirm it with a test extract from each system while there is no deadline attached.

There is a broader point underneath all four. A complete, field-consistent dataset of supplier invoices feeds several obligations at once. The same invoice-level records that support a payment times submission also support the extracts a team needs to build a Taxable Payments Annual Report from contractor invoices, and the same weaknesses, missing ABNs, inconsistent dates and undocumented transformations, break both. Teams that treat the supplier invoice dataset as a standing asset rather than a twice-yearly reporting exercise spend the lodgement window calculating rather than assembling.

That is also the argument for making the extraction step repeatable. Where the invoice half of the dataset is produced by a saved extraction prompt reapplied each cycle, the column structure, field naming and formatting are identical from period to period, which is what makes a consolidated group dataset comparable across reporting periods rather than a fresh reconciliation every six months.