Monthly Archives: September 2026

29/09/2026

Why eInvoicing belongs in procurement and contract management, not just finance

eInvoicing is often treated as a finance or IT project. That makes sense at first: invoices land in finance systems, and the connection to the Peppol network usually involves technology. But as eInvoicing becomes more established across Australia and New Zealand, procurement and contract teams have a bigger role to play.

New Zealand is a good example. From 1 January 2027, government agencies that follow the Government Procurement Rules will need to require large suppliers to send eInvoices. Importantly, the requirement is not being applied retrospectively to every existing contract overnight. Instead, agencies are expected to build eInvoicing into procurement activity, contract renewals, retenders and significant variations over time.

That is a useful lesson for organisations on both sides of the Tasman. If eInvoicing only appears once an invoice reaches accounts payable, you are already late in the process. The best opportunity to make eInvoicing the normal way of working is earlier, when supplier expectations and commercial terms are being set.

The invoice process starts before the invoice

A supplier does not decide how to invoice you in isolation. The method is often shaped by onboarding information, purchase orders, contract terms and the instructions they receive from procurement or account managers. If those touchpoints still say “email your invoice to this address”, suppliers will keep using PDFs even if your finance system is ready for eInvoicing.

Procurement and contract teams can help close that gap by making the preferred invoicing method clear from the beginning. That could mean adding eInvoicing information to tender documents, supplier onboarding packs, contract schedules or purchase order instructions.

Build eInvoicing into procurement requirements

When you’re sourcing a new supplier, ask about eInvoicing capability early. You do not need a long technical questionnaire. In many cases, a few simple questions are enough:

  • Can the supplier send Peppol eInvoices?
  • What business identifier will they use, such as an ABN or NZBN?
  • If they are not enabled today, what is their plan and timeframe to become enabled?

Capturing this information during procurement gives finance and implementation teams a clearer picture of which suppliers can be onboarded quickly and which may need extra support.

Make the contract language practical

Contract wording should make the invoicing process easy to understand. If eInvoicing is required or preferred, say so clearly and explain what the supplier needs to do. It is also worth checking that invoice requirements in the contract line up with the data your finance system needs, such as a purchase order number, contract reference or business unit identifier.

This matters because eInvoicing works best when structured invoice data can move straight into automated workflows. If a supplier sends an eInvoice but leaves out the information needed for matching or approval, the invoice can still end up in an exception queue.

Use contract events as natural transition points

You do not always need to move every supplier at once. Contract renewals, retenders, new scopes of work and major variations can be useful points to introduce or strengthen eInvoicing requirements. They are moments when both parties are already reviewing processes and expectations, so the change is easier to explain and document.

This is particularly relevant in New Zealand as agencies prepare for the 2027 large-supplier requirement. Government guidance makes it clear that the rule is expected to be incorporated through procurement and contract management processes over time, rather than applied retrospectively to every existing contract on 1 January 2027.

Keep supplier master data up to date

Once a supplier is eInvoicing enabled, record that information somewhere your teams can use it. Depending on your systems, that might be your ERP, procurement platform or contract management system.

Useful information can include the supplier’s Peppol identifier, whether they are ready to send or receive eInvoices, when they were onboarded and any special invoice requirements. This can help procurement avoid giving suppliers outdated instructions and gives finance better visibility of where eInvoicing should be the default channel.

Give procurement, finance and IT clear ownership

eInvoicing works across several parts of the business, so responsibility should not sit with one team alone. A simple operating model can make a big difference: procurement sets expectations with suppliers, finance owns invoice processing and exception handling, and IT or your eInvoicing provider manages the technical connection and system changes.

The important part is having a clear handover. For example, when procurement onboards a supplier that can send eInvoices, finance should know when to expect the channel to change. If the supplier has a technical issue, everyone should know whether it goes to your internal IT team, the supplier’s software provider or your Access Point provider.

Australia can use the same approach

Australia does not have the same 1 January 2027 large-supplier rule, but the principle still applies. The ATO continues to support Peppol as the standardised eInvoicing network in Australia, while government policy continues to focus on improving payment practices and reducing friction for suppliers.

For Australian organisations, putting eInvoicing into procurement and contract processes can help turn an available technical capability into a business-as-usual process. It creates a more consistent supplier experience, helps increase eInvoicing volumes and gives finance teams a better chance of automating invoices from the moment they arrive.

A practical checklist

    • Tender and sourcing: Ask suppliers about Peppol eInvoicing capability during procurement.
    • Contracts: State whether eInvoicing is required or preferred and make invoice data requirements clear.
    • Supplier onboarding: Give suppliers consistent eInvoicing instructions before their first invoice.
    • Supplier master data: Record eInvoicing readiness, identifiers and any special processing requirements.
    • Contract events: Use renewals, retenders and major variations as opportunities to transition suppliers.
    • Internal ownership: Define the roles of procurement, finance, IT and your Access Point provider.
    • Ongoing review: Track which suppliers still use PDFs and target the highest-value opportunities first.

Make eInvoicing part of the supplier relationship

The more eInvoicing is treated as a normal part of buying, contracting and supplier management, the less work finance teams need to do later to move suppliers away from manual invoicing.

For New Zealand organisations, the 2027 government requirements make this especially timely. For Australian businesses, it is a practical way to improve adoption and get more value from the eInvoicing capability they already have.

If you want to make eInvoicing easier to build into your supplier processes, MessageXchange can help you connect your existing software to the Peppol network and support your onboarding approach, get in touch with our team below.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.

E-invoicinggovernmentRetailers

24/09/2026

Changing ERP systems? How to keep EDI running through the transition

Changing an ERP system is a major project. It can improve reporting, simplify workflows and give teams a better foundation for growth, but it also changes the systems that create, receive and process the data your trading partners rely on. For businesses using electronic data interchange (EDI), that makes EDI an important part of the ERP transition plan. Purchase orders, order responses, advanced shipping notices, invoices and other messages may be moving automatically today, but changes to fields, formats, workflows or integrations can affect that flow if they are not considered early. The goal is not to rebuild EDI from scratch every time an ERP changes. It is to understand what’s changing, test the right things and make sure day-to-day trading can continue with minimal disruption.

Start by mapping what EDI depends on today

Before making changes, document how EDI fits into your current environment. It is easy to think of EDI as a connection between two businesses, but internally it often touches several systems and teams.
  • Which ERP fields are used to create each EDI message?
  • Which messages are sent and received for each trading partner?
  • How product, customer, supplier and location data is referenced?
  • What business rules and validations are applied?
  • Where are acknowledgements, errors and exceptions monitored?
  • Which downstream systems rely on the EDI data once it arrives?
This gives the project team a baseline. It also helps identify dependencies that may not be obvious until testing begins.

Look beyond the file format

An ERP migration can change more than whether a file is XML, CSV or another format. The structure of the data can change as well. Field names may be different, product identifiers may be stored differently, optional fields may become mandatory and workflows may create information at a different point in the process. That is where EDI mapping becomes important. Mapping translates the format and structure produced by your software into the format required by your trading partners. If the ERP output changes, the mapping may need to change too. Reviewing this before go-live can help prevent a situation where the new ERP is working internally, but trading documents are failing because a required field is missing, moved or populated differently.

Test complete business scenarios, not just individual messages

A successful connectivity test is a good start, but it does not prove the whole order flow will work as expected. The safest approach is to test the business process from end to end. For example, a retailer and supplier might test a complete scenario that includes:
  • sending a purchase order
  • receiving and processing the order in the new ERP system
  • returning an order response
  • creating an advanced shipping notice
  • generating the invoice
  • confirming each message is accepted and processed correctly at the other end.
It is also worth testing exceptions. Part-filled orders, changed quantities, invalid product codes, cancelled lines and other real-world scenarios can expose issues that a simple happy-path test will miss.

Check master data before cutover

EDI relies heavily on consistent master data. Product codes, GLNs, supplier identifiers, customer numbers, units of measure and delivery locations need to line up across systems and trading partners. During an ERP migration, master data is often cleaned up or restructured. That can be beneficial, but any identifier changes that affect EDI need to be coordinated. A new customer code in the ERP, for example, may need to be reflected in a mapping or trading-partner configuration before transactions can flow correctly. Treat master data as part of the EDI workstream, rather than assuming it sits only within the ERP project.

Plan the cutover around real trading activity

ERP projects often have a technical cutover plan. EDI needs an operational cutover plan as well. Think about what happens to transactions that are already in flight when the switch occurs.
  • Will orders created in the old ERP still need responses from the new ERP?
  • How will invoices be handled for goods shipped before cutover?
  • What happens to messages received during a planned system outage?
  • Who will monitor failed or delayed messages immediately after go-live?
For retailers, suppliers and manufacturers, timing matters. Avoiding a cutover during peak trading periods can reduce risk, but even outside peak periods, teams should know how open orders and outstanding documents will be handled.

Keep your trading partners in the loop

Not every ERP change will require action from every trading partner, but communication is still important when testing or identifiers are changing. Let the affected partners know what is happening, what they need to test, if anything, and when the production change will occur. Clear communication is particularly useful when a retailer has a large supplier community. A structured testing process can reduce back-and-forth and make it easier to confirm that each supplier is ready before the change goes live.

Monitor closely after go-live

The first few days after cutover are when small issues can become operational problems if they are not picked up quickly. Monitor message volumes, acknowledgements and exceptions closely, and compare them with normal trading patterns. Useful checks include whether expected purchase orders are being sent, whether order responses and ASNs are arriving, whether invoices are being accepted and whether any trading partner is experiencing an unusual level of failures. This lets the team deal with genuine exceptions quickly instead of waiting for a supplier, customer or finance team to report that something has gone missing.

Your ERP can change without disrupting your EDI

An ERP migration is a significant change, but it does not need to interrupt the way you trade electronically. The key is to treat EDI as part of the project from the beginning, rather than something to check at the end. By understanding existing dependencies, reviewing mappings and master data, testing complete workflows and planning the cutover carefully, businesses can move to a new ERP with greater confidence that orders, deliveries and invoices will keep moving.If you are planning an ERP change and want to understand what it could mean for your EDI setup, MessageXchange can help with integration, mapping and testing. Get in touch with our EDI experts.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.

EDIRetailersSuppliersSupply Chain