A submission route is easier to trust when its source population is visible.
Start an InvoiceNow source register with the systems that originate invoices and purchase evidence, then connect those sources to the approved reporting population. Starting with NetSuite's successful transmissions can leave you unable to explain what never arrived.
For a Singapore finance team, the register answers a precise question: have all adviser-confirmed, in-scope sources been assigned a reporting route and a completeness check? It should also show deliberate exclusions. An expense platform, till or billing application may contain a mixture of reportable documents, payment events, duplicates and records outside the applicable submission scope.
This article concerns source discovery and coverage. The broader Singapore GST and InvoiceNow guide provides context for the overall workstream. First confirm that the requirement applies to the business and which transactions are relevant; the register does not determine those legal questions.
“One row per application” is a useful starting inventory, but usually a poor final register. A retail application may create sales receipts, returns and settlement records. Those need different inclusion decisions even though they share a system name.
Use a source row for a specific document family, legal entity and extraction route. Record the source-system owner, business reviewer, original identifier, relevant date fields, currency fields, extraction method and downstream destination. Add the approved inclusion decision and the evidence supporting it.
Keep “not yet assessed” distinct from “excluded”. An empty decision cell must not quietly become a filter that removes records from the project. Similarly, “sent through NetSuite” should name the actual route and evidence, rather than imply that the presence of an accounting balance establishes invoice-data coverage.
IRAS distinguishes invoice data from other GST obligations and permits aggregation for specified categories, including POS supplies and petty cash purchases. Your adviser and solution provider should agree how that applies to each source. A chosen aggregation rule needs a trace back to its constituent records.
Consider a fictional Singapore business with a shop, a subscription service and a small employee expense programme. The following rows are invented to demonstrate the register. They do not establish which transactions a real business must submit.
Row A: NetSuite customer invoices. The billing lead owns the original invoice population. The key combines legal entity and internal transaction reference, while the customer-facing invoice number is retained separately. The approved candidate population is compared with the configured reporting route. Evidence consists of the source list, selection criteria and document-to-submission references.
Row B: shop receipts and returns. The retail manager owns daily POS extracts. The proposed identifier includes shop, business date, till and receipt reference. The tax owner must approve whether and how permitted aggregation is used. The daily close report and constituent receipt list become the coverage evidence. Card settlement totals remain supporting reconciliation data; they are not substituted for receipt identity.
Row C: external subscription invoices. The billing application owns invoice versions and credit references. Finance identifies which legal entity issues them and whether NetSuite receives full invoices or only summary journals. A summary posting cannot explain every source document without an additional mapping. The billing owner supplies an independent invoice register for the selected period.
Row D: employee purchase evidence. The expense administrator owns receipts and supplier invoice references. AP decides whether a document also exists in the supplier-bill population. The tax reviewer approves inclusion at the underlying purchase level. The expense report number, receipt reference and related NetSuite posting are retained even where one is not a separate reporting item.
The register now exposes two design questions before anyone writes an interface: how the external billing detail will reach the reporting route, and how expense evidence will be matched to AP without double representation.
For each included row, obtain a period extract independently of the transmission process. Capture when it was produced, its filters and the owner's approval. An export of the destination queue is useful later, but it should not define the expected population.
Work through a small illustrative reconciliation. Suppose a raw external billing extract contains 120 records. The source owner explains that five test documents belong to a non-production environment and two records are superseded versions of documents already represented. The reviewer approves 113 candidate documents. The downstream register contains 111 matched identities and two unresolved identities.
The arithmetic is 120 minus five minus two equals 113; 111 plus two equals 113. These invented counts illustrate a control, not a permitted legal exclusion. The five test records and two superseded versions need explicit evidence. If either explanation is unsubstantiated, the difference stays open.
Check both counts and values where meaningful. Counts can match while one high-value invoice is missing and another duplicated. Values can match while different documents offset each other. Keep currencies separate unless an approved conversion basis has been stated.
For aggregated routes, compare the approved group population with the underlying records as well as the submitted aggregate. A daily total with no list of contributing receipts leaves the reviewer unable to investigate a later return or correction.
Oracle documents a Singapore PEPPOL-Ready e-Invoicing SuiteApp and GST InvoiceNow reporting functionality. That is evidence of a supported product route, subject to its prerequisites and configuration. It does not establish that data in your external POS, subscription application or expense service is automatically extracted and submitted.
For each register row, ask the implementation team to demonstrate a representative document end to end. Identify the installed components, permitted transaction types, field mappings and operating owner. Mark custom extraction, middleware and manual preparation separately from the documented SuiteApp functions.
Ask where reconciliation evidence will be available to finance. Oracle's reporting documentation describes outbound transactions and transmission-level rows. External-source completeness still needs the source register and mapping evidence; a successful outbound report cannot independently certify every upstream application.
Keep the registration, access-point onboarding and tax decisions assigned to the appropriate owners. The source register supports those workstreams but should not claim that a configured connector alone guarantees compliance.
Before marking a row ready, require a reviewer to answer:
Treat a failed answer as a specific task. “Missing source identifier” calls for mapping work. “Unclear purchase scope” calls for a tax decision. “No independent extract” calls for a source-owner control. These problems should not all be assigned to the integration developer.
Finally, place the register under ordinary change control. Opening a new shop, adding a billing tool or changing an expense process should trigger a source review. Keep the previous approved version so the team can explain which coverage decision applied to an earlier period.
Bring the first completed register, including unresolved rows, to the NetSuite implementation team. It gives the discussion a concrete boundary: the sources that are covered, the evidence that proves it and the remaining work that needs an owner.