Singapore InvoiceNow & Peppol Access

The problem

IRAS is folding InvoiceNow into GST reporting, which moves Peppol from a nice-to-have integration into a filing dependency. Once your entity is in scope, an invoice is not finished when it is approved in NetSuite — it is finished when a structured Peppol BIS Billing 3.0 document has been accepted by your Access Point, and when the transmission data behind it can be reconciled against what you report to IRAS.

Stock NetSuite gives you a transaction record, a PDF, and an email. It does not give you a UBL payload, a Peppol Participant Identifier, an Access Point handshake, an MLR (Message Level Response) to store against the transaction, or a place to see which invoices have actually been delivered. Teams usually paper over that gap with a spreadsheet, a portal, and a manual re-key — which is exactly the thing that breaks at month-end volume and leaves you unable to prove what was transmitted.

This app is built to close that gap inside NetSuite, so the accounting team keeps working in Invoice and Credit Memo records and the compliance evidence accumulates automatically.

What ECOSIRE builds

This is a build-to-order SuiteScript 2.1 project. Nothing here is a shelf product you download — we scope it against your account, then build, install and support it. The build is delivered as an unmanaged bundle or SDF project that you own outright.

Document generation

A User Event script on Invoice, Credit Memo and (where in scope) Cash Sale records validates Peppol readiness at approval time. A Map/Reduce script then generates the UBL 2.1 XML for Peppol BIS Billing 3.0 — invoice and credit note profiles — mapping NetSuite fields into the required structure: cbc:ID, cbc:IssueDate, cbc:DueDate, cac:AccountingSupplierParty and cac:AccountingCustomerParty (including Peppol Participant Identifier scheme and value), cac:PaymentMeans, cac:TaxTotal with the correct Singapore GST category codes, cac:InvoiceLine per NetSuite transaction line with item, quantity, cbc:LineExtensionAmount and unit-of-measure code, plus cac:AllowanceCharge for discounts and freight.

Access Point exchange

Outbound transmission runs through a Scheduled or Map/Reduce script calling your Access Point's API over HTTPS, with credentials held in a NetSuite secret (N/https with the secure-string pattern, never a plain custom field). Inbound documents — supplier invoices arriving over Peppol — land through a RESTlet that your Access Point posts to; the RESTlet parses the UBL, applies your vendor and item matching rules, and creates a Vendor Bill or a staged custom record for review, depending on what you decide during scoping.

Status, responses and evidence

Every transmission writes to a custom record — customrecord_ecs_peppol_txn or your naming convention — holding the payload, the transmission identifier returned by the Access Point, the MLR / Application Response, HTTP status, retry count and error text. Custom fields on the transaction (custbody_ecs_peppol_status, custbody_ecs_peppol_sent_date, custbody_ecs_peppol_doc_id) let you drive saved searches, reminders and dashboard portlets from real state instead of guesswork. Failed transmissions are retried on a schedule with exponential backoff and a hard stop, then surfaced to a queue rather than dying silently.

OneWorld and multi-entity

If you run OneWorld, per-subsidiary configuration is first class: each Singapore subsidiary carries its own Participant Identifier, GST registration number, Access Point endpoint and sender details, so a shared instance serving several entities does not cross-post. Custom segments and classifications are carried into the payload where your mapping requires them.

Master data and validation

Customer and vendor records gain Peppol identifier fields with format validation, so a malformed UEN-derived identifier is caught at entry rather than at transmission. Item records gain optional classification fields where your document profile requires a standardised item identifier. A validation routine runs before send and blocks documents that would be rejected downstream — missing tax category, missing identifier, zero-quantity line, unbalanced totals.

Who it is for

Singapore-registered entities running NetSuite that are moving into InvoiceNow scope: local companies filing GST, regional groups with a Singapore subsidiary inside a OneWorld account, and shared-service centres issuing Singapore invoices on behalf of multiple entities. It suits finance teams that already have an Access Point relationship (or are about to sign one) and want NetSuite to be the system of record rather than a feeder into a separate portal.

It is not a fit if you want a hosted portal outside NetSuite, or if you need us to act as your Access Point — we build the NetSuite side and integrate with the provider you appoint.

How delivery works

1. Scoping call. We walk your account: NetSuite version and edition, OneWorld or single instance, which transaction types are in scope, your Access Point and its API contract, your GST tax code setup, and how you want inbound documents handled. We look at real records, not a questionnaire.

2. Fixed quote. You get a written scope with the exact scripts, records, fields and mappings we will build, the field-level mapping table, the assumptions, and a fixed price. No hourly drift.

3. Build. We develop against your sandbox or a development account using SuiteScript 2.1 and SDF, with the mapping table as the contract. You see progress against named milestones.

4. Install in test. The bundle installs into your sandbox first. We run your own transaction data through it — real customers, real tax codes, real edge cases — and validate the generated UBL against the BIS Billing 3.0 rules before anything touches production.

5. Production install. After you sign off in sandbox, we install into production, configure per-subsidiary settings, set script deployment statuses and roles/permissions, and run a controlled first batch with you watching.

6. Support. A defined support window covers defect fixes, mapping adjustments and questions from your team. Changes driven by later IRAS or Peppol specification updates are quoted separately, and we will tell you plainly when something is a change rather than a fix.

Lead time is typically one working week from signed quote to sandbox install, depending on how many transaction types and subsidiaries are in scope and how quickly Access Point credentials arrive.