- ہوم
- Apps
- SaaS Tools
- Indonesia e-Faktur Tax for Business Central
مثالی پیش منظرAn AL extension that turns posted Business Central sales invoices into e-Faktur compliant tax invoices,
with serial number control, DJP-ready export files, correction handling and an auditable archive.
ECOSIRE builds it to your scope, installs it and supports it.
Indonesia e-Faktur Tax for Business Central کیا ہے؟
An AL extension that turns posted Business Central sales invoices into e-Faktur compliant tax invoices, with serial number control, DJP-ready export files, correction handling and an auditable archive. ECOSIRE builds it to your scope, installs it and supports it. Built to order by ECOSIRE for Dynamics 365 BC (build-to-order) — indicative price from $999.00 USD; request a quote for a scoped proposal.
اہم خصوصیات
آرڈر پر تیار، مکمل طور پر آپ کے لیے
خود سیٹ اپ کی ضرورت نہیں — ایک کام کرنے والی ایپ جو ECOSIRE بناتا، انسٹال اور سپورٹ کرتا ہے۔
- 1
آپ آرڈر دیتے ہیں
ایک بار کی تعمیر کی قیمت سے آغاز کریں۔ آغاز پر ہم آپ کے ساتھ مل کر دائرہ کار طے کرتے ہیں۔
- 2
ہم بناتے اور انسٹال کرتے ہیں
ECOSIRE اسے آپ کے Dynamics 365 Business Central پر بناتا، ترتیب دیتا اور انسٹال کرتا ہے۔
- 3
لائیو + معاونت
آپ تقریباً ایک کاروباری ہفتے میں لائیو ہو جاتے ہیں، گو لائیو کے بعد دو ہفتوں کی معاونت کے ساتھ۔ ہمارے فراہم کردہ کوڈ کی خرابیاں مفت درست کی جاتی ہیں۔
اس مصنوع کے بارے میں
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 one working week: 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 نیٹو |
|---|---|---|---|---|
| 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 one working week 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 one working week 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.
Related Modules

India GST e-Invoice & Payment Bridge for Business Central
A build-to-order Business Central per-tenant AL extension that ties UPI/card payment capture to India GST IRP e-invoice generation (IRN and signed QR), e-way bill linkage, GSTR-ready export, and refund/credit-note handling — built, installed, and supported by ECOSIRE on your tenant.

India Localization (GST, TDS/TCS) Pack for Business Central
A per-tenant AL extension that adds India statutory localization to Business Central — GST (CGST/SGST/IGST), TDS/TCS, HSN/SAC, GSTR-1/3B exports and reverse charge — built, deployed and supported by ECOSIRE on your environment.

Intrastat & EC Sales List Reporting for Business Central
A build-to-order AL extension that automates Intrastat (arrivals & dispatches) and EC Sales List preparation, threshold monitoring, and authority file generation directly inside your Business Central tenant.

Inventory Stocktake & Cycle Count
A build-to-order Business Central (AL) extension that streamlines full and ABC cycle counts for retail — mobile scan entry by location/bin, blind-count and re-count workflows, variance review and approval, and direct posting of item adjustments into BC. Built, installed as a per-tenant extension and supported by ECOSIRE on your own environment.
Indonesia e-Faktur Tax for Business Central
An AL extension that turns posted Business Central sales invoices into e-Faktur compliant tax invoices, with serial number control, DJP-ready export files, correction handling and an auditable archive. ECOSIRE builds it to your scope, installs it and supports it.
- 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