How Invoice Data Reaches IRAS Through InvoiceNow

Under Singapore's GST InvoiceNow Requirement, one invoice makes two journeys. It travels from you to your customer over the Peppol network exactly as it always did, and a data set drawn from that same invoice is transmitted to IRAS by your access point — not uploaded by you, and not a portal you log into. That second journey is the fifth corner, and this page follows it end to end.

If you want the programme rather than the plumbing, the Singapore InvoiceNow guide covers the network, IMDA's role and the GST rollout. This page is the reporting leg only.

How does invoice data reach IRAS?

Through five corners. The first four are ordinary Peppol; the fifth is what Singapore's GST requirement adds.

The four-corner part is the Peppol model that runs in more than forty countries. Corner five is a Singapore addition, and in IMDA's accreditation material it is named exactly that: the C5 leg, tested separately from ordinary network delivery before a provider is allowed to operate it.

Who actually sends the data?

Your access point does. It holds the connection to the government API through which IRAS receives invoice data — reached through Singapore's government API exchange, APEX — and the accreditation that permits it to use it. From the business's side there is no second submission, no upload and no reconciliation step at month-end.

What falls to you sits upstream of that, and it is not a small thing: the data has to exist in your system and be right. A missing GST category, a customer without a UEN, or a foreign-currency invoice with no Singapore-dollar tax amount will stop the document before anything reaches IRAS. Those checks belong to your ERP, and they are set out in what an InvoiceNow-ready ERP is.

What actually travels to IRAS?

A defined set of fields, rather than a copy of your invoice.

The provider-side specifications IMDA issues for this leg describe a data extraction and transformation exercise with a separate data specification annex — in other words, named fields are drawn out of the invoice and sent in a defined shape. That is different from Oman's approach, where the report submitted to the Tax Authority carries the complete original invoice embedded inside it, and it has practical consequences: no doubling of stored payload per transaction, and a field-level rather than document-level conversation with the authority.

If you work across both markets, Oman's five-corner model is the contrast worth reading — the same corner count, a materially different fifth corner.

What we are not saying: we are not publishing a field list here. The exact set is in the specifications IMDA issues to accredited providers, and a field list copied from a summary is exactly the kind of detail that goes stale without anyone noticing.

What about sales that never travel over the network?

Not every transaction goes through Peppol. A customer may not be on InvoiceNow at all; a sale may be to a consumer; a document may be a purchase you received rather than a sale you issued.

The accreditation test pack a provider works through covers these cases explicitly: it includes document types for non-Peppol invoices and credit notes, along with business-to-consumer and purchase scenarios. The reporting leg is therefore broader than "invoices you sent over InvoiceNow", which is the single most common misreading of the requirement.

That is the shape of the duty as it appears in the provider testing material. The duty itself is IRAS's to define, and the current wording is on their page — a provider summary, this one included, is not a substitute for it.

Is this a clearance model?

No, and the distinction matters when you are scoping.

• Clearance — the tax authority sits between supplier and buyer, and the invoice is not valid until it has been cleared. Delivery waits on the authority.
• Reporting alongside exchange — Singapore's shape. The commercial invoice goes to the buyer over Peppol, and the data goes to IRAS in parallel. Your customer is not waiting on a tax authority to receive their invoice.

The practical consequence: a problem in the reporting leg is a compliance problem to fix, not an interruption to your customers' invoices.

When does this apply to my business?

It already applies to some businesses. The requirement is being phased in by cohort, and the first two cohorts are past:

Two readings of that table are wrong often enough to be worth naming. It is not "voluntary in Singapore" — that stopped being true on 1 November 2025. And 1 April 2026 is not a full business-to-business switch-on; it is new voluntary GST registrants only.

IRAS sets these dates and publishes the cohort detail for the 2028–2031 phases. Confirm your own start date against IRAS's GST InvoiceNow Requirement page, which is the only version of it that is authoritative on the day you read this.

What usually goes wrong first

In our experience of Peppol markets with a reporting leg, the failures cluster upstream of the tax authority, not at it:

1. The participant was never registered. In Singapore this is completed by the business authenticating itself, not by the provider alone, and an unfinished registration expires.
2. A customer has no UEN. Peppol scheme 0195 routes on it; without one the invoice cannot be addressed.
3. A line has no GST category, or the wrong one. Singapore's rules distinguish standard-rated, zero-rated, exempt, out of scope, not GST-registered, and taxable supplies where GST need not be charged.
4. A foreign-currency invoice carries no Singapore-dollar tax amount, which Singapore's validation requires.
5. There is no receiving path. Sending is scoped, receiving is forgotten, and the first supplier invoice that arrives has nowhere to land.

Every one of these is visible by validating a real document before you are in scope — which costs nothing and can be done today. The general failure patterns are in validation errors you can prevent.

What to do next

1. Establish which cohort you are in — the table above for the shape of it, then IRAS's own page for your date.
2. Validate one real invoice against the Singapore profile and read what comes back. The developer sandbox does this without sending anything.
3. Ask your provider how they perform the C5 leg and what they do when a transmission fails — a reporting leg with no retry story is a reporting leg you will be chasing.
4. Check the receiving side, not just sending.

For the market view see Singapore e-invoicing, and for how the same integration reaches other Peppol countries, the multi-country API. To scope it against your own system, book a working session.

Where GoRoute stands

GoRoute operates a Peppol-certified Access Point and SMP (Service Provider ID POP000991, ClayDesk LLC). Singapore adds its own requirements on top of ordinary Peppol — accreditation by IMDA, registration in the central registry, and the reporting leg described above — and those are the questions to put to any provider in writing, ours included, before a contract is signed.

Sources

• IRAS — GST InvoiceNow Requirement — who the reporting duty applies to and from when
• IMDA — nationwide e-invoicing framework — InvoiceNow and IMDA's role as Singapore's Peppol Authority
• IMDA — InvoiceNow technical playbook — the technical requirements behind the reporting leg
• SG Peppol Guide — billing specification — the Singapore billing profile and its validation rules
• OpenPeppol — the network the exchange runs on