Coretax DJP for Developers: e-Faktur, e-Bupot & NPWP Integration

If you build or maintain ERP, accounting, or fintech software for the Indonesian market, Coretax DJP is the single biggest tax-integration change in a decade. Rolled out by the Direktorat Jenderal Pajak (DJP) on 1 January 2025, it merges taxpayer registration, VAT invoicing (e-Faktur), withholding certificates (e-Bupot), payments, and SPT filing into one system. The old separate applications you may have integrated against are being phased out.

I recently helped an Indonesian client migrate their invoicing pipeline off legacy e-Faktur onto Coretax, and the pain was almost never conceptual — it was data format, tax IDs, and timing. This post walks through what actually changed and what you must handle in code.

NPWP is now 16 digits — and it is the NIK

The most fundamental schema change is the tax ID itself. Under PMK-136/PMK.03/2023, the 15-digit NPWP is replaced by a 16-digit format. For resident individuals, the 16-digit NPWP IS the NIK (the national ID number on the KTP). For companies, government bodies, and non-resident individuals still on the old 15-digit NPWP, you migrate by simply prefixing a '0'. That sounds trivial until you realise every foreign-key column, unique index, validation regex, and printed document in your system assumed 15 digits.

// Normalise a legacy 15-digit NPWP to the 16-digit Coretax format
// Individuals: use the 16-digit NIK directly.
// Entities / old NPWP: left-pad with a single "0".
function toCoretaxTaxId(raw: string): string {
  const digits = raw.replace(/\D/g, ""); // strip dots, dashes, slashes
  if (digits.length === 16) return digits;      // already NIK / new NPWP
  if (digits.length === 15) return "0" + digits; // legacy NPWP -> 16 digit
  throw new Error(`Unexpected tax ID length: ${digits.length}`);
}

// ALWAYS keep it a string. Never: parseInt(npwp)
const TAX_ID_COLUMN = "VARCHAR(16) NOT NULL";

Tax invoice numbers (NSFP) are now auto-generated and 17 digits

In the legacy world you requested a batch of Nomor Seri Faktur Pajak (NSFP) up front via e-Nofa, stored them, and consumed one per invoice. That workflow is gone. Under PER-11/PJ/2025 (effective 22 May 2025), Coretax auto-generates the serial number when an invoice is successfully submitted and electronically signed. The number is now 17 digits: a 2-digit transaction code, a 2-digit status code, then a 13-digit serial (2-digit year plus an 11-digit sequence).

For developers this is actually simpler — you stop managing an NSFP inventory and reconciling unused numbers. But it inverts your flow: the tax number no longer exists at draft time, only after a successful server round-trip. If your UI or PDF template printed the NSFP before submission, that assumption is now broken.

Everything imports as XML — build your ERP export around the DJP schema

Coretax uses a new XML scheme for bulk import of output invoices (faktur keluaran), withholding certificates (bukti potong), and SPT attachments. The old CSV/import formats from legacy e-Faktur are no longer accepted. DJP publishes the official XML templates plus an Excel-to-XML converter on pajak.go.id, and this is the contract your ERP export must satisfy.

The pragmatic pattern most Indonesian ERP teams have landed on: keep your internal invoice model as-is, add a serialiser that maps it to the DJP XML template, and treat Coretax as an outbound integration target. Validate against DJP's schema before upload — a single malformed field rejects the whole batch, and Coretax error messages during 2025 were notoriously terse.

<!-- Simplified shape of a Coretax output-invoice XML row.
     Get the authoritative template + XSD from pajak.go.id before coding. -->
<TaxInvoice>
  <TaxInvoiceDate>2026-07-10</TaxInvoiceDate>
  <TrxCode>04</TrxCode>              <!-- 2-digit transaction code -->
  <BuyerTin>0012345678901234</BuyerTin>   <!-- 16-digit NPWP / NIK -->
  <BuyerDocument>TIN</BuyerDocument>
  <GoodService>A</GoodService>
  <ItemName>Jasa konsultasi</ItemName>
  <Qty>1</Qty>
  <Price>10000000</Price>
  <TaxBase>10000000</TaxBase>
  <VATRate>12</VATRate>             <!-- rate is explicit: 11 or 12 -->
  <VAT>1200000</VAT>
</TaxInvoice>
<!-- NSFP is NOT sent here; Coretax assigns it on successful sign. -->

The transition pain: two systems running at once

Coretax's early-2025 launch was rough — login failures, tax-invoice save errors, and facial-validation problems for digital certificates delayed real invoicing. In response DJP issued KEP-54/PJ/2025, keeping the legacy systems live alongside Coretax so taxpayers could fall back to the more stable path during the transition. For integrators this means you cannot assume a single source of truth for part of 2025-2026: some counterparties issue from Coretax, some still from legacy.

• Account and authority issues: PIC/representative assignment for an entity (impersonation rights) was a common blocker — the person signing invoices must be correctly delegated in Coretax.
• Account activation and authentication: email or phone not synced with the taxpayer record blocked certificate use.
• e-Bupot now integrated: withholding data flows straight into SPT Unifikasi, so you no longer submit scanned hardcopy bukti potong.
• Data sync lag: prepopulated/counterparty data can arrive late, so build retries and reconciliation, not one-shot reads.

Integration options: direct XML, converter, or DJP API partner

DJP is building API interoperability with dozens of external entities to exchange standardised data — but a general-purpose public host-to-host API you can freely self-serve is not the realistic day-one path for most SME builders. The three practical routes, from cheapest to most automated:

The bottom line for developers: Coretax is not just a new URL. It changes your tax-ID data type, removes your NSFP inventory logic, and swaps your export format to XML. Handle those three correctly and the migration is manageable; ignore any one and you will ship silently wrong invoices.