Singapore InvoiceNow and Peppol Delivery

Why SAP Business One cannot do this on its own

Singapore's InvoiceNow initiative moves business-to-business invoicing onto the Peppol network. Instead of emailing a PDF, you transmit a structured electronic invoice through an Access Point to your customer's Access Point, addressed by a Peppol participant identifier rather than an email address. GST-registered businesses are being brought into scope on a phased timetable, and once you are in scope the obligation is to transmit, not to print.

SAP Business One has no Peppol capability. It can produce an A/R Invoice and a Crystal Reports PDF of it, but it cannot build a Peppol BIS Billing 3.0 XML document, cannot address a participant, cannot speak the AS4 protocol an Access Point requires, and has nowhere to record whether a transmission succeeded. Nor can it receive a supplier's Peppol invoice into A/P.

The workaround most sites fall into is a portal: someone re-keys the invoice into a web form, or uploads a spreadsheet, and the ERP loses sight of the document the moment it leaves. That breaks reconciliation, hides rejections until a customer chases payment, and makes the audit trail depend on one person's browser history.

ECOSIRE builds the missing lane inside SAP Business One.

What ECOSIRE builds

Document mapping to Peppol BIS Billing 3.0

We map your posted SAP Business One documents to the Peppol BIS Billing 3.0 invoice and credit-note syntax. The mapping covers header identity (document number, issue date, due date, currency, document type code, buyer reference and order reference), supplier and customer party blocks built from the Business Partner master and company details, line detail from the marketing document lines including item identification, quantity, unit of measure, unit price, line extension amount and allowances or charges, and the tax structure derived from the document's own tax lines. GST is expressed with the correct category coding, taxable amount per rate, and exemption reason where applicable. A/R Credit Memos map to credit notes with the reference to the original invoice.

Where the standard requires a field SAP Business One does not hold natively, we add a UDF on the document or the Business Partner and expose it in the relevant form, rather than inventing a value at transmission time.

Participant addressing and directory lookup

We add Peppol participant identifier and scheme fields as UDFs on the Business Partner master, with a validation and lookup action that confirms the participant is registered and supports the invoice document type before you attempt a send. Your own participant identifier and registration details are held in a configuration UDT. Customers not reachable over Peppol are flagged so you keep the existing output channel for them instead of failing a send.

Transmission through your Access Point

ECOSIRE is not an Access Point and does not present itself as one. Transmission runs through the Access Point provider you contract with — we integrate to their API using credentials you hold. The add-on builds the document, submits it, captures the returned transmission identifier, and then polls for delivery and business-level responses so acceptance, rejection, and error detail all land back in SAP Business One. If you change provider later, the integration layer is isolated so the mapping and the user experience survive the switch.

Status tracking on the document itself

Every A/R Invoice and Credit Memo in scope gains a Peppol status visible on the document: not applicable, ready, queued, transmitted, delivered, rejected, or failed. A transmission log UDT holds the full history — payload reference, transmission identifier, timestamps, response codes, and error text — so a rejection is diagnosable from inside the ERP. Rejected documents can be corrected and re-sent without creating a duplicate invoice, with the re-send linked to the original attempt.

Pre-send validation

The expensive failure is a rejection discovered days later. We validate before transmission: schema and business-rule checks against the BIS Billing 3.0 rule set, GST arithmetic reconciliation against the posted document totals, participant reachability, and completeness of every mandatory party and line field. Validation results are surfaced at the point of send with the specific field at fault, and the same checks run in the batch lane so a run reports what it skipped and why.

Inbound supplier invoices

Optionally in scope: receiving your suppliers' Peppol invoices. Inbound documents are retrieved from your Access Point, parsed, matched to the Business Partner by participant identifier and to open Purchase Orders where a reference exists, and staged as draft A/P Invoices for review. Nothing posts to the general ledger without a human release, and unmatched documents queue with the parsed data visible rather than being discarded.

Batch and scheduled operation

Beyond per-document sending, a scheduled job picks up all documents in a configured state and transmits them, with retry and backoff on transport failures and an alert to named recipients when a document exhausts its retries or is rejected. Failed sends never silently disappear.

Who this is for

GST-registered Singapore companies running SAP Business One that are in scope for InvoiceNow or preparing to be, groups with a Singapore entity on SAP Business One that must transmit while other entities stay on existing channels, and businesses whose larger customers already require Peppol delivery. It suits distribution, manufacturing, logistics, and professional services sites where invoice volume makes portal re-keying untenable.

Compatibility

Built for SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on-premise or cloud-hosted, as an add-on using the Service Layer (REST) and the DI API. Configuration, addressing, and logging use UDFs, UDTs, and UDOs. Approval procedures can gate transmission. No modification of SAP system tables and no change to how documents post.

How delivery works

1. Scoping call. We confirm your GST registration and InvoiceNow position, which document types are in scope, your Access Point provider (or help you shortlist one), your numbering series, your GST tax codes and how they map to Peppol tax categories, and whether inbound A/P receipt is in scope.

2. Fixed quote. You receive a written scope covering the mapping, the validation rules, the Access Point integration, the status model, the batch behaviour, and the acceptance criteria — with a fixed price and delivery date.

3. Build. We develop against a copy of your company database so the mapping is exercised against your real Business Partners, items, tax codes, and document history.

4. Install in test. We install into your test company, load configuration, and run acceptance against your Access Point's test environment: transmit each document type, force and resolve a rejection, verify status write-back and the log, and — if in scope — receive an inbound invoice into a draft A/P Invoice. You sign off against the criteria from step 2.

5. Install in production. After sign-off we install into production during an agreed window and run a controlled first live transmission to a real customer, watching the response end to end before opening the lane.

6. Support. A defect-fix window follows go-live. Because this is a compliance lane, we also tell you plainly which parts are ours to maintain (mapping, validation, status handling) and which sit with your Access Point contract and your registration.

Build-to-order, stated plainly

Nothing here is pre-built or downloadable, and there is no trial. The build begins after you approve a fixed quote, and it is fitted to your Access Point, your tax code set, and your document flow. Typical lead time is two to four weeks from quote approval; inbound A/P receipt and multi-entity scope push toward the upper end. Peppol network access and your participant registration are contracted with your Access Point provider, not with ECOSIRE.