Indonesian finance teams running ERPNext hit the same wall every filing period: core ERPNext gives you flexible Item Tax Templates and Tax Withholding Categories, but it has no concept of an e-Faktur (Faktur Pajak elektronik), no NPWP master data with a check-digit validation, no split between PPN output/input tracking the way DJP expects, and no export shaped for Coretax or the older e-Faktur desktop/host-to-host formats. Accountants end up re-keying invoice data into government tools, reconciling PPh 21/23/26/4(2) withholding by hand in spreadsheets, and hoping the manually assembled Faktur Pajak numbers line up with the DJP-issued NSFP ranges. That gap is exactly where a native ERPNext app is needed rather than a workaround.

ECOSIRE builds a proper Frappe app (its own module, DocTypes, and hooks.py) that lives inside your ERPNext instance instead of bolting on external scripts. We add an e-Faktur DocType that links one-to-one to Sales Invoice and captures the buyer NPWP, transaction code, Faktur Pajak serial (NSFP), and status, plus custom fields on Customer, Supplier, and Company for npwp, nik, and PKP flags. NPWP entry is validated by a client script for format and by a server-side validate doc event for the modulus check, so bad tax IDs never reach a posted invoice. PPN is configured through Item Tax Templates and Tax Categories so the correct 11% (or prevailing) output/input VAT applies automatically, while PPh withholding is driven by ERPNext's Tax Withholding Category extended with the Indonesian rate schedules and object codes.

Technically, the reporting layer is the part that saves the most time. We build whitelisted server methods (@frappe.whitelist()) and Query/Script Reports that assemble the e-Faktur output (CSV/XML in the layout your KPP or Coretax upload expects) and the PPN and PPh withholding recaps, all filterable by tax period and company. hooks.py doc_events keep the e-Faktur record and the Sales Invoice in sync on submit and cancel, a scheduler event can flag invoices missing a Faktur number before period close, and the endpoints are reachable over the Frappe REST API so a middleware or the DJP host-to-host channel can pull data programmatically. Access is governed by ERPNext permissions and a dedicated role profile (for example an "Indonesia Tax" role) so only finance staff can issue or void Faktur numbers, with the standard audit trail on every document. Print Formats deliver a bilingual (Bahasa Indonesia / English) commercial invoice and Faktur Pajak layout.

Because this is build-to-order, you are not downloading a generic marketplace app and forcing your process into it. We start with a short scoping call to confirm your transaction types, PPh objects, NSFP handling, and whether you file via Coretax, the e-Faktur client, or a host-to-host provider. We then build against your Frappe/ERPNext v15 or v16 version, test on a staging copy of your data, run UAT with your accountant, and deploy to production with a rollback plan. Typical delivery is one working week from confirmed scope. You receive the full source in a Git repository, so the app is yours to keep, audit, and extend.