Separate how many invoices need a result from how many attempts were made.
Count business documents and transmission attempts separately when reconciling InvoiceNow activity. One invoice can have several attempts, while a transmission row can still be waiting for a verified outcome. Treating either count as the other can make a reporting queue look complete when a document remains unresolved.
Oracle's GST InvoiceNow Reporting documentation explicitly says that each transmission is displayed as a separate row. It also describes reconciliation with the latest IRAS transaction status through the access point. Those two facts make the distinction operationally important: the report helps investigate transmissions, but finance still needs to establish document-level completeness.
Use a document-to-attempt worksheet around the configured reporting route. The worksheet below is a proposed control, not a claim that every field or management label exists natively in NetSuite.
The business-document identity describes the underlying invoice or adjustment. Keep its legal entity, source-system reference, document number and relevant version. The attempt identity describes a specific submission event. The response reference identifies the evidence used to establish an outcome.
Your solution may also use a Document UUID and other network identifiers. Record the actual relationships supported by the selected route. Do not assume that a UUID remains unchanged across every correction, or that generating a new UUID is a safe duplicate-prevention strategy.
The worksheet should connect these identities without replacing the originals. A stable internal case reference can help support coordinate an investigation, but it should not be presented as a provider identifier or injected into a transmission without an approved design.
Also name the reporting stage represented by each response. Delivery to another business, receipt by an access point and an IRAS status can convey different information. Technical acceptance does not approve the invoice's GST treatment.
The following ledger is illustrative. Its identifiers, sequence and outcome descriptions are invented. “Accepted”, “rejected” and “uncertain” are plain-language descriptions for this exercise, not asserted status values from a particular account or provider.
| Business document | Attempts observed | Latest evidence in the example | Current owner |
|---|---|---|---|
| INV-A101 | 1 | Verified accepted outcome for the relevant IRAS reporting stage | Finance reviewer |
| INV-A102 | 2 | First rejected; supported correction made; second outcome verified accepted | Finance reviewer |
| INV-A103 | 1 | Response remains uncertain after the available local check | Integration support |
There are three business documents and four attempts. Two documents have the required verified outcome in this fictional ledger; one still needs investigation. Four transmission rows therefore do not establish that all three documents are complete.
For INV-A102, preserve both attempts. The rejected attempt explains the issue and the correction; the later verified outcome supplies the current completion evidence. Counting the two attempts as two accepted invoices would overstate the document population.
For INV-A103, the operator's local timeout or absent response does not establish that the recipient failed to process the submission. The next action is to investigate the existing attempt using the supported route. Starting another attempt without that evidence can make the reconciliation harder.
For INV-A101, retain enough detail to distinguish its verified outcome from a generic “sent” indicator. A reviewer should be able to identify where the outcome came from and when it was last checked.
Where the configured Singapore e-invoicing route uses Oracle's GST InvoiceNow Reporting page, the documented prerequisite is enabling the GST InvoiceNow preference. The documented search uses a Peppol ID and a Document UUID or transaction date range. The reconciliation action retrieves current status through the access point and updates the report and related transaction records.
Validate the installed SuiteApps, account setup and permissions with the implementation team. A reporting function described by Oracle is not proof that the route has been activated correctly in every NetSuite account.
For a review, retain the search criteria and the time reconciliation was performed. Compare the resulting transmission rows with the attempt ledger, then map them back to business documents. An unexpectedly empty report may reflect the selected date range or identifier rather than an absence of submissions.
Do not treat a report refresh as authorisation to resubmit. Its purpose is to establish the latest evidence. The permissible retry or correction action depends on the actual outcome and the provider's supported process.
For each unresolved document, ask what is missing.
If the latest authoritative outcome cannot be established, preserve the original references and investigate. Check available logs and supported status evidence, then involve the responsible provider if necessary. Keep the case with one owner while finance remains informed of deadline risk.
If a rejection is verified, identify whether the cause belongs to source data, an approved tax decision, configuration or transport. Correct the cause through the supported route and retain the relationship to the original document. A transmission correction should not automatically create a new commercial invoice or a second accounting transaction.
If the required outcome is verified, mark the document complete for that reporting stage and retain the supporting response. Keep any separate accounting, tax-treatment or customer-delivery issue open under its own control. A single green status should not imply that all business obligations have been satisfied.
These decisions depend on evidence, not a fixed number of retries. This article does not assert an idempotency guarantee, automatic duplicate suppression or a universal safe-resend interval.
Use this compact worksheet for each review:
Reconcile the expected document list to the worksheet first. Then reconcile the attempt list to the transmission evidence. These two checks catch different failures: a missing business document can be absent from every attempt log, while a missing response can affect a document that is already represented in the queue.
Keep counts and amounts at a stated grain. Summing the invoice amount across every attempt would double-count INV-A102 in the illustrative example. For financial completeness, use the approved business-document population; use attempt counts to investigate processing history.
Under the applicable GST InvoiceNow rules, invoice-data timing is linked to the relevant GST return. Finance therefore needs a current list of unresolved documents, not just a technical success percentage. The Singapore GST and InvoiceNow overview explains the wider workstream.
When an uncertain case reaches the close review, report the business document, its attempts, the latest checked evidence and the decision still needed. Bring the worksheet to integration support when the missing evidence is technical. The immediate objective is to establish what happened to the existing submission so the authorised owner can choose the next supported action.