A small AEMO change raises a much bigger strategic question for gas operators: how close is your commercial system to the people who understand the business?

On 21 August, version 17.1 of AEMO’s Gas Supply Hub Exchange Agreement came into effect. It introduced pipeline-capacity-trading products at the Reedy Creek point on the Reedy Creek–Wallumbilla Pipeline for pre-matched trades and amended the definition of “gas day”.

On paper, this is a contained regulatory and market change. In practice, it is another reminder that the gas industry is constantly evolving.

New transportation points emerge. Capacity products change. Market interfaces develop. Gas-day definitions, settlement rules and operational processes are amended.

The strategic question is not simply whether the technology can accommodate the change. It is whether the organisation can respond quickly, safely and economically without creating unnecessary dependency on programmers, consultants or lengthy development cycles.

The closer the change capability sits to the business user, the lower the cost of change.

In a market where margins are under pressure and regulatory, commercial and operational requirements continue to evolve, the cost of change is not limited to software development. It also includes:

• The time business users spend explaining market requirements to technical teams.
• The delay between a rule change and the implementation of a compliant process.
• The cost of testing and retesting hard-coded changes.
• The risk of billing errors, settlement disputes and incorrect allocations.
• The operational burden of spreadsheets, email approvals and manual workarounds.
• The loss of agility when every change requires a formal development project.

These costs can be more significant than the initial technology investment. A system that appears inexpensive to maintain can become very expensive to operate when every market change requires specialist intervention.

The real test is what happens next inside the organisation.

• Can authorised business users configure the change themselves?
• Can local support teams respond quickly because they understand both the platform and the Australian gas market?
• Can commercial and operational teams validate the outcome directly rather than waiting for a technical team to interpret the requirement?
• Or does the organisation have to call in programmers, explain the market context, wait for a development cycle and then test hard-coded changes every time the rules move?

Flexibility is not simply the ability to modify software. It is the ability to control the cost, risk and speed of change.

A modern commercial gas platform should allow authorised users and experienced local support teams to configure:

• Transportation points, so new receipt, delivery or transfer locations can be added quickly and trades, nominations and allocations can be directed to the correct network location without creating manual workarounds.
• Capacity products, so products such as pre-matched pipeline-capacity trades can be represented accurately, reducing spreadsheet-based tracking and improving visibility of available, purchased and used capacity.
• Gas-day boundaries, so nominations, measurements, allocations and invoices align with amended market timing, reducing cut-off errors and preventing transactions from being assigned to the wrong trading period.
• Workflows, so approvals, exception handling and operational hand-offs reflect the new process, helping teams respond consistently and reducing reliance on email and manual intervention.
• Settlement rules, so charges, credits and invoices are calculated according to the updated agreement, reducing billing disputes and shortening the time required to implement and validate market changes.

These changes should be possible without rebuilding the underlying system. Where development is genuinely required, it should be the exception—not the default response to normal market evolution.

The best operating model has three levels of change capability:

1. Business users manage controlled configuration where appropriate.
2. Local specialists provide support when market or commercial expertise is required.
3. Product developers become involved only when a genuine software change is necessary.

That does not mean removing governance. It means combining configuration, permissions, audit trails, testing and approval controls with practical business ownership.

The objective is not to let anyone change anything. It is to ensure that the right people can make the right changes without unnecessary technical dependency.

That distinction matters when selecting technology for pipeline billing, shipper services and commercial operations. The question is not only whether the system meets today’s requirements.

The better questions are:

• How quickly can it respond to tomorrow’s market change?
• How much of that change can be managed by the business?
• Is local support available from people who understand the market?
• How much external technical effort will be required?
• And what will the total cost of change be over the life of the platform?

The most valuable system is not necessarily the one with the lowest purchase price. It is the one that keeps the organisation closest to its customers, contracts, market obligations and operational reality while keeping the cost and risk of change under control.

AEMO determination and Exchange Agreement amendments