InvoiceNow GST Validation: Check Supplier Registration Before Issuing or Submitting

Purpose and version

Version 1.0 was updated on 7 March 2025. It recommends a feature for InvoiceNow-Ready Solution Providers and GST-registered businesses using in-house enterprise solutions: detect potentially wrongful GST charges from invoice data and the IRAS Check GST Register API. The in-house businesses are termed Transmitting Enterprises in the TX2 specification.

The recommended point of checking differs between creating an InvoiceNow invoice and submitting data extracted from an invoice. The source describes a compliance aid, rather than a full determination of whether every aspect of a GST charge is correct.

Participation dates recorded in the document

A footnote records voluntary early participation from 1 May 2025, including existing GST-registered businesses and applicants wishing to adopt early. It describes mandatory participation for newly incorporated companies voluntarily registering for GST from 1 November 2025, and all new voluntary GST registrants from 1 April 2026. These are the phases described by this March 2025 version; read subsequent requirements separately.

What documents and data are included

The InvoiceNow use case includes credit notes issued through the network. The broader invoice-data term covers invoices, tax and simplified tax invoices, debit notes, credit notes and related data. Examples include aggregated point-of-sale or simplified-tax-invoice sales and aggregated petty-cash purchases. Both inbound and outbound data transmitted to C5 are within the four-type mapping.

Four submission types and their methods

Type 1A is the supplier’s sale inside the InvoiceNow network, using Peppol submission. Type 1B is the customer’s corresponding purchase received within the network, submitted by the solution-extracted method. Type 2 is a sale outside the network, and Type 3 is a purchase outside it; both use solution-extracted submission. Thus Type 1B belongs to the second validation use case even though its underlying transaction arrived through InvoiceNow.

Invoice fields, API result and frequency

For invoice data with a positive GST amount, IBT-110, pass the supplier’s GST registration number, IBT-031, to the Check GST Register API. The sample request illustrates clientID and regID. The result includes registration information such as Status and RegisteredFrom; the text also specifies RegisteredTo for period checks. The displayed sample response does not show a RegisteredTo field, so the API specification must be consulted for actual response handling.

Validate at invoice level using up-to-date status. IRAS recommends daily checks and allows a daily cache of each business’s registration information for efficiency. An access point may offer a passthrough API so the solution has one integration point.

The common registration and date conditions

The status must indicate Registered or Deregistered, and the invoice date, IBT-002, must fall within the registration start and end dates, including the stated boundaries. Deregistered is not automatically rejected: an invoice dated within the relevant registration period may meet the check. A favourable result permits transmission under this validation feature.

Type 1A: check before invoice creation or issue

The implementation table places the Type 1A check at C1 when the invoice is created or issued. If the supplier GST number is invalid or not found, alert the supplier to check it and correct the number or remove the GST charge before issuing.

The detailed procedure allows the supplier to override the alert and issue the invoice if, after checking, the supplier maintains that the details are correct. The initial scope description’s instruction not to issue must therefore be read together with this explicit override route, rather than as an absolute technical prohibition.

Type 2: alert the supplier and still submit

For a sale outside InvoiceNow, the table places the check at C1 when invoice data is submitted. If the conditions fail, alert the supplier to check the GST number but continue the submission to IRAS. The transaction has already occurred, so failure of the validation is not a reason to omit its data.

Types 1B and 3: alert the customer and still submit

For both purchase-data types, the table places the check at C4 on submission to IRAS. If the registration or period test fails, alert the customer and continue submitting. The customer may pursue the apparently wrongful charge with the supplier. The data submission itself does not establish an input-tax entitlement or resolve the dispute.

Annex A: both decision flows

The first flow starts at invoice creation or issue. If GST is not charged, it proceeds to the access point for submission. If GST is charged, it checks status and dates; a failure leads to an alert and amendment or the supplier’s stated override before transmission.

The second flow covers solution-extracted Types 1B, 2 and 3. Without a positive GST charge it proceeds directly. With a charge it performs the registration and period checks; a failure leads to an alert followed by submission, not a blocking branch. This diagram labels the API call through C1, while the implementation table distinguishes C1 supplier-side and C4 purchase-side checks; the article preserves those labels rather than silently rewriting the diagram.

Credentials, testing and onboarding support

Use the Client ID and Client Secret provided during e-invoicing API account registration and setup. Test the Check GST Register API in the sandbox before production, using its API specifications for both environments.

The document restricts production APIs to actual live-business e-invoicing records and prohibits testing there. Breaches may suspend or terminate the account. For onboarding support it lists the IRAS Digital Partnerships Team at [email protected].