e-Faktur Indonesia: How to Issue, Correct, and Reconcile Tax Invoices Under Coretax

An Indonesian company’s finance team issues a tax invoice to a PKP client on the 18th of the month. The amount is correct, the VAT rate is correct, and the invoice is filed on time. But the NPWP that auto-populated from Coretax does not match the client’s name as it appears in the company’s own ERP system. The client cannot use the invoice for input VAT credit. The client contacts the company to request a correction. Now the seller needs to issue a Faktur Pengganti (Replacement Invoice) through Coretax, wait for the client to log into their own Coretax account and confirm the change, and only then does the invoice achieve “Amended” status. Until that confirmation arrives, neither the original nor the replacement is cleanly reconciled in either party’s VAT position.

This scenario plays out across Indonesian businesses every month. It is not a software glitch. It is the new operational reality of e-Faktur under the Coretax administration system that has been fully operational since January 2025 under PMK No. 81 of 2024. The mechanics of issuing, correcting, and reconciling tax invoices have changed in ways that the legacy e-Faktur system never required, and companies that are still applying the old mental model to the new system are generating compliance exposure they cannot see until the VAT reconciliation surfaces it.

What Coretax Changed About the e-Faktur Framework

The legacy e-Faktur system, which operated from 2014 through the end of 2024, was a largely seller-side operation. The PKP (Pengusaha Kena Pajak, or VAT-registered taxpayer) seller created the invoice in the e-Faktur desktop application, uploaded it to DJP’s server for approval, received a serial number, and the approved invoice was then distributed to the buyer. The buyer received a document. They did not interact with the DJP system as part of the invoice creation process.

Coretax restructured this in three fundamental ways.

First, the invoice number is now generated by Coretax itself, not by a serial number block pre-downloaded by the seller. Each e-Faktur receives its unique number from DJP’s system at the point of creation, which eliminates the serial number management burden but also means the seller cannot pre-assign numbers or create offline batches without eventually syncing to Coretax.

Second, buyer identity data is pre-populated from the Coretax database based on the NPWP or NIK entered. The seller does not freely type the buyer’s name and address. The system retrieves it. This creates accuracy on data it knows, but it also means that if the buyer’s registered data in Coretax does not match the name or address the seller has in its own systems, the discrepancy appears in the issued invoice, not as a creation error.

Third, corrections and returns now require bilateral action. A Faktur Pengganti requires the buyer’s confirmation within Coretax before it achieves finalized status. A Nota Retur (return note for goods) is now created by the buyer, not the seller, and submitted through the buyer’s own Coretax portal for DJP approval. The seller’s VAT position is affected by actions the buyer takes on the buyer’s side of the same system.

For companies that had clean, well-structured e-Faktur operations under the legacy system, these changes require process adaptation, not panic. For companies that were already managing the old system inconsistently, the Coretax framework makes inconsistencies more visible and harder to defer.

Issuing an e-Faktur Under Coretax: The Standard Flow

The starting point for any e-Faktur issuance is PKP (VAT-registered taxpayer) status. A company that has not registered as a PKP cannot issue valid tax invoices, and in B2B transactions, PKP buyers will not accept invoices from non-PKP suppliers because they cannot credit the input VAT. For companies that have recently crossed the IDR 4.8 billion annual revenue threshold, or that expect to cross it, PKP registration should be initiated before the threshold is reached, not after, to avoid a period of non-compliant invoicing. The PKP registration process and its interaction with Coretax activation is covered in XPND’s VAT compliance guide for foreign companies in Indonesia, which addresses both the threshold mechanics and the practical steps for Coretax setup.

Once PKP status is active and Coretax access is configured for the company’s authorized signatory, the e-Faktur issuance flow under PMK 81/2024 runs as follows:

The Invoice Creation Sequence

Step 1: Enter the buyer’s tax identity

The seller inputs the buyer’s NPWP (for corporate PKP buyers), NIK (for individual buyers), or a special identifier for non-PKP buyers. Coretax retrieves and pre-populates the buyer’s registered name, address, and classification from the DJP database. The seller must verify that this retrieved data matches the buyer’s actual identity before proceeding.

Step 2: Select the correct transaction code

The transaction code appears at the beginning of the e-Faktur serial number and identifies the type of supply. Code 01 applies to domestic taxable supplies to PKP buyers. Code 02 applies to domestic supplies to non-PKP buyers. Code 07 applies to export of taxable goods. Applying the wrong code invalidates the invoice for input VAT credit purposes at the buyer’s end. A domestic supply coded as an export, or vice versa, is not a correctable data error: it requires a Faktur Pengganti (replacement invoice) through the full bilateral correction process.

Step 3: Enter the supply details

The goods or services description, quantity, unit price, total transaction value, and applicable VAT rate are entered. Under PMK No. 131 of 2024, the VAT rate remains 12 percent, but the tax base for general taxable goods and services is set at 11/12 of the transaction value, producing an effective VAT charge of 11 percent. Companies need to configure this correctly in their invoice templates to avoid overclaiming or underclaiming VAT on both sides of the transaction.

Step 4: Submit and receive Coretax approval

The e-Faktur is submitted through the Coretax portal. DJP’s system generates the invoice serial number and returns an approved document with digital signature. This approved document is the valid tax invoice that can be issued to the buyer. The buyer’s Coretax account receives a notification of the incoming invoice.

Step 5: Meet the issuance deadline

The e-Faktur must be issued by the 20th of the month following the month of the taxable supply. An invoice for a supply made on March 15 must be approved and issued by April 20. An invoice issued on April 21 or later for a March supply is late. The practical consequence of a late e-Faktur is that the buyer cannot credit the input VAT in the correct tax period, which creates a reconciliation problem in the buyer’s monthly VAT return and may create a billing dispute.

Explore Our Services Tax Compliance in Indonesia

Correcting an e-Faktur: Faktur Pengganti vs Faktur Batal

Two correction mechanisms exist under PMK 81/2024, and they apply to different situations. Using the wrong mechanism for a given error is a common source of complications.

Faktur Pengganti (Replacement Invoice): For Errors in Invoice Data

A Faktur Pengganti is issued when an approved e-Faktur contains incorrect information: wrong buyer identity, incorrect goods description, wrong quantity or price, incorrect VAT amount, or an incorrect transaction code. The replacement invoice does not cancel the original outright. It replaces it while maintaining traceability to the original.

The Coretax process for a Faktur Pengganti is fundamentally bilateral:

• The seller initiates the replacement by modifying the relevant details within the Coretax system against the original invoice reference
• Coretax changes the invoice status to “Waiting for Amendment” and sends a notification to the buyer’s Coretax account
• The buyer must log into their own Coretax account and confirm the amendment
• Only after the buyer’s confirmation does the invoice status change to “Amended” and the replacement become finalized

Until the buyer confirms, neither the original nor the replacement is in a settled state for VAT reconciliation purposes. A seller who issues a Faktur Pengganti and then files the monthly VAT return without waiting for buyer confirmation is filing on an unsettled position. This is one of the recurring reconciliation failures that surfaces when sellers and buyers are not coordinating their Coretax actions during the month.

Faktur Batal (Cancelled Invoice): For Voiding an Invoice Before the Tax Period Closes

A Faktur Batal cancels an e-Faktur entirely. This mechanism is available when a transaction did not actually occur, when an invoice was created in error with no corresponding supply, or when a supply was cancelled before delivery. Unlike the Faktur Pengganti, a Faktur Batal voids the invoice rather than replacing it, and it must be processed before the end of the tax period in which the original invoice was issued. An invoice from March cannot be cancelled with a Faktur Batal in April. By April, the correction route is a Faktur Pengganti.

Returns: The Nota Retur Under Coretax

When a buyer returns taxable goods after the original transaction has been settled and the tax period has closed, a Nota Retur (return note) is required to adjust the VAT position of both parties. Under the Coretax framework governed by PMK 81/2024, the Nota Retur process has shifted significantly from the legacy system.

In the legacy system, the seller handled the documentation of a return. Under Coretax, the Nota Retur is created and submitted by the buyer. The buyer creates the Nota Retur document through their own Coretax portal, referencing the original e-Faktur, and the document is submitted for DJP approval through the same system. Once DJP approves the Nota Retur, both the seller’s output VAT and the buyer’s input VAT positions are adjusted in the respective Coretax ledgers.

The Nota Retur must contain specific mandatory information under PMK 81/2024: the Nota Retur number, the date the return was made, the name and NPWP of the seller PKP, the name and NPWP or NIK of the buyer, the number and date of the original e-Faktur, and the quantity and value of the returned goods with the corresponding VAT amount. Missing any mandatory field will cause the DJP approval process to fail.

The practical implication for sellers is that the adjustment of their output VAT following a goods return depends on actions taken by the buyer in the buyer’s system. A seller cannot force a buyer to create the Nota Retur, and a seller’s output VAT position remains unadjusted until the buyer’s Nota Retur is approved. This creates a new type of coordination risk in commercial relationships that did not exist in the old system.

Reconciling e-Faktur Data Against the Coretax Ledger

One of the most operationally important aspects of e-Faktur compliance under Coretax is the reconciliation between the company’s internal records and the pre-populated data that DJP’s system generates on the company’s behalf.

Under the Taxpayer Account Management function in Coretax, DJP’s system creates pre-populated entries for incoming invoices based on data received from the seller’s Coretax submissions. A PT PMA that purchases services from a PKP supplier will see a pre-populated input VAT entry in its Coretax account reflecting the supplier’s e-Faktur submission, before the buyer’s own finance team has matched the invoice to a purchase order or recorded it in the ERP. If the buyer’s internal records do not match the pre-populated Coretax data, the discrepancy must be resolved before the monthly VAT return is filed.

The Three Most Common Reconciliation Failures

Buyer data mismatch

The NPWP or company name in the seller’s Coretax submission does not match the buyer’s registered identity in DJP’s database. This may arise from the seller entering data manually rather than using Coretax’s pre-population function, or from the buyer’s DJP registration data being outdated relative to the name they use commercially. The result is an e-Faktur that cannot be matched to the buyer’s Coretax account and cannot be credited as input VAT.

Transaction code error

The most immediate consequence of a wrong transaction code is that the invoice appears in the wrong ledger category in the Coretax system, which creates a discrepancy between the buyer’s expected input VAT classification and what DJP has recorded. Correcting this requires a Faktur Pengganti with the bilateral confirmation process described above.

Timing gap between pre-populated data and internal booking

A supplier issues an e-Faktur in mid-March for services rendered in February. The buyer’s Coretax account shows the pre-populated entry in March. The buyer’s internal accounting has booked the accrual in February. The VAT period, the accounting period, and the e-Faktur period are three different months. Reconciling these requires clear period-mapping rules in the buyer’s internal processes, and filing the monthly VAT return using the Coretax pre-populated data as the reference, not the accounting accrual date.

For companies managing high volumes of e-Faktur transactions across multiple counterparties, the monthly reconciliation between internal ERP data and Coretax pre-populated entries is the single most operationally demanding aspect of VAT compliance. A discrepancy that is not resolved before the 30th of the following month, when both the VAT payment and the SPT Masa PPN are due, means filing on an inconsistency. The downstream consequences, including DJP cross-referencing the VAT return against the corporate income tax return under Coretax’s integrated data-matching function, are addressed in the annual tax reporting compliance guide for Indonesia, which covers how unresolved monthly VAT discrepancies become SP2DK triggers.

The Coretax Access Structure That Finance Teams Need to Understand

A company’s Coretax access operates through the director’s personal account using an impersonation feature, as XPND’s accounting article noted. This means the director must have a valid NPWP registered in Coretax, and for foreign national directors, a valid KITAS linked to that NPWP. A company whose director has not properly configured their Coretax access cannot fulfill the company’s e-Faktur issuance obligations through the standard portal, which creates operational dependency on the director’s personal tax registration being in order before the first invoice needs to be issued.

For companies with multiple authorized signatories or where the finance function is managed by an external provider, the delegation of Coretax access must be formally structured within the system. An accounting or tax compliance outsourcing firm that manages e-Faktur issuance, SPT Masa PPN filing, and reconciliation on behalf of a PT PMA does so through access that is properly configured within the company’s Coretax account structure, not through informal system sharing.

XPND’s tax compliance team manages the full e-Faktur cycle for PT PMA clients, covering issuance, correction workflows including Faktur Pengganti coordination with buyers, Nota Retur tracking where returns are pending, and monthly reconciliation of internal records against the Coretax pre-populated ledger before SPT Masa PPN submission.

Reach out to XPND’s tax compliance team to review your current e-Faktur issuance process and Coretax reconciliation workflow before a data mismatch accumulates into a VAT adjustment that cannot be corrected within the filing period.