Indonesia e-Faktur Tax for Business Central

Key Features

NSFP serial range management: DJP-allocated blocks held as `E-Faktur Serial Range` records with sequential assignment, gap detection, low-watermark alerting and a hard stop when a range is exhausted

Table and page extensions on Customer, Sales Header and Posted Sales Invoice carrying NPWP/NIK, buyer type, branch code, transaction code (kode transaksi) and the assigned serial

Pre-posting validation via `OnBeforePostSalesDoc` event subscribers — a missing NPWP, an invalid transaction code or an unavailable serial blocks the post instead of surfacing at filing time

Single-posting dual output: a DJP-format machine file (CSV/XML per your current e-Faktur schema) and a human-readable Faktur Pajak PDF Report object, both generated from the same posted lines

Table-driven master data mapping — item and G/L tax treatment, UoM translation, DPP Nilai Lain rules — maintained in setup pages rather than hardcoded in AL

Whole-rupiah rounding policy applied consistently to DPP and PPN across lines, discounts, freight and prepayment invoices, reconciled against the posted VAT entries

Explicit status lifecycle on every e-Faktur record: Draft, Exported, Approved, Rejected, Replaced, Cancelled, with the rejection reason captured from your filing route

Correction workflow: a Replace action generates the replacement document under the correct code with a bidirectional link to the superseded record, keeping both in the archive

`E-Faktur Worklist` page with filtered views by period, status and customer, plus batch export of a selected set

Job Queue Entry for scheduled period-end export and status refresh, so filing runs on your VAT cadence without manual triggering

Append-only audit log table recording serial assignment, export, reprint, replacement and cancellation with user, timestamp and export-file hash

Compliant archiving of generated export files and PDFs with configurable retention, retrievable from the posted document

Granular permission sets separating serial assignment, export, and cancellation/replacement rights

API pages (REST API v2.0 / OData v4) exposing e-Faktur records and statuses to Power BI, Power Automate and Dataverse-connected flows

Built and tested against your Business Central version and deployment model — SaaS per-tenant extension or on-premises — on current release waves, with no base-application modification

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Indonesian VAT (PPN) reporting is unforgiving in exactly the places a standard Business Central install is silent. A Faktur Pajak needs a controlled Nomor Seri Faktur Pajak (NSFP) drawn from the range DJP allocated to your NPWP, in strict sequence, with no gaps you cannot explain. It needs the buyer's NPWP/NIK, address and transaction code carried correctly onto the document. It needs a DPP and PPN calculation that survives rounding to whole rupiah, prepayments, freight and discount lines. And when a document is rejected or the customer's data was wrong, it needs a formal replacement or cancellation that leaves the original visible, not overwritten. Business Central out of the box gives you VAT posting setup, a VAT statement and document number series — none of which model an externally allocated tax invoice serial, a kode transaksi, or the correction lifecycle. Teams end up rekeying posted invoices into a spreadsheet or the DJP application, and the ERP and the tax filing quietly drift apart.

What ECOSIRE builds is an AL extension for your Business Central tenant that treats the e-Faktur record as a first-class object beside the posted sales invoice. An E-Faktur Setup page holds your NPWP, branch codes, default transaction and status codes, rounding policy and export destination. E-Faktur Serial Range tables record every NSFP block DJP issued, with a low-watermark warning and a hard stop when a range is exhausted, so you never post past your allocation. Table extensions on Customer, Sales Header and Sales Invoice Header carry NPWP/NIK, buyer type, transaction code and the assigned serial; page extensions surface them where the finance team already works, and validation runs through event subscribers on OnBeforePostSalesDoc so a document with a missing NPWP or an invalid code is stopped before it posts, not discovered at filing time.

One posting produces both outputs. A codeunit builds the machine format — the DJP CSV/XML layout your filing route requires, structured to your current e-Faktur schema and validated field by field before the file is written — while a Report object renders the human-readable Faktur Pajak PDF, so the document you hand the customer and the record you file are generated from the same posted lines and can never disagree. Master data mapping is table-driven, not hardcoded: item and G/L mappings, unit-of-measure translation, currency handling and DPP Nilai Lain rules live in setup tables your accountant can maintain. Batch export runs from a Job Queue Entry on your VAT period cadence, or on demand from a filtered E-Faktur Worklist page.

Rejection handling is the part most spreadsheet workflows get wrong, so it is modelled explicitly. Each e-Faktur record carries a status — Draft, Exported, Approved, Rejected, Replaced, Cancelled — and a rejection reason returned from your filing route. A Replace action generates the correction document under the correct replacement code with a link back to the superseded record, and the archive keeps both. Every state change, serial assignment, export and reprint is written to an audit log table with user, timestamp and file hash, and archived export files are retained under your policy so a DJP audit can be answered from Business Central rather than from someone's Downloads folder. Dedicated permission sets separate who may assign serials, who may export and who may cancel. Everything is reachable over API pages (REST API v2.0 / OData v4) if you want Power BI reporting or a Power Automate flow watching for rejected documents in Dataverse.

This is build-to-order, not an AppSource download. We start with a scoping call, confirm your Business Central version and deployment (SaaS or on-premises, current release wave), your filing route, your existing customisations, and the exact document layouts and codes you use. From confirmed scope, typical delivery is 2 to 4 weeks: we build the extension against your version, deploy it to your sandbox for UAT with your own data, run the correction and rejection paths with you, then install to production behind a rollback plan. You receive the AL source, the git repository, technical and user documentation, a training session and a post-go-live support window.

What you get

Complete AL extension source code, compiled and tested against your specific Business Central version and deployment model (SaaS or on-premises)

Installation and configuration on your sandbox and production environments, including NPWP, branch codes, serial ranges, transaction codes and mapping tables

Technical documentation: object ID ranges, table/page extension inventory, event subscriber map, export file schema, API page endpoints and upgrade codeunit notes

End-user guide covering serial range loading, daily invoicing, batch export, rejection handling and the replacement workflow

Live training session for your finance and tax team, recorded for later joiners

UAT on your sandbox with your own master data, a documented test script covering happy path, rejection, replacement and cancellation, and a rollback plan for the production install

Post-go-live support window covering defect fixes and configuration assistance, deliberately spanning your first full VAT period-end close

Git repository handover with full commit history, a tagged release for the deployed version, and build instructions

Who this is for

Finance Manager / Tax Accountant

Owns the monthly PPN filing and signs off the SPT Masa. Needs every posted sales invoice to carry a valid NSFP and NPWP, needs DPP and PPN on the filing to tie exactly to the general ledger, and needs to answer a DJP query without reconstructing history from email. Wants rejections handled as a workflow with a visible status, not a note in a spreadsheet column.

Controller / Finance Director of an Indonesian entity

Responsible for compliance risk across one or more Indonesian legal entities inside a wider Business Central deployment. Cares that serial allocations cannot be skipped or reused, that cancellations leave a trail, and that segregation of duties is enforced by permission sets rather than by trust. Wants the compliance story to be demonstrable to a group auditor.

IT Manager / Business Central Administrator

Owns the tenant and the upgrade cycle. Needs a supported per-tenant extension with clean object IDs and event-subscriber integration that survives Microsoft release waves, no base-application modification, and a git repository they can hand to any future partner. Wants the export job running on a Job Queue Entry they can monitor like any other.

Accounts Receivable / Billing Clerk

Issues the invoices day to day. Needs tax invoice fields validated at posting rather than discovered at month end, needs the customer-facing Faktur Pajak PDF to print from the same document they posted, and needs one clear action to issue a replacement when a customer reports wrong NPWP details.

How Indonesia e-Faktur Tax for Business Central Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Fit to your tax setup and document layouts	Built to your confirmed scope — your transaction codes, mapping rules, rounding policy and layouts	Fully bespoke, but you specify, build and test it yourself	Fits the vendor's assumed Indonesian setup; edge cases become change requests	No e-Faktur concept at all — VAT posting groups and a VAT statement only
NSFP serial number control	Serial range tables with sequential assignment, gap detection and exhaustion stop	Whatever your developer builds; sequence integrity is yours to design	Usually present, but the allocation model is fixed by the vendor	Standard number series only — no externally allocated tax serial
Correction and rejection workflow	Explicit status lifecycle with linked replacement documents and preserved originals	Commonly deferred past go-live and handled manually at first	Varies widely; some apps only export and leave corrections to the DJP tool	Credit memo posting only, with no tax-invoice replacement linkage
Source code and ownership	Full AL source and git repository handed over — no lock-in	You own it outright, and you own the whole maintenance burden	Compiled AppSource app; source stays with the vendor	Microsoft base application, not modifiable
Time to production	Typically 2-4 weeks from confirmed scope, including sandbox UAT	Months once hiring, specification and testing are counted honestly	Fast to install, then weeks of configuration and gap work	Available immediately, but does not solve the requirement
Upgrade safety through release waves	Extensions and event subscribers only, no base-app modification, tested on your version	Depends entirely on the discipline of whoever wrote it	Vendor maintains compatibility, on the vendor's own schedule	Microsoft-maintained by definition
Reporting and automation access	API pages (REST v2.0 / OData v4) for Power BI, Power Automate and Dataverse	Possible, but usually the first thing cut from scope	Often UI-only, with limited or undocumented endpoints	Standard BC APIs exist, but expose no e-Faktur data
Support and accountability	Post-go-live window through your first period-end close, then an optional agreement	Internal team or a contractor who may have moved on	Vendor support queue with SLA tiers and no context on your setup	Microsoft supports the platform, not your compliance gap

Frequently Asked Questions about Indonesia e-Faktur Tax for Business Central

How long does delivery take?

This is a build-to-order extension — there is no instant download. Typical delivery is 2 to 4 weeks from confirmed scope. The clock starts once we have agreed your Business Central version and deployment model, your filing route and e-Faktur schema version, your document layouts and transaction codes, and any existing customisations we must coexist with. Broader scope — multiple legal entities, unusual DPP Nilai Lain rules, or an integration with a third-party filing service — is quoted with its own timeline at the scoping call.

Does this submit directly to DJP for me?

The extension generates the compliant machine-format export file and the human-readable Faktur Pajak, manages serial numbers, and records the status returned for each document. Whether the file is uploaded through the DJP application, a licensed PJAP/ASP service, or a direct API depends on your filing route. If you use a service with an API, we scope that connection as part of the build; if you file manually, the extension produces the file and tracks the outcome you record against each document.

Will it work on my Business Central version, and on-premises?

Yes — we build against the version you actually run. For Business Central online we ship a per-tenant extension; for on-premises we build and deploy against your specific application and platform version. The extension uses table and page extensions plus event subscribers only, with no base-application modification, so it upgrades cleanly through Microsoft release waves. Tell us your version at the scoping call and we confirm before quoting.

What happens when a tax invoice is rejected or the customer's NPWP was wrong?

Each e-Faktur record carries an explicit status and a rejection reason. A Replace action creates the correction document under the correct replacement code, linked in both directions to the superseded record, so the original stays visible in the archive rather than being overwritten. Cancellation is a separate, permission-gated action that is also logged. Nothing is silently edited after export.

How do support and updates work after go-live?

Every build includes a post-go-live support window covering defect fixes and configuration help, and we deliberately keep it running through your first full VAT period-end close, which is where real problems surface. After that you can take an ongoing support and maintenance agreement covering compatibility with Business Central release waves and updates when DJP changes the e-Faktur schema or serial rules. Because you receive the full AL source and git repository, you are never locked in — your own team or another partner can maintain it.

Can we get e-Faktur data into Power BI or trigger alerts on rejections?

Yes. The e-Faktur records and their statuses are exposed through API pages (REST API v2.0 / OData v4), so Power BI can report on them directly and a Power Automate flow can watch for rejected or unexported documents and notify the finance team. Dataverse connectivity works through the standard Business Central virtual tables. A specific dashboard or flow can be built as part of the scope if you want it.

We already have customisations and another Indonesian localisation. Will this conflict?

We check before quoting. At the scoping call we review your installed extensions and object ID ranges and identify anywhere another app already extends the same posting events or sales tables. If an existing localisation already covers part of this, we scope only the gap rather than duplicating it — a narrower build is cheaper for you and lower risk at upgrade time.